Subject: [ippm] Éric Vyncke's No Objection on draft-ietf-ippm-metric-registry-22: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 03 Dec 2019 05:36:01 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-metric-registry-22: No Objection

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/

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

Thank you for the work put into this document. It is quite extensive (I even
wonder whether it was useful to indicate the motivations for the registry).

There are a couple of COMMENTs below; feel free to ignore them but I would
appreciate if you replied.

Regards,

-éric

== COMMENTS ==

-- Section 5 --
"interpretable by the user." who is the user in this case? (I have my guess of
course but let's try to be clear)

Why specifying "implementable by the **software** designer," ? I.e., are HW
designers out of scope ?

"accurate" is also quite vague

Also a couple of nits in the section about ',' or '.' and upper/lower case
characters.

-- Section 6.1 --
s/will/should/ in "Why this Attempt Will Succeed" ? ;-)

-- Section 7 --
The table part below is quite unclear at first and second reading. Worth
re-wording ? " Category
------------------
Column |  Column |
"
Or perhaps use a tree form (à la YANG module tree) ?

-- Section 7.1..2 --
Probably worth mentioning "such as and not limited to" rather than "such as" ?

It is also unclear how the MetricType, Method, ... can be extended.

-- Section 11.1.3. --
Should the URL be an https:// one ?

---

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

Hi Éric,

Thanks for your review, please see replies below [acm],
Al

> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:[email-masked]]
> Sent: Tuesday, December 3, 2019 8:36 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Éric Vyncke's No Objection on draft-ietf-ippm-metric-registry-22:
> (with COMMENT)
> 
> 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=-
> EqEK9BLfYLCxQw5QIpvnCbgMRwglD07OW38FgE5f-
> 0&s=ZGkx_Z4dGD4YiLCxag2aeKb_D369tT_Xys6-nW9KSI4&e=
> 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=-
> EqEK9BLfYLCxQw5QIpvnCbgMRwglD07OW38FgE5f-
> 0&s=B_kk53Lojfac4VzaJgy87IkD4D31Ic8r8NRWpEXYHXo&e=
> 
> 
> 
[acm] 
OK, added "or hardware"
> "accurate" is also quite vague
[acm] 
OK, now reads
accurate in terms of producing equivalent results, 
and for interoperability and deployment across vendors

> Also a couple of nits in the section about ',' or '.' and upper/lower case
[acm] 
will seek and destroy

> s/will/should/ in "Why this Attempt Will Succeed" ? ;-)
[acm] 
"should" it will be...

> The table part below is quite unclear at first and second reading. Worth
[acm] 

How about making it clear that this is a Legend, à la

=======================================================================
Legend:
    Registry Categories and Columns are shown below as:
    Category
    ------------------...
    Column |  Column |...
=======================================================================

> It is also unclear how the MetricType, Method, ... can be extended.
[acm] 
We specified that aspect in IANA Considerations section 10.2:

When preparing a Metric entry for Registration, the developer 
SHOULD choose Name elements from among the registered elements. 
However, if the proposed metric is unique in a significant way, 
it may be necessary to propose a new Name element to properly 
describe the metric, as described below.

> Should the URL be an https:// one ?
[acm] Thanks, that's the one I forgot to fix...

all initial-registry draft entries say:
https://www.iana.org/ ... <name>