Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX)
draft-ietf-opsawg-ipfix-on-path-telemetry-23

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-opsawg-ipfix-on-path-telemetry and RFC 9951, changed IESG state to RFC Published)

Please address DISCUSS/COMMENTS provided by:
- Mike Bishop
- The Performance Metrics expert has issues.
- Eric has comments
- Gorry has comments
- Gunter has a few DISCUSSes.
- Intdir review has some minor comments.
- Deb Cooley’s comments
- Med’s comments

[Ballot comment]
https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-on-path-telemetry-20.html#section-1-5 feels like an argument for why the metrics are registered and why they're named what they are. Does the document need this, or should it just specify and register them?

"Hybrid Type I Passive" is used as a single term in this document, saying it's imported from RFC7799. However, https://www.rfc-editor.org/rfc/rfc7799#section-3.8 appears to use "Hybrid Type I" and "Passive" as two separate terms, and RFC 7799 does not appear to contain the string "Hybrid Type I Passive".

===NITS FOLLOW===

- In 3.3.2, "Section 4.4.2.3 and 4.4.2.4" => "Sections 4.4.2.3 and 4.4.2.4", and these should probably be links to the sections in question.

- In 3.3.5, should "hybrid type I" be capitalized as it is elsewhere in the document?

- In the Acknowledgements, "Rest in Peace Al" => "Rest in Peace, Al" or simply "Rest in Peace" to avoid misreading this as a nickname.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-on-path-telemetry-20
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). I also second many Gunter's points (about "mean" and IANA).

Special thanks to Giuseppe Fioccola for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Tim Wicinski, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-opsawg-ipfix-on-path-telemetry-20-intdir-telechat-wicinski-2025-08-02/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Abstract

Abstract should be short of course but this one is too succinct IMHO: be specific about encapsulating/decapsulating node (i.e., OAM header encaps and not VPN encaps) + a reference to RFC 9232 would be useful.

### Section 1

The term 'delay' is ambiguous in the IETF context... is it end to end ? serialisation ? propagation ? Only the 2nd paragraph explains it.

s/postcard mode, where the metrics are also exposed in transit nodes/postcard mode, where the metrics are also exposed *by* transit nodes/ ?

Again `decapsulating nodes` suggest using "OAM header decapsulating nodes".

Unsure whether the next text is useful in an introduction and is not also easy to parse `Following the guidelines for Registered ... even if they are performed using different implementations and in different networks.`

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

`and/or the sum of measured path delay` it is unclear why there is a "and/or" and what is the "sum" here ? The accumulated delay by all segments or the sum of all delays locally computed ? If the latter, does it have any statistical value in the absence of sample count ?

### Section 3.3.2

[I-D.zhou-ippm-enhanced-alternate-marking] and [I-D.fz-spring-srv6-alt-mark] are clearly *normative* references.

### Section 3.3.5

Is the `host A Role` defined somewhere ? Add a forward reference ? or why not using "initiator" ? It seems to overly add some complexity.

### Section 3.3.6

The terms should rather be defined in the terminology section.

### Section 6.2

In 2025, does a division have a significant CPU impact when compared to other factors ?

### Section 6.4

Who is the "we" in `we might miss the temporal distribution` ? The authors ? The WG ? The IETF ? Please avoid using "we" in an I-D.

### Section 6.5

s/IPv6 options header/IPv6 *extensions* header/

### Appendix A

THANKS for the IPv6 examples ;-)

s/us/µs/ as UTF-8 encoding is supported in I-D.

[Ballot comment]
Thanks to Martin Duke for his TSV-ART review, where he notes:

This document could use an editorial review for clarity. Sentence fragments
like "The timestamp when the packet is being received at OAM encapsulating
node." are hard to parse. The Introduction was really unclear and I had to read
it a few times to understand what this document was doing, despite a basic
conceptual familiarity with IOAM.

Please also see the DISCUSS comments of Gunter Van de Velde regarding operation of Alt Mark.

