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

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

Hi Alissa,

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


> -----Original Message-----
> From: ippm [mailto:[e-mail]] On Behalf Of Alissa Cooper via
> Datatracker
> Sent: Wednesday, December 4, 2019 11:12 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; ippm-
> [e-mail]; [e-mail]
> Subject: [ippm] Alissa Cooper's Discuss on draft-ietf-ippm-metric-
> registry-22: (with DISCUSS and COMMENT)
> 
> 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://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=
> 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=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=eF4izB8BIcIZhNvyTqrK0dTI-
> FP6QcmgawGjMLtavic&s=ElNRLqSJi931KDNnlJH548rF8HwtiMbocp38JV8uiiY&e=
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I support Alvaro's DISCUSS point #2. 
[acm] 
OK, we are still resolving this one.

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


> 
> 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. 
[acm] 
I understand.

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

> 
> 
> ----------------------------------------------------------------------
> 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.
[acm] 
OK, fixed in the working version.
> 
> 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.
[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...


> 
> 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.
[acm] 
Right, Will has become Should in the working version (overlapping comment).
> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> 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=