Hi Alanna, Thank you for the edits. I have reviewed the document and approve for publication.
Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Alanna Paloma <apal...@staff.rfc-editor.org> Sent: 29 January 2025 02:44 To: Shraddha Hegde <shrad...@juniper.net> Cc: rfc-edi...@rfc-editor.org; kapil...@gmail.com; Mukul Srivastava <m...@juniper.net>; samson....@gmail.com; nagendrakumar.nai...@gmail.com; mpls-...@ietf.org; mpls-cha...@ietf.org; adr...@olddog.co.uk; james.n.guich...@futurewei.com; auth48archive@rfc-editor.org Subject: Re: AUTH48: RFC-to-be 9716 <draft-ietf-mpls-spring-inter-domain-oam-20> for your review [External Email. Be cautious of content] Hi Shraddha, Thank you for your reply. We have updated the files as requested. The files have been posted here (please refresh): https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.xml__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_we5sEoVsA$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.txt__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_wcg7RrQlw$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.html__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_weYILTT9w$ https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.pdf__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_wfTlanuLQ$ The relevant diff files have been posted here: https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-diff.html__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_weU3kLSqw$ (comprehensive diff) https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-rfcdiff.html__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_wexUxTcUA$ (side by side) https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-auth48diff.html__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_wfJDtrC1g$ (AUTH48 changes) Please review the document carefully and contact us with any further updates you may have. Note that we do not make changes once a document is published as an RFC. We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process. For the AUTH48 status of this document, please see: https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9716__;!!NEt6yMaO-gk!HKQnASN_GiSe_PH5ncL-89DoCKIJvSoOIHMbdcxphFBCN1JA9OokX-VkKeI4U4u1tFZnkjne7Mxn6KUB_wckCA338w$ Thank you, RFC Editor/ap > On Jan 27, 2025, at 9:04 PM, Shraddha Hegde > <shraddha=40juniper....@dmarc.ietf.org> wrote: > > Hi, > > Thank you for the edits. > Pls see inline for replies <SH>.. > > I could not open the text side-by-side diff link. > Could you pls send the link again ? I want to review the diff before > approving. > > > Rgds > Shraddha > > > Juniper Business Use Only > -----Original Message----- > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Sent: 24 January 2025 04:33 > To: Shraddha Hegde <shrad...@juniper.net>; kapil...@gmail.com; Mukul > Srivastava <m...@juniper.net>; samson....@gmail.com; > nagendrakumar.nai...@gmail.com > Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; > mpls-cha...@ietf.org; adr...@olddog.co.uk; > james.n.guich...@futurewei.com; auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9716 > <draft-ietf-mpls-spring-inter-domain-oam-20> for your review > > [External Email. Be cautious of content] > > > Authors, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the XML file. > > 1) <!-- [rfced] Title > > a.) As "Path Monitoring System/Head-end" is not mentioned in the abstract, > may we clarify the title as follows so that it aligns more closely with the > abstract? It will also help avoid the awkward hyphenation of "Path Monitoring > System/Head-end based". > > Original: > > Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter- > domain Segment Routing Networks > > Perhaps: > > Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain > Segment Routing Networks > > <SH> OK > > b.) Note that we have updated the short title, which appears in the running > header in the PDF output. Please review. > > Original: > Inter-as-OAM > > Current: > MPLS Ping and Traceroute in Inter-Domain SR Networks > > --> > <SH> OK > > 2) <!-- [rfced] FYI - We have slightly adjusted Figure 1 to reduce the > width of the artwork in order to fit the 72-character limit. Please > review. --> <SH> OK > > 3) <!-- [rfced] Please review the following questions regarding the text > below: > > a.) To improve readability, may we remove the "/" characters and update the > text as follows? > > b.) In addition, may we expand "SID" as follows (as Section 3.6 of RFC 7322 > suggests that abbreviations should be expanded upon first use)? > > Original: > > AS1, AS2, and AS3 are SR enabled and the egress links have PeerNode > SID/PeerAdj SID/ PeerSet SID configured and advertised via [RFC9086]. > PeerNode SID/PeerAdj SID/PeerSet SID are referred to as Egress Peer > Engineering SIDs (EPE- SIDs) in this document. > > Perhaps: > > AS1, AS2, and AS3 are SR enabled, and the egress links have the following > Segment Identifiers (SIDs) configured and advertised via [RFC9086]: > PeerNode SID, PeerAdj SID, and PeerSet SID. The PeerNode SID, PeerAdj > SID, and PeerSet SID are referred to as Egress Peer Engineering SIDs (EPE- > SIDs) in this document. > > --> > <SH> OK > > 4) <!--[rfced] To avoid the repetition of "based", may we update this > sentence as follows? > > Original: > > [RFC7743] describes an Echo-relay based solution based on advertising > a new Relay Node Address Stack TLV containing a stack of Echo-relay > IP addresses. > > Perhaps: > > [RFC7743] describes an Echo-relay-based solution that is predicated on > advertising a new Relay Node Address Stack TLV containing a stack of > Echo-relay IP addresses. > > --> > <SH> OK > > 5) <!-- [rfced] Please review our questions regarding the citations in the > text below: > > Original: > > The connectivity to the remote PEs can be achieved using BGP-Labeled > Unicast (BGP-LU) [RFC8277] or by stacking the labels for each domain > as described in [RFC8604]. > > a.) We were unable to find the term "BGP-Labeled Unicast (BGP-LU)" used in > RFC 8277 or other previous RFCs. How may we update this citation accordingly? > > b.) We were unable to find content about "stacking labels" in RFC 8064. > Please review and let us know if any updates are needed. > > --> > <SH> The connectivity to the remote PEs can be achieved by BGP > advertisements With MPLS label bound to the prefix as described in [RFC > 8277] or by building paths using list of segments as described in [RFC8604]. > > 6) <!-- [rfced] Please review our updates to the text below to ensure these > changes do not alter your intended meaning. > > Original: > > This document defines the Type-A, Type-C, and Type-D Segment sub-TLVs > usage and processing when it appears in TLV 21(Reply Path TLV). > > Current: > > This document defines the usage and processing of the Type-A, Type-C, and > Type-D Segment sub-TLVs when they appear in TLV 21 (Reply Path TLV). > > --> > <SH> ok > > 7) <!-- [rfced] May we add "(MBZ)" to the text following Figure 4 to reflect > similar text that appears following Figure 5? > > Original (appears after Figure 4): > > When A-flag is unset, this > field has no meaning and thus MUST be set to zero on transmission and > ignored on receipt. > > Original (appears after Figure 5): > > When A-flag is unset, this > field has no meaning and thus MUST be set to zero (MBZ) on transmission and > ignored on receipt. > > --> > <SH> OK > > 8) <!-- [rfced] FYI - We have removed the second sentence from the definition > below as it repeats information from the first sentence. Please review and > let us know if further updates are needed. > > Original: > > SID: optional: 4-octet field containing label, TC, S and TTL as > defined in Section 4.1. The SID is optional and specifies a 4-octet > MPLS SID containing label, TC, S, and TTL as defined in Section 4.1. > When the SID field is present, it MUST be used for constructing the > Reply Path. > > Current: > > SID: Optional 4-octet field containing the labels TC, S, and TTL as > defined in Section 4.1. When the SID field is present, it MUST be > used for constructing the Reply Path. > > --> > <SH> OK > > 9) <!-- [rfced] FYI - We have updated the text below for clarity; please > review. > > Original: > > If optional MPLS SID is present in the Type-C/Type-D segments SID > MUST be used to encode the echo reply with MPLS labels. > > Current: > > If an optional MPLS SID is present in the Type-C/Type-D segments, the SID > MUST be used to encode the echo reply with MPLS labels. > > --> > <SH> OK > > 10) <!--[rfced] IANA queries > > (Note: After this document completes AUTH48, we will ask IANA to > update their registry accordingly.) <SH> OK > > a.) To reflect the definition of "Type-A", should a comma be added after "SID > only" in the Sub-TLV Name of Sub-Type 46? > > Current: > > Type-A: SID only, in the form of an MPLS label > ... > +-==========+-====================================+-=============+- > | Sub-Type | Sub-TLV Name | Reference | > +-==========+-====================================+-=============+- > | 46 | SID only in the form of MPLS label | Section 4.1 | > | | | of RFC 9716 | > > > <SH> OK > > b.) As other values registered in the "Reply Path Return Codes" registry do > not include periods, we have removed the periods from the descriptions of the > following values registered by this document. Please let us know of any > objections. > > Original: > > TBA1 Use Reply Path TLV from this echo > reply for building next echo request. > > TBA2 Local policy does not allow dynamic > return Path building. > > Current: > > 0x0006 Use Reply Path TLV from this echo > reply for building the next echo request > > 0x0007 Local policy does not allow dynamic > return path building > > --> > <SH> OK > > 11) <!-- [rfced] FYI - We have updated the [IEEE-802.1AE] reference entry as > follows. Please review. > > Original: > > [IEEE-802.1AE] > IEEE, "IEEE Standard for Local and metropolitan area > networks-Media Access Control (MAC) Security", August > 2023. > > Current: > > [IEEE-802.1AE] > IEEE, "IEEE Standard for Local and metropolitan area > networks-Media Access Control (MAC) Security", IEEE Std > 8021.AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December > 2018, > <https://urldefense.com/v3/__https://ieeexplore.ieee.org/document/8585421__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD3LMsDLl$ > >. > --> > > <SH> OK > 12) <!--[rfced] FYI - The section previously titled "APPENDIX" has been moved > after the references and is now titled as "Examples". > Please review. > --> > > <SH> OK > 13) <!--[rfced] As the "/" character can mean "and", "or", or "and/or", "the > controller/PMS or head-end node" is unclear in the sentence below. Please > review and let us know how this sentence may be clarified. > > Original: > > Topology of AS1 and AS2 are > advertised via BGP-Link State (BGP-LS) to the controller/PMS or head- > end node. > > --> > <SH> / means "OR" here. > > 14) <!-- [rfced] Please review our changes to the text below to ensure these > updates do not alter your intended meaning. > > Original: > > The same Reply Path TLV is sufficient for any router in AS2 to send the > reply. Because the first label(N-ASBR4) can direct echo reply to ASBR4 and > the second one (EPE-ASBR4-ASBR1) to direct echo reply to AS1. > ... > The example described in the above paragraphs can be extended to > multiple ASes by following the same procedure of each ASBR adding > Node-SID and EPE-SID on receiving echo requests from neighboring AS. > > Current: > > The same Reply Path TLV is sufficient for any router in AS2 to send the > reply. This is because the first label (N-ASBR4) can direct the echo reply > to ASBR4 and the second one (EPE-ASBR4-ASBR1) can direct the echo reply to > AS1. > ... > The example described in the above paragraphs can be extended to multiple > ASes. This is done by following the same procedure for each ASBR, i.e., > adding Node-SIDs and EPE-SIDs on receiving echo requests from neighboring > ASes. > > --> > <SH> OK > > 15) <!--[rfced] We are having some difficulty understanding how "while > sending the echo reply" fits into this sentence. May we clarify this sentence > as follows? > > Original: > > ABR1 receives the echo request > and while sending the echo reply adds its node Label to the Reply > Path TLV and sets the Reply path return code to TBA1. > > Perhaps: > > ABR1 receives the echo request, adds its node Label to the Reply > Path TLV (while sending the echo reply), and sets the Reply path return > code to 0x0006. > > --> > <SH> OK. > > 16) <!-- [rfced] Terminology: > > a.) The following terms appear to be capitalized inconsistently throughout > this document. Please review these different uses and let us know how to > update for consistency. > > A-Flag vs. A-flag vs. A Flag > <SH> A-Flag > > Reply Path return code vs. reply path return code vs. Reply path > return code <SH> Reply Path return code > > Segment Types vs. segment Types vs. segment types > > <SH>Segment Types > > SR path vs. SR Path > <SH> SR Path > > SR Policy vs. SR policy > <SH> SR Policy > > > b.) We note inconsistencies in the terms listed below. We updated to the form > on the right. Please let us know any concerns. > > Inter-AS vs. inter-AS > <SH> OK > Inter-domain vs. inter-domain > <SH> OK > Sub-TLV vs. sub-TLV > <SH> OK > Label vs. label (when used generally) > <SH> ok > Segment Sub-TLV vs. segment sub-TLV vs. Segment sub-TLV <SH> OK MPLS > Label vs. MPLS label <SH> OK > > IPv4 node address vs. IPv4 Node Address <SH> OK > IPv6 node address vs. IPv6 Node Address <SH> OK > > > c.) We have updated the following terms to reflect how they appear in > previously published RFCs. Please review and let us know of any objections. > > BGP Peering Segments > BGP peering segments (per RFC 8402) <SH> OK > Centralized BGP Egress Peer Engineering > centralized BGP Egress Peer > Engineering (per RFC 9087) <SH> OK > > > d.) FYI - We have removed quotation marks from around the following field > names to reflect how field names are more commonly used throughout the text. > > Original: > > The Segment Types described above contain the following flags in the > "Flags" field (codes to be assigned by IANA from the new registry > "Segment Sub-TLV Flags"): > ... > A-Flag: This flag indicates the presence of SR Algorithm ID in the > "SR-Algorithm" field applicable to various segment Types. > > Current: > > The Segment Types described above contain the following flags in the > Flags field (codes assigned by IANA from the "Segment ID Sub-TLV > Flags" registry): > ... > A-Flag: This flag indicates the presence of an SR Algorithm ID in > the SR Algorithm field applicable to various segment Types. > <SH> OK > > e.) Per RFC 8029, may we capitalize all instances of "return code"? > > --> > <SH> OK > > 17) <!-- [rfced] FYI - We have added expansions for abbreviations upon first > use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > > Forwarding Equivalence Class (FEC) > Media Access Control Security (MACsec) > > --> > <SH> OK > > 18) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide > <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD8E22Xgr$ > > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which[IEEE-802.1AE] is helpful for > readers. > > Note that our script did not flag any words in particular, but this should > still be reviewed as a best practice. > --> > <SH> OK > > Thank you. > > RFC Editor/kf/ap > > > On Jan 23, 2025, at 3:02+IC8-PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2025/01/23 > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and approved > by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies available as > listed in the FAQ > (https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-k5UviL$ > ). > > You and you coauthors are responsible for engaging other parties (e.g., > Contributors or Working Group) as necessary before providing your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP +IBM > https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDz5iektO$ > ). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > > <https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxBIHBB0$ > >. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using +IBg-REPLY ALL+IBk as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * rfc-edi...@rfc-editor.org (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD5yArK-_$ > > * The archive itself: > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD5POq1mx$ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > auth48archive@rfc-editor.org will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > +IBQ OR +IBQ > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit list > of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, and > technical changes. Information about stream managers can be found in the > FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating that > you approve this RFC for publication. Please use +IBg-REPLY ALL+IBk, as all > the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.xml__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-gMj3BM$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD0EICwtZ$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.pdf__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD6zBnDjK$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716.txt__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxxrD7Ab$ > > Diff file of the text: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-diff.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDxEigQtD$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-rfcdiff.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMDykF9OTr$ > (side by side) > > Diff of the XML: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9716-xmldiff1.html__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD2WHfV2S$ > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9716__;!!NEt6yMaO-gk!HaATadzYlFDiy1PvZZeL81r-taqAVJrT5ZVs4euc40O73gOqOd910nVCLjV9y0m28ygLtwl68evidYtMD-j1uYHH$ > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9716 (draft-ietf-mpls-spring-inter-domain-oam-20) > > Title : Path Monitoring System/Head-end based MPLS Ping and > Traceroute in Inter-domain Segment Routing Networks > Author(s) : S. Hegde, K. Arora, M. Srivastava, S. Ninan, N. Kumar > WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li > > Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
