Re: [ippm] next steps with IPPM registry

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

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. 

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? 

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

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

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



> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm