Subject: [Gen-art] Genart last call review of draft-ietf-ippm-2330-ipv6-04

From: Francesca Palombini <[email-masked]>
Date: Mon, 23 Apr 2018 03:44:37 -0700

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-2330-ipv6-??
Reviewer: Francesca Palombini
Review Date: 2018-04-23
IETF LC End Date: 2018-04-25
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: None

Minor issues: None

Nits/editorial comments:

Please note that most of the following comments are suggestions to make the
text more clear in my opinion. Feel free to disregard or fix as you prefer.

* Section 3:

    "For example Neighbor Discovery
    Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value
    set to 255, and the validity test specifies that the Hop Limit MUST
    have a value of 255 at the receiver, too.  So, while other tests may
    intentionally exclude the TTL/Hop Limit value from their Type-P
    definition, for this particular test the correct Hop Limit value is
    of high relevance and MUST be part of the Type-P definition."

Regarding the use of MUST: The text above is not an absolute requirement of the
specification, but rather an example to a referenced document. In my opinion,
using "must" would be ok here.

(About MUST, was there any specific reason not to use the updated boilerplate
referencing RFC8174?)

* Section 3:

    "Load balancing over parallel paths is one particular example where
    such a class C would be more complex to determine in IPPM
    measurements."

I would have appreciated a reference to a load balancing over parallel paths
example.

* Section 4:

    "For an IPv4 ( [RFC0791] and updates) packet to be standard-formed,
    the following additional criteria are REQUIRED:"

    "For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the
    following criteria are REQUIRED:"

To be consistent with the first bullet of the list above ("It includes a valid
IP header: see below for version-specific criteria."), I would rephrase the
text above with something on the lines of:

"For an IPvX (...) packet to be standard-formed, the IPvX-specific criteria for
a valid IP header are:"

Also, note the space before "[RFC0791] and updates)"

* Section 4:

    "An adaptation
    layer enables the transfer IPv6 packets over networks having a MTU
    smaller than the minimum IPv6 MTU."

NEW: "An adaptation
layer enables the transfer of IPv6 packets over networks having a MTU
smaller than the minimum IPv6 MTU."

* Section 5:

    "All these changes MUST be reported."

I'd like more clarity on where they should be reported: does this mean they
MUST be reported when reporting the test results? Or on test spec? Either? Both?

* From id-nits check:

     (Using the creation date from RFC2330, updated by this document, for
     RFC5378 checks: 1998-02-23)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

     IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
        This document may contain material from IETF Documents or IETF
        Contributions published or made publicly available before
        November 10, 2008.  The person(s) controlling the copyright in
        some of this material may not have granted the IETF Trust the
        right to allow modifications of such material outside the IETF
        Standards Process. Without obtaining an adequate license from the
        person(s) controlling the copyright in such materials, this
        document may not be modified outside the IETF Standards Process,
        and derivative works of it may not be created outside the IETF
        Standards Process, except to format it for publication as an RFC
        or to translate it into languages other than English.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 26 Apr 2018 00:28:23 +0000

Thanks for your review and Editorial Comments, Francesca.

Please see replies in-line, [acm]
Al

> -----Original Message-----
> From: Francesca Palombini [mailto:[email-masked]]
> Sent: Monday, April 23, 2018 6:45 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Genart last call review of draft-ietf-ippm-2330-ipv6-04
> 
> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=VJKwYLLgC5yVNhjtEl5IagVCTZdnL
> 5-8_ofLX0lkl54&s=yI6g6zIDh7aVNRTNNRsgn5AJ_Rv4xO3uavDu5vWO3o8&e= >.
> 
[acm] 
We're helping the reader to search for requirements
by using MUST, albeit a referenced requirement.

> (About MUST, was there any specific reason not to use the updated
[acm] 
You mean the Requirements Language RFC has been updated?
News to me.  Will fix. Seems like the Nits check should catch that.
Also, it can't be 8174 alone, the definitions of the terms has not changed.
 
> I would have appreciated a reference to a load balancing over parallel
> paths example.
[acm] 
ECMP is a rather well-known circumstance in IP networking today,
as are other forms of load balancing, but I don't know of a 
canonical reference.
 
> "For an IPvX (...) packet to be standard-formed, the IPvX-specific
[acm] 
Your wording suggestion dropped the clear indication of a requirement.
We are using the RFC2119 terms consistently for requirements.

> Also, note the space before "[RFC0791] and updates)"
[acm] 
fixed.

>    smaller than the minimum IPv6 MTU."
[acm] 
added "of"
> MUST be reported when reporting the test results? Or on test spec? Either?
[acm] 
Yes, reported with the test results, this is a testing framework.
2330 makes the context clear. Added "with the test results"
>      https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__trustee.ietf.org_license-2Dinfo&d=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=VJKwYLLgC5yVNhjtEl5IagVCTZdnL
> 5-8_ofLX0lkl54&s=pPcdsrj7ZX8s_-XuhHUONGmdrq6xHXpqqPL4gHbAtW4&e=  for more
> information.)
> 
[acm] 
We can add the pre-5378 disclaimer as a catch-all, but I doubt the original 
authors would make any fuss about the small amount of common text with 2330.
Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their time.

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 27 Apr 2018 07:43:54 +0000

Hi Al,

Thanks for your reply.
I cut selected parts of the email to detail some of my comments, see inline. 

Francesca

> > (About MUST, was there any specific reason not to use the updated
> > boilerplate referencing RFC8174?)
> >
> [acm]

I think it does for Standard track docs.
Yes, I did mean the boilerplate that *also* references RFC8174 (which you can find in RFC8174) :) 

> ECMP is a rather well-known circumstance in IP networking today, as are
> other forms of load balancing, but I don't know of a canonical reference.
>

Ok. (This was just for my -or a generalist reader- sake, since I am not very knowledgeable in the area)

> > To be consistent with the first bullet of the list above ("It includes
> > a valid IP header: see below for version-specific criteria."), I would
> > rephrase the text above with something on the lines of:
> >
> > "For an IPvX (...) packet to be standard-formed, the IPvX-specific
> > criteria for a valid IP header are:"
> [acm]

I was trying to point out that the first part of the section (first bullet list) does not use RFC2119 terms. I read the second bullet list as a "sub-list" of the first one, which is why I was suggesting removing the REQUIRED term. Or you could rephrase the first list to use REQUIRED too. Anyway, this is nit-picking. Feel free to disregard.

> Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their

I'm sure they are :) Just relaying what the id-nits told me.