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

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Wed, 04 Dec 2019 08:12:12 -0800

Alissa Cooper 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 support Alvaro's DISCUSS point #2. I'm confused about what the registration
policy is for metrics in the new registry. If it is Specification Required,
then the places in the document that assume new metrics are defined in an RFC
need to be generalized, because Specification Required need not involve any RFC
at all.

I have an additional concern about this text:

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

This appears to put a requirement on RFCs to include language that is not
timeless and may later become out of date. That is, if this guidance is
followed but a metric is later widely deployed, the RFC would have to be
updated just to remove the text about the metric not being ready for
registration. It seems better to just give guidance about which identifier
range registration requests should target, and to give guidance to the
designated experts about how to evaluate requests in different ranges.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1:

"any other organization that wishes to create a Performance Metrics Registry"

It seems like performance metrics registry should not be capitalized here since
the next section defines the capitalized version as the one maintained by IANA.

Section 6:

I would strongly recommend that this section be moved to an appendix. Some
readers may find it useful, but it doesn't seem like it belongs in the body of
the document.

Also, I would caution against a section heading entitled "Why this Attempt Will
Succeed." I certainly hope it will, but the future is hard to predict and the
IETF has a long history of being wrong about what will and will not succeed.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 4 Dec 2019 18:13:54 +0000

Hi Alissa,

Thanks for your review and comments, please see replies 
marked with [acm] below,
Al

> -----Original Message-----
> From: ippm [mailto:[email-masked]] On Behalf Of Alissa Cooper via
> Datatracker
> Sent: Wednesday, December 4, 2019 11:12 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; ippm-
> [email-masked]; [email-masked]
> Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-metric-
> registry-22: (with DISCUSS and COMMENT)
> 
> Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=eF4izB8BIcIZhNvyTqrK0dTI-
> FP6QcmgawGjMLtavic&s=55JvuC_PQkACOOC_N_GRxARgXbdRNeoLJWvkshHfQnk&e=
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dippm-2Dmetric-
> 2Dregistry_&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=eF4izB8BIcIZhNvyTqrK0dTI-
> FP6QcmgawGjMLtavic&s=ElNRLqSJi931KDNnlJH548rF8HwtiMbocp38JV8uiiY&e=
> 
> 
> 
> I support Alvaro's DISCUSS point #2. 
[acm] 
OK, we are still resolving this one.

> I'm confused about what the registration
> need to be generalized, because Specification Required need not involve
> any RFC at all.
[acm] 
Yes, I believe Roni Even made this comment during Gen_ART Review.
Roni sat at the IANA table when we met, and we believe we found
all non-consistent cases during that session.

> registration. 
[acm] 
I understand.

> It seems better to just give guidance about which identifier
[acm] 
OK, Alvaro still has difficulty with the resolution text I proposed,
it's the same paragraph mentioned in Alvaro's DISCUSS point #2.

This text was added during the meet-up with IANA at IETF-106,
and it was intended to solve a corner-case of a Performance Metric
RFC-to-be @ IESG, *with a section that defines a performance metric entry*
that doesn't quite meet all the Section 5
criteria for performance metrics.

I'll take one last shot at solving this, and if that fails,
propose to delete this new paragraph and handle on a case-by-case
basis.

[acm] 
OK, fixed in the working version.
> readers may find it useful, but it doesn't seem like it belongs in the
> body of the document.
[acm] 
There should be a lot of actors who read this RFC-to-be, who will balk at
the amount of detail needed to avoid the pitfalls described in this section.
I'm defending the current placement, tightly coupled with section 5 on 
criteria for performance metrics...

> IETF has a long history of being wrong about what will and will not
[acm] 
Right, Will has become Should in the working version (overlapping comment).
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=eF4izB8BIcIZhNvyTqrK0dTI-
> FP6QcmgawGjMLtavic&s=E53_OPxerJgemgafwNbGZinanoMhg2hM0gjaOm_CPK4&e=