[Ballot discuss]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-opsawg-ipfix-on-path-telemetry-20

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-ipfix-on-path-telemetry-20.txt

# I observed a few DISCUSS items. I think most will be reasonable easy to resolve, and some suggestions to increase readability in few paragraphs.

# in generak the draft is a nice and comfortable read.

# DISCUSS
# ========

## (DISCUSS#1) in the below snip (line 126-129) Alternative marking does not operate by inserting timestamps. The insinuation in the text seems from that perspective wrong. (alternate marking uses the event of a bit going up->down or visa versa, an dnot by insreting timestamps)

126   Maintenance (IOAM) Deployment [RFC9378] and Alternate Marking
127   Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path
128   delay between two endpoints is measured by inserting a timestamp in
129   the packet.

## (DISCUSS#2) IANA expert review comments reports issue that needs to be resolved

## (DISCUSS#3) In the below snip it is assumed that there is a timestamp carried in the dataplane packet, which is not the situation when alternate marking is used. Instead the slope of the bit going up/down/up is used instead. This may have to be made more explicit in the below snip.

## (DISCUSS#4) In the below snip, on line 180 it is unclear what is a "mean"? Is there a reference that can be pointed towards? from mathematical perspective there are various way to compute a "mean" (i.e. Arithmetic Mean, Weighted Mean, Geometric Mean, Harmonic Mean, Moving Average (Rolling Mean), Running/Incremental Mean, Trimmed or Winsorized Mean).

176   Assuming time synchronization on devices, the delay is measured by
177   calculating the difference between the timestamp imposed with On-Path
178   Telemetry in the packet at the OAM encapsulating node and the
179   timestamp exported in the IPFIX flow record from the OAM transit and
180   decapsulating nodes.  The lowest, highest, mean, and/or the sum of
181   measured path delay can be exported, thanks to the different IPFIX IE
182   specifications.

## (DISCUSS#5) In the below what is an "IP Flow"? On line 260 there is a reference "Flow" but the term "IP Flow" by itself is not specified. Can this be clarified or defined what exactly is meant with the term?

238   *  Encapsulating Node: Receives the IP Flow packets, encapsulates the
239       packets with the OAM header and adds the timestamp into the OAM
240       header.

GV> (DISCUSS#6) Considering the below snip, in the routing world the term one-way is not used so much, but unidirectional is.
for example see:
* https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type
* "Min Unidirectional Link Delay" as defined in [RFC8570, Section 4.2] and [RFC7471, Section 4.2].
Also the existing TE metrics speak about unidirectional delay and not one-way metric. There is inconsistency. Could the term unidirectional be used instead?

286 3.1.  IP One-Way Delay Hybrid Type I Passive Performance Metrics

[Ballot comment]
# Detailed Review
# ===============

16   This document specifies new IP Flow Information Export (IPFIX)
17   Information Elements to export the On-Path Telemetry measured delay
18   in the OAM transit and decapsulating nodes.

GV> What about the following alternative proposal to have slightly more elaborate abstract:

"
This document defines a set of IP Flow Information Export (IPFIX) Information Elements to support the export of on-path telemetry data. By standardizing the export format for on-path telemetry using IPFIX, this document facilitates interoperable data collection and analysis across multi-vendor network environments. The Information Elements defined herein support various telemetry paradigms, including in-situ OAM (IOAM), Alternate Marking, and hybrid schemes, and enable comprehensive visibility into packet-level behavior observed along the network path.
"

108 1.  Introduction

110   Network operators usually gather and maintain some forms of
111   statistical delay view of their networks (or segments of their
112   networks).  That view is meant to help with understanding where in
113   the network, for which customer traffic or services, how much, and
114   why abnormal delay is being accumulated.  To that aim, delay-related
115   data needs to be reported from devices covering both data and control
116   planes.  In order to understand which customer traffic is affected,
117   delay-related data needs to be reported in the context of the
118   customer data-plane.  That enables network operators to quickly
119   identify when the control-plane updates the current path with a
120   different set of intermediate hops (that is, a change of the
121   forwarding path) and interfaces, how the path delay changes for which
122   customer traffic.

GV> I found the text here reasonable confusing to digest. Suggest a rephrasing to consider with the following alternative:

"
Network operators commonly maintain statistical views of delay across their networks to support diagnostics and performance analysis. These views assist in identifying the location, extent, and potential causes of abnormal delay affecting specific customer traffic or services. To achieve this, delay-related telemetry must be collected from both the data and control planes and correlated with the customer data plane. This correlation enables timely detection of changes in forwarding paths, such as updated intermediate hops or interfaces, and the resulting impact on delay experienced by customer traffic.
"

124   With On-Path Telemetry, described in the Network Telemetry Framework
125   [RFC9232] and applied in In Situ Operations, Administration, and
126   Maintenance (IOAM) Deployment [RFC9378] and Alternate Marking
127   Deployment Framework [I-D.ietf-ippm-alt-mark-deployment], the path
128   delay between two endpoints is measured by inserting a timestamp in
129   the packet.

GV> (see DISCUSS) There seems to be a miscommunication i here. The alt-mark-framework is not measuring by inserting timestamps, but my setting bits and alternating these bits to measure a delay based upon the event when a a bit goes up or down.

131   At least two modes of On-Path Telemetry can be distinguished.
132   Passport mode, where only the last hop in the forwarding path of the
133   On-Path Telemetry domain exposes all the metrics, and postcard mode,
134   where the metrics are also exposed in transit nodes.  In both modes
135   the forwarding path exposes performance metrics allowing to determine
136   how much delay has been accumulated on which hop.  The proposal in
137   this document makes more sense for the postcard mode.

GV> What about the following proposal:

"
Two modes of on-path telemetry are generally recognized: passport mode, in which only the egress node of the telemetry domain reports metrics; and postcard mode, in which transit nodes also export telemetry data. Both modes enable exposure of per-hop performance metrics, including delay accumulation. The approach defined in this document is primarily applicable to postcard mode.
"

139   In order to export the delay-related metrics via IPFIX [RFC7011],
140   this document defines four new IPFIX Information Elements (IEs),
141   exposing the On-Path delay on OAM transit and decapsulating nodes,
142   following the postcard mode principles.  Since these IPFIX IEs are
143   performance metrics [RFC8911], they are also registered in the "IANA
144   Performance Metric Registry [IANA-PERF-METRIC] .
145
146   Following the guidelines for Registered Performance Metric Requesters
147   and Reviewers [RFC8911], the different characteristics of the
148   performance metrics (Identifier, Name, URI, Status, Requester,
149   Revision, Revision Date, Description, etc.) must be clearly specified
150   in the "IANA Performance Metric Registry [IANA-PERF-METRIC] in order
151   for the measurement results using the Performance Metrics to be
152   comparable even if they are performed using different implementations
153   and in different networks.  The first performance metric
154   characteristic is the selection of a meaningful name, following the
155   "MetricType_Method_SubTypeMethod_... Spec_Units_Output" naming
156   convention (See Section 7.1.2 of [RFC8911]).

GV> alternative proposal:

"
To enable the export of delay-related metrics via IPFIX [RFC7011], this document defines four new IPFIX Information Elements (IEs) that report on-path delay at OAM transit and decapsulating nodes, consistent with postcard mode telemetry. As these IEs represent performance metrics, they are also registered in the IANA Performance Metric Registry [IANA-PERF-METRIC] in accordance with [RFC8911].

In line with the guidelines for Registered Performance Metric Requesters and Reviewers [RFC8911], each metric is specified with its required characteristics (e.g., Identifier, Name, URI, Status, Requester, Revision, Description) to ensure comparability of measurement results across implementations and environments. Metric naming follows the "MetricType_Method_SubTypeMethod_..._Spec_Units_Output" convention defined in Section 7.1.2 of [RFC8911]
"

176   Assuming time synchronization on devices, the delay is measured by
177   calculating the difference between the timestamp imposed with On-Path
178   Telemetry in the packet at the OAM encapsulating node and the
179   timestamp exported in the IPFIX flow record from the OAM transit and
180   decapsulating nodes.  The lowest, highest, mean, and/or the sum of
181   measured path delay can be exported, thanks to the different IPFIX IE
182   specifications.

GV> (see DISCUSS) With alternative marking there is no timestamp within the packet, but it contains an alternating slope of a bit used for marking packets.

GV> (See DISCUSS) Another observation i have is what is meant with "mean"? There are various ways to compute a mean value.

210   The advantage of this solution is that the delay metrics (min, max,
211   and mean) can be computed on the OAM node, and aggregated directly
212   within the Flow Record, saving export bandwidth and computation on
213   the Collector.  For the computation of the min, max, and mean delay
214   metric to be computed locally on the OAM node, the exporter Metering
215   Process requires some local caching/processing computation (for each
216   new packets in the flow), specifically the mean value when Flow
217   Aggregation [RFC7015] is being used.  A less computational heavy
218   solution for the OAM node is the export of the delay sum instead of
219   the delay mean; on the Collector, the delay mean can easily be
220   computed by a single division operation (using the packet count).
221   The alternative, with no delay monitoring on the OAM node, requires
222   the export of every single packet as a separate Flow Record,
223   including the timestamps information, as described in
224   [I-D.ietf-opsawg-ipfix-alt-mark] for Alternate Marking, for the
225   Collector to compute delay metrics (min, max, and mean), before
226   recomputing the aggregated Flow Record.

GV> What about the following alternative:

"
This solution enables the computation of delay metrics (minimum, maximum, and mean) directly on the OAM node, allowing aggregation within the Flow Record. This reduces both export bandwidth and processing requirements on the Collector. To compute these metrics locally, the Exporter’s Metering Process must perform per-packet caching and processing, particularly when computing mean delay under Flow Aggregation [RFC7015]. A less computationally intensive alternative is to export the sum of delays, allowing the Collector to compute the mean via a simple division using the packet count.

In contrast, if no delay processing occurs on the OAM node, each packet must be exported as an individual Flow Record, including timestamp information, as specified in [I-D.ietf-opsawg-ipfix-alt-mark]. The Collector must then compute the delay metrics and reconstruct the aggregated Flow Record accordingly.
"

238   *  Encapsulating Node: Receives the IP Flow packets, encapsulates the
239       packets with the OAM header and adds the timestamp into the OAM
240       header.

GV> (See DISCUSS) what is an "IP Flow"? On line 260 is made to a reference "Flow" but the term "IP Flow" by itself is not specified.

Thanks for this write-up.

Gunter Van de Velde
RTG Area Director

The IPFIX Information Elements registrations have been approved. Feedback for the Performance Metrics registrations: Iread the latest version of the draft and found that my concern about the naming new IEs ( see comments from 10, 2024) is not addressed, along with concerns with using undefined entities like "OAM node" and "Collector". Below, please find my comments to the draft-ietf-opsawg-ipfix-on-path-telemetry-20:
Characterization if Passport and Postcard modes in the Introduction is not consistent with RFC 9232 where the passport mode is referred to IOAM as defined in RFC 9127, while postcard mode - to RFC 9326. According to RFC 9232, the passport mode is when telemetry information is collected along the path and transported in the trigger packet, while postcard mode - such information is collected and transported from each traversed node by some mechanism, e.g., over the management plane.
Combining "Hybrid Type I" with "Passive" in reference to performance metrics is confusing and inaccurate. RFC 7799 defines hybrid measurement methods as a combination of the elements of passive and active measurement methods. Furthermore, RFC 7799 identifies two types of hybrid measurement methods - Type I (IOAM and Alternate Marking are examples of it) and Type II. There's no mention of Hybrid Type I Passive in RFC 7799.
Another concern with the naming new IPFIX IEs is reference to IP in "HybridType1_Passive_IP". Is it to signify that the IEs are applicable only to delay measurement of the IP flows? But can they be used to export delay metrics of, for example, an MPLS flow?
Some key elements used in the document, e.g., "OAM node" and "Collector", are underdefined.
I consider the content of Section 3.2.2 Packet Stream Generation essential and that the reader must understand any document referenced in the section. Hence, I believe that references to [I-D.zhou-ippm-enhanced-alternate-marking]  and [I-D.fz-spring-srv6-alt-mark] must be normative, if the Alternate Marking method is in the scope of the document.
I hope that my comments are helpful.

[Ballot comment]
Thanks to Linda Dunbar for their secdir review.

Section 7, para 4:  While RFC 7011 does indeed recommend TLS/DTLS to protect sensitive or privacy information, it pre-dates TLS 1.3 and DTLS 1.3. 
Consider adding a note to use BCP195, perhaps this: 'Implementations SHOULD also refer to [BCP195] for additional details.'

[Ballot comment]
Hi Thomas, Benoît, and Alex,

Thank your for the effort put into this specification. Interesting to see the approach defined in RFC 8911 exercised here.

Also, thanks to Menachem Dodge for the OPSDIR review and Qin Wu for the PERFMETRDIR review. Appreciate that Menachem, Qin, and authors converged for both reviews.

As I reviewed a previous version of the spec [1], I only focused the current review on the diff since then [2]. I specifically appreciated the new text added to explain the need for the IEs compared to an approach where intermediate nodes export the timestamps observed in packets and local receiving timestamps and let the collector to do the various math operations. Likewise, I appreciate that the IEs were generalized to be independent of IOAM.

I only have very minor comments:

# Use the exact registry name

## Section 1

OLD:
  In order to export the delay-related metrics via IPFIX [RFC7011],
  this document defines four new IPFIX Information Elements (IEs),
  exposing the On-Path delay on OAM transit and decapsulating nodes,
  following the postcard mode principles.  Since these IPFIX IEs are
  performance metrics [RFC8911], they are also registered in the "IANA
  Performance Metric Registry [IANA-PERF-METRIC].

NEW:
  In order to export the delay-related metrics via IPFIX [RFC7011],
  this document defines four new IPFIX Information Elements (IEs),
  exposing the On-Path delay on OAM transit and decapsulating nodes,
  following the postcard mode principles.  Since these IPFIX IEs are
  performance metrics [RFC8911], they are also registered in the IANA
  “Performance Metric” Registry [IANA-PERF-METRIC].

## Section 1

OLD:
  Following the guidelines for Registered Performance Metric Requesters
  and Reviewers [RFC8911], the different characteristics of the
  performance metrics (Identifier, Name, URI, Status, Requester,
  Revision, Revision Date, Description, etc.) must be clearly specified
  in the "IANA Performance Metric Registry [IANA-PERF-METRIC] in order

NEW:
  Following the guidelines for Registered Performance Metric Requesters
  and Reviewers [RFC8911], the different characteristics of the
  performance metrics (Identifier, Name, URI, Status, Requester,
  Revision, Revision Date, Description, etc.) must be clearly specified
  in the IANA "Performance Metric” Registry [IANA-PERF-METRIC] in order

## Section 3.1

OLD:
  This section specifies four performance metrics for the Hybrid Type I
  Passive assessment of IP One-Way Delay, to be registered in the "IANA
  Performance Metric Registry [IANA-PERF-METRIC].

NEW:
  This section specifies four performance metrics for the Hybrid Type I
  Passive assessment of IP One-Way Delay, to be registered in the IANA
  “Performance Metric” Registry [IANA-PERF-METRIC].

# There might be multiple OAM encapsulating nodes

OLD:
  Assuming time synchronization on devices, the delay is measured by
  calculating the difference between the timestamp imposed with On-Path
  Telemetry in the packet at the OAM encapsulating node and the
                              ^^^^ 

NEW:
  Assuming time synchronization on devices, the delay is measured by
  calculating the difference between the timestamp imposed with On-Path
  Telemetry in the packet at an OAM encapsulating node and the

Please check other similar constructs.

# I don’t remember I have seen “flow packet” used in other IPFIX specs + there might be many OAM headers

RFC7011 defines flow as follows:

      A Flow is defined as a set of packets or frames passing an
      Observation Point in the network during a certain time interval.
      All packets belonging to a particular Flow have a set of common
      properties.

I suggest we make this change:

OLD:
  *  Encapsulating Node: Receives the IP Flow packets, encapsulates the
                                          ^^^^^^^^^^^^
      packets with the OAM header and adds the timestamp into the OAM
      header.

  *  Transit Node: Receives the IP Flow packets, measures the delay^
                                    ^^^^^^^^^^^^
      between the timestamp in the packet and the timestamp when the
      packet was received.

  *  Decapsulating Node: Receives the IP Flow packets, computes the
                                          ^^^^^^^^^^^^
      delay between the timestamp in the packet and the timestamp when
      the packet was received and removes the OAM header from the
      packet.

NEW:
  *  Encapsulating Node: Receives the IP packets, encapsulates the
      packets with an OAM header and adds the timestamp into the OAM
                  ^^
      header.

  *  Transit Node: Receives the IP packets, measures the delay
      between the timestamp in the packet and the timestamp when the
      packet was received.

  *  Decapsulating Node: Receives the IP Flow packets, computes the
      delay between the timestamp in the packet and the timestamp when
      the packet was received and removes the OAM header from the
      packet.

# Please add “Collector” and “Observation Point” to the list of terms under 7011

CURRENT:
  The following terms are used as defined in [RFC7011]:
  …

# (Nit) Only one term is imported from 7799

OLD:
  The following terms are used as defined in Section 3.8 of [RFC7799]:

  *  Hybrid Type I Passive

NEW:
  The following term is used as defined in Section 3.8 of [RFC7799]:

  *  Hybrid Type I Passive

# (nit) Section 3.1.2

OLD:
    We consider the
    measurement of one-way delay based on a single Observation Point
    [RFC7011] somewhere in the network.

NEW:
    The
    measurement of one-way delay is based on a single Observation Point
    [RFC7011] somewhere in the network.

Please make the same change for other similar constructs in the document.

# IANA is the authoritative reference for IEs, not RFC7012 & Use the exact registry names

OLD:
5.2.  IPFIX Entities

  This document requests IANA to register new IPFIX IEs (see table 3)
  under the "IPFIX Information Elements" registry [RFC7012] available
  at "IANA IP Flow Information Export (IPFIX) Entities Registry
  [IANA-IPFIX] and assign the following initial code points.

NEW:
5.2.  IPFIX Entities

  This document requests IANA to register new IPFIX IEs (see table 3)
  under the "IPFIX Information Elements" registry  under
  the " IP Flow Information Export (IPFIX) Entities” registry group
  [IANA-IPFIX] and assign the following initial code points.

# RFC-to-be

There are several notes to the RFC editor with distinct patterns [RCC-to-be] vs. _RFC[RFC-to-be]

(1) with RFC label

778   Reference:  [RFC-to-be]

(2) without RFC label

…
781       OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the
782       IANA Performance Metric Registry.

Hope this won't be confusing for the RFC editor.

#  Section 6.5

## nit

s/Section 4.4.2.3 and 4.4.2.4 of [RFC9197]/ Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]

