Hi Paul/Benoit, I wonder too who wrote RFC 8911 :-(
Unless someone is willing to write a rfc8911-bis and fix the format/template, I am grinding my teeth and accepting the format as is.🧐 Cheers. > On Jun 11, 2025, at 6:36 AM, Benoit Claise > <[email protected]> wrote: > > 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]> >> <mailto:[email protected]> >> Sent: Wednesday, June 11, 2025 13:45 >> To: Aitken, Paul <[email protected]> <mailto:[email protected]>; Mahesh >> Jethanandani <[email protected]> <mailto:[email protected]>; >> [email protected] >> <mailto:[email protected]><[email protected]> >> <mailto:[email protected]> >> Cc: opsawg-chairs <[email protected]> <mailto:[email protected]>; >> opsawg <[email protected]> <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> <[email protected]> <mailto:[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 Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
