Ballot for draft-ietf-ippm-initial-registry
Yes
No Objection
Note: This ballot was opened for revision 14 and is now closed.
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/]
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, ...'
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.
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!
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.
Thank you for addressing my Discuss points!
Thanks for addressing both my discuss and comment
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?