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.
