Greetings, Rakesh, thank you for your reply. We have updated the document as noted below. Looking at the change in the diff, we would appreciate you or one of your coauthors confirming that this update is as intended. Specifically, please confirm whether:
… response messages with an IP/UDP header “out-of-band” … is the same as or was intended to be … a response to an Out-of-band Response Requested message … The current files are available her: https://www.rfc-editor.org/authors/rfc9779.xml https://www.rfc-editor.org/authors/rfc9779.txt https://www.rfc-editor.org/authors/rfc9779.pdf https://www.rfc-editor.org/authors/rfc9779.html Diffs highlighting the most recent updates: https://www.rfc-editor.org/authors/rfc9779-lastdiff.html https://www.rfc-editor.org/authors/rfc9779-lastrfcdiff.html (side by side) AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9779-auth48diff.html https://www.rfc-editor.org/authors/rfc9779-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9779-diff.html https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html (side by side) Thank you, RFC Editor/sg > On Apr 21, 2025, at 3:43 PM, Rakesh Gandhi (rgandhi) <rgan...@cisco.com> > wrote: > > Hello Sandy, > > Thanks for the great updates. They all look good to me. > > Please see inline with one comment <RG>.. > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Date: Monday, April 21, 2025 at 5:19 PM > To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com> > Cc: RFC Editor <rfc-edi...@rfc-editor.org>, Clarence Filsfils (cfilsfil) > <cfils...@cisco.com>, daniel.vo...@bell.ca <daniel.vo...@bell.ca>, > stefano.sals...@uniroma2.it <stefano.sals...@uniroma2.it>, > mach.c...@huawei.com <mach.c...@huawei.com>, > danvoyerw...@gmail.com<danvoyerw...@gmail.com>, Dan Voyer (davoyer) > <davo...@cisco.com>, mpls-...@ietf.org <mpls-...@ietf.org>, > mpls-cha...@ietf.org <mpls-cha...@ietf.org>, tony...@tony.li > <tony...@tony.li>, james.n.guich...@futurewei.com > <james.n.guich...@futurewei.com>, > auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > Subject: Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for your > review > > Hi Rakesh, > > Thank you for your review and reply. We have updated the document based on > your replies below. For item 9, we are having trouble parsing the text: > > > <RG> How about following? > > > > In one-way measurement mode defined in Section 2.4 of [RFC6374], the > > querier can receive response messages with an IP/UDP > > header “out-of-band” by properly setting the UDP Return Object (URO) TLV > > in the > > query message. > > We wonder if the following correctly conveys the intended meaning? > > In one-way measurement mode defined in Section 2.4 of [RFC6374], the > querier can receive a response to an Out-of-band Response Requested > message by properly setting the UDP Return Object (URO) TLV > in the IP/UDP header. > > > <RG> Looks good. > > Thanks, > > Rakesh > > > > Please review the updated files here: > https://www.rfc-editor.org/authors/rfc9779.xml > https://www.rfc-editor.org/authors/rfc9779.txt > https://www.rfc-editor.org/authors/rfc9779.pdf > https://www.rfc-editor.org/authors/rfc9779.html > > AUTH48 diffs (highlight only the changes noted below): > https://www.rfc-editor.org/authors/rfc9779-auth48diff.html > https://www.rfc-editor.org/authors/rfc9779-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9779-diff.html > https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html (side by side) > > Please review and let us know if additional updates are needed or if you > approve the RFC for publication. > > Thank you, > RFC Editor/sg > > > > > On Apr 16, 2025, at 8:01 PM, Rakesh Gandhi (rgandhi) > > <rgandhi=40cisco....@dmarc.ietf.org> wrote: > > > > Hello Editor, > > > > Thank you for the great updates to the document. > > > > Note: I am adding new email IDs for Dan Voyer. Dan, please reply with your > > preference on how you would like to update your information in the > > RFC-to-be. > > > > Please see replies inline with <RG>… > > > > > > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > > Date: Wednesday, April 16, 2025 at 7:00 PM > > To: Rakesh Gandhi (rgandhi) <rgan...@cisco.com>, Clarence Filsfils > > (cfilsfil) <cfils...@cisco.com>, daniel.vo...@bell.ca > > <daniel.vo...@bell.ca>, stefano.sals...@uniroma2.it > > <stefano.sals...@uniroma2.it>, mach.c...@huawei.com <mach.c...@huawei.com> > > Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > > mpls-...@ietf.org <mpls-...@ietf.org>, mpls-cha...@ietf.org > > <mpls-cha...@ietf.org>, tony...@tony.li<tony...@tony.li>, > > james.n.guich...@futurewei.com <james.n.guich...@futurewei.com>, > > auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> > > Subject: Re: AUTH48: RFC-to-be 9779 <draft-ietf-mpls-rfc6374-sr-17> for > > your review > > > > Authors, > > > > While reviewing this document during AUTH48, please resolve (as necessary) > > the following questions, which are also in the XML file. > > > > 1) <!-- [rfced] May we update the document title as shown below for > > clarity? > > > > Original: > > Performance Measurement for Segment Routing Networks with MPLS Data > > Plane > > > > Perhaps: > > Performance Measurement for Segment Routing Networks over the MPLS Data > > Plane > > > > --> > > > > <RG> We could use following example as a guidance? > > > > RFC 8660 uses term: Segment Routing with the MPLS Data Plane > > > > https://datatracker.ietf.org/doc/html/rfc8660 > > > > <RG> Performance Measurement for Segment Routing Networks with the MPLS > > Data Plane > > > > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > > the title) for use on https://www.rfc-editor.org/search. --> > > > > > > <RG> Delay Measurement, Loss Measurement, Link Measurement, SR-MPLS Policy > > Measurement > > > > > > 3) <!-- [rfced] We have updated the text below for readability and to > > clarify the relationship between SR-MPLS and its expansion. Please review > > and let us know any objections. > > > > Original: > > This document specifies the application of the MPLS loss and delay > > measurement techniques, originally defined in RFC 6374, RFC 7876, and > > RFC 9341 within Segment Routing (SR) networks that utilize the MPLS > > data plane (SR-MPLS). > > > > Current: > > This document specifies the application of the MPLS loss and delay > > measurement techniques (originally defined in RFCs 6374, 7876, and 9341) > > within Segment Routing (SR) networks that utilize the MPLS data plane, > > also referred to as Segment Routing over MPLS (SR-MPLS). > > > > --> > > > > <RG> Ok. > > > > > > 4) <!-- [rfced] We have updated the text below to demonstrate a 1:1 > > relationship between abbreviation and expansion. Please review. > > > > Original: > > > > Segment Routing (SR), as specified in [RFC8402], leverages the source > > routing paradigm and applies to both the Multiprotocol Label > > Switching (SR-MPLS) and IPv6 (SRv6) data planes. > > > > Current: > > > > Segment Routing (SR), as specified in [RFC8402], leverages the source > > routing paradigm and applies to both the Multiprotocol Label > > Switching (MPLS) and Internet Protocol version 6 (IPv6) data planes. > > These are referred to as Segment Routing over MPLS (SR-MPLS) and > > Segment Routing over IPv6 (SRv6), respectively. > > > > --> > > <RG> Ok. > > > > > > 5) <!-- [rfced] For clarity, please consider whether the following > > suggested update conveys the intended meaning. > > > > Original: > > This document defines Return Path and Block Number TLV extensions for > > [RFC6374], in Section 6, for delay and loss measurement in SR-MPLS > > networks. > > > > Current: > > This document extends [RFC6374] by defining Return Path and Block > > Number TLVs (see Section 6) for delay and loss measurement in > > SR-MPLS networks. > > --> > > <RG> Ok. > > > > 6) <!-- [rfced] Does "also apply" mean "can also be used"? > > > > Original: > > These TLV extensions also apply to MPLS Label Switched > > Paths (LSPs) [RFC3031]. > > > > Perhaps: > > These TLVs can also be used in MPLS Label Switched > > Paths (LSPs) [RFC3031]. > > --> > > <RG> Ok > > > > 7) <!-- [rfced] Seemingly, Success (0x1) is a Control Code. If this is > > correct, may we udpate the text as follows? > > > > Original: > > The responder that supports this TLV MUST return > > Success in "Control Code" [RFC6374] if it is the intended destination > > for the query. > > > > Perhaps: > > The responder that supports this TLV MUST return > > Control Code 0x1 (Success) [RFC6374] if it is the intended destination > > for the query. > > --> > > > > <RG> Ok > > > > > > 8) <!-- [rfced] Could the text below be adjusted for clarity? Specifically, > > what is being sent as "the destination address"? > > > > Original: > > When the querier sets an IP address and a UDP port in the URO TLV, the > > response message MUST be sent to that IP address as the destination > > address > > and UDP port as the destination port. > > > > Perhaps: > > When the querier sets an IP address and a UDP port in the URO TLV, the > > response message MUST be sent to that IP address, with that IP address as > > the destination address and the UDP port as the destination port. > > --> > > <RG> Ok > > > > > > > > 9) <!-- [rfced] May we update "out-of-band response messages" to > > "Out-of-Band Response Requested messages..."? It is unclear whether the > > text refers to the Response Requested messages or res ponses to Out-of-Band > > Response Requested messages. > > > > Original: > > In one-way measurement mode defined in Section 2.4 of [RFC6374], the > > querier can receive "out-of-band" response messages with an IP/UDP > > header by properly setting the UDP Return Object (URO) TLV in the > > query message. > > --> > > <RG> How about following? > > > > In one-way measurement mode defined in Section 2.4 of [RFC6374], the > > querier can receive response messages with an IP/UDP > > header “out-of-band” by properly setting the UDP Return Object (URO) TLV > > in the > > query message. > > > > > > 10) <!-- [rfced] How may we update the text below for clarity and > > readability? > > > > Original: > > In two-way measurement mode defined in Section 2.4 of [RFC6374], the > > response messages SHOULD be sent back in-band on the same link or the > > same end-to-end SR-MPLS path (same set of links and nodes) in the > > reverse direction to the querier, in order to perform accurate two- > > way delay measurement. > > > > Perhaps: > > In the two-way measurement mode defined in Section 2.4 of [RFC6374], > > the response messages SHOULD be sent back one of two ways: either > > they are sent back in-band on the same link, or they are sent back > > on the same end-to-end SR-MPLS path (i.e., the same set of links and > > nodes) in the reverse direction to the querier. This is done in order > > to perform accurate two-way delay measurement. > > > > --> > > <RG> Ok. > > > > > > > > 11) <!-- [rfced] For readability, we suggest the update below. Please > > review to ensure it does not impact the intended meaning. > > > > Original: > > The querier can request in the query message for the responder > > to send the response message back on a given return path using the > > MPLS Label Stack sub-TLV in the Return Path TLV defined in this > > document. > > > > Perhaps: > > In the query message, the querier can request that the responder send > > the response message back on a given return path using the MPLS Label > > Stack Sub-TLV in the Return Path TLV defined in this document. > > --> > > <RG> Ok. > > > > > > > > 12) <!-- [rfced] Please review these similar sentences and let us know if > > we may update them for readability. > > > > More specifically, what does "which" refer to in the examples below? Does > > it refer to the ACH or the different values in parentheses? > > > > <RG> Value as in the suggested text. > > > > In addition, we were unable to find "Combined DM+LM" in RFC 6374 as seen in > > the third example. Should this be updated to "combined LM/DM message" as > > used in RFC 6374? > > > > <RG> Yes. > > > > > > Original: > > As defined in [RFC6374], MPLS Delay Measurement (DM) query and > > response messages use the Associated Channel Header (ACH) (value > > 0x000C for delay measurement) [RFC6374], which identifies the message > > type and the message payload as defined in Section 3.2 [RFC6374] > > following the ACH. > > > > As defined in [RFC6374], MPLS LM query and response messages use the > > Associated Channel Header (ACH) (value 0x000A for direct loss > > measurement or value 0x000B for inferred loss measurement), which > > identifies the message type and the message payload defined in > > Section 3.1 [RFC6374] following the ACH. > > > > As defined in [RFC6374], Combined DM+LM query and response messages > > use the Associated Channel Header (ACH) (value 0x000D for direct loss > > and delay measurement or value 0x000E for inferred loss and delay > > measurement), which identifies the message type and the message > > payload defined in Section 3.3 [RFC6374] following the ACH. > > > > Perhaps: > > As defined in [RFC6374], MPLS Delay Measurement (DM) query and response > > messages use the Associated Channel Header (ACH) (with the value 0x000C > > for delay measurement). This value identifies the message type and the > > message payload that follow the ACH, as defined in Section 3.2 of > > [RFC6374]. > > > > As defined in [RFC6374], MPLS LM query and response messages use the ACH > > (with the value 0x000A for direct loss measurement or the value 0x000B > > for inferred loss measurement). This value identifies the message type > > and the message payload that follow the ACH, as defined in Section 3.1 > > of [RFC6374]. > > > > As defined in [RFC6374], combined DM+LM query and response messages use > > the ACH (with the value 0x000D for direct loss and delay measurement or > > the value 0x000E for inferred loss and delay measurement). This value > > identifies the message type and the message payload that follows the > > ACH, as defined in Section 3.3 of [RFC6374]. > > > > --> > > <RG> Ok. Except DM+LM to be changed to LM/DM as suggested. > > > > > > 13) <!-- [rfced] In the instances below, we have adjusted "for accounting > > received traffic". Please review to ensure these changes do not alter your > > meaning. > > > > Original: > > The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the > > received data packet for the traffic flow under measurement for > > accounting received traffic on the egress node of the SR-MPLS Policy. > > > > Different values of PSID can be used per Candidate-Path for accounting > > received traffic to measure packet loss at the Candidate- Path level. > > > > Current: > > The Path Segment Identifier (PSID) [RFC9545] MUST be carried in the > > received data packet for the traffic flow under measurement, in order to > > account for received traffic on the egress node of the SR-MPLS Policy. > > > > Different values of the PSID can be used per Candidate-Path to account > > for received traffic and to measure packet loss at the Candidate-Path > > level. > > --> > > <RG> Ok > > > > > > 14) <!-- [rfced] In the text below, does "while" mean "at the same time", > > or does it represent a contrast (like "whereas" or "on the other hand")? > > > > Original: > > The LM query and response messages defined in [RFC6374] are used to > > measure packet loss for the block of data packets transmitted with > > the previous marking while data packets carry alternate marking. > > > > Perhaps: > > The LM query and response messages defined in [RFC6374] are used to > > measure packet loss for the block of data packets transmitted with the > > previous marking, whereas data packets carry alternate marking. > > --> > > <RG> Ok > > > > > > > > 15) <!-- [rfced] FYI - The quoted text below appears differently in RFC > > 9341. We have updated to match RFC 9341. > > > > Original: > > "The assumption of the block number mechanism is that the measurement > > nodes are time synchronized" as specified in Section 4.3 of [RFC9341] > > is not necessary, as the block number on the responder can be > > synchronized based on the received LM query messages. > > > > Current: > > Section 4.3 of [RFC9341] specifies: "The assumption of this BN > > mechanism is that the measurement nodes are time synchronized." However, > > this is not necessary, as the block number on the responder can be > > synchronized based on the received LM query messages. > > > > --> > > > > <RG> Ok > > > > > > 16) <!-- [rfced] Is "LSE" singular or plural in the text below? > > > > Original: > > The MPLS Label Stack contains a list of 32-bit LSE that includes a > > 20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS > > (S) field. > > > > Perhaps (LSE is plural): > > The MPLS Label Stack contains a list of 32-bit LSEs that each include a > > 20-bit label value, an 8-bit TTL value, a 3-bit TC value, and a 1-bit > > EOS (S) field. > > > > --> > > <RG> Ok > > > > > > > > 17) <!-- [rfced] We have removed "TLV" from the Descriptions to align with > > the IANA registries <https://www.iana.org/assignments/g-ach-parameters>. > > Please let us know any corrections. > > > > Original: > > | TBA1 | Return Path TLV | This document | > > | TBA2 | Block Number TLV | This document | > > > > Current: > > | 5 | Return Path | RFC 9779 | > > | 6 | Block Number | RFC 9779 | > > --> > > <RG> Ok > > > > > > > > 18) <!-- [rfced] Should the registry name be plural? Note that we will ask > > IANA to update their registry if this change is accepted. > > > > Current: Return Path Sub-TLV Type > > Perhaps: Return Path Sub-TLV Types > > --> > > <RG> Yes > > > > > > 19) <!-- [rfced] Much of this text duplicates what appears in the table. > > Perhaps the text should just indicate that the code points are assigned as > > defined in Table 2? > > > > Section 12: > > All code points in the range 0 through 175 in this registry > > shall be allocated according to the "IETF Review" procedure as > > specified in [RFC8126]. Code points in the range 176 through 239 in > > this registry shall be allocated according to the "First Come, First > > Served" procedure as specified in [RFC8126]. Remaining code points > > are allocated according to Table 2: > > > > Table 2: > > | Value | Description | Reference | > > +===========+=========================+===============+ > > | 1 - 175 | IETF Review | This document | > > | 176 - 239 | First Come First Served | This document | > > | 240 - 251 | Experimental Use | This document | > > | 252 - 254 | Private Use | This document | > > --> > > <RG> Agree to change to: > > > > The code points are allocated according to Table 2: > > > > > > 20) <!-- [rfced] Would it make sense to refer to the MPLS Review Team > > (assuming that is correct), as we are unsure what MPLS-RT refers to and we > > are unable to find information about it. > > > > Original: > > Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS-RT expert > > review, ... > > --> > > <RG> Perhaps > > > > Thanks to Huaimo Chen, Yimin Shen, and Xufeng Liu for MPLS expert > > review, ... > > > > > > 21) <!-- [rfced] [IEEE802.1AX] references the 2008 version of this IEEE > > Standard. May we update this reference to use the current standard from > > 2020 as seen in the following URL: > > <https://ieeexplore.ieee.org/document/9105034>? > > > > --> > > <RG> Yes > > > > > > 22) <!-- [rfced] We removed the quotes around Control Code throughout to > > align with use in RFC 6374. We have also removed the quotes and > > capitalized "in-band response requested" and "out-of-band response > > requested" to match what appears in RFC 6374 and the IANA registry. Please > > review and let us know if corrections are needed. > > --> > > <RG> Ok > > > > 23) <!-- [rfced] Please review the following changes and questions > > regarding the terms used in this document: > > > > a) RFC 8402 uses "node-SID" and "Anycast-SID" rather than "node SID" and > > "Anycast SID". May we update these to match the usage from RFC 8402? > > > > <RG> Yes. > > > > b) We note different capitalization of label stack vs. Label Stack. We > > believe the lowercase "label stack" is used in general text, but "Label > > Stack" is capitalized when it refers to the the TLV. Please confirm that > > MPLS Label Stack is capitalized correctly in the following: > > > > Original: > > The MPLS Label Stack contains a list of 32-bit LSE that includes a > > 20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS > > (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels > > or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. > > --> > > <RG> Perhaps > > > > The MPLS label stack contains a list of 32-bit LSE that includes a > > 20-bit label value, 8-bit TTL value, 3-bit TC value, and 1-bit EOS > > (S) field. An MPLS Label Stack Sub-TLV may carry a stack of labels > > or a Binding SID label [RFC8402] of the Return SR-MPLS Policy. > > > > > > > > 24) <!-- [rfced] Please review the following questions and changes > > regarding the abbreviations used in this document. > > > > a) Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be > > expanded upon first use. Is "EOS" in the text below an abbreviation? If so, > > how may it be expanded? > > > > 1-bit EOS (S) field > > > > <RG> Perhaps: > > > > 1-bit End of Stack (S) field > > > > b) FYI - We have expanded the abbreviation below. Please review to > > ensure correctness. > > > > Border Gateway Protocol - Link State (BGP-LS) > > > > --> > > <RG> Ok > > > > 25) <!-- [rfced] Please review the "Inclusive Language" portion of the > > online Style Guide > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > 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. > > > > --> > > > > <RG> Believe the document is ok. > > > > Thanks, > > > > Rakesh > > > > > > > > Thank you. > > > > RFC Editor > > > > > > > > On Apr 16, 2025, at 3:52 PM, rfc-edi...@rfc-editor.org wrote: > > > > *****IMPORTANT***** > > > > Updated 2025/04/16 > > > > 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://www.rfc-editor.org/faq/). > > > > 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://trustee.ietf.org/license-info). > > > > * 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://authors.ietf.org/rfcxml-vocabulary>. > > > > * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > > > * The archive itself: > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > * 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://www.rfc-editor.org/authors/rfc9779.xml > > https://www.rfc-editor.org/authors/rfc9779.html > > https://www.rfc-editor.org/authors/rfc9779.pdf > > https://www.rfc-editor.org/authors/rfc9779.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9779-diff.html > > https://www.rfc-editor.org/authors/rfc9779-rfcdiff.html (side by side) > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9779-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9779 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9779 (draft-ietf-mpls-rfc6374-sr-17) > > > > Title : Performance Measurement for Segment Routing Networks > > with MPLS Data Plane > > Author(s) : R. Gandhi, C. Filsfils, D. Voyer, S. Salsano, M. Chen > > WG Chair(s) : Nicolai Leymann, Tarek Saad, Tony Li > > > > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde > > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
