Subject: [ippm] metric registry data formats

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Sep 2015 12:27:41 +0200

Hi,

the metrics registry seems to mandate data encoding. For example,
entries say that an IPv4 address is a 32 bit unsigned integer or that
a timestampe is to be represented as a specific NTP encoding. The
general assumption here seems to be that metric parameters (and
outputs) are encoded in binary formats. Given that LMAP intends to use
the metrics registry with protocols that use XML or JSON as their
encoding, it seems kind of odd to represent parameters in binary
(which essentially leads to base64 encoded values).

My proposal would be that the metrics registry entries instead define
clearly what the parameters are and what the precision requirements
are but that they leave the encoding details to users of the registry.
I would also be fine if there are specific suggestions, e.g., for use
with YANG, the IP address parameters are represented as an ip-address
as defined in RFC 6991. Or anything in between is fine - I just would
dislike to configure parameters in binary base64 encoded values.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 30 Sep 2015 14:15:06 +0000

> the metrics registry seems to mandate data encoding. For example, entries
> say that an IPv4 address is a 32 bit unsigned integer or that a timestampe is to
> be represented as a specific NTP encoding. The general assumption here
> seems to be that metric parameters (and
> outputs) are encoded in binary formats. Given that LMAP intends to use the
> metrics registry with protocols that use XML or JSON as their encoding, it
> seems kind of odd to represent parameters in binary (which essentially leads
> to base64 encoded values).
> 
> My proposal would be that the metrics registry entries instead define clearly
> what the parameters are and what the precision requirements are but that
> they leave the encoding details to users of the registry.
> I would also be fine if there are specific suggestions, e.g., for use with YANG,
> the IP address parameters are represented as an ip-address as defined in
> RFC 6991. Or anything in between is fine - I just would dislike to configure
> parameters in binary base64 encoded values.

I agree with Juergen that the data format (encoding) of run-time parameters does not need to be specified.
My expectation of the registry entries for the Run-time Parameters column would be that the parameters listed use precisely the names of parameters from the referenced specification (which is what the example from https://www.ietf.org/proceedings/interim/2015/09/29/lmap/slides/slides-interim-2015-lmap-3-1.pdf mostly did). What's not clear to me is how these parameter names are delimited in the registry. In order for them to be machine parsable (which would be great), I really need to understand how they are delimited in the registry entry. I would think comma delimited would be good, with quotes around the names?
"Src", "Dst", "T0", "Tf", "upper bound" [note that the upper bound, which the example has as "Upper limit on Poisson distribution" is problematic because the reference (RFC2681) only loosely describes this concept and does not list it as a parameter]  

I'm even more concerned with the format of registry entries that would be very useful if they were machine-parsable, such as Fixed Parameters. The example of fixed parameters that was on slide 9 of https://www.ietf.org/proceedings/interim/2015/09/29/lmap/slides/slides-interim-2015-lmap-3-1.pdf is very unparsable. Something like 
"IPv4.dscp"="0", "IPv4.ttl"="255", "IPv4.protocol"="17", "Tmax"="3 seconds", "payload.length"="16 octets"
[I was going to put the other elements listed as fixed parameters on that slide, but got really confused as to how a locally generated (at run-time?) checksum, sequence number, and timestamp were "fixed" parameters -- really what these seem to be are attempts to specify unspecified portions of the reference that hint at the need to include timestamp and sequence number in the payload, which is awkward.]
But something like this means there would need to be a list of these sorts of fixed parameter names and how to express them. I would be tempted to use something like Wireshark names for protocol components.
Barbara