Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ippm-2679-bis-03

[Spencer Dawkins at IETF <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
>>> Sent: Friday, July 31, 2015 3:45 AM
>>> To: [e-mail]; 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.
>>
>>