Hi Brian, Thanks for your review. Please see replies and proposed resolutions below.
regards, Al > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Friday, July 31, 2015 3:45 AM > To: [email protected]; General Area Review Team > Subject: Gen-ART Last Call review of draft-ietf-ippm-2679-bis-03 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-ippm-2679-bis-03.txt > Reviewer: Brian Carpenter > Review Date: 2015-07-31 > IETF LC End Date: 2015-08-11 > IESG Telechat date: > > Summary: Ready with issues > -------- > > Major issue: > ------------ > > The draft does not mention the IP version. RFC 2330 states that it > applies to IPv4 only (section 15) and uses terminology that only applies > to IPv4. At the very minimum, the current draft needs to state its > limited applicability. I would be much happier if it explained how it > applies to IPv6. [ACM] In this update, we added an explicit reference to Section 15 of RFC 2330 on the requirements for standard-formed packets (note: most, but not all, usage of "standard-formed" in RFC2330 is hyphenated). I suggest that we note the limitation of the current reference in the text: + The packet is standard-formed, the default criteria for all metric definitions defined in Section 15 of [RFC2330], otherwise the packet will be deemed lost. Note: At this time, the definition of standard-formed packets only applies to IPv4. Further, I propose that we begin the process of updating this section of RFC 2330 immediately. This way, the IPv6 coverage will extend to all IPPM RFCs, especially RFC2680bis which is also in IETF Last Call. > > Minor issues: > ------------- > > In sections 3.6 and 3.8.1 there are passing references to the diffserv > code point. I think that the ECN bits should be mentioned too: their > setting could also affect router processing time. ECN is a bit tricky as > it might change on the fly. [ACM] So can DSCP if the packet is re-marked, as you know well. We can mention ECN in section 3.8.1 (the original text referred to the TOS field, so what you read was already updated), with further revisions below: The value of Type-P-One-way-Delay could change if the protocol (UDP or TCP), port number, size, or arrangement for special treatment (e.g., IP DS Field [RFC2780], ECN [RFC3168] or RSVP) changes. The exact Type-P used to make the measurements MUST be accurately reported. But... > > Along the same lines, should Router Alert be mentioned? And for IPv6 > applicability, any hop-by-hop options should certainly be mentioned. [ACM] RFC 2330, Section 13 says: A fundamental property of many Internet metrics is that the value of the metric depends on the type of IP packet(s) used to make the measurement. ... < some IPv4-centric examples, then > ... Because of this distinction, we introduce the generic notion of a "packet of type P", where in some contexts P will be explicitly defined (i.e., exactly what type of packet we mean), partially defined (e.g., "with a payload of B octets"), or left generic. If we seek to identify several more distinctions for "packets of Type-P", then I would prefer to update the RFC 2330 Framework Section 13 on this topic, so it's more widely applicable and less IPv4-centric. I'll take immediate steps to accomplish this update. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
