I also don't have any other comments and it's approved from my side. Thank you, Samson
On Wed, Dec 18, 2024, 21:45 Mukul Srivastava <m...@juniper.net> wrote: > I have no further comments. > > Approved from my side. > > > > Thanks > > Mukul > > > > Juniper Business Use Only > > *From: *Shraddha Hegde <shrad...@juniper.net> > *Date: *Wednesday, December 18, 2024 at 6:40 AM > *To: *rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, Mukul > Srivastava <m...@juniper.net>, kapil...@gmail.com <kapil...@gmail.com>, > samson....@gmail.com <samson....@gmail.com>, xuxiaohu_i...@hotmail.com < > xuxiaohu_i...@hotmail.com> > *Cc: *mpls-...@ietf.org <mpls-...@ietf.org>, mpls-cha...@ietf.org < > mpls-cha...@ietf.org>, tsaad....@gmail.com <tsaad....@gmail.com>, > james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > *Subject: *RE: AUTH48: RFC-to-be 9703 <draft-ietf-mpls-sr-epe-oam-19> for > your review > > Hi, > > > Thanks for the edits. Pls see inline for response tagged by <SH> > > Rgds > Shraddha > > > Juniper Business Use Only > -----Original Message----- > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Sent: 14 December 2024 05:46 > To: Shraddha Hegde <shrad...@juniper.net>; Mukul Srivastava < > m...@juniper.net>; kapil...@gmail.com; samson....@gmail.com; > xuxiaohu_i...@hotmail.com > Cc: rfc-edi...@rfc-editor.org; mpls-...@ietf.org; mpls-cha...@ietf.org; > tsaad....@gmail.com; james.n.guich...@futurewei.com; > auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9703 <draft-ietf-mpls-sr-epe-oam-19> 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] We updated "MPLS Data Plane" to "MPLS Data Planes" in the > document title. If that is not correct and it should be singular, please > let us know. We also added a hyphen to "EPE SIDs" in the abbreviated title > that spans the PDF to match the running text. > > Original: > (title) > Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) > Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS > Data Plane > > (short title) > LSP for SR EPE SIDs with MPLS > > Current: > (title) > Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) > Egress Peer Engineering (EPE) Segment Identifiers (SIDs) with MPLS > Data Planes > > (short title) > LSP for SR EPE-SIDs with MPLS > --> > <SH> I think that MPLS data plane should be singular. Also not sure what > you mean by short title. > Is this the title that would appear on the document? > I would prefer below short title > LSP Ping/Traceroute for SR EPE-SIDs with MPLS > > 2) <!-- [rfced] FYI - In Figure 1, we updated "AS 2", "AS 3", and "AS 4" > to have no spaces in order to match "AS1" in the diagram and "AS2" and > "AS3" in the subsequent text. Please let us know if there is any objection. > > AS 2 > AS2 > AS 3 > AS3 > AS 4 > AS4 > --> > > <SH> This is ok > 3) <!--[rfced] Please clarify this sentence. Are SR paths built using > either EPE-SIDs or PCEP extensions? Please let us know which option is > preferred. > > Original: > These EPE-SIDs may be used to build Segment Routing paths as described > in [I-D.ietf-idr-segment-routing-te-policy] or using Path Computation > Element Protocol (PCEP) extensions as defined in [RFC8664]. > > Perhaps A: > These EPE-SIDs may be used to build SR paths as described > in [SR-TE-POLICY]], or Path Computation Element Protocol (PCEP) > extensions as defined in [RFC8664] may be used. > or > > Perhaps B: > SR paths are built using these EPE-SIDs as described in [SR-TE-POLICY] > or Path Computation Element Protocol (PCEP) extensions as defined in > [RFC8664]. > --> > <SH> The previous sentence is misleading. I would propose below > modification > > These EPE-SIDs may be used to build SR paths and communicated using > extensions described > in [SR-TE-POLICY-IDR]] or Path Computation Element Protocol (PCEP) > extensions as defined in [RFC8664]. > > Pls note the change in shorthand for SR-TE-POLICY. Its important to > indicate its and IDR extension > > 4) <!--[rfced] Would it be correct to say that the extensions do not > define how to "acquire" or "acquire and carry" the details of the SID, or > is the intension to only mention "carry"? We ask because the next few > sentences discuss how the node can "acquire the details". > > Original: > The extensions in [I-D.ietf-idr-segment-routing-te-policy] and > [RFC8664] do not define how to carry the details of the SID > that can be used to construct the FEC. > > Perhaps: > The extensions in [SR-TE-POLICY] and [RFC8664] do not define how > to acquire and carry the details of the SID that can be used to > construct the FEC. > --><SH> This is ok > > > 5) <!--[rfced] It appears that Table 1 (Section 4) and Table 2 (Section 6) > are the same. Would you like to remove Table 1 and add a link to Table 2 > (which would then become Table 1) as shown below? > > Current: > In this document, three new sub-TLVs are defined for the Target FEC > Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), > and the Reply Path TLV (Type 21). > > - Table 1 - > > Perhaps: > In this document, three new sub-TLVs are defined for the Target FEC > Stack TLV (Type 1), the Reverse-Path Target FEC Stack TLV (Type 16), > and the Reply Path TLV (Type 21); see Table 1. > --> > <SH> ok > > 6) <!--[rfced] Is "the OAM packet will be sent out" an example of what is > specified? We updated this sentence as reflected below; if that is not > correct, please let us know. > > Original: > As per [RFC8029], the node advertising the EPE SIDs will send > Downstream Detailed Mapping (DDMAP TLV) specifying the details > of nexthop interfaces, the OAM packet will be sent out. > > Current: > As per [RFC8029], the node advertising the EPE-SIDs will send a > Downstream Detailed Mapping (DDMAP) TLV specifying the details > of the next-hop interfaces, e.g., when the OAM packet will be > sent out. > --> > Suggest as below remov the OAM packet will be sent out > > New: > As per [RFC8029], the node advertising the EPE SIDs will send > Downstream Detailed Mapping (DDMAP TLV) specifying the details > of nexthop interfaces. > > > > 7) <!--[rfced] We believe that the slash indicates "or" in these > instances, so we updated accordingly for clarity. If that is not correct or > desired, please let us know. > > Original: > Local Interface Address :4 octets/16 octets > > Remote Interface Address :4 octets/16 octets > > Current: > Local Interface Address: 4 octets or 16 octets > > Remote Interface Address: 4 octets or 16 octets > --> > <SH> This is ok > > 8) <!-- [rfced] FYI - For conciseness, we updated this sentence as > follows. Please let us know if there is any objection. > > Original: > [RFC9086] allows optional link descriptors of local and > remote interface addresses as described in section 4.2. > > Current: > Optional link descriptors of local and remote interface > addresses are allowed as described in Section 4.2 of [RFC9086]. > --><SH> ok > > > 9) <!-- [rfced] FYI - Since "RECOMMENDED", not "RECOMMENDS", is a BCP 14 > key word, we rephrased the text as shown below. > > Original: > This document RECOMMENDs sending these optional descriptors and using > them to validate incoming interface. > > Current: > In this document, it is RECOMMENDED to send these optional descriptors > and use them to validate incoming interfaces. > --><SH> ok > > > 10) <!--[rfced] Is it intentional that instances of "No.of" do not contain > a space? Please let us know if this should remain as is or if a space can > be added (e.g., "No. of"). Note that there are seven occurrences. > > Two examples (see the text for more): > > Original: > No.of elements in set > > Length = (20 + No.of IPv4 interface pairs * 8 > > Perhaps: > No. of elements in set > > Length = (20 + No. of IPv4 interface pairs * 8 > --> <SH> Pls edit as needed. The absence of space is not intended > > > 11) <!--[rfced] Should "variable" be singular (option A) or plural (option > B) in the following sentence? > > Original: > Value: Expressed in octets and variable based on the number of > elements in the set. > > Perhaps A: > Value: Expressed in octets and a variable based on the number of > elements in the set. > or > > Perhaps B: > Value: Expressed in octets and variables based on the number of > elements in the set. > --> > Suggest below > > Value: Expressed in octets and is a variable based on the number of > elements in the set. > > 12) <!-- [rfced] We notice that the titles of Sections 5 and 5.1 are the > same. How may we update these to avoid confusion? Is Section 5.1 perhaps > the example validation, e.g., "EPE-SID FEC Validation Examples" (option A) > or "Segment Routing IGP-Prefix, IGP-Adjacency SID, and EPE-SID Validation > Examples (option B)? > > Original: > 5. EPE-SID FEC validation > 5.1. EPE-SID FEC validation > > Perhaps A: > 5. EPE-SID FEC Validation > 5.1. EPE-SID FEC Validation Examples > > or > > Perhaps B: > 5. EPE-SID FEC Validation > 5.1. Segment Routing IGP-Prefix, IGP-Adjacency SID, > and EPE-SID Validation Examples > --> > <SH> Suggest below > 5. EPE-SID FEC Validation > 5.1. EPE-SID FEC Validation Rules > > 13) <!--[rfced] Section 5.1. > > a) Please let us know how we may clarify the first sentence in this > section. Are Segment Routing IGP-Prefix, IGP-Adjacency SID, and EPE-SID > being validated, and is the term "receiving node" > implying that the node received the OAM message as shown below? > > Original: > Segment Routing IGP-Prefix, IGP-Adjacency SID and EPE-SID Validation: > Receiving node term used in this section implies the node that > receives OAM message with the FEC stack TLV. > > Perhaps: > This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID, and > EPE-SID validations. Note that the term "receiving node" in this > section > implies that the node receives the OAM message with the FEC stack TLV. > <SH> suggested as below > This is an example of Segment Routing IGP-Prefix, IGP-Adjacency SID, and > EPE-SID validations. Note that the term "receiving node" in this > section > Corresponds to the node that receives the OAM message with the FEC > stack TLV. > > b) For clarity, may we update "If any below conditions fail" to "Check if > any conditions below fail" (note that there are 4 instances)? > > Original: > If any below conditions fail: > > - Validate that the receiving node's BGP... > > Perhaps: > Check if any conditions below fail: > > - Validate that the receiving node's BGP... > <SH>ok > > c) Should the text reflect "the receiving node's BGP" or "the Receiving > Node BGP" for consistency (note that there are multiple instances)? > <SH> I think "the receiving node's BGP" is correct. BGP is a protocol that > runs on the node. > > d) Should "the remote AS field" or "one of the remote AS fields" be used > for consistency? > > Original: > - Validate that the receiving node's BGP Local AS matches > with the remote AS field in the received PeerNode SID > FEC sub-TLV. > > - Validate that the Receiving Node BGP Local AS matches > with one of the remote AS field in the received > PeerSet SID FEC sub-TLV. > > <SH> PeerNode SID steps cant be replaced by Peer Set SID procedures. > > > e) Should citations be included for return codes 3 and 10? Should "<RSC>" > be added to the descriptions to match how they appear in RFC 8029? > > Original: > Set the Best-return-code to 10, "Mapping for this FEC is not > the given label at stack-depth". If any below conditions fail: > > If all above validations have passed, set the return code to 3, > "Replying router is an egress for the FEC at stack-depth". > > Perhaps: > Set the Best-return-code to 10, "Mapping for this FEC is not > the given label at stack-depth <RSC>" [RFC8029]. If any below > conditions fail: > > If all above validations have passed, set the return code to 3, > "Replying router is an egress for the FEC at stack-depth <RSC>" > [RFC8029]. > --><SH> ok > > > 14) <!-- [rfced] We have included some specific questions about the IANA > text below. In addition to responding to those questions, please review all > of the IANA-related updates carefully and let us know if any further > updates are needed. > > a) It appears that the "IANA Considerations" section references the > "Sub-TLVs for TLV Types 1, 16, and 21" registry in the "Multiprotocol Label > Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" > registry group, but it does not include a citation for this registry here > or in the references section. > > May we add the following citation as a normative or informative reference > as shown below? > > Original: > IANA is requested to allocate three new Target FEC stack sub-TLVs > from the "Sub-TLVs for TLV types 1,16 and 21" subregistry in the > "TLVs" registry of the "Multi-Protocol Label switching (MPLS) Label > Switched Paths (LSPs) Ping parameters" namespace. > > Perhaps: > IANA has allocated three new Target FEC stack sub-TLVs in the > "Sub-TLVs for TLV Types 1, 16, and 21" registry > [IANA-MPLS-LSP-PING-Parameters] within the "TLVs" registry of the > "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) > Ping Parameters" registry group. > > Reference: > [IANA-MPLS-LSP-PING-Parameters] > IANA, "Sub-TLVs for TLV Types 1, 16, and 21", > < > https://urldefense.com/v3/__https://www.iana.org/assignments/mpls-lsp-ping-parameters__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chTV9e9Lv$ > >. > > <SH> OK > > b) We have removed "Sub-TLV" from the entries in Tables 1 and 2 per IANA's > note. Please let us know if "Sub-TLV" should be removed from any other > instances in the running text for consistency. > We note the following variations: > > PeerAdj SID > PeerAdj SID FEC > PeerAdj SID FEC sub-TLV > PeerAdj SID Sub-TLV > PeerAdj SID sub-TLV > > PeerSet SID sub-TLV > PeerNode SID sub-TLV > --><SH> Pls keep the sub-TLV and remove FEC " PeerAdj SID Sub-TLV" > consistently in all the text. > The IANA table can follow IANA's Note > > > > 15) <!-- [rfced] Since 'draft-ietf-idr-segment-routing-te-policy' > is expired and has been replaced by > 'draft-ietf-idr-bgp-sr-segtypes-ext' and 'draft-ietf-idr-sr-policy-safi', > may we replace the current reference entry with the entries for these two > drafts? > > Note that this would include adding two reference tags to the text in > Section 2. > > Original: > [SR-TE-POLICY] > Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and > D. Jain, "Advertising Segment Routing Policies in BGP", > Work in Progress, Internet-Draft, draft-ietf-idr-segment- > routing-te-policy-26, 23 October 2023, > < > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chcINvc0-$ > segment-routing-te-policy-26>. > > Perhaps: > [BGP-SR-SEGTYPES-EXT] > Talaulikar, K., Filsfils, C., Previdi, S., Mattes, P., and > D. Jain, "Segment Routing Segment Types Extensions for BGP > SR Policy", Work in Progress, Internet-Draft, draft-ietf- > idr-bgp-sr-segtypes-ext-06, 7 November 2024, > < > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chfFJ8uqL$ > sr-segtypes-ext-06>. > > [SR-BGP-POLICY] > Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and > D. Jain, "Advertising Segment Routing Policies in BGP", > Work in Progress, Internet-Draft, draft-ietf-idr-sr- > policy-safi-10, 7 November 2024, > < > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chaYNd1Mw$ > policy-safi-10>. > --><SH> OK > > > 16) <!-- [rfced] May we update the title of the appendix to avoid the > repetition of "Appendix A: Appendix"? Perhaps "Examples of Correctly and > Incorrectly Programmed States" or "Examples of Programmed States? > > Current: > Appendix A. Appendix > > Perhaps: > Appendix A. Examples of Programmed States > --><SH>ok > > > 17) <!-- [rfced] Terminology and Abbreviations > > a) Throughout the text, the following terminology appears to be > capitalized inconsistently. Please review these occurrences and let us know > if/how they may be made consistent. > > Adj-Type vs. Adj type > Integer vs. integer > Local AS number vs. local AS number > Local interface vs. local interface > Link Descriptors vs. link descriptors > Remote interface vs. remote interface > <SH> yes. They should be consistent > > b) How may we make these terms consistent? For the case, we suggest > capitalizing "Target" and "Stack" to match use in RFC 8287 and other past > RFCs. > > Target FEC Stack TLV vs. > Target FEC stack TLV vs. > target FEC stack TLV vs. > target FEC stack > [Note: should the last instance contain "TLV"?] > <SH> "Target FEC Stack TLV" is the right usage > Change the last instance as well > > FEC stack TLV vs. > FEC stack > [Note: should "Target" be added to these instances? And > should the last instance contain "TLV"?] > <SH> > Original: > As described in Section 1, this document defines FEC stack TLVs for > EPE-SIDs, > > Change to > As described in Section 1, this document defines sub-TLVs of the Target > FEC Stack TLV for > EPE-SIDs > > > Target FEC Stack sub-TLV vs. > Target FEC stack sub-TLV vs. > Target FEC sub-TLV > [Note: should "Stack" be added to the last instance?] > > <SH> Pls change to "Target FEC Stack sub-TLV" for all instances > > c) In the text, "Type 1" appears to have two different names. Are these > meant to be the same or different? We see "Target FEC Stack TLV (Type 1)" > in RFC 8287. > Please let us know how/if we may update. Note that we recommend making > "stack" > uppercase for consistency. > > Abstract: > MPLS Target stack TLV (Type 1) > <SH> change to" Target FEC Stack TLV(Type 1)" > > Section 4: > Target FEC Stack TLV (Type 1) > <SH> This one looks fine > > d) It appears that in past RFCs, the term "FEC stack-depth" is used > instead of "FEC-stack-depth". Should we update to only one hyphen? > <SH>ok > > > e) We see "MPLS Ping and Traceroute procedures" and "ping or traceroute > packets" > in the running text. Should 1 instance of "MPLS traceroute procedure" > perhaps be "MPLS Ping and Traceroute procedures" for consistency? > > Original: > The data plane validation of the SID will be done during the > MPLS traceroute procedure. > > Perhaps: > The data plane validation of the SID will be done during the > MPLS Ping and Traceroute procedures. > <SH> No. The validation applicable to traceroute only. Pls keep original > text > > f) FYI - We added expansions for the following abbreviations in the text. > Please review for accuracy. > > ASN: Access Service Network > <SH> Pls change ASN to AS Number > > BGP-LS: Border Gateway Protocol - Link State > EBGP: External BGP > OAM: Operations, Administration, and Maintenance > <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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chaUIxJYx$ > > and let us know if any changes are needed. Updates of this nature > typically result in more precise language, which 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/st/kc > > > On Dec 13, 2024, at 4:14 PM, rfc-edi...@rfc-editor.org wrote: > > *****IMPORTANT***** > > Updated 2024/12/13 > > 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chftkYTRQ$ > ). > > 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 – > https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYaCgDkH$ > <https://urldefense.com/v3/__https:/trustee.ietf.org/license-info__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYaCgDkH$> > ). > > * 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chUj2pAgn$ > >. > > * 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 ‘REPLY ALL’ 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!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdiPGFLb$ > <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdiPGFLb$> > > * The archive itself: > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chWbVSeVB$ > <https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chWbVSeVB$> > > * 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 > — OR — > 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 ‘REPLY ALL’, 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/rfc9703.xml__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chfOrRqCw$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703.xml__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chfOrRqCw$> > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdWgWwU-$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chdWgWwU-$> > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.pdf__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chUiabt79$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703.pdf__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chUiabt79$> > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703.txt__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYcSJ6_w$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703.txt__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chYcSJ6_w$> > > Diff file of the text: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-diff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chRs2yfwd$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703-diff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chRs2yfwd$> > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-rfcdiff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chZfCnyBt$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703-rfcdiff.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chZfCnyBt$> > (side by side) > > Diff of the XML: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9703-xmldiff1.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chQNcNkqZ$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/authors/rfc9703-xmldiff1.html__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chQNcNkqZ$> > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9703__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chbYoLjPh$ > <https://urldefense.com/v3/__https:/www.rfc-editor.org/auth48/rfc9703__;!!NEt6yMaO-gk!FQ0xv4n_uks3qfMaOruoB-6ugBXHCZ51YQAZyGId0xJdMf4K3cPb6WVvy3YeR8aM1-heH_8JtjxSBm-chbYoLjPh$> > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC9703 (draft-ietf-mpls-sr-epe-oam-19) > > Title : Label Switched Path (LSP) Ping/Traceroute for Segment > Routing (SR) Egress Peer Engineering Segment Identifiers (SIDs) with MPLS > Data Plane > Author(s) : S. Hegde, M. Srivastava, K. Arora, S. Ninan, X. Xu > 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
