Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
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. 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? 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? Nit: Shouldn't Sections 3, 4, and 5, really be Sections 2.1, 2.2, and 2.3? Eliot
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
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
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 02:05 , Klaas Wierenga wrote: On 5/31/12 10:58 AM, Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. As a non-native speaker I agree. I think colloquial is fine. The one thing causes me some trouble is all the references that Americans make to sports that nobody in the civilized world cares about ;-) (left field, Hail Mary passes If the Congregatio a Sancta Cruce hadn't come to North America from Le Mans France and specifically to South Bend Indiana there would be no Hail Mary.
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
On Sat, 2 Jun 2012, Joe Touch wrote: 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. FWIW, I thought it was helpful. 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. After re-reading the text I agree with Eliot that it is confusing. Dropping the sentence in Section 4 would be fine. Another possibility would be to reword it along the following lines: Other uses have been envisioned for the IPv4 ID field. 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. Better, I think, would be not known to be 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? That would be fine but I'm also OK with leaving the document the way it is (especially if it would get it into the publication queue faster). //cmh
Re: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
On Sat, 2 Jun 2012, Masataka Ohta wrote: Existing routers, which was relying on ID uniqueness of atomic packets, are now broken when they fragment the atomic packets. Such routers were always broken. An atomic packet has DF=0 and any router fragmenting such a packet was and is non-compliant with the relevant specifications (RFCs 791, 1122, 1812). //cmh
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: ... 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. Better, I think, would be not known to be unique. Except that the two are not semantically equivalent. ...
Re: [Int-area] Apps Directorate Review of draft-ietf-intarea-ipv4-id-update-05
On Sun, 3 Jun 2012, Glen Zorn wrote: On Sat, 2012-06-02 at 21:21 -0700, C. M. Heard wrote: ... 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. Better, I think, would be not known to be unique. Except that the two are not semantically equivalent. Indeed. That was why I suggested the change. //cmh
