Benoit,
I suggest removing section 4 as sections 6.2.x contain a superset of the same information. 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. Citing "it was already done badly in another RFC" is a disappointing excuse. Otherwise, please apply the changes. 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]
