Skip to main content

Initial Performance Metrics Registry Entries


No Objection

(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Suresh Krishnan)

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

Roman Danyliw
No Objection
Comment (2019-12-04 for -14) Sent
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/]
Warren Kumari
No Objection
Comment (2019-12-03 for -14) Not sent
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 :-)

Abstract - 'The set includes, UDP Round-trip Latency and Loss, ...' -> 'The set includes: UDP Round-trip Latency and Loss, ...'
Éric Vyncke
(was Discuss) No Objection
Comment (2019-12-03 for -14) Sent
Thank you for the work put into this document. 

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




-- 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).


-- Section 4.2.2 -- and others

Should some additional parameters be specified for IPv6? Namely flow label and the absence of extension header.
Mirja Kühlewind Former IESG member
Yes (2019-12-03 for -14) Not sent
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:"

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!
Adam Roach Former IESG member
No Objection
No Objection (for -14) Not sent

Alexey Melnikov Former IESG member
No Objection
No Objection (for -14) Not sent

Alissa Cooper Former IESG member
No Objection
No Objection (for -14) Not sent

Alvaro Retana Former IESG member
No Objection
No Objection (2019-12-03 for -14) Sent
I have a significant issue related to the approval of this initial registry, and then a minor point.

(1) This is the significant issue:


   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.
Barry Leiba Former IESG member
No Objection
No Objection (for -14) Not sent

Benjamin Kaduk Former IESG member
(was Discuss, No Record, Discuss) No Objection
No Objection (2019-12-11 for -15) Sent
Thank you for addressing my Discuss points!
Deborah Brungard Former IESG member
No Objection
No Objection (for -14) Not sent

Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2019-12-12 for -15) Sent
Thanks for addressing both my discuss and comment
Martin Vigoureux Former IESG member
No Objection
No Objection (2019-12-03 for -14) Sent
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
Is that on purpose?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -14) Not sent