Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Hi Tommy,
I support the publication of this document. It is well-written and, when
published, become an essential component of industry-wide work on defining
the IP Maximum Capacity metric and its measurement methodology.

Dear Authors,
thank you for this work. I have several questions and a number of editorial
suggestions that you might find useful. I greatly appreciate your
consideration of the comments below:

   - Is this document intended to update an RFC? The first page suggests
   that you have thought about that but have not yet pointed to the RFC to be
   updated. If you decide that the new document does update the existing RFC,
   you may note that also in the Abstract.
   - The document uses a significant number of acronyms that probably are
   not well-known at IETF, e.g., RTD, RTL, etc. I think that adding a
   sub-section Acronyms will be helpful to a reader.
   - A number of references don't work as links, e.g., "[ refs to ITU-T
   SG12, ETSI STQ, BBF liaisons ]". Also, several sections are references by
   title, e.g., "[see section Related Round-Trip Delay and Loss Definitions
   below]", and that makes finding the right place more challenging.
   - In Section 4 a source IP address of a host accompanied with a note
   "such as the globally routable IP address". Should the note be
   interpreted as an example or as a normative statement?
   - Section 4 defines dt as "dt, the duration of N equal sub-intervals in
   I (default 1 sec)". But further in the document, on two occasions, it is
   noted that "all sub-intervals SHOULD be of equal duration". If dt MAY be of
   varying duration, then the definition in Section 4 might be changed to "dt,
   the duration of N sub-intervals in I (default 1 sec)". On the other hand,
   if that definition is interpreted as normative, then s/SHOULD/MUST/2.
   - It is not obvious whether "Note that the UDP transport layer is one
   requirement specified below." applies to the test protocol or something
   else.
   - Also, in Section 4, the last sentence notes that

   Note that time stamps, sequnce numbers, etc. will be established by

   the test protocol.

Perhaps that may be put as a requirement for the test protocol.

   - Security Consideration section references RFC 4656 OWAMP and RFC 5357
   TWAMP. Do you think that adding references to RFC 8672 STAMP and
   draft-ietf-ippm-stamp-option-tlv, as STAMP and its extensions, might be
   used as the protocol to measure the IP Capacity, is helpful?
   - I think that the requirement to provide control of the number of
   concurrent test sessions can be stronger, as the rate-limiting requirement,
   than a recommendation. The requirement is more applicable to the test
   protocol that MUST provide control over the number of simultaneous test
   sessions.

Several nits:

   - s/[copycat
   <https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-03#ref-copycat>
   ][copycat]/[copycat]/
   -  s/sequnce/sequence/
   - A reference in "Type-P is a parallel concept to "population of
   interest" defined in ITU-T Rec. Y.1540." will be helpful.
   - I assume that in "T, the host time of the *first* test packet's
   *arrival* as measured at MP(Dst)", MP stands for Measurement Point. Is that
   correct?
   - Capitalization in "Target performance threshold" throughout the
   document needs consistency, on several occasions, it is used as "target
   performance threshold".

Regards,
Greg

On Fri, Aug 14, 2020 at 2:21 PM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> Hello IPPM,
>
> As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is
> stable, and the group felt it is ready for Working Group Last Call.
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02
>
> The last call will end on *Wednesday, September 2*. Please reply to
> ippm@ietf.org with your reviews and comments, and indicate if you think
> the document is ready to progress!
>
> Best,
> Tommy & Ian
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>