Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-registry-22: (with COMMENT)

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

Hi Benjamin, 
please see replies below,
Al

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto:[e-mail]]
> Sent: Thursday, December 5, 2019 2:58 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-registry-
> 22: (with COMMENT)
> 
> Benjamin Kaduk 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=UMdJiopPvXH0rGwEWVH5t8Q9WbFXF
> qG0-Xe78jMsGpE&s=mzT1hSL2E7AlNR4tc4-ziFE1hrSzku6CctmzGeegZBs&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=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=UMdJiopPvXH0rGwEWVH5t8Q9WbFXF
> qG0-Xe78jMsGpE&s=9uMM8WPNbtgjXv72ejb5q5G3FhwRYq9HdcjugHRjDik&e=
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The sometimes-conversational tone of the text here is at odds with my
> mental preconception of what a BCP (or, for that matter, a
> Standards-Track document) is, though I make no claim that my mental
> preconception is relevant to anyone other than myself.
> 
> I agree with the comment about parts of the text assuing that metric
> specifications will be RFCs being at odds with the lower
> specification-required regisration policy.
> 
> I support Alissa's Discuss point.
> 
> Section 1
> 
>    applications transported over its protocols.  Performance metrics are
>    such an important part of the operations of IETF protocols that
>    [RFC6390] specifies guidelines for their development.
> 
> It's not entirely clear that the existence of RFC 6390 supports exactly
> this conclusion.
[acm] 
Let's try
Performance metrics are important part of network operations using IETF protocols,
and [RFC6390] specifies guidelines for their development.

> 
>    The definition and use of Performance Metrics in the IETF happens in
>    various working groups (WG), most notably:
> 
> Is this going to age well?
[acm] 
Let's simply state the facts, in past a present tense.
IPPM and BMWG have demonstrated longevity:

The definition and use of Performance Metrics in the IETF has been fostered in various working groups (WG), most notably:

(and note the concluded WG).

> 
>       The "Performance Metrics for Other Layers" (PMOL) a concluded WG,
> 
> nits: s/a //, no comma
[acm] 
ok

> 
> Section 2
> 
>       Examples of Performance Metrics are the FTP response time for a
>       complete file download, the DNS response time to resolve the IP
>       address, a database logging time, etc.  This definition is
> 
> nit: DNS responses are not limited to single IP addresses, so the
> definite article seems wrong here.
[acm] 
ok address(es)

> 
>       consistent with the definition of metric in [RFC2330] and broader
>       than the definition of performance metric in [RFC6390].
> 
> Why are we using a different definition of performance metric than BCP
> 170?  [How can both be BCPs at the same time but be in conflict?]
[acm] 
We learn as we go: RFC7799 should probably be a BCP and update 170.
I think this memo will be Standards track now, as a result of other
discussions.

> 
>    Parameter:  A Parameter is an input factor defined as a variable in
>       the definition of a Performance Metric.  A Parameter is a
>       numerical or other specified factor forming one of a set that
>       defines a metric or sets the conditions of its operation.  All
>       Parameters must be known to measure using a metric and interpret
>       the results.  There are two types of Parameters: Fixed and Run-
> 
> nit: I suggest "all Parameters must be known in order to make a
> measurement using a metric", as currently "known to measure" flows
> oddly.
[acm] 
Yes, agreed. 

> 
> Section 3
> 
>    groups: IPPM, XRBLOCK, IPFIX, and BMWG.  This document analyzes an
>    prior attempt to set up a Performance Metrics Registry, and the
> 
> nit: s/ an/ a/
[acm] 
ok

> 
>    Based on [RFC8126] Section 4.3, this document is processed as Best
>    Current Practice (BCP) [RFC2026].
> 
> As was already noted, the referenced section does not have any obvious
> relevance to publication status for this document.
[acm] 
This sentence has been removed, after it was discovered that the 
8126 changed the outline and requirements.

> 
> Section 4.1
> 
>    As any IETF registry, the primary use for a registry is to manage a
> 
> nit: I think this was intended to be "As for any IETF registry"
[acm] 
flagged earlier, now: As with any ...

