[OPSAWG]Re: AD review of draft-ietf-opsawg-ipfix-on-path-telemetry-17

[Benoit Claise <[e-mail]>]

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 <[e-mail]>
> *Sent:* Wednesday, June 11, 2025 13:45
> *To:* Aitken, Paul <[e-mail]>; Mahesh Jethanandani 
> <[e-mail]>; 
> [e-mail] 
> <[e-mail]>
> *Cc:* opsawg-chairs <[e-mail]>; opsawg 
> <[e-mail]>; [e-mail] <[e-mail]>
> *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
>
>
>
>
>