There are many such occurrences in the doc.

## Cite  RFC8754

CURRENT:
919   be applied to the SRv6 Segment Routing Header.

Hope this helps.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/opsawg/qRNGYGSasUsON8PUvpqrP86ojyo/

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-08&url2=draft-ietf-opsawg-ipfix-on-path-telemetry-20&difftype=--html

Request for IETF Last Call review by SECDIR Completed: Has Nits. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-opsawg-ipfix-on-path-telemetry-19. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Performance Metrics Registry in the Performance Metrics Registry group located at:

https://www.iana.org/assignments/performance-metrics/

four new registrations will be made as follows:

Identifier: Name: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean
URI: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean
Description: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean: This metric assesses the mean of one-way delays of all successfully forwarded IP packets constituting a single Flow. We consider the measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network
Reference: [ RFC-to-be ]
Change Controller: IETF
Version: 1.0

Identifier: Name: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min
URI: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min
Description: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min: This metric assesses the minimum of one-way delays of all successfully forwarded IP packets constituting a single Flow. We consider the measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network
Reference: [ RFC-to-be ]
Change Controller: IETF
Version: 1.0

Identifier: Name: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max
URI: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max
Description: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max: This metric assesses the maximum of one-way delays of all successfully forwarded IP packets constituting a single Flow. We consider the measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network.
Reference: [ RFC-to-be ]
Change Controller: IETF
Version: 1.0

