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

[Alvaro Retana via Datatracker <[e-mail]>]

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://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-metric-registry/



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

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

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

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.


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

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.

s/Expert Review [RFC8126]policy/Expert Review [RFC8126] policy

s/Submission to IANA MAY be during IESG review/Submission to IANA may be during
IESG review     Just stating a fact...no Normative value.