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

[Guy Almes <[e-mail]>]

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.
>