Subject: [ippm] AD Evaluation for draft-ietf-ippm-2330-ipv6-03

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 29 Mar 2018 16:24:50 -0500

Dear IPPMers,

On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell <[email-masked]> wrote:

> Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03
> as Informational on behalf of the IPPM working group.
>
> Please verify the document's state at https://datatracker.ietf.org/
> doc/draft-ietf-ippm-2330-ipv6/

I've completed my AD Evaluation for this draft, and have a few questions.
These should be easy to resolve before I request Last Call for the draft.

Please let me know when you're ready to proceed.

Thanks for this draft.

Spencer

I wasn't quite sure what to make of this text:

  We further require that if a packet is described as having a "length
   of B octets", then 0 <= B <= 65535; and if B is the payload length in
   octets, then B <= (65535-IP header size in octets, including any
   Extension Headers).  The jumbograms defined in [RFC2675] are not
   covered by this length analysis.

Is the point that jumbograms aren't valid standard-form packets?

In this text,

  [RFC2330] defines the "minimal IP packet from A to B" as a particular
   type of standard-formed packet often useful to consider.  When
   defining IP metrics no packet smaller or simpler than this can be
   transmitted over a correctly operating IP network.  However, the
   concept of the minimal IP packet has not been used in the meantime
   and its practical use is limited.

I wonder if "in the meantime" is clear enough. Perhaps "since [RFC2330] was
published in 1998", or something like that? ("If it wasn't useful in the
first 20 years, it probably won't be useful in the next 20 years" :-)

I'm wondering if the upper-case "SHOULD" in

  If the information constituting Type-P at the Source is found to have
   changed at the Destination (or at a measurement point between the
   Source and Destination, as in [RFC5644]), then the modified values
   SHOULD be noted and reported with the results.

is consistent with the lower-case "must" in

  The definition and execution of measurements within the context of
   the IPPM Framework is challenged whenever such translation mechanisms
   are present along the measurement path.  In particular use cases like
   IPv4-IPv6 translation, NAT, protocol encapsulation, or IPv6 header
   compression may result in modification of the measurement packet's
   Type-P along the path.  All these changes must be reported.

? I'm also wondering if I should suggest https://tools.ietf.org/html/rfc8174
as the reference for requirements language, or ask for a scrub to ensure
that requirements language is consistent throughout the document.

This text
  Points that are worthwhile discussing further: handling of large
   packets in IPv6 (including fragment extension headers, PMTUD,
   PLPMTUD), extent of coverage for 6LO and IPv6 Header Compression, and
   the continued need to define a "minimal standard-formed packet".

didn't seem consistent with the previous mentions of "minimal
standard-formed packet", which I read as deprecating this concept. Does
this text say that concept might be coming back?

I didn't understand

  When considering privacy of those involved in measurement or those
   whose traffic is measured, the sensitive information available to
   potential observers is greatly reduced when using active techniques
   which are within this scope of work.

Was the point that people measuring traffic using active measurements know
pretty well what they sent, so privacy isn't a concern for those packets,
or is something else being talked about?

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 30 Mar 2018 16:11:29 +0000

Hi Spencer, please see replies in-line.
Thanks for your review!
Al

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, March 29, 2018 5:25 PM
To: Brian Trammell <[email-masked]>
Cc: Nevil Brownlee <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: AD Evaluation for draft-ietf-ippm-2330-ipv6-03

Dear IPPMers,

On Sun, Mar 4, 2018 at 4:06 PM, Brian Trammell <[email-masked]<mailto:[email-masked]>> wrote:
Brian Trammell has requested publication of draft-ietf-ippm-2330-ipv6-03 as Informational on behalf of the IPPM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ippm-2330-ipv6/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D2330-2Dipv6_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YxD_EfxF2WcKAaXXUc6HBO0nphy9V20c0u6ERnpdCnU&s=XZYIHllUkJIfs63MzV1Gf5Ro5fNJSiAACb7t2sEA4o4&e=>

