Hi Thomas/Greg, Thomas, thanks for addressing the remaining comments and publishing -22 version of the document.
Greg et. al, the last item left was an expert review of the draft with respect to the Performance Metrics Registry and the proposed registration. Therefore, comments or concerns related to the registry, e.g., naming of the registry, are in scope of the discussion. All other points should be considered out of scope at this time. As I understand it, the contention is around the use of HybridType1_Passive in the name. Is the objection with the addition of _Passive in the name? Would you be ok if _Passive is dropped? Are the authors ok with just using HybridType1 in the name? Thanks. > On Sep 21, 2025, at 5:33 PM, Greg Mirsky <[email protected]> wrote: > > Hi, Thomas and the Authors, > thank you for sharing the new version. I have several concerns with -21, > Please find them below: > I appreciate the addition of references to RFC 7799 in Terminology section: > The following term is used as defined in Section 3.7 of [RFC7799]: > * Passive > The following term is used as defined in Section 3.8 of [RFC7799]: > * Hybrid Type I > What is stil not clear is why naming of metrics combines these two mutually > exclusive characteristics of performance measurement methods. According to > RFC 7799, a performance measurement method is either Active, Passive, Hybrid > Type I, or Hybrid Type II. A combination some elements of passive, i.e., > observation of a flow, with elements of active, e.g., augmentation of a data > packet with special shim to perform or enhance measurements, is characterized > as a hybrid measurement method in RFC 7799. Adding more passive methodology > will still be characterized as a hybrid measurement method. If you disagree, > can you propose a text or point to it in the draft that explains the use of > HybridType1_Passive in namings. > Furthermore, as I understand it, the draft defines metrics measured using > IOAM or the Alternate-Marking Method applied to a data packet. But, described > in several documents discussed in the IPPM WG, these shims can be applied to > a test probe packet, e.g., STAMP test packet. Then, it will be an Active > measurement method per RFC 7799 classification of the measurement methods. In > your opinion, would these be the same metrics as defined in the document, and > can they be exported using the same IPFIX IEs as specified in the draft? > What is the rationale in not referencing the fundamental IOAM and the > Aternate-Marking Method RFCs? For example, IOAM is defined by RFC 9197, not > RFC 9378. Similarly, the Alternate-Marking Method is specified in RFC 9341, > not draft-zhou-ippm-enhanced-alternate-marking. > Can you add a direct reference that supports the following assertion: > In contrast, if no delay processing occurs on the OAM header transit > or decapsulating node, each packet must be exported as an individual > Flow Record, including timestamp information, as specified in > [I-D.ietf-opsawg-ipfix-alt-mark]. > As I understand RFC 9326, IOAM-DEX does not specify how metrics generated on > a transit IOAM node are exported. > > Thank you for your consideration of my comments. > > Regards, > Greg > > On Thu, Sep 11, 2025 at 12:04 AM <[email protected] > <mailto:[email protected]>> wrote: >> Dear Greg, >> >> >> >> On behalf of the authors. We received feedback from Deb, Gunter, Med and >> Greg and decided to publish revision -21. >> >> >> >> https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-21 >> >> >> >> From what we understand from this conversation is that there is one open >> item regarding the naming of the performance metrics. >> >> >> >> We are also expecting feedback from Éric, Tim, Gorry and Mike and based on >> their and the discussion with you we will merge the input in -22. >> >> >> >> Best wishes >> >> Thomas >> >> >> >> From: Graf Thomas, SCS-INI-NET-VNC-E2E >> Sent: Monday, September 8, 2025 8:43 AM >> To: Greg Mirsky <[email protected] <mailto:[email protected]>> >> Cc: [email protected] >> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: RE: [OPSAWG]Re: [IANA #1422930] expert review for >> draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) >> >> >> >> Dear Greg, >> >> >> >> Thanks a lot. See my reply inline. >> >> >> >> Best wishes >> >> Thomas >> >> >> >> From: Greg Mirsky <[email protected] <mailto:[email protected]>> >> Sent: Monday, September 8, 2025 2:53 AM >> To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] >> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: Re: [OPSAWG]Re: [IANA #1422930] expert review for >> draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) >> >> >> >> Be aware: This is an external email. >> >> >> >> Dear Thomas, >> >> thank you for adding more structure to the discussion. Please find my >> follow-up notes below tagged GIM2>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Sat, Sep 6, 2025 at 11:48 PM <[email protected] >> <mailto:[email protected]>> wrote: >> >> Dear Greg, >> >> >> >> GIM>> I probably was not clear in my notes. My question is Why Hybrid Type 1 >> and Passive are concatenated in IE's name, e.g., >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? >> >> >> >> TG> The reason why passive is chosen is because of the document scope: >> Export of Delay Performance Metrics in IPFIX. The IPFIX process passively >> observes IP flows. Section 4.3.2, Packet Stream Generation, starts with "The >> time when the packet is being received at the OAM header encapsulating node" >> therefore. >> >> >> >> GM> thought that Passive refers to the measurement method, not the method of >> collecting metrics >> >> >> >> Thans a lot. I think we misunderstand each other. We need to distinguish >> between the performance metrics definition which includes 'method AND >> metrics' and the IPFIX where 'metrics' are defined. >> >> >> >> Section 4.1.1.2 of draft-ietf-opsawg-ipfix-on-path-telemetry-21 defines the >> name of the performance metrics. The document follows the guideline from >> https://datatracker.ietf.org/doc/html/rfc8911#section-7.1.2 which includes >> RFC 7799 terminology and how it applies in performance metrics naming. >> https://datatracker.ietf.org/doc/html/rfc8912 is the first document >> describing performance metrics following those guidelines. Section 4 of >> draft-ietf-opsawg-ipfix-on-path-telemetry-21 follows the criteria in >> https://datatracker.ietf.org/doc/html/rfc8911#section-5 where one objective >> is "accurate in terms of producing equivalent results". >> >> >> >> https://www.rfc-editor.org/rfc/rfc7013.html#section-4.1 gives guidance on >> IPFIX entity naming. Even though >> https://datatracker.ietf.org/doc/html/rfc8911#section-1 intend is to >> facilitate a centralize performance metrics which can be then referenced >> when being used in data models of telemetry protocols such as IPFIX or YANG, >> it does not give guidance on naming those data elements. This makes sense to >> me since IPFIX and YANG as example models and name data differently. Have >> different taxonomies. >> >> >> >> Taking https://datatracker.ietf.org/doc/html/rfc8911#section-7.1.2 as naming >> guidance, do you agree that the following names match the guidance or do you >> propose a different more appropriate name? >> >> >> >> 4.1.1.2. Name >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum >> >> GIM2>> I have two questions to use of HybridType1 and Passive in the naming >> performance metrics: >> >> RFC 7799 defines Hybrid Type 1 measurement methods as follows: >> Augmentation or modification of the stream of interest, or >> >> employment of methods that modify the treatment of the stream >> >> Should note that "stream" here is interpreted as a flow of data, i.e., >> customer's, packets. On the other hand, since the publication of RFC 9197 >> and RFC 9326, where only combination of IOAM shim with a data packet is >> considered, we have drafts that propose combining IOAM shim with, for >> example, STAMP packet. Such a measurement method, in my opinion, is an >> active method according to RFC 7799. Do you agree? >> >> >> >> TG2> Correct. It is active because packets are originated and reflected at >> the OAM node with STAMP. >> >> >> >> Hence my first question: >> >> Are these performance metrics produced using only RFC9197-based manner or >> also combining, for example, STAMP and IOAM? >> >> >> >> TG2> No. Section 4.3.2 "Packet Stream Generation" should be clear with the >> sentence "The time when the packet is being received at the OAM header >> encapsulating node" that the OAM packet is not originated. It is passive >> therefore. >> >> >> >> If the intention to include both approaches, characterization Hybrid Type 1 >> in the name contradicts my conclusion about the combination of STAMP and >> IOAM as an active measurement method. >> >> >> >> TG2> It is not the authors intention. >> >> >> >> My second question is about using Passive in the name. As understand naming >> recommendation <https://datatracker.ietf.org/doc/html/rfc8911#name-name>, >> HybridType1_Passive intended to reflect a method that is recommended as >> follows: >> >> Method: >> >> One of the methods defined in [RFC7799], such as and not limited to: >> >> As an alternative to HybridType1_Passive, I propose Hop_by_Hop >> >> >> >> What are your thoughts? >> >> >> >> TG2> Since neither RFC 7799 nor RFC 8911 contain the word "hop" nor >> "Hop_by_Hop" I object to introduce new terms which are not clearly defined >> prior. I would like to understand what the objective (judging from prior >> questions, probably your concern is that it is applicable beyond Hybrid Type >> 1 Passive, which is not the case) is and from there I can help to make a >> proposal. >> >> >> >> Taking https://www.rfc-editor.org/rfc/rfc7013.html#section-4.1 as naming >> guidance, taking from that guidance "new Information Elements pertaining to >> a specific protocol should name the protocol in the first word in order to >> ease searching by name" into account, considering that the IPFIX metering >> process can't distinguish between wherever the metrics are generated >> actively or passively, take icmp packets captured by the IPFIX process as >> example, do you agree that the following names match the guidance or do you >> propose a different more appropriate name than pathDelay? >> >> >> >> 6.2. IPFIX Entities >> >> pathDelayMeanDeltaMicroseconds >> pathDelayMinDeltaMicroseconds >> >> pathDelayMaxDeltaMicroseconds >> >> pathDelaySumDeltaMicroseconds >> >> >> >> Best wishes >> >> Thomas >> >> >> >> From: Greg Mirsky <[email protected] <mailto:[email protected]>> >> Sent: Saturday, September 6, 2025 8:33 PM >> To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] >> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: Re: [OPSAWG]Re: [IANA #1422930] expert review for >> draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) >> >> >> >> Be aware: This is an external email. >> >> >> >> Hi Thomas, >> Thank you for the expedient response. I thought that Passive refers to the >> measurement method, not the method of collecting metrics. If Passive in the >> registry name refers to IPFIX as the performance metric collection method, >> should all metrics collected using IPFIX include the Passive reference? Is >> this naming convention used in the IANA Performance Metrics registry >> <https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml>? >> If performance metrics defined in the draft are collected using methods >> other than IPFIX, e.g., YANG notifications, should it be described in the >> registry as a different metric? And as we are discussing naming, according >> to RFC 7799, the Hybrid performance method is a combination of Passive and >> Active measurement methods. IOAM and Alternate Marking are examples of a >> Hybrid measurement method when applied to a data flow. However, when IOAM or >> Alternate Marking is used in combination with a specially constructed test >> packet, e.g., STAMP, it is still characterized as an Active measurement >> method. But that combination can produce performance metrics defined in the >> draft under discussion. That brings me to question the use of Hybrid Type 1 >> in the naming of new entries in the IANA Performance Metrics registry. Would >> both cases of using IOAM or Alternate Marking be generalized by replacing >> HybridType1 with another identification, e.g., HopByHop, to signify the >> collection of performance metrics from transit nodes? >> What are your thoughts? >> >> Regards, >> Greg >> >> >> On Sat, Sep 6, 2025 at 1:07 AM <[email protected] >> <mailto:[email protected]>> wrote: >> >> Dear Greg, >> >> >> >> GIM>> I probably was not clear in my notes. My question is Why Hybrid Type 1 >> and Passive are concatenated in IE's name, e.g., >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? >> >> >> >> Apologies for not having commented this point. >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum is the name in the >> performance registry. Not the IE name. >> >> >> >> The name for the performance registry is defined in section 4.1.1.2 where >> for IPFIX entities in 6.2 >> >> >> >> 4.1.1.2. Name >> >> >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Min >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Max >> >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum >> >> >> >> 6.2. IPFIX Entities >> >> >> >> pathDelayMeanDeltaMicroseconds >> >> pathDelayMinDeltaMicroseconds >> >> pathDelayMaxDeltaMicroseconds >> >> pathDelaySumDeltaMicroseconds >> >> >> >> The reason why passive is chosen is because of the document scope: Export of >> Delay Performance Metrics in IPFIX. The IPFIX process passively observes IP >> flows. Section 4.3.2, Packet Stream Generation, starts with "The time when >> the packet is being received at the OAM header encapsulating node" therefore. >> >> >> >> Does that clarify your question or do you propose different names? Paul as >> designated IPFIX expert is on C. >> >> >> >> Best wishes >> >> Thomas >> >> >> >> From: Greg Mirsky <[email protected] <mailto:[email protected]>> >> Sent: Saturday, September 6, 2025 2:16 AM >> To: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected] >> <mailto:[email protected]>> >> Cc: [email protected] >> <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]>; [email protected] >> <mailto:[email protected]> >> Subject: Re: [OPSAWG]Re: [IANA #1422930] expert review for >> draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) >> >> >> >> Be aware: This is an external email. >> >> >> >> Hi, Thomas and the authors, >> >> thank you for your careful consideration of my comments. I appreciate >> updates that address them improving the document. Please find my follow-up >> notes below tagged GIM>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Thu, Sep 4, 2025 at 10:16 PM <[email protected] >> <mailto:[email protected]>> wrote: >> >> Dear David and Greg, >> >> >> >> On behalf of the authors, thank you very much for your detailed review and >> comments. >> >> >> >> We addressed your feedback together with Tim's, Mike's, Med's, Deb's, >> Éric's, Gunter's and Gorry's as following >> >> https://author-tools.ietf.org/diff?doc_1=draft-ietf-opsawg-ipfix-on-path-telemetry-20&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-21.txt >> >> >> >> GM> 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. >> >> >> >> Your description on Passport and Postcard mode is correct. Regarding RFC >> 9232 reference. I believe you are refering to >> https://datatracker.ietf.org/doc/html/rfc9232#appendix-A.3.5. Our >> understanding is that IOAM is one of many implementations of passport resp. >> postcard mode. Your understanding is that IOAM the only implementation >> correct? >> >> GIM>> The updated terminology, i.e., "OAM header decapsulating node" and >> "OAM header transit node", addresses my concern. You may consider dropping >> "header" altogether. >> >> >> >> GM> 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. >> >> >> >> This has been addressed by refering now to two terms "Passive" and "Hybrid >> Type I" to section 3.7 and 3.8 of RFC 7799 separately. >> >> GIM>> I probably was not clear in my notes. My question is Why Hybrid Type 1 >> and Passive are concatenated in IE's name, e.g., >> OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Sum? >> >> >> >> GM> 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? >> >> >> >> The document scope is IP flow. Therefore IP is used in the naming. >> >> >> >> GM> Some key elements used in the document, e.g., "OAM node" and >> "Collector", are underdefined. >> >> >> >> "Collector" has been used from RFC 7011 and is now defined as well. "OAM >> node" has been replaced with "OAM header encapsulating node", "OAM header >> transit node" and "OAM header decapsulating node" which are defined in the >> document. >> >> GIM>> Thank you. >> >> >> >> GM> 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 agree that the "Packet Stream Generation" section contains two normative >> sentences: >> >> >> >> The time when the packet is being received at the OAM header >> >> encapsulating node. The timestamp format depends on On-Path >> >> Telemetry implementation. >> >> >> >> However the sentences describing possible implementations such as IOAM or >> Enhanced Alternate Marking are not normative since in the preceding section, >> "IP One-Way Delay Hybrid Type I Passive Performance Metrics", a generic >> metric definition is defined as per RFC 8911. >> >> >> >> I hope this addresses your comments. Looking forward to your review. >> >> >> >> Best wishes >> >> Thomas >> >> >> >> >> >> From: Greg Mirsky <[email protected] <mailto:[email protected]>> >> Sent: Friday, August 1, 2025 10:52 PM >> To: [email protected] >> <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]>; >> [email protected] <mailto:[email protected]> >> Subject: [OPSAWG]Re: [IANA #1422930] expert review for >> draft-ietf-opsawg-ipfix-on-path-telemetry (performance-metrics) >> >> >> >> Hi David, >> >> thank you for your kind consideration. Iread the latest version of the draft >> and found that my concern about the naming new IEs ( see comments from 10, >> 2024 >> <https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/>) >> 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. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Tue, Jul 29, 2025 at 1:46 PM David Dong via RT >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Greg, >> >> That will be fine, thank you! >> >> Best regards, >> >> David Dong >> IANA Services Sr. Specialist >> >> On Tue Jul 29 20:44:30 2025, [email protected] >> <mailto:[email protected]> wrote: >> > Hi David, >> > my apologies for the belated response and missing the deadline. I can >> > review the current version by August 1st. Please let me know if that is >> > acceptable to you. >> > >> > Regards, >> > Greg >> > >> > On Tue, Jul 29, 2025 at 12:39 PM David Dong via RT < >> > [email protected] >> > <mailto:[email protected]>> wrote: >> > >> > > Hi Greg, >> > > >> > > Just a ping on this one if you're available to take another look at this >> > > document. >> > > >> > > Thank you! >> > > >> > > Best regards, >> > > >> > > David Dong >> > > IANA Services Sr. Specialist >> > > >> > > On Wed Jul 16 20:58:45 2025, [email protected] >> > > <mailto:[email protected]> wrote: >> > > > Hi David, >> > > > >> > > > As Greg has already reviewed earlier versions of this document, I >> > > > believe that he is in a better position to review this document. >> > > > >> > > > If Greg is not available, I'd have a look myself. >> > > > >> > > > I have not followed this document in detail so far. As far as I can >> > > > see, there has been a OPSAWG list discussion regarding IANA in the >> > > > past. For what it is worth, I back some of the questions raised by >> > > > Greg in his past e-mail >> > > > ( >> > > https://mailarchive.ietf.org/arch/msg/opsawg/kbNvNZgNfDThtg3ZZj9q0Jawx80/ >> > > ). >> > > > And at least in the list archive it is not clear how all of them have >> > > > been resolved, as there is only one follow-up posting. For instance, >> > > > RFC 7799 Section 3.8 doesn't really define a combination of "Hybrid I" >> > > > and "Passive", as far as I read the text of RFC 7799. But Greg has >> > > > probably more context regarding that discussion. >> > > > >> > > > Best regards >> > > > >> > > > Michael >> > > > >> > > > >> > > > >> > > > > -----Original Message----- >> > > > > From: David Dong via RT <[email protected] >> > > > > <mailto:[email protected]>> >> > > > > Sent: Tuesday, July 15, 2025 12:01 AM >> > > > > Cc: [email protected] <mailto:[email protected]>; Scharf, >> > > > > Michael <Michael.Scharf@hs- >> <mailto:Michael.Scharf@hs-%0b>> > > > esslingen.de <http://esslingen.de/>>; >> [email protected] <mailto:[email protected]> >> > > > > Subject: [IANA #1422930] expert review for draft-ietf-opsawg-ipfix- >> > > > > on-path- >> > > > > telemetry (performance-metrics) >> > > > > >> > > > > Dear Greg Mirsky, Michael Scharf (cc: opsawg wg), >> > > > > >> > > > > As the designated experts for the Performance Metrics Registry, can >> > > > > you >> > > > > review the proposed registrations in draft-ietf-opsawg-ipfix-on-path- >> > > > > telemetry-19 for us? Please see >> > > > > >> > > > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-on-path- >> > > > > telemetry/ >> > > > > >> > > > > The due date is July 28th. >> > > > > >> > > > > If this is OK, when the IESG approves the document for publication, >> > > > > we'll make >> > > > > the registration at: >> > > > > >> > > > > https://www.iana.org/assignments/performance-metrics/ >> > > > > >> > > > > Unless you ask us to wait for the other reviewer, we’ll act on the >> > > > > first response >> > > > > we receive. >> > > > > >> > > > > With thanks, >> > > > > >> > > > > David Dong >> > > > > IANA Services Sr. Specialist >> > > >> > > >> Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
