Initial Performance Metrics Registry Entries
draft-ietf-ippm-initial-registry-16

Note: This ballot was opened for revision 14 and is now closed.

(Mirja Kühlewind) Yes

Comment (2019-12-03 for -14)
No email
send info
Please be aware of the following note in the IANA section of draft-ietf-ippm-metric-registry-22 (which might simply reviewing):

"Mock-ups of the implementation of this set of requests
   have been prepared with IANA's help during development of this memo,
   and have been captured in the Proceedings of IPPM working group
   sessions.  IANA is currently preparing a mock-up.  A recent version
   is available here: http://encrypted.net/IETFMetricsRegistry-106.html"

Also as draft-ietf-ippm-metric-registry defines the registry that this draft specifies initial values for, it makes sense to review draft-ietf-ippm-metric-registry first!

Deborah Brungard No Objection

Alissa Cooper No Objection

Roman Danyliw No Objection

Comment (2019-12-04 for -14)
Trivial editorial nits:
- Section 4.4.4.  s/*available accuracy*/available accuracy/
- Section 4.5.2. s/This RFC numner/This RFC number/
- Section 7.5.2. s/This REFC number/This RFC number/
- Section 10.5.2. s/This RFC/This RFC number/
- Section 10.3.1.  s/with[Strowes]/with [Strowes/]

Benjamin Kaduk (was Discuss, No Record, Discuss) No Objection

Comment (2019-12-11 for -15)
Thank you for addressing my Discuss points!

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-12-03 for -14)
No email
send info
Meta comment: Next time a document like this is produced, I think it would be very helpful to have something like a "tag" (e.g: '{IANA}') to help the IANA find all of the sections where they need to take action / make an edit -- this document (unsurprisingly!) has many places where edits are needed (e.g: 'YYYY-MM-DD') it is seems possible that one will be missed.

I found the example registry helpful, thanks! Also, props to Eric for catching the Ipv6 codepoint issues :-)

Nits: 
Abstract - 'The set includes, UDP Round-trip Latency and Loss, ...' -> 'The set includes: UDP Round-trip Latency and Loss, ...'

Barry Leiba No Objection

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

Comment (2019-12-03 for -14)
I have a significant issue related to the approval of this initial registry, and then a minor point.

(1) This is the significant issue:

§2:

   This document defines the initial set of Performance Metrics Registry
   entries, for which IETF approval (following development in the IP
   Performance Metrics (IPPM) Working Group) will satisfy the
   requirement for Expert Review.  Most are Active Performance Metrics,
   which are based on RFCs prepared in the IPPM working group of the
   IETF, according to their framework [RFC2330] and its updates.

s/IETF approval/IESG Approval     
There is no "IETF approval" policy in rfc8126.

Even though it is self-serving for this document to provide guidance on the approval for the new registry entries, I think that it should be possible to do so using IESG Approval given that these initial entries into the new registry have been reviewed by the WG.  However, draft-ietf-ippm-metric-registry only explicitly talks about using Specification Required (including Expert Review), and it makes no exceptions.

This document should not make statements about criteria used for this initial registration, so §2 should be deleted.

draft-ietf-ippm-metric-registry should be explicit about the initial population of the registry.  I am them balloting DISCUSS on that other document to address the approval of the initial registry entries in this document.


(2) Minor point:

§1: "The process in [I-D.ietf-ippm-metric-registry] also requires that new entries are administered by IANA through Expert Review or IETF Standards action, which will ensure that the metrics are tightly defined."   The registration policy defined in I-D.ietf-ippm-metric-registry is "Specification Required", which requires the review of an expert.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Comment (2019-12-03 for -14)
Thank you for this document.

I only have one question:

Sections 4.3.3, 6.3.3., 9.3.3., and 10.3.3 seem to have kept the text from the template:
   The measured results based on a filtered version of the packets
   observed, and this section provides the filter details (when
   present).
Is that on purpose?

Éric Vyncke (was Discuss) No Objection

Comment (2019-12-03 for -14)
Thank you for the work put into this document. 

Thank you for quickly addressing my previous DISCUSS (kept here for history)

Regards,

-éric

== DISCUSS ==

-- Section 4.2.2 --
Easy to fix: there is no 'protocol' field in the IPv6 header but a 'next header' one that has the same semantic.

-- Section 9.2.2. --
Also easy to fix, 'next header' for ICMPv6 is not 01 but 58 (decimal) and 'ICMPv6 echo request' is 128 (decimal).

== COMMENTS ==

-- Section 4.2.2 -- and others

Should some additional parameters be specified for IPv6? Namely flow label and the absence of extension header.

Magnus Westerlund (was Discuss) No Objection

Comment (2019-12-12 for -15)
Thanks for addressing both my discuss and comment