I also approve the document for publication. Thanks, Samson
On Wed, Jan 29, 2025 at 12:07 AM Shraddha Hegde <shrad...@juniper.net> wrote: > 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
