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

[Benjamin Kaduk <[e-mail]>]

Hi Al,

Thanks for all the updates.  Just a few more notes inline...

On Tue, Dec 10, 2019 at 04:36:52PM +0000, MORTON, ALFRED C (AL) wrote:
> 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

I'm not sure that it does ... in common English usage (ignoring any 7594
jargon), one would "send a request to an agent to perform a measurement
task" or "request an action of an agent" or "request that an agent perform
a task" or "task an agent to perform an operation".  While I didn't read
all 50 pages of RFC 7594, some targeted searching fails to find a jargon
usage where "request a task to an agent" has a specific meaning.

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

I guess that there's a couple ways one could parse this sentence: "in
general" could apply to the way the columns are populated, or to what the
specification defining the new columns has to do.  I was reading it in the
second variant, and qualifying a MUST like that is fairly dicey with the
current IESG.  But the former parsing is not problematic, and it sounds
like that's what you intended.  Perhaps "MUST give general guidelines for
populating" would avoid the misparse, though it may have problems of its
own.

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

Whoops, sorry for missing that.

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

I meant, we're implicitly saying that IPv4 and IPv6 are the only address
families that anyone will ever care about.  IANA has quite a few more than
two that are defined...

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

Thanks :)

-Ben

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