Hi, No comments from my side as well. Approved from my side as well. Thanks Kapil Arora
On Wed, 18 Dec 2024, 22:12 Samson, <samson....@gmail.com> wrote: > 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
