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

[Benjamin Kaduk <[e-mail]>]

On Thu, Dec 12, 2019 at 11:36:40PM +0000, MORTON, ALFRED C (AL) wrote:
> Hi Benjamin,
> 
> I'll trim this message down to focus on the last few points,

Thanks; I probably should have done some trimming too.

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

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

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

> > 
> > > >
> ...
> > 
> > Thanks :)
> > 
> > -Ben
> > 
> [acm] Thank you, Ben.
> 
> I'll be holding these changes in another working version,
> pending a few more questions from Michelle/IANA.

Sounds good.

-Ben