Hi, all,
On 6/2/2012 9:21 PM, C. M. Heard wrote:
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.
That's much better, IMO.
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".
Sure.
>> 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).
I'll check. I'm not sure if it matters whether I do a rev inbetween IETF
LC and final RFC Editor processing. If so, I'll check on this to see if
it can be done with minimal content impact (maybe some fluff to explain
the flow, but no semantic changes).
Joe