Thomas/Greg, Thanks for closing on all the open issues. I will proceed with a publication request.
> On Sep 30, 2025, at 10:02 PM, [email protected] wrote: > > Dear Greg and Mahesh, > > Thanks a lot. All good with me. I removed the passive references from the > performance metric and IPFIX entity names and the terminology and submitted > the changes in -23. > > Diff: > https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-22&url2=draft-ietf-opsawg-ipfix-on-path-telemetry-23&difftype=--html > > <https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-22&url2=draft-ietf-opsawg-ipfix-on-path-telemetry-23&difftype=--html> > Doc: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-23 > > <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-23> > > Best wishes > Thomas > > From: Greg Mirsky <[email protected] <mailto:[email protected]>> > Sent: Monday, September 29, 2025 8:57 PM > To: Mahesh Jethanandani <[email protected] > <mailto:[email protected]>> > Cc: Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; Michael SCHARF > <[email protected] <mailto:[email protected]>>; > opsawg <[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 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] > <mailto:[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] > <mailto:[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 > > <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 > <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 > <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 > inhttps://datatracker.ietf.org/doc/html/rfc8911#section-5 > <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 > <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 > <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 > <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 > <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 > > <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 > <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/ > > > <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- > > > > > <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/ > > > > > <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] <mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
