Re-sending to include IPPM-list (not in .all alias) to give the full context:
> -----Original Message----- > From: MORTON, ALFRED C (AL) > Sent: Sunday, August 02, 2015 2:45 PM > To: 'Brian E Carpenter'; [email protected]; General > Area Review Team > Subject: RE: Gen-ART Last Call review of draft-ietf-ippm-2679-bis-03 > > 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
