Hi Mahesh, Thank you for your pragmatic proposal. Yes, removing _Passive from the names of performance metrics proposed for the Performance Metrics Registry would address my concern.
Regards, Greg On Mon, Sep 29, 2025 at 11:39 AM Mahesh Jethanandani < [email protected]> wrote: > 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]> 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]> >> *Cc:* [email protected]; >> [email protected]; [email protected]; [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]> >> *Sent:* Monday, September 8, 2025 2:53 AM >> *To:* Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> >> *Cc:* [email protected]; >> [email protected]; [email protected]; [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]> 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]> >> *Sent:* Saturday, September 6, 2025 8:33 PM >> *To:* Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> >> *Cc:* [email protected]; >> [email protected]; [email protected]; [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]> 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]> >> *Sent:* Saturday, September 6, 2025 2:16 AM >> *To:* Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]> >> *Cc:* [email protected]; >> [email protected]; [email protected]; [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]> 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]> >> *Sent:* Friday, August 1, 2025 10:52 PM >> *To:* [email protected] >> *Cc:* [email protected]; [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]> 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] 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]> 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] 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]> >> > > > > Sent: Tuesday, July 15, 2025 12:01 AM >> > > > > Cc: [email protected]; Scharf, Michael <Michael.Scharf@hs- >> <Michael.Scharf@hs-%0b>> > > > esslingen.de>; [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]
