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

[Barry Leiba <[e-mail]>]

Hi, Álvaro.  On the first DISCUSS point, I don't see an issue.  If it
had all been done in one document it would be unremarkable, and we
would not think that a formal review by the DE would be needed.  In
this case, it's clear that this is a single product of the working
group that has, for editorial convenience, been split into two
documents.  I think there's neither need nor value in worrying about
it further for these initial registrations.

But...
For future registrations let me suggest that there's a fourth
alternative to your list.  Is it the working group's intent that if an
IETF-consensus document should want to make a future registration --
say, another document out of the IPPM WG -- it would have to go
through expert review even though it has working group consensus, and,
in theory, the DE could override WG consensus?

If so, then we're fine as we are.  But if not, then:

d. The registration policy could be set as "Specification Required or
IETF Review".  We use that in a number of registries, and it means
that an IETF-consensus document can register items without formal
expert review, though, of course, we would expect the DE(s) to
participate in forming the IETF consensus on it.  But specifications
that do not have IETF consensus -- from other RFC streams or non-RFC
sources -- would have to get a formal DE review.

The working group might consider whether this is or isn't what they
want before we cast the policy in stone.

Barry

On Tue, Dec 3, 2019 at 5:37 PM Alvaro Retana via Datatracker
<[e-mail]> wrote:
>
> 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.
>
>