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
<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>
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.
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.
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17#section-3.4.2.5>Metric
Units
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17#name-metric-units>
*
Mean
*
Min
*
Max
*
Sum
The one-way delay of the IP Flow singleton is expressed in seconds.
NEW:
3.4.2.5.
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17#section-3.4.2.5>Metric
Units
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-17#name-metric-units>
*
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
<https://rfc-editor.org/rfc/rfc6020#section-9.3> of [RFC6020
<https://www.rfc-editor.org/info/rfc6020>]) 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
<https://rfc-editor.org/rfc/rfc5905#section-6> of [RFC5905
<https://www.rfc-editor.org/info/rfc5905>].
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
<https://rfc-editor.org/rfc/rfc6020#section-9.3> of [RFC6020
<https://www.rfc-editor.org/info/rfc6020>]) 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
<https://rfc-editor.org/rfc/rfc5905#section-6> of [RFC5905
<https://www.rfc-editor.org/info/rfc5905>].
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]
