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.