Identifier: Name: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum
URI: https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum
Description: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum: This metric assesses the sum of one-way delays of all successfully forwarded IP packets constituting a single Flow. We consider the measurement of one-way delay based on a single Observation Point [RFC7011] somewhere in the network.
Reference: [ RFC-to-be ]
Change Controller: IETF
Version: 1.0

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the IPFIX Information Elements registry in the IP Flow Information Export (IPFIX) Entities registry group located at:

https://www.iana.org/assignments/ipfix/

four new registrations are to be made as follows:

ElementID: [ TBD-at-Registration ]
Name: pathDelayMeanDeltaMicroseconds
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Description: This Information Element identifies the mean path delay of all packets in the Flow, in microseconds, between the OAM encapsulating node and the local node with the OAM domain (either an OAM transit node or an OAM decapsulating node), according to OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the IANA Performance Metric Registry.
Units:
Range:
Additional Information: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the IANA Performance Metric Registry.
Revision: 0
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: pathDelayMinDeltaMicroseconds
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Description: This Information Element identifies the lowest path delay of all packets in the Flow, in microseconds, between the OAM encapsulating node and the local node with the OAM domain (either an OAM transit node or an OAM decapsulating node), according to the OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min in the IANA Performance Metric Registry.
Units:
Range:
Additional Information: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min in the IANA Performance Metric Registry
Revision: 0
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: pathDelayMaxDeltaMicroseconds
Abstract Data Type: unsigned32
Data Type Semantics: deltaCounter
Description: This Information Element identifies the highest path delay of all packets in the Flow, in microseconds, between the OAM encapsulating node and the local node with the OAM domain (either an OAM transit node or an OAM decapsulating node), according to OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max in the IANA Performance Metric Registry.
Units:
Range:
Additional Information: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max in the IANA Performance Metric Registry.
Revision: 0
Date: [ TBD-at-Registration ]

