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

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

Hi Benjamin,

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

> -----Original Message-----
> From: Benjamin Kaduk [mailto:[e-mail]]
> Sent: Wednesday, December 11, 2019 11:57 PM
> To: MORTON, ALFRED C (AL) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-ippm-metric-
> registry-22: (with COMMENT)
> 
> Hi Al,
> 
> Thanks for all the updates.  Just a few more notes inline...
> 
...
> > >       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://urldefense.proofpoint.com/v2/url?u=https-
> 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=
> 
> 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.
[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.


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

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

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

> 
> > >
...
> 
> Thanks :)
> 
> -Ben
> 
[acm] Thank you, Ben.

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

Al