Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05

[Joe Touch <[e-mail]>]

Hi, Eliot,

On Jun 2, 2012, at 6:00 AM, Eliot Lear wrote:

> 
> Document: draft-ietf-intarea-ipv4-id-update-05
> Title: Updated Specification of the IPv4 ID Field
> Reviewer: Eliot Lear
> Review Date: 2 June 2012
> IETF Last Call Date: 31 May  2012
> 
> 
> Summary: This draft is quite well written, and is very nearly ready for publication.
> 
> This draft is well written, and from the applications perspective represents an important step to improving performance and error reduction.  It uses a new requirements call-out style that I would class as experimental, but not bad.  It is worth people reading this draft and deciding if they agree with Joe's approach.
> 
> Major issues:
> 
> None (Yay!).
> 
> Minor issues:
> 
> Section 4 needs to be reconciled a bit with Section 6.1.  Specifically:
> 
>>  The IPv4 ID field can be useful for other purposes. 
> 
> 
> And
> 
>   >> IPv4 ID field MUST NOT be used for purposes other than
>    fragmentation and reassembly.
> 
> 
> My suggestion is to drop the above sentence from Section 4.

The two are not contradictory - the ID can be useful, but generating it correctly is prohibitive and typically not done.

> In Section 6.1:
> 
> 
>>    Datagram de-duplication can be accomplished using hash-based
>>    duplicate detection for cases where the ID field is absent.
>> 
> 
> Under what circumstances would the ID field be absent?

Replace "absent" with "known not unique".

>>    >> Sources of non-atomic IPv4 datagrams using strong integrity checks
>>    MAY reuse the ID within MSL values smaller than is typical.
>> 
> 
> Is the issue really the source using strong integrity checks or the destination in this context?  What is typical?

The onus is on the source (of non-atomic datagrams) - if it includes strong integrity checks (that are presumably validated by the receiver), it then has more flexibility in its generation of the iD values.

> Nit:
> 
> Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3?

Not subsections of 2, but perhaps "3, 3.1, 3.2"? 

Joe