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

From: Ted Hardie <[email-masked]>
Date: Tue, 6 Mar 2012 18:06:44 -0800

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]

---

From: Joe Touch <[email-masked]>
Date: Wed, 07 Mar 2012 07:40:25 -0800

Hi, Ted,

Thank you for your comments. Some clarifications below.

Joe

> are fragmented or which may later be fragmented.

The equations are intended to be pseudocode, to define atomicity in 
terms of specific tests on IP header fields. This helps clarify the 
interpretation of the English definition to help coders. We can clarify 
that by replacing "mathematical expression" with "pseudocode".

Would that clarify the utility of the expressions? Should we also 
explain the rationale for including them in a single sentence?

> IPv4 IDs on atomic datagrams seems potentially useful.

Yes, thanks for pointing that out.

> perhaps some additional context is needed?

We could change that to "less efficient. Such non-changing IDs have been 
described in various RFCs (e.g., footnote 21 of [RFC1144 and cRTP 
[RFC2508])."

Would that be more clear?

---

From: Ted Hardie <[email-masked]>
Date: Wed, 7 Mar 2012 11:26:02 -0800

Hi Joe,

Thanks for your quick reply; comments in-line.

On Wed, Mar 7, 2012 at 7:40 AM, Joe Touch <[email-masked]> wrote:
> The equations are intended to be pseudocode, to define atomicity in terms of
> specific tests on IP header fields. This helps clarify the interpretation of
> the English definition to help coders. We can clarify that by replacing
> "mathematical expression" with "pseudocode".
>
> Would that clarify the utility of the expressions? Should we also explain
> the rationale for including them in a single sentence?
>

If you will retain them, I think it should be stated more explicitly
that the expressions are simply a restatement of the textual
definitions.  Perhaps:

OLD:

Atomic datagrams: datagrams not yet fragmented (MF=0 and fragment
      offset=0) and for which further fragmentation has been inhibited
      (DF=1), i.e., as a mathematical expression (equals is ==, logical
      'and' is &&, logical 'or' is ||, greater than is >, logical 'not'
      is ~, and parenthesis function typically):

         (DF==1)&&(MF==0)&&(frag_offset==0)

   o  Non-atomic datagrams: datagrams which have either already been
      fragmented, i.e.:

         (MF=1)||(frag_offset>0)

      or for which fragmentation remains possible:

         (DF==0)

      I.e., non-atomic datagrams can be expressed in two equivalent
      tests:

         (DF==0)||(MF==1)||(frag_offset>0)

      which can also be expressed as follows, using DeMorgan's Law and
      other identities:

         ~((DF==1)&&(MF==0)&&(frag_offset==0))

      Note that this final expression is the same as "not(atomic)".

NEW:

Atomic datagrams are datagrams not yet fragmented and for which
further fragmentation has been inhibited.

Non-atomic datagrams are datagrams which either have already been
fragmented or for which fragmentation remains possible.

This same definition can be expressed in pseudo code as using common
logical operators (equals is ==, logical 'and' is &&, logical 'or' is
||, greater than is >, logical 'not' is ~, and parenthesis function
typically) as:

atomic datagrams:   (DF==1)&&(MF==0)&&(frag_offset==0)

non-atomic datagrams:   (DF==0)||(MF==1)||(frag_offset>0)

<cut>
> Would that be more clear?

Yes, that's clearer,

thanks,

Ted Hardie

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Mar 2012 09:56:49 -0800

Hi, Ted,

Agreed on your suggested change - thanks!

Please let me know - and I'll also check with the ADs - whether these 
changes require a revision before proceeding or can be handled during 
AUTH48.

Joe

On 3/7/2012 11:26 AM, Ted Hardie wrote:
> On Wed, Mar 7, 2012 at 7:40 AM, Joe Touch<[email-masked]>  wrote:
>>
>        'and' is&&, logical 'or' is ||, greater than is>, logical 'not'
> logical operators (equals is ==, logical 'and' is&&, logical 'or' is
> ||, greater than is>, logical 'not' is ~, and parenthesis function
> typically) as:
>

That works much better - thanks!

---

From: Ted Hardie <[email-masked]>
Date: Thu, 8 Mar 2012 10:53:42 -0800

> changes require a revision before proceeding or can be handled during

I personally think these changes would be fine in AUTH48.  Thanks
again for your quick responses to the review.

regards,

Ted