I've completed my AD Evaluation for this draft, and have a few questions. These should be easy to resolve before I request Last Call for the draft.

Thanks for this draft.

Spencer

Is the point that jumbograms aren't valid standard-form packets?
[acm]
No, that IPv6 Jumbograms in 2675 can be eve longer!
from 2675:
   A "jumbogram" is an IPv6 packet containing a payload longer than
   65,535 octets.
Practical MTUs keep all this from becoming a point
of contention, as we explain.

In this text,

I wonder if "in the meantime" is clear enough. Perhaps "since [RFC2330] was published in 1998", or something like that? ("If it wasn't useful in the first 20 years, it probably won't be useful in the next 20 years" :-)
[acm]
I agree, we could explain that a little better.
How about:
However, the concept of the minimal IP packet has not been
employed (since typical active measurement systems employ a
transport layer and a payload) and its practical use is limited.
Therefore, this memo deprecates the concept of the "minimal IP packet from A to B".

? I'm also wondering if I should suggest https://tools.ietf.org/html/rfc8174<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8174&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YxD_EfxF2WcKAaXXUc6HBO0nphy9V20c0u6ERnpdCnU&s=_OA3PK0UONPj5S5lEiWwAB3K3uHjBtR4SITP5XkgKKE&e=> as the reference for requirements language, or ask for a scrub to ensure that requirements language is consistent throughout the document.
[acm]
Good catch, both the above need to be MUST.
I did a scrub of “must” and “should”, and fixed a few
cases.

This text

didn't seem consistent with the previous mentions of "minimal standard-formed packet", which I read as deprecating this concept. Does this text say that concept might be coming back?
[acm]
Ugh, This seems to be a list of open issues which we have addressed,
But somehow this text was left behind. Sorry!

I didn't understand

Was the point that people measuring traffic using active measurements know pretty well what they sent, so privacy isn't a concern for those packets, or is something else being talked about?
[acm]
Yes, even when users launch their own active measurement traffic,
the packets will bear their IP addresses and that’s unavoidable,
but no other sensitive info would normally appear.

I’ll push a revised version for authors to check shortly.
…

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 30 Mar 2018 16:55:04 -0500

Hi, Al,

> Hi Spencer, please see replies in-line.

I have one item below that I'm still not clear on, but I think we are in
sync everywhere else.

> Thanks for your review!
>
> Al
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* Thursday, March 29, 2018 5:25 PM
> *To:* Brian Trammell <[email-masked]>
> *Cc:* Nevil Brownlee <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> *Subject:* AD Evaluation for draft-ietf-ippm-2330-ipv6-03
>
>
>
> Dear IPPMers,
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2D2330-2Dipv6_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YxD_EfxF2WcKAaXXUc6HBO0nphy9V20c0u6ERnpdCnU&s=XZYIHllUkJIfs63MzV1Gf5Ro5fNJSiAACb7t2sEA4o4&e=>
>
>
>
> *[acm] *

Right, but what I'm not lacing together is

- I have an IPv6 packet with 65,536 bytes
- Let's say that It would be a valid standard-form packet if it was one
byte shorter
- am I understanding that it is not a valid standard-form packet?
- or is the point that we basically never see IPv6 jumbograms because they
would take up at least 40 maximum-length Ethernet packets, so we don't care
whether they would be valid standard-form packets if we ever did see one?

Thanks for clues,

Spencer

> I wonder if "in the meantime" is clear enough. Perhaps "since [RFC2330]
> was published in 1998", or something like that? ("If it wasn't useful in
> the first 20 years, it probably won't be useful in the next 20 years" :-)
>
> *[acm] *
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8174&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YxD_EfxF2WcKAaXXUc6HBO0nphy9V20c0u6ERnpdCnU&s=_OA3PK0UONPj5S5lEiWwAB3K3uHjBtR4SITP5XkgKKE&e=>
> *[acm] *
> *[acm] *
> *[acm] *