ElementID: [ TBD-at-Registration ]
Name: pathDelaySumDeltaMicroseconds
Abstract Data Type: unsigned64
Data Type Semantics: deltaCounter
Description: This Information Element identifies the sum of the path delay of all packets in the Flow, in microseconds, between the OAM encapsulating node and the local node with the OAM domain (either an OAM transit node or an OAM decapsulating node), according to OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum in the IANA Performance Metric Registry.
Units:
Range:
Additional Information: OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum in the IANA Performance Metric Registry.
Revision: 0
Date: [ TBD-at-Registration ]

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-07-17):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-ipfix-on-path-telemetry@ietf.org, giuseppe.fioccola@huawei.com, mjethanandani@gmail.com, opsawg-chairs@ietf.org, opsawg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX)) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Export of
Delay Performance Metrics in IP Flow Information eXport
  (IPFIX)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-07-17. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies new IP Flow Information Export (IPFIX)
  Information Elements to export the On-Path Telemetry measured delay
  in the OAM transit and decapsulating nodes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path-telemetry/



No IPR declarations have been submitted directly on this I-D.

Please see AD review comments at:

https://mailarchive.ietf.org/arch/msg/opsawg/SutAzwO1A0swogr8q-aQKtD9QKg/

I am also requesting that IANA take an early look at the document, and within that request, have Paul verify the IPFIX registry requests.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document received several reviews from participants of the OPSAWG WG, and
also reached broad agreement in meetings.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no controversies.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals and no indications of discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document specifies new IPFIX Information Elements to export the On-Path
Telemetry measured delay. The draft also reports the implementation status
including a list of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document received relevant feedback before the Last Call, in particular:
IANA Early review, IPFIX designated expert review, IPPM registry designated
expert review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

