[apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update

Ted Hardie <ted.ietf@gmail.com> Wed, 07 March 2012 02:06 UTC

MIME-Version: 1.0
Date: Tue, 06 Mar 2012 18:06:44 -0800
Message-ID: <CA+9kkMB19wok5S=ag0r-z3X0DWTCYdkeDTURgXZPKs8_i-QUyA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IESG <iesg@ietf.org>
Subject: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update
Precedence: list

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-intarea-ipv4-id-update-04
Reviewer:Ted Hardie
Review Date:March 6, 2012


Summary:

There are some areas which would benefit from clarification, but no
major issues.

Major Issues: [list any major issues such as security concerns,
preferably by section number]

No Major issues.

Minor Issues: [list any minor issues such as text that is unclear or
confusing, preferably by section number]

In section 6, the inclusion of the mathematical expression for which
datagrams were atomic vs. non-atomic did not seem to add anything to
the clarity of the surrounding text.  By introducing several
abbreviations and reviewing the logical operators, it seemed to
complicate what appeared to be a very clear statement:  Atomic
datagrams are those which are not fragmented now and for which later
fragmentation is inhibited; non-atomic datagrams are those that either
are fragmented or which may later be fragmented.

In section 6.1, the document states:

  Duplicate suppression was only suggested [RFC1122], and no impacts of IPv4 ID
  reuse have been noted.

Deduplication is often listed as a feature of "wan accelerator"
devices.  It might be useful to include these
devices in the list of middleboxes in section 9.  Advice to update the
behaviors of those devices to ignore
IPv4 IDs on atomic datagrams seems potentially useful.

In section 10, the document states:

When compression assumes a changing ID as a default, having a non-
   changing ID can make compression less efficient (see footnote 21 of
[RFC1144] or
  cRTP [RFC2508]).

The text of footnote 21 is:

   Note that the test here is against one, not zero.  The packet ID is
   typically incremented by one for each packet sent so a change of zero is
   very unlikely.  A change of one is likely:  It occurs during any period
   when the originating system has activity on only one connection.

I was expecting the footnote to contain data that referred to
compression efficiency;
perhaps some additional context is needed?

Nits: [list editorial issues such as typographical errors, preferably
by section number]

[apps-discuss] APPS directorate review of ietf-in… Ted Hardie
Re: [apps-discuss] APPS directorate review of iet… Joe Touch
Re: [apps-discuss] APPS directorate review of iet… Ted Hardie
Re: [apps-discuss] APPS directorate review of iet… Joe Touch
Re: [apps-discuss] APPS directorate review of iet… Ted Hardie