Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-sfc-multi-layer-oam-28> for your review

[[e-mail]]

Hi Alanna & all,
Thank you all very much for your hard work and contribution. I agree with all updates to the document.

Best Regards,


Wei Meng
Director of Standard and Open Source Planning
ZTE Corporation





Original


From: AlannaPaloma <[e-mail]>
To: Greg Mirsky <[e-mail]>;
Cc: 孟伟10043967;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;auth48archive <[e-mail]>;
Date: 2023年11月08日 03:11
Subject: Re: AUTH48: RFC-to-be 9516 <draft-ietf-sfc-multi-layer-oam-28> for your review

Hi Greg,
 
Thank you for your reply. We have updated the files as requested.
 
The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc9516.xml
 https://www.rfc-editor.org/authors/rfc9516.txt
 https://www.rfc-editor.org/authors/rfc9516.html
 https://www.rfc-editor.org/authors/rfc9516.pdf
 
The relevant diff files have been posted here:
 https://www.rfc-editor.org/authors/rfc9516-diff.html (comprehensive diff)
 https://www.rfc-editor.org/authors/rfc9516-auth48diff.html (AUTH48 changes)
 
Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.
 
We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.
 
For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9516
 
Thank you,
RFC Editor/ap
 
 
> On Nov 7, 2023, at 2:23 AM, Greg Mirsky <[e-mail]> wrote:
>  
> Hi Alanna,
> thank you for your kind reminder. Please find my answers to your questions below, tagged GIM>>. Please let the authors know if there are any further questions or concerns.
>  
> Kind regards,
> Greg
>  
> On Mon, Nov 6, 2023 at 10:49 PM Alanna Paloma <[e-mail]> wrote:
> Greetings,
>  
> We do not believe we have heard from you regarding this document's readiness for publication.  Please review our previous messages describing the AUTH48 process and containing any document-specific questions we may have had.
>  
> We will wait to hear from you before continuing with the publication process.
>  
> The AUTH48 status page for this document is located here:
> https://www.rfc-editor.org/auth48/rfc9516
>  
> Thank you,
> RFC Editor/ap
>  
>  
> > On Oct 30, 2023, at 3:56 PM, [e-mail] wrote:
> >  
> > Authors,
> >  
> > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> >  
> > 1) <!--[rfced] Please note the title of the document has been updated as  
> > follows. Abbreviations have been expanded per Section 3.6 of RFC 7322  
> > ("RFC Style Guide"). Please review.
> >  
> > Original:
> >   Active OAM for Service Function Chaining (SFC)
> >  
> > Current:
> >   Active Operations, Administration, and Maintenance (OAM) for Service  
> >   Function Chaining (SFC)
> GIM>> Agree, thank you.  
> > --> 
> >  
> >  
> > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the  
> > title) for use on https://www.rfc-editor.org/search. --> 
> GIM>> I would propose adding:
> NSH
> Fault Management
>  
> >  
> >  
> > 3) <!--[rfced] We do not see "Performance Monitoring OAM" mentioned in RFC  
> > 8924.  Please let us know if/how this citation should be updated.
> GIM>> Thank you for raising this question. I think that Section 3.1.2 and Section 3.2.2  of RFC 8924 express requirements for PM OAM in SFC.
> >  
> > Additionally, "as a requirement" is unclear. May we update the sentence as
> > follows?
> >  
> > Original:
> >   Note that
> >   Performance Monitoring OAM, as mentioned in [RFC8924], as a
> >   requirement, is not satisfied by this document and is out of scope.
> >  
> > Perhaps:
> >   Note that
> >   Performance Monitoring OAM, as required by [RFC8924],
> >   is not satisfied by this document and is out of scope.
> GIM>> Thank you for the suggested text. Agree.  
> > --> 
> >  
> >  
> > 4) <!--[rfced] Should the terms in Section 2.2 be listed in alphabetical  
> > order?  
> GIM>> Indeed, thank you.  
> --> 
> >  
> >  
> > 5) <!-- [rfced] Please confirm that references to Section 6.5.4 for SFF  
> > traceroute are correct, as we don't see mention of SFF or Service Function  
> > Forwarders in that section.  Perhaps "SFF traceroute" should be "SFP  
> > tracing"?  Please let us know if any updates are neeeded.
> GIM>> Thank you for pointing this out. I believe that your suggestion of replacing "SFF traceroute" with "SFP tracing" (below) is absolutely correct.  
> >  
> > Original:
> >   *  REQ#2: Continuity monitoring via the SFF traceroute defined in
> >      Section 6.5.4 ("Tracing an SFP ").
> >  
> >   *  REQ#4: Connectivity verification via the SFF traceroute
> >      (Section 6.5.4).
> > --> 
> >  
> >  
> > 6) <!-- [rfced] We have updated the following 2 instances of "Active SFC  
> > OAM" to "SFC Active OAM" to match the description in the IANA registry.   
> > Please let us know if any updates are needed.  
> >  
> > Original:
> >   To identify the active SFC
> >   OAM message, the "Next Protocol" field MUST be set to Active SFC OAM
> >   (TBA1) (Section 10.1). ... A case when the O bit is clear and the
> >   "Next Protocol" field value is set to Active SFC OAM (TBA1) is
> >   considered an erroneous combination.
> >  
> > We note that Figure 2 includes a "SFC Active OAM Control Packet" field, but  
> > the section title is "Active SFC OAM Header" - should the section title be  
> > SFC Active OAM Header?  
> >  
> > Original:  
> >   5.  Active SFC OAM Header
> >  
> > Perhaps:  
> >   5.  SFC Active OAM Header
> >  
> >  
> > In addition, the term appears inconsistently throughout the document.  
> > Please review and let us know how/if these may be updated for consistency.  
> >  
> > active SFC OAM vs Active SFC OAM (capitalization)
> > SFC active OAM vs SFC Active OAM (capitalization)
> > active SFC OAM vs SFC active OAM (location of "active")
> GIM>> Thank you for raising these questions. I agree that the document should use consistent terminology. In this case, I propose converging to "SFC Active OAM" being used throughout the document.  
> As for the capitalization, it depends. I think that when we refer to the value (TBA1) or name the header "SFC Active OAM" is appropriate. But when referring to the specific method of OAM, then "SFC active OAM" seems appropriate, e.g., "SFC active OAM combines OAM commands". WDYT?
> > --> 
> >  
> >  
> > 7) <!--[rfced] We see a number of author-inserted comments in the ..xml file  
> > for this document. We are unsure if these have been resolved. Please review  
> > and let us know if these can be deleted or if they need to be addressed.
> GIM>> My apologies for leaving these around. All notes have been addressed and can be removed.  
> > --> 
> >  
> >  
> > 8) <!--[rfced] In Section 6.4.1, should "Errored TLVs Type" be "Errored  
> > TLVs" to match the field in Figure 6?  
> >  
> > Original:
> >   The Errored TLVs Type <bcp14>MUST</bcp14> be set to 2 (Section 10.4).
> >  
> > Perhaps:
> >   Errored TLVs - <bcp14>MUST</bcp14> be set to 2 (Section 10.4).
> GIM>> Agree with the proposed update. Thank you.  
> > --> 
> >  
> >  
> > 9) <!--[rfced] We are having some trouble parsing "information on the  
> > actual path the CVReq packet has traveled". Is this meant to described the  
> > information that is collected?
> >  
> > Original:
> >   As a result, the ingress SFF collects information about all traversed
> >   SFFs and SFs, information on the actual path the CVReq packet has
> >   traveled.
> >  
> > Perhaps:
> >   As a result, the ingress SFF collects information about all traversed
> >   SFFs and SFs, i.e., information on the actual path the CVReq packet has
> >   traveled.  
> GIM>> Thank you for improving the text. Agree with the update.  
>  
> > --> 
> >  
> >  
> > 10) <!--[rfced] There are no definitions for the "Length" and "SF  
> > Information Sub-TLV" fields in Figure 9. Should ones be added? If so,  
> > please provide text.
> GIM>> Thank you for pointing out the missing text. Please use the following:
>       Length - the value equals the sum of lengths of the Service Path Identifier, reserved, and SF Information Sub-TLV fields in
>       octets.
> It appears that SF Information Sub-TLV is explained as follows:
>       SF Information Sub-TLV: The sub-TLV is as defined in
>       Section 6.6.2.
> > -->     
> >  
> >  
> > 11) <!--[rfced] In Section 6.6.2, should "SF sub-TLV Type" be "SF Sub-TLV" 
> > to match the field in Figure 10?
> >  
> > Original:
> >   SF sub-TLV Type: one-octet long field.  The value is (5)
> >      (Section 10.4).
> >  
> > Perhaps:
> >   SF Sub-TLV : one-octet field.  The value is (5) (Section 10.4).
> GIM>> Yes, I agree with the update proposed.  
> > -->       
> >  
> >  
> > 12) <!--[rfced] To clarify, does "their" refer to the "SF ID Type"? If so,
> > may we update "their" to "its"?
> >  
> > Original:
> >   For this case, the SF ID Type,
> >   which must be the same for all of these SFs, appears once but all of
> >   their SF Identifiers will appear concatenated in the SF Identifier
> >   area of the Sub-TLV (see Figure 10).
> >  
> > Perhaps:
> >   For this case, the SF ID Type,
> >   which must be the same for all of these SFs, appears once but all of
> >   its SF Identifiers will appear concatenated in the SF Identifier
> >   area of the sub-TLV (see Figure 10).
> GIM>> Thank you for the suggestion. I propose a slightly different update:
>    For this case, the SF ID Type,
>    which must be the same for all of these SFs, appears once, but all the
>    respective SF Identifiers will be listed sequentially in the SF Identifier
>    field of the Service Function Information Sub-TLV (see Figure 10).  
> WDYT?
> > --> 
> >  
> >  
> > 13) <!-- [rfced] Should the section title and registry title be plural  
> > (i.e., s/Type/Types)?  
> >  
> > Perhaps:
> >   SFC Active OAM Message Types
> GIM>> Indeed, thank you!  
> > --> 
> >  
> >  
> > 14) <!-- [rfced] The IETF Review range has been updated to specify 0-31, to  
> > match what appears in the IANA registry.  See https://www.iana.org/assignments/sfc-active-oam/sfc-active-oam.xhtml#sfc-active-oam.
> >  
> > Original:  
> > 2-31 IETF Review
> GIM>> Yes, 0-31 is the correct range.  
> > --> 
> >  
> >  
> > 15) <!-- [rfced] May we update instances of "Echo Request/Echo Reply" to be  
> > "Echo Request/Reply" throughout the document, including the IANA-related  
> > text, to align with text in Section 2?  
> >  
> > From Section 2:  
> >   In this document, "Echo Request/Reply" and "SFC Echo                     
> >   Request/Reply" are used interchangeably.
> >  
> > For example, this is the current IANA-related text from Table 2:  
> >   | 1      | SFC Echo Request/Echo Reply | RFC 9516  |
> >  
> > Perhaps:  
> >   | 1      | SFC Echo Request/Reply | RFC 9516  |
> GIM>> Great! I agree.  
> > --> 
> >  
> >  
> > 16) <!-- [rfced] Note that these two rows have been combined to match what  
> > appears in the IANA registry:  
> >  
> > Original:
> >         | 2 - 31 |          Unassigned         | This document |
> >         | 32-62  |          Unassigned         | This document |
> >  
> > Current:  
> >        | 2 - 62 |          Unassigned         |           |
> GIM>> Agreed.  
> > --> 
> >  
> >  
> > 17) <!-- [rfced] We do not see an "SFC Echo Request/Echo Reply Parameters"  
> > registry within the "Service Function Chaining (SFC) Active Operations,  
> > Administration, and Maintenance (OAM)" registry.  Based on the IANA  
> > actions, we believe the intent is for registries defined in sections 10.3.1  
> > - 10.3.4, 10.4, and 10.5 (in the I-D) to be created within the "Service  
> > Function Chaining (SFC) Active Operations, Administration, and Maintenance  
> > (OAM)" registry - we have updated the text accordingly (including removing  
> > Section 10.3).  Please review the updates carefully and let us know any  
> > objections.  
> >  
> > From IANA:  
> > We've created the following registries and placed them in the "Service  
> > Function Chaining (SFC) Active Operations, Administration, and Maintenance  
> > (OAM)" registry group:   
> >  
> > SFC Active OAM Message Type   
> > SFC Echo Request Flags   
> > SFC Echo Types   
> > SFC Echo Reply Modes   
> > SFC Echo Return Codes   
> > SFC Active OAM TLV Type   
> > SF Identifier Types   
> >  
> > Please see https://www.iana.org/assignments/sfc-active-oam for the list of  
> > registrations and procedures.   
> > --> 
> >  
> >  
> > 18) <!-- [rfced] Section 9.2.3. SFC Echo Types
> >  
> > Note that the IETF Review range has been updated to reflect what appears in  
> > the IANA registry.   
> >  
> > The following ranges were commented out in the XML, but they appear in the  
> > IANA registry.   
> >  
> >   240-251    Experimental Use  
> >   252-254    Private Use
> >  
> > We have re-added the ranges to the Assignment Policy, as the ranges appear  
> > in the IANA registry and the table below.  Please review and let us know  
> > whether these ranges are valid or if they should be removed from the IANA  
> > registry.   
> > See <https://www.iana.org/assignments/sfc-active-oam>.  
> >  
> > Note that these rows have been combined to match what appears in the IANA   
> > registry.
> >  
> >     | 5 - 175   |              Unassigned              |         |
> >     | 176 - 239 |              Unassigned              |         |
> >  
> > Current:  
> >     | 5 - 239   |              Unassigned              |         |
> GIM>> Agree. Thank you!  
> > --> 
> >  
> >  
> > 19) <!-- [rfced] Section 9.2.4.  SFC Echo Reply Modes
> >  
> > Similar to what was done for Section 9.2.3, the IETF Review range has been  
> > updated to reflect what appears in the IANA registry.
> >  
> > The following ranges were commented out in the XML, but they appear in the  
> > IANA registry.
> >  
> >   240 - 251   Experimental
> >   252 - 254   Private Use
> >  
> > We have re-added the ranges to the Assignment Policy, as the ranges appear  
> > in the IANA registry and the table below.  Please review and let us know  
> > whether these ranges are valid or if they should be removed from the IANA  
> > registry.  
> > See <https://www.iana.org/assignments/sfc-active-oam>.
> >  
> > Note that these rows have been combined to match what appears in the IANA  
> > registry.
> >  
> >        | 8 -   |             Unassigned             |         |
> >        | 175   |                                    |         |                            
> >        | 176 - |             Unassigned             |         |                            
> >        | 239   |                                    |         |                            
>  
> GIM>> Agreed.  
> > --> 
> >  
> >  
> > 20) <!-- [rfced] Section 9.2.5.  SFC Echo Return Codes  
> >  
> > Similar to above, the IETF Review range has been updated to reflect what  
> > appears in the IANA registry.
> >  
> > The following range was commented out in the XML, but it appears in the  
> > IANA registry.  
> >  
> >   252 - 254   Private Use
> >  
> > We have re-added the range to the Assignment Policy, as the range appears  
> > in the IANA registry and the table below.  Please review and let us know  
> > whether the range is valid or if it should be removed from the IANA  
> > registry.
> > See <https://www.iana.org/assignments/sfc-active-oam>.
> >  
> >  
> > Note that these rows have been combined to match what appears in the IANA  
> > registry.
> >  
> >   | 9 -191  |                  Unassigned                 |          |
> >   | 192-251 |                  Unassigned                 |          |
> GIM>> AFAICS, the new range is 9-251 Unassigned. Right? I agree.  
> > --> 
> >  
> >  
> > 21) <!-- [rfced]  9.2.6. SFC Active OAM TLV Type  
> >  
> > Should the registry and section title be plural (i.e., s/Type/Types)?  
> >  
> > Note that the IETF Review range has been updated to reflect what appears in  
> > the IANA registry.
> >  
> > The following ranges were commented out in the XML, but they appear in the  
> > IANA registry.   
> >   240 - 251  Experimental
> >   252 - 254   Private Use
> >  
> > We have re-added the ranges to the Assignment Policy, as the ranges appear  
> > in the IANA registry and the table below.  Please review and let us know  
> > whether these ranges are valid or if they should be removed from the IANA  
> > registry.  
> > See <https://www.iana.org/assignments/sfc-active-oam>.
> >  
> > Note that these rows have been combined to match what appears in the IANA
> > registry.
> >  
> >       | 6 - 175   |             Unassigned            |          |
> >       | 176 - 239 |             Unassigned            |          |
> GIM>> Agree to the renaming and merging of the ranges proposed.  
> > --> 
> >  
> >  
> > 22) <!--[rfced] 9.2.7.  SF Identifier Types  
> >  
> > FYI, as no SF Types registry is mentioned in RFC 9263, we have  
> > removed the citation from the sentence below.  
> >  
> > Original:
> >   IANA is requested to create in the SF Types registry [RFC9263] the
> >   sub-registry as follows:
> >  
> >  
> > Similar to above, the IETF Review range has been updated to reflect what  
> > appears in the IANA registry.
> >  
> > The following range was commented out in the XML, but it appears in the  
> > IANA registry.
> >  
> >   252 - 254   Private Use
> >  
> > We have re-added the range to the Assignment Policy, as the range appears  
> > in the IANA registry and the table below.  Please review and let us know  
> > whether the range is valid or if it should be removed from the IANA  
> > registry.   
> > See <https://www.iana.org/assignments/sfc-active-oam>.  
> >  
> >  
> > Note that these rows have been combined to match what appears in the IANA  
> > registry.
> >  
> >                   | 4 -191  |  Unassigned |          |
> >                   | 192-251 |  Unassigned |          |
> GIM>> Agree to the proposed changes.  
> > --> 
> >  
> >  
> > 23) <!-- [rfced] Throughout the text, the following terminology appears to  
> > be used inconsistently. May we update to use the latter ?
> >  
> > performance monitoring vs. Performance Monitoring
> > Echo Request/Echo Reply vs. Echo Request/Reply
> GIM>> As discussed above, Echo Request/Reply will be used throughout the text. As for the capitalization of Performance Monitoring, it depends. For example, it is capitalized in Performance Monitoring OAM (PM OAM). In other cases, the lower case is usually used, e.g., "performance monitoring methods".  
> >  
> > --> 
> >  
> >  
> > 24) <!-- [rfced] Acronyms
> >  
> > a) "SFC" has been expanded as both "Service Function Chain" and "Service
> > Function Chaining" in this document. We have updated to use the latter to  
> > parallel the use in the other documents from Cluster C479 (RFCs 9451 and  
> > 9452). Note that instances of "service function chain" (lowercased) have  
> > been left as is. Please let us know of any objections.
> >  
> > b) FYI - We have expanded the following abbreviation
> > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> > expansion in the document carefully to ensure correctness.
> >  
> > Label Switched Path (LSP)
> GIM>> Agree to both.  
> > --> 
> >  
> >  
> > 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.
> >  
> > For example, please consider whether "sanity" should be updated.
> GIM>> Thank you for bringing this to the review. I think that s/sanity/consistency/ can be applied throughout the document. WDYT?  
> > --> 
> >  
> >  
> > Thank you.
> >  
> > RFC Editor
> >  
> >  
> >  
> >  
> > On Oct 30, 2023, at 1:52 PM, [e-mail] wrote:
> >  
> > *****IMPORTANT*****
> >  
> > Updated 2023/10/30
> >  
> > 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
> >  
> >   *  [e-mail] (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).
> >  
> >   *  [e-mail], 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,  
> >        [e-mail] 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/rfc9516.xml
> >   https://www.rfc-editor.org/authors/rfc9516.html
> >   https://www.rfc-editor.org/authors/rfc9516.pdf
> >   https://www.rfc-editor.org/authors/rfc9516.txt
> >  
> > Diff file of the text:
> >   https://www.rfc-editor.org/authors/rfc9516-diff.html
> >   https://www.rfc-editor.org/authors/rfc9516-rfcdiff.html (side by side)
> >  
> > Diff of the XML:  
> >   https://www.rfc-editor.org/authors/rfc9516-xmldiff1.html
> >  
> > The following files are provided to facilitate creation of your own  
> > diff files of the XML.   
> >  
> > Initial XMLv3 created using XMLv2 as input:
> >   https://www.rfc-editor.org/authors/rfc9516.original.v2v3.xml  
> >  
> > XMLv3 file that is a best effort to capture v3-related format updates  
> > only:  
> >   https://www.rfc-editor.org/authors/rfc9516.form.xml
> >  
> >  
> > Tracking progress
> > -----------------
> >  
> > The details of the AUTH48 status of your document are here:
> >   https://www.rfc-editor.org/auth48/rfc9516
> >  
> > Please let us know if you have any questions.   
> >  
> > Thank you for your cooperation,
> >  
> > RFC Editor
> >  
> > --------------------------------------
> > RFC9516 (draft-ietf-sfc-multi-layer-oam-28)
> >  
> > Title            : Active OAM for Service Function Chaining (SFC)
> > Author(s)        : G. Mirsky, W. Meng, T. Ao, B. Khasnabish, K. Leung, G. Mishra
> > WG Chair(s)      : Joel M. Halpern, Jim Guichard
> >  
> > Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston