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