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 <http:///>: > > - 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 > > > > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
