Hi Paul,
Thanks for the quick reaction.
On 6/11/2025 3:06 PM, Aitken, Paul wrote:
Benoit,
I suggest removing section 4 as sections 6.2.x contain a superset of
the same information.
Fine
For sections 3.1.1.2 - 3.1.2, the draft reads like it's filling a
form; it does not read well as a stand-alone document. If someone
would refer back to this in future, the information they need would be
spread across many sections of the document.
It's actually just "filling a form". A painful form, I agree, according
to RFC 8911 with the guidelines in RFC 6390. I wonder who wrote those
RFCs? ;-)
Michele Cotton still hates me for the IPFIX and Performance Metric
registries, and remind me at every single meeting ;-)
The end goal is the IANA registrations, not this document, IMO. Hence my
early discussion with IANA, to make sure they were fine.
Unless the AD insists, I would be reluctant to make the change. I am
afraid I would have duplicate much of the following content (all entries
in the template), with just a few changes:
3.1.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Description . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. Reference . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4. Change Controller . . . . . . . . . . . . . . . . . . 9
3.1.5. Version of Registry Format . . . . . . . . . . . . . 9
3.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Reference Definition . . . . . . . . . . . . . . . . 9
3.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 9
3.3. Method of Measurement . . . . . . . . . . . . . . . . . . 10
3.3.1. Reference Methods . . . . . . . . . . . . . . . . . . 10
3.3.2. Packet Stream Generation . . . . . . . . . . . . . . 10
3.3.3. Traffic Filtering (Observation) Details . . . . . . . 10
3.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 10
3.3.5. Runtime Parameters and Data Format . . . . . . . . . 10
3.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Reference Definition . . . . . . . . . . . . . . . . 12
3.4.3. Administrative Items . . . . . . . . . . . . . . . . 14
3.4.4. Comments and Remarks . . . . . . . . . . . . . . . . 15
Not sure the draft is going to read any better, as the reader will have
to back and forth if the entries are similar with min,max,mean,sum
Citing "it was already done badly in another RFC" is a disappointing
excuse.
Otherwise, please apply the changes.
Thanks and regards, Benoit
Thanks,
P.
------------------------------------------------------------------------
*From:* Benoit Claise <[email protected]>
*Sent:* Wednesday, June 11, 2025 13:45
*To:* Aitken, Paul <[email protected]>; Mahesh Jethanandani
<[email protected]>;
[email protected]
<[email protected]>
*Cc:* opsawg-chairs <[email protected]>; opsawg
<[email protected]>; [email protected] <[email protected]>
*Subject:* [**EXTERNAL**] Re: AD review of
draft-ietf-opsawg-ipfix-on-path-telemetry-17
Hi Paul,
Thomas addressed some feedback already in
https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-opsawg-ipfix-on-path-telemetry/refs/heads/main/draft-ietf-opsawg-ipfix-on-path-telemetry-18.txt
[author-tools.ietf.org]
<https://urldefense.com/v3/__https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-17&url_2=https:**Araw.githubusercontent.com*network-analytics*draft-ietf-opsawg-ipfix-on-path-telemetry*refs*heads*main*draft-ietf-opsawg-ipfix-on-path-telemetry-18.txt__;Ly8vLy8vLy8!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFFR0WjKwg$>
So I'll keep only the remaining items in this email thread.
3.1.1.2 - 3.1.2
The document should define and request one metric at a time,
rather than providing bulk inputs.
At least the Name, URI, Description, and Units should be grouped
per metric, because the current format provides no relation
between these values.
We actually followed the RFC 8912 section 4.1.x. So we believe we're
safe on that front, as IANA already process a similar RFC.
Note: the RFC 8912 is the first and only RFC that populates
https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml
[iana.org]
<https://urldefense.com/v3/__https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml__;!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFGpRr6UnQ$>.
Also I discussed this specific draft with IANA already.
3.4.2.5 Why are the PM metrics measured in seconds (with a
resolution of 1ns) while the IPFIX IEs are in Microseconds?
There was no mention that they are incompatible, nor any
discussion of how to convert between them.
Well spot.
OLD:
3.4.2.5. [datatracker.ietf.org]
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17*section-3.4.2.5__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFHmeEkp6Q$>Metric
Units [datatracker.ietf.org]
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17*name-metric-units__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFFxu5yUEA$>
*
Mean
*
Min
*
Max
*
Sum
The one-way delay of the IP Flow singleton is expressed in seconds.
NEW:
3.4.2.5. [datatracker.ietf.org]
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17*section-3.4.2.5__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFHmeEkp6Q$>Metric
Units [datatracker.ietf.org]
<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17*name-metric-units__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFFxu5yUEA$>
*
Mean
*
Min
*
Max
*
Sum
The one-way delay of the IP Flow singleton is expressed in
microseconds.
OLD (4 instances):
The time value of the result is expressed in units of seconds, as
a positive value of type decimal64 with fraction digits = 9
(similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org]
<https://urldefense.com/v3/__https://rfc-editor.org/rfc/rfc6020*section-9.3__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFEf4Rdpvw$>
of
[RFC6020 [rfc-editor.org]
<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc6020__;!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFFB5HhsbQ$>])
with a resolution of 0.000000001 seconds (1.0 ns), and with
lossless conversion to/from the 64-bit NTP timestamp as per
Section 6 [rfc-editor.org]
<https://urldefense.com/v3/__https://rfc-editor.org/rfc/rfc5905*section-6__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFEwygPnrg$>
of
[RFC5905 [rfc-editor.org]
<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc5905__;!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFGBckR8yg$>].
NEW:
The time value of the result is expressed in units of seconds, as
a positive value of type decimal64 with fraction digits = 9
(similar to the decimal64 in YANG, Section 9.3 [rfc-editor.org]
<https://urldefense.com/v3/__https://rfc-editor.org/rfc/rfc6020*section-9.3__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFEf4Rdpvw$>
of
[RFC6020 [rfc-editor.org]
<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc6020__;!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFFB5HhsbQ$>])
with a resolution of 0.000001 seconds (1.0 microsecond), and with
lossless conversion to/from the 64-bit NTP timestamp as per
Section 6 [rfc-editor.org]
<https://urldefense.com/v3/__https://rfc-editor.org/rfc/rfc5905*section-6__;Iw!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFEwygPnrg$>
of
[RFC5905 [rfc-editor.org]
<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc5905__;!!OSsGDw!LQPkow8moMoM3yyCIykKWuwgb17k751knnoaT7ia1LWf22waMzjI9O4QRNrvZsLu41nxTvNS9iH7KFGBckR8yg$>].
Section 4. Is this section necessary? These definitions repeat
those in section 6, except that the line, "according to
OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_* in the
IANA Performance Metric Registry." is missing.
We could remove it
6.1 "with the four templates defined in Section 3."
It was not clear that section 3 defined four templates.
OLD:
3. Performance Metrics This section defines the new performance
metrics following the template defined in Section 11 of [RFC8911].
NEW:
3. Performance Metrics This section defines four the new
performance metrics following the template defined in Section 11
of [RFC8911].
If fine with you, I'll apply the changes.
Thanks and regards, Benoit
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
