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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Thanks for your review and Editorial Comments, Francesca.

Please see replies in-line, [acm]
Al

> -----Original Message-----
> From: Francesca Palombini [mailto:[e-mail]]
> Sent: Monday, April 23, 2018 6:45 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Genart last call review of draft-ietf-ippm-2330-ipv6-04
> 
> 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://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= >.
> 
> 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.
> 
[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
> boilerplate
> referencing RFC8174?)
>
[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.
 
> * 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.
[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.
 
> 
> * 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:"
[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.

> 
> * 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."
[acm] 
added "of"
> 
> * 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?
[acm] 
Yes, reported with the test results, this is a testing framework.
2330 makes the context clear. Added "with the test results"
> 
> * 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://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.)
> 
>      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.
> 
[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.