> 
>       particular example is the LMAP framework [RFC7594].  Using the
>       LMAP terminology, the Performance Metrics Registry is used in the
>       LMAP Control protocol to allow a Controller to request a
>       measurement task to one or more Measurement Agents.  In order to
> 
> nit: please check the grammar of "request a measurement task to".
[acm] 
Yes, it matches the LMAP control framework.
https://tools.ietf.org/html/rfc7594

> 
> Section 4.2
> 
>    different (and incompatible) ways.  Having a registry would allow
>    both the IETF community and external people to have a single list of
> 
> nit: I suggest rephrasing "external people" as needlessly divisive;
> perhaps "other communities"?
[acm] 
Sounds better to me.

> 
> Section 7
> 
>    form of registry extension.  The specification defining the new
>    column(s) MUST give guidelines to populate the new column(s) for
>    existing entries (in general).
> 
> Is "MUST (in general)" really still a "MUST"?
[acm] 
I think so, we're talking about new columns having a similar 
level of detail in their description as the columns in the 
current registry (future version 2.0).

> 
> Section 7.1.2
> 
>          RTDelay (Round Trip Delay)
> 
>          RTDNS (Response Time Domain Name Service)
> 
> It's slightly unfortunate that "RT" expands to both "Round Trip" and
> "Response Time".
[acm] 
agree, no change though because no ambiguity for the complete element.

> 
>    o  SubTypeMethod: One or more sub-types to further describe the
>       features of the entry, such as:
> 
>          ICMP (Internet Control Message Protocol)
> 
>          IP (Internet Protocol)
> 
>          DSCPxx (where xx is replaced by a Diffserv code point)
> 
> I thought Diffserv code point interpretation was a local matter; is it
> really appropriate in the metric definition?
[acm] 
Yes, some DSCP values are widely accepted. 

> 
> Section 7.3.5
> 
>    devices.  For example, parameters that include an IPv4 address can be
>    encoded as a 32 bit integer (i.e. binary base64 encoded value) or ip-
>    address as defined in [RFC6991].  The actual encoding(s) used must be
> 
> nit: YANG types are specified distinctly from their possible encodings;
> indicating an XML or JSON encoded version of the YANG ip-address would
> be appropriate here.
[acm] 
Yes, and we go on in the next sentence to say:
	The actual encoding(s) used must be explicitly defined for each Run-time parameter.

> 
>    explicitly defined for each Run-time parameter.  IPv6 addresses and
>    options MUST be accomodated, allowing Registered Metrics to be used
>    in either address family.
> 
> nit: is "either" too limiting, here?
[acm] 
No, especially for active testing, where we generate the test traffic
in one address family at a time.

> 
> Section 8.2
> 
>    A change to a Registered Performance Metric SHALL be determined to be
>    backward-compatible only when:
> 
> Is it better to give the Experts some leeway to do the right thing
> rather than locking it down with rigid procedures?
[acm] 
Ok, removed "only" to allow for the un-foreseen.

> 
> Section 8.3
> 
>    The use of deprecated Registered Performance Metrics should result in
>    a log entry or human-readable warning by the respective application.
> 
> Taken literally this would require any measurement agent to query IANA
> before performing every measurement, to confirm that the metric being
> used is not deprecated.  Presumably some less-frequent polling
> frequencey would still be acceptable!
[acm] 
Ok what we meant was:
The *intentional* use of deprecated...

> 
> Section 10.2
> 
>    reviewed along with the metric entry.  New assignments for Registered
>    Performance Metric Name Elements will be administered by IANA through
>    Expert Review [RFC8126], i.e., review by one of a group of experts,
>    the Performance Metric Experts, who are appointed by the IESG upon
>    recommendation of the Transport Area Directors.
> 
> It's not entirely clear to me that we need to go into this much detail
> when RFC 8126 covers it already.  (Also elsewhere.)
[acm] 
This background was needed by some, also people questioning the process...

> 
> Section 11.1.3
> 
> Please use https:// URIs.
[acm] 
Done.
> 
> Section 13.2
> 
> One might argue that RFC 7799 should be normative, since we defer to it
> for the allowed valuse for the Method column.
[acm] 
I agree, fixed.

>