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:[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
