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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Dec 2019 23:58:13 -0800

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://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:
----------------------------------------------------------------------

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.

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

Is this going to age well?

      The "Performance Metrics for Other Layers" (PMOL) a concluded WG,

nits: s/a //, no comma

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.

      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?]

   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.

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/

   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.

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"

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

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

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

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

   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?

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.

   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?

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?

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!

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

Section 11.1.3

Please use https:// URIs.

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.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 10 Dec 2019 16:36:52 +0000

Hi Benjamin, 
please see replies below,
Al

> -----Original Message-----
> From: Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Sent: Thursday, December 5, 2019 2:58 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Benjamin Kaduk'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=DwICaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=UMdJiopPvXH0rGwEWVH5t8Q9WbFXF
> qG0-Xe78jMsGpE&s=mzT1hSL2E7AlNR4tc4-ziFE1hrSzku6CctmzGeegZBs&e=
> 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=
> 
> 
> 
[acm] 
Let's try
Performance metrics are important part of network operations using IETF protocols,
and [RFC6390] specifies guidelines for their development.

> 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,
[acm] 
ok

> definite article seems wrong here.
[acm] 
ok address(es)

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

> measurement using a metric", as currently "known to measure" flows
[acm] 
Yes, agreed. 

>    prior attempt to set up a Performance Metrics Registry, and the
[acm] 
ok

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

> nit: I think this was intended to be "As for any IETF registry"
[acm] 
flagged earlier, now: As with any ...

> 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

> perhaps "other communities"?
[acm] 
Sounds better to me.

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

> It's slightly unfortunate that "RT" expands to both "Round Trip" and
[acm] 
agree, no change though because no ambiguity for the complete element.

> really appropriate in the metric definition?
[acm] 
Yes, some DSCP values are widely accepted. 

> indicating an XML or JSON encoded version of the YANG ip-address would
[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.

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

> rather than locking it down with rigid procedures?
[acm] 
Ok, removed "only" to allow for the un-foreseen.

> frequencey would still be acceptable!
[acm] 
Ok what we meant was:
The *intentional* use of deprecated...

> when RFC 8126 covers it already.  (Also elsewhere.)
[acm] 
This background was needed by some, also people questioning the process...

> Please use https:// URIs.
[acm] 
Done.
> for the allowed valuse for the Method column.
[acm] 
I agree, fixed.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Dec 2019 20:56:48 -0800

Hi Al,

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

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

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

> 	The actual encoding(s) used must be explicitly defined for each Run-time parameter.

Whoops, sorry for missing that.

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

> The *intentional* use of deprecated...

Thanks :)

-Ben

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 12 Dec 2019 23:36:40 +0000

Hi Benjamin,

I'll trim this message down to focus on the last few points,
Al

> From: Benjamin Kaduk [mailto:[email-masked]]
> Sent: Wednesday, December 11, 2019 11:57 PM
> To: MORTON, ALFRED C (AL) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-
> registry-22: (with COMMENT)
> 
> Hi Al,
> 
...
> 3A__tools.ietf.org_html_rfc7594&d=DwIBAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-
> 6zYMI&m=MzVZrMUvKmgZUrc2Qyn-SPWdwhnUOKygq-
> TCWAfOpjI&s=o0bDjUeJH_LTfE10Zmgr5u1Gil0KGRd3Yloz5WMbG0A&e=
> 
[acm] 
ok, probably "schedule a task" would have. I was focusing on the "request"
part. Controllers send tasks to measurement agents and they can be refused.

Let's try:
LMAP Control protocol to allow a Controller 
to schedule a measurement task for one or more Measurement Agents.

> populating" would avoid the misparse, though it may have problems of its
[acm] 
Let's try your suggestion.

The specification defining the new column(s) MUST give general guidelines 
for populating the new column(s) for existing entries.

...
> Whoops, sorry for missing that.
[acm] 
NP

> families that anyone will ever care about.  IANA has quite a few more than
[acm] 
I didn't see that coming. I don't read any of the examples of 
Run-time Parameters as the limiting set in this section.

Let's try:
IPv6 addresses and options MUST be accommodated, allowing Registered 
Metrics to be used in *that* address family. 
*Other address families are permissable.*

...
> -Ben
[acm] Thank you, Ben.

I'll be holding these changes in another working version,
pending a few more questions from Michelle/IANA.

Al

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Dec 2019 16:47:19 -0800

> I'll trim this message down to focus on the last few points,

Thanks; I probably should have done some trimming too.

> to schedule a measurement task for one or more Measurement Agents.

That does the trick; thanks for working through it with me.

> *Other address families are permissable.*

Thanks.

> pending a few more questions from Michelle/IANA.

Sounds good.

-Ben