Hi Thomas, Thank you for a very constructive discussion and thoughtful consideration of my comments.
Hi Mahesh, Thank you for guiding throughout the discussion. The publication of this valuable document marks a significant achievement in the further development of performance measurement methods and metrics. Regards, Greg On Wed, Oct 1, 2025 at 11:27 AM Mahesh Jethanandani <[email protected]> wrote: > 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 > Doc: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-on-path-telemetry-23 > > Best wishes > Thomas > > *From:* Greg Mirsky <[email protected]> > *Sent:* Monday, September 29, 2025 8:57 PM > *To:* Mahesh Jethanandani <[email protected]> > *Cc:* Graf Thomas, SCS-INI-NET-VNC-E2E <[email protected]>; > [email protected]; Michael SCHARF < > [email protected]>; opsawg <[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 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]: > > > > 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] > > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
