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
