Hi Shraddha, Mukul, and Samson, Mukul and Samson - Thank you for your replies. We have marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9703). We will assume your assent to any further changes submitted by your coauthors unless we hear objection at that time.
Shraddha - Thank you for your reply. We have updated the document accordingly. All - We have a few followup questions/comments (A-F): A) FYI - Regarding: >> 1) ... >> Original: ... >> (short title) >> LSP for SR EPE SIDs with MPLS >> >> Current: ... >> (short title) >> LSP for SR EPE-SIDs with MPLS >> --> > <SH> I think that MPLS data plane should be singular. ACK > Also not sure what you mean by short title. > Is this the title that would appear on the document? Yes and no! The short title appears at the top of each page in just the PDF file. This is not the same as the title at the beginning of the document that appears in all file types. > I would prefer below short title > LSP Ping/Traceroute for SR EPE-SIDs with MPLS ACK B) Regarding: > >> >> 13) <!--[rfced] Section 5.1. >> >> 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. We were meaning to call your attention to the differences between the two points: ...the remote AS field... ...one of the remote AS field... i) May we update both to one or the other for consistency? ii) Also, regarding your feedback "PeerNode SID steps cant be replaced by Peer Set SID procedures.", are you asking to update the text further? If so, please let us know so we may update for correctness. C) Regarding: >> 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 We have added the reference as an informative reference. Please let us know if this needs to be moved to be a normative reference. D) Regarding: > >> >> 14)... >> >> 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 Before making global changes to the document, we want to verify that we are to: i) Keep "sub-TLV" in the text (as it is currently). Should we also add "sub-TLV" to the following instances: > >> >> PeerAdj SID >> PeerAdj SID FEC ii) Remove "FEC" in all instances of "PeerAdj SID FEC": > >> >> PeerAdj SID FEC >> PeerAdj SID FEC sub-TLV Please let us know if this is correct in part or as a whole and if we should proceed differently. E) Regarding: >> 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 Please let us know which capitalizations you want to use. F) Regarding: >> 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 ACK - However, with keeping the original text, may we capitalize "traceroute" to match other occurrences in the document? The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9703.txt https://www.rfc-editor.org/authors/rfc9703.pdf https://www.rfc-editor.org/authors/rfc9703.html https://www.rfc-editor.org/authors/rfc9703.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9703-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9703-auth48diff.html (AUTH48 changes only) Note that it may be necessary for you to refresh your browser to view the most recent version. For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9703 Thank you, RFC Editor/st > On Dec 18, 2024, at 10:42 AM, 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$ > ). > > * 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$ > > * The archive itself: > > 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.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.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-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$ > > > 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$ > > 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
