Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22: (with DISCUSS and COMMENT)

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

Hi Alvaro,

Thanks for your review and comments. 

Please see replies marked [acm] below,
Al

> -----Original Message-----
> From: Alvaro Retana via Datatracker [mailto:[e-mail]]
> Sent: Tuesday, December 3, 2019 5:37 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Alvaro Retana's Discuss on draft-ietf-ippm-metric-registry-22:
> (with DISCUSS and COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-ippm-metric-registry-22: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=EtTYlWuZoXD0BCznVTc0bk6Y3qChy
> oUO9dp0prUdtp0&s=v3ONAc_XSQinjyxQv6WtNdhAF5xxs0vstrGaYRWe13M&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dmetric-
> 2Dregistry_&d=DwIDaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=EtTYlWuZoXD0BCznVTc0bk6Y3qChy
> oUO9dp0prUdtp0&s=1f72Np2tfL7sqsWqx4tt_RTCu4bLV7znBDNprUiTcl4&e=
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I have two separate issues that I would like to DISCUSS.
> 
> (1) Approval of the initial performance metrics entries (in
> draft-ietf-ippm-initial-registry).
> 
> This document describes the format of the registry, and the initial entries are
> defined in draft-ietf-ippm-initial-registry.  However, the registration policy
> of Specification Required would not be met if the entries in
> draft-ietf-ippm-initial-registry are approved without expert review.
> 
> As I mentioned in my ballot for draft-ietf-ippm-initial-registry, I believe
> that because both documents are being processed at the same time, and the new
> entries have been reviewed by the WG, IESG Approval [rfc8126] can be used.
> 
> I can think of at least three ways to address this DISCUSS point (there may be
> others):
> 
> a. Designated Experts for this document can be assigned and the formal review
> can be done.
> 
> b. The text in this document can explicitly say that the entries in
> draft-ietf-ippm-initial-registry are to be approved using IESG Approval.
> 
> c. The Responsible AD can add a Management Item to the Telechat for the IESG to
> explicitly approve (beyond approval for the publication of
> draft-ietf-ippm-initial-registry) the new entries.
> 
> I am ok with either choice, but would prefer Option c because it would be
> faster and cause less churn.
[acm] 
C. is my preference too, although it is worth noting that Mirja has
begun to form the Experts Group, with two of the initial-registry
authors as the Experts.


> 
> (2)
> 
> §8.1 (Adding new Performance Metrics to the Performance Metrics Registry)
> defines the following process for entries that are "not yet widely
> deployed":
> 
>    If the proposed registry entry is defined in an RFC but is not yet
>    widely deployed, there SHOULD be a statement in the RFC that says the
>    proposed registry entry is not ready for registration, and use SHOULD
>    employ a private/experimental ID.  It is the responsibility of the
>    document authors to submit the request to IANA when the proposed
>    registry entry is ready for official registration.
> 
> Considering the Specification Required policy and the fact that the RFC has
> already gone through all the reviews required for publication (including expert
> review, as mentioned in the same section), how will it work for the "authors to
> submit the request to IANA when the proposed registry entry is ready for
> official registration"?  What specification will be presented to IANA to
> satisfy the registration requirement?   It seems to me that the statement
> mentioned above would prevent the official registration in the first place, and
> that same statement (still present in the RFC) should prevent a second review
> of the same document from resulting in an official registration.
> 
> This process needs more discussion and clarity for it to work.
[acm] 
Yes, I see your point. This a paragraph we added at the IANA desk 
during IETF-106, to resolve a question raised, and it seems we didn't
read it critically. Let me suggest several revisions as a paragraph 
below:

If the proposed registry entry is defined in an RFC but is not yet 
widely deployed, there SHOULD be a statement in the RFC that says the 
proposed registry entry is not ready for registration because it lacks 
deployment (in the IANA Considerations Section), and SHOULD employ a 
private/experimental ID when used in practice. The IANA and Expert 
reviews of the proposed registry entry take place as normally required, 
and registration SHALL be held. When the authors are ready to show 
evidence of widespread deployment, they SHOULD submit the evidence 
to IANA to be evaluated in consultation with the Performance Metric 
Experts for registration at that time.


> 
> [Not part of this DISCUSS point, but related.]
> 
> a. Section 8 talks about instructions about handling of the registry.
> Perhaps it should be part of the IANA Considerations section.
[acm] 
Section 8 contains instructions for all the actors, Experts, etc. 
but perhaps we can make that clear with a change to the title:
"Processes for Managing the Performance Metric Registry Group"

> 
> b. §7.1.1 contains additional instructions for IANA, including the reservation
> of a private/experimental range of Identifiers.  This test should also be
> part of the IANA Considerations section.
[acm] 
OK, all the details in 7.1.1 are now part of Section 10.3, for Identifiers.


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1)  I don't understand why this document is a BCP and not on the Standards
> Track.  The Shepherd writeup says that the status "is best current
> practice...as explained in the draft", but the document only justifies it
> this way:
> 
>    Based on [RFC8126] Section 4.3, this document is processed as Best
>    Current Practice (BCP) [RFC2026].
> 
> rfc8126/§4.3 talks about the Hierarchical Allocation registration policy.
> I'm lost.
> 
> It does seem strange that this document is classified as a BCP when it is
> defining a registry...when many other documents serving the same function
> are simply on the Standards Track.  It would be ideal if there was an actual
> justification.
[acm] 
Aha, I finally sorted this out.  8126 obsoleted 5226, and changed the 
outline completely. (someone said 5226 is obsolete,
the number was changed and the requirement section was not checked, 
mea culpa).

RFC 5226 said:
4.  Creating a Registry
...
4.3.  Updating IANA Guidelines for Existing Registries

   Updating the registration process for an already existing (i.e.,
   previously created) namespace (whether created explicitly or
   implicitly) follows a process similar to that used when creating a
   new namespace.  That is, a document is produced that makes reference
   to the existing namespace and then provides detailed guidelines for
   handling assignments in each individual namespace.  Such documents
   are normally processed as Best Current Practices (BCPs)
   [IETF-PROCESS].

and this memo was written while 5226 was In-force. It now seems a bit 
tenuous to have used this section as the justification for BCP, but
many other opinions were involved over time.

I don't see a similar requirement in 8126.

I don't think anyone would have a problem if this memo is Standards Track now.

I am deleting the sentence you cited above (at end of section 3)
and changing the status in the working version.

> 
> Related to being a BCP.  Should this document be part of BCP 170?
> 
> (2) Nits:
> 
> s/any other organization that wishes to create a Performance Metrics Registry
> MAY use the same formatting specifications/any other organization that wishes
> to create a Performance Metrics Registry may use the same formatting
> specifications      There is no Normative value, just stating a fact.
[acm] 
OK

> 
> s/Expert Review [RFC8126]policy/Expert Review [RFC8126] policy
[acm] 
This is left-over from the pre-IETF-106 discussion with IANA.
The agreed policy is now Specification Required (which includes
Expert Review).

> 
> s/Submission to IANA MAY be during IESG review/Submission to IANA may be
> during
> IESG review     Just stating a fact...no Normative value.
> 
[acm] OK

All these changes implemented in the working version.