IANA Early review:
https://mailarchive.ietf.org/arch/msg/opsawg/k6Kh3PJcJWyOqHJEhVTGw9bDais/
IPFIX designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/snK3i5duq1j55zWZAM8M8F4aOL0/
IPPM registry designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/
The comments received have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Such checks are not needed for this document, other than idnits.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I find this document to be well written, and has the correct category.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There were reviews from IANA, IPFIX and IPPM experts. TSVART and OPSDIR Last Call
reviews were also positive.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors are aware of the requirements. A poll was sent to the list and
the authors did not disclose any IPR related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the three authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are a few nits to fix.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs and are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There is no need to list it.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references. I expect that the only DOWNREF will be fixed in a new version.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not update any other documents.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new designated expert in addition to those indicated above.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document received several reviews from participants of the OPSAWG WG, and
also reached broad agreement in meetings.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no controversies.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals and no indications of discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document specifies new IPFIX Information Elements to export the On-Path
Telemetry measured delay. The draft also reports the implementation status
including a list of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document received relevant feedback before the Last Call, in particular:
IANA Early review, IPFIX designated expert review, IPPM registry designated
expert review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

IANA Early review:
https://mailarchive.ietf.org/arch/msg/opsawg/k6Kh3PJcJWyOqHJEhVTGw9bDais/
IPFIX designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/snK3i5duq1j55zWZAM8M8F4aOL0/
IPPM registry designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/
The comments received have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Such checks are not needed for this document, other than idnits.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I find this document to be well written, and has the correct category.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There were reviews from IANA, IPFIX and IPPM experts. TSVART and OPSDIR Last Call
reviews were also positive.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors are aware of the requirements. A poll was sent to the list and
the authors did not disclose any IPR related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the three authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are a few nits to fix.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs and are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There is no need to list it.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references. I expect that the only DOWNREF will be fixed in a new version.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not update any other documents.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new designated expert in addition to those indicated above.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document received several reviews from participants of the OPSAWG WG, and
also reached broad agreement in meetings.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no controversies.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No threats of appeals and no indications of discontent.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document specifies new IPFIX Information Elements to export the On-Path
Telemetry measured delay. The draft also reports the implementation status
including a list of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

