Updated Specification of the IPv4 ID Field
draft-ietf-intarea-ipv4-id-update-07

I understand why this document was written, and support the intent of clarifying what is really in the wild. Furthermore, such documentation will facilitate future interoperability and stability.

My concern was that this change in definition of the specification would impact existing deployed implementations that depended on or used other interpretation of the ID. I am persuaded that there is such a significant base of implementations that already act according to what is described in this new document that "old" implementations would already be experiencing interoperability problems. 

Thus, I support this work. 
(I look forward to the revision that adds clarification of this point)

I share Stewart's concern about the lack of data to support this document. The document does not have a section on how current implementations actually do this, and that lack is worrying. (The shepherd writeup has *no* information on implementation, and that's a problem. The shepherd should have asked.) All things being equal, I would have silently balloted "No Objection", but I given his comments, I do support Stewart's DISCUSS.

Thank you for addressing my Discuss and Comment points.

In section 8.3's update to RFC2003, consider saying "as permitted by RFCXXXX" instead of "as permitted by this document" to avoid any chance that someone would misinterpret "this document" to mean RFC2003.

As noted in Steve Kent's secdir review, the security considerations section should indicate whether the change proposed in this document may adversely affect availability, if middleboxes are not updated to account for this change.

Minor comments, feel free to take 'em or leave 'em. 

(Updated: I'd forgotten to note the secdir review.)

- A reference for a hash-based de-duplication scheme mentioned
in 6.1 might be useful, even if only as an illustration.

- The reference to SEAL (RFC 5320) is a bit unclear.  You have
a "SHOULD verify integrity" requirement but then say "as in
SEAL." I'm not clear if you're saying that SEAL is a SHOULD,
and if you are, then would that be ok? (SEAL being an
experimental RFC.) I assume that you don't mean SEAL is a
SHOULD-implement though, and since its given as an example in
the next para, I think you could delete the reference from the
SHOULD requirement bullet in section 7.

- The discussion of entropy in section 11 is a little opaque,
you could say why the entropy of a datagram is interesting. (Is
it that people sometimes use datagram fields to seen PRNGs?).
Steve Kent's secdir review [1] also suggested maybe changing
or removing this.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03358.html


- Typo: s/now adds much less entropy of the header/ now adds
much less to the entropy of the header/?

The authors have addressed my original concerns largely by providing better context for their proposed changes and thus I am clearing my discuss.

There is however one other concern that I am trying to get my head around, but as I am unable to fully articulate it, and as I did not pick this up the first time I only log it is only a comment. I leave it to the Author/AD to decide what action (if any) to take.

Although it is an axiom of IP networking that packets may be misordered, this is, at least in most networks, a very rare event. Routers work hard not to re-order packets, and networks are normally very stable. Thus de facto packets normally arrive strictly in order, and almost  emulate a circuit switch in this regard. Hence the constant ID value is not, in practice, of any great importance. Re-ordering really only arises during a routing (or virtual physical layer) event. When a failure occurs, the normal case is (a) a number of packets are often lost and (b) the outage is normally long compared to the inter-fragment pair delay. Even so the normal case is that the new path is longer than the old path, the application is normally disrupted by packet lost, but if not, order is usually maintained anyway. What is interesting is the case where we shorten the outage time through fast reroute and the new path is shorter, here I would expect to see occasional misordering of fragments. Note that you may also get a misorder when the path is restored because the restored path is usually shorter and less congested than the path in use at that point, but most routing networks handle restoration in much the same way as outage and one may well see packet loss that disrupts the application.

The text is silent on the issue of the interaction between the IP layer and the routing layer and the transport network (virtual physical) layer, but I think it likely that those systems that use constant ID are largely saved by the in-order and reliability properties of modern networks, with reassembly errors that are so rare they are usually passed off as something else.

It is possibly worth some text on this layer interaction since we rarely consider it much, and it might be useful if the reader interested in the IP layer was reminded of the properties of the packet path provided by the network layer process and of the virtual physical layers we now use.