Re: [ippm] next steps with IPPM registry

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Dec 01, 2015 at 11:41:59AM -0500, MORTON, ALFRED C (AL) wrote:
> Hi Juergen and Marcelo (and Brian Trammell),
> please see more discussion below,
> Al [ACM]
> 
> > -----Original Message-----
> > From: ippm [mailto:[e-mail]] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Tuesday, December 01, 2015 5:04 AM
> > To: marcelo bagnulo braun
> > Cc: STARK, BARBARA H; [e-mail]
> > Subject: Re: [ippm] next steps with IPPM registry
> > 
> > On Tue, Dec 01, 2015 at 06:39:31AM +0100, marcelo bagnulo braun wrote:
> > > Hi,
> > >
> > > I understand that the only remaining open issue with the registry is
> > > to figure out if/how we want to include machine readable information
> > in it.
> > >
> > > In order to figure this out, i understand the idea was for proponents
> > > of doing so should explain the use cases they have in mind, so we can
> > > understand if we want to do this and now.
> > >
> > > I understand Barbara and Juergen were proposing this, so could you (or
> > > anyone else who thinks this is a good idea) to explain the use cases?
> > >
> > 
> > I think the question is which role the registry plays in the overall
> > framework. Is it (i) primarily some form of documentation an MA can
> > refer to or (ii) is the idea that the registry is normative when it
> > comes to run-time parameters and data formats. In the later case, I
> > think it is desirable that tools can work with the portions of the
> > registry that are used by implementations in order to drive automation
> [ACM] 
> The registry entries are certainly normative w.r.t. run-time parameter
> semantics and units and precision. By providing a data format, we easily
> achieve the requirements for units and precision, and ensure the values 
> appear in a form which can be consumed in many measurement protocols
> without conversion. Since many of the values are needed in binary format,
> the tools should take the role of accepting human-readable input and 
> conversion to the binary protocol fields (and display both when necessary).
> This applies to both Fixed and Run-time parameters, and also to 
> output results.

Configuration interfaces (whether its CLIs or YANG-based interfaces)
usually do not operate on binary data. Are we talking about parameters
that get configured or not?

> The above description of consumable formats for measurement protocols 
> is a viable use case for the data formats currently provided in 
> draft-morton-ippm-initial-registry.
> 
> So, I would like to hear a use case for tools working with portions of 
> the registry. What (LMAP) functional entities use these tools, 
> and how does registry access make their job easier?

I may not understand your question. I am starting form an LMAP YANG
data model and if I use a certain metric, I believe I have to
configure certain parameters. In some legislations, customers are free
to deploy CPEs of their choice and hence it would be nice if tools can
discover parameters by discovering the capabilities of an LMAP agent
and then following the pointer to a registry that defines the
parameters. But it could also be that the registry is not supposed to
support tools driving automation (e.g. tools able to display
parameters that can be set without having a human programmer to
program this for every device in the field).

> > (and this likely also requires putting restrictions on say parameter
> > names - for example, the parameter name '1/lambda' in draft-morton-ippm-
> > initial-registry-01.txt is likely troublesome if you take it literally
> > in implementations).
> [ACM] 
> During the IPPM-94 session, Brian Trammell commented on this, too (from the minutes):
> 
> "Brian wondered about using names which could be automatically converted using APIs. 
> Al said that there was some discussion about hierarchical naming. 
> [ACM - this was during the RAIM workshop].
> Will talk about this offline."
> 
> Specifications for naming are new to me, I would be glad to try to use
> someone's suggestion if it helps.

Having parameter names that start with a digit and that look like an
expression may cause a lot of fun. Usually parameter names are
restricted much like variable names in many programming languages. If
the parameter names indeed are normative, I think we should opt for
names that have a high chance to work across many programming and data
modeling languages. To make a concrete proposal: Limit parameter names
to [a-z,A-Z,_]+ or something like that.

> > Perhaps the answer is in between, namely that the registry is primarily
> > documentation for humans and that a formalization of the parameters that
> > are relevant for implementations is a separate step (e.g., for metric X
> > in the registry, some human writes a concrete YANG module defining the
> > concrete configuration parameters to configure metric X following the
> > guidelines given in the registry).
> [ACM] 
> So, the registry was never intended to replace a YANG model for its
> ability to convey configuration information, 
> and it must contain information that should never appear in a YANG model,
> that is information for measurement implementers to attain the goal
> of measurements that can be compared between independent implementations.

I never proposed to write the registry in YANG. The parameters,
apparently, are an interface between the registry and tha YANG model
so we should understand how this works in practice, in particular if
the parameters are normative.

> > If the registry is primarily documentation (and this is what section 5
> > might be saying), then I would prefer if parameters are described with
> > their semantics and units and precision but not the specific encoding.
> [ACM] 
> But we do have a use case for the encoding formats, described above.
> After specifying the encoding, I would be willing to add:
> "... or alternate format for values with equivalent units and precision,
> recognizing that conversion to the specified format may be required."

But see, I also have a use case (LMAP) where binary encodings are not
used. Perhaps the easiest solution is to find a loose coupling since a
tighter coupling apparently creates some tension. That is, to drive
automation, we would rely on a human created machine readable
serialization of data model content, not the registry itself. In other
words, the registry pointer really is just a reference for
documentation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>