The document received relevant feedback before the Last Call, in particular:
IANA Early review, IPFIX designated expert review, IPPM registry designated
expert review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

IANA Early review:
https://mailarchive.ietf.org/arch/msg/opsawg/k6Kh3PJcJWyOqHJEhVTGw9bDais/
IPFIX designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/snK3i5duq1j55zWZAM8M8F4aOL0/
IPPM registry designated expert review:
https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/
The comments received have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

This document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

Such checks are not needed for this document, other than idnits.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I find this document to be well written, and has the correct category.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There were reviews from IANA, IPFIX and IPPM experts. TSVART and OPSDIR Last Call
reviews were also positive.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard is being requested for new IPFIX entities according to
https://datatracker.ietf.org/doc/html/rfc7011#section-13.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, the authors are aware of the requirements. A poll was sent to the list and
the authors did not disclose any IPR related to the document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the three authors are willing to be listed.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There are a few nits to fix.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Yes, the reference to RFC 7799 should be changed from normative to informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are published RFCs and are freely available. The only
exception is a DOWNREF (normative reference to the informational RFC 7799), that
should be fixed.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There is no need to list it.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No such references. I expect that the only DOWNREF will be fixed in a new version.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document does not update any other documents.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The IPFIX entities created by this document are consistent with the body of the
document. IPFIX entities are added to the existing registry as defined in
https://datatracker.ietf.org/doc/html/rfc7012#section-7.4.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new designated expert in addition to those indicated above.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/