And, for what it's worth, the responsible AD agrees with what Brian and Al are cooking up, for this draft and for RFC2680bis.
Spencer On Mon, Aug 3, 2015 at 9:02 AM, Guy Almes <gal...@tamu.edu> wrote: > Al, > I very much agree on moving toward treating IPv6 fully as these evolve. > -- Guy > > > On 8/2/15 1:45 PM, MORTON, ALFRED C (AL) wrote: > >> Hi Brian, >> >> Thanks for your review. >> Please see replies and proposed resolutions below. >> >> regards, >> Al >> >> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >>> Sent: Friday, July 31, 2015 3:45 AM >>> To: draft-ietf-ippm-2679-bis....@ietf.org; 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
