Re: [auth48] AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

["Samuel Sidor (ssidor)" <[e-mail]>]

Hi Rebecca,

I checked latest document and looks good to me as well.

I approve publication.

Thanks a lot,
Samuel

-----Original Message-----
From: Rebecca VanRheenen <[e-mail]> 
Sent: Wednesday, October 4, 2023 5:08 PM
To: Andrew Stone (Nokia) <[e-mail]>; Mustapha Aissaoui (Nokia) <[e-mail]>; Samuel Sidor (ssidor) <[e-mail]>; [e-mail]
Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; julien.meuric <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: AUTH48: RFC-to-be 9488 <draft-ietf-pce-local-protection-enforcement-11> for your review

Hi Andrew,

Thanks for the quick reply! We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9488).

We will await approvals from each author prior to moving forward in the publication process.

Thank you,
RFC Editor/rv


> On Oct 3, 2023, at 3:56 PM, Andrew Stone (Nokia) <[e-mail]> wrote:
> 
> Hi Rebecca,
> 
> Thank you for the updates. I've reviewed the latest document and it looks good to me. 
> 
> I approve publication.
> 
> Thank you once again!
> Andrew
> 
> 
> 
> On 2023-10-02, 5:13 PM, "Rebecca VanRheenen" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Hi Andrew,
> 
> Thank you for the updated XML file! Responses to your points about questions 12, 17, and 18f are below in addition to a comment about question 18a. Links to the updated files are also listed below.
> 
> Please let us know if you have any further questions or comments.
> 
>>> 12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first 
>>> and then bit 7 (matches IANA registry)? Or do you prefer the current 
>>> (matches order mentioned in text before table)?
>>> -->
>> 
>> [andrew] Updated to keep consistency with IANA registry and reading the bit object definition from left to right.
>> 
>> [andrew] Is it recommended to also update the order of the bit descriptions as well?
> 
> 
> The current looks good to us. Let us know if you think any further changes are needed.
> 
> 
> 
> 
>>> 17) <!-- [rfced] Would you like the references to be alphabetized or 
>>> left in their current order?
>>> -->
>> 
>> [andrew] No preference, Okay to proceed with alphabetized if it is commonly recommended and also okay to keep as is.
> 
> 
> We alphabetized the references as this is more common in the RFC Series (though it is not required).
> 
> 
> 
> 
>>> 18f) We see that "LSP object" is used in both RFCs 8231 and 8281, 
>>> but "LSP Attribute Object" (or "LSPA") is not used in either. Should 
>>> the sentence below be updated to reflect usage in the cited documents?
>>> 
>>> 
>>> Original:
>>> It is
>>> important to note that [RFC8231] and [RFC8281] permit the LSP 
>>> Attribute Object to be included in PCUpd messages for PCC-initiated 
>>> and PCE-initiated LSPs.
>>> -->
>> 
>> [andrew] LSPA is defined in RFC5440 section 7.11. This is the base PCEP RFC (stateless, only defines PcReq Msg).
>> LSP and LSPA are seperate objects. LSPA is referenced in RFC8231, see definition in RFC8231 section 6.4.
>> As per section 6.4, The LSPA object follows immediately after the LSP object in other message exchanges defined in that RFC (ex:
>> PcUpd).
>> The flag is embedded within the LSP Attribute object, not the LSP 
>> Object, thus needs to remain referencing the "attribute" object.
>> 
>> Perhaps a citation to RFC5440?:
>> 
>> It is
>> important to note that [RFC8231] and [RFC8281] permit the LSP 
>> Attribute Object([RFC5440]) to be included in PCUpd messages for 
>> PCC-initiated and PCE-initiated LSPs.
> 
> 
> Thank you for the clarification. We added the [RFC5440] citation.
> 
> 
> 
> 
>>> 18a) Please confirm the name/description for the E flag defined in 
>>> this document. We see the following forms used in the document:
>>> 
>>> 
>>> Enforcement
>>> Protection Enforcement
>>> Local Protection Enforcement
>>> 
>>> 
>>> Note: The current name in the "LSPA Object Flag Field" registry is 
>>> "Protection Enforcement" (see 
>>> https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-fi
>>> eld<https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field> <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field&lt;https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field&gt;>); if needed, we will request an update to the registry prior to publication.
>> 
>> [Andrew] 'Protection Enforcement' should be used.
> 
> 
> We updated two instances to use “Protection Enforcement”. See Sections 1 and 5 (Table 1). Please review.
> 
> 
> ______________
> 
> 
> Updated XML file:
> https://www.rfc-editor.org/authors/rfc9488.xml 
> <https://www.rfc-editor.org/authors/rfc9488.xml>
> 
> 
> Updated output files:
> https://www.rfc-editor.org/authors/rfc9488.txt 
> <https://www.rfc-editor.org/authors/rfc9488.txt>
> https://www.rfc-editor.org/authors/rfc9488.pdf 
> <https://www.rfc-editor.org/authors/rfc9488.pdf>
> https://www.rfc-editor.org/authors/rfc9488.html 
> <https://www.rfc-editor.org/authors/rfc9488.html>
> 
> 
> Diff file showing all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9488-auth48diff.html 
> <https://www.rfc-editor.org/authors/rfc9488-auth48diff.html>
> 
> 
> Diff files showing all changes:
> https://www.rfc-editor.org/authors/rfc9488-diff.html 
> <https://www.rfc-editor.org/authors/rfc9488-diff.html>
> https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html 
> <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html> 
> (side-by-side diff) 
> https://www.rfc-editor.org/authors/rfc9488-alt-diff.html 
> <https://www.rfc-editor.org/authors/rfc9488-alt-diff.html> (diff 
> showing changes where text is moved or deleted)
> 
> 
> 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/rfc9488 
> <https://www.rfc-editor.org/auth48/rfc9488>
> 
> 
> 
> 
> Thank you,
> RFC Editor/rv
> 
> 
> 
> 
> 
> 
>> On Oct 1, 2023, at 8:55 PM, Andrew Stone (Nokia) <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi RFC Editor,
>> 
>> Thank you very much for undertaking this work and doing a thorough review. Much appreciated.
>> 
>> I've edited the XML document and attached in the reply. Most recommendations adopted, comments resolved within the XML have been removed. Thank you for the abbreviation expansions.
>> 
>> A few outstanding comments/replies embedded in the XML with [andrew].
>> 
>> Outstanding points (see reply inline in xml):
>> 
>> - (12) reordered table to align with IANA and left-to-right reading, but should bit field description be re-ordered as well? Or okay to keep descriptions in order as is?
>> - (17) reference re-ordering. No preference, okay with selection by 
>> RFC editor
>> - (18.f) text should remain LSPA, but rfceditor to confirm LSPA 
>> citation to 5440 required or not
>> 
>> Thanks
>> Andrew
>> 
>> 
>> 
>> On 2023-09-28, 5:03 PM, "[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> 
>> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>> 
>> 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 that the title of the document has been 
>> updated as follows. We expanded the abbreviation "PCEP" per Section 
>> 3.6 of RFC 7322 ("RFC Style Guide"). Please review.
>> 
>> 
>> Original:
>> Local Protection Enforcement in PCEP
>> 
>> 
>> Current:
>> Local Protection Enforcement in the Path Computation Element 
>> Communication Protocol (PCEP)
>> 
>> 
>> Note that we also updated the abbreviated title (only appears in the 
>> running header of the pdf output) to match the document title as there was space.
>> 
>> 
>> Original:
>> Protection Enforcement
>> 
>> 
>> Current:
>> Local Protection Enforcement in PCEP
>> -->
>> 
>> 
>> 
>> 
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear 
>> in the
>> title) for use on https://www.rfc-editor.org/search 
>> <https://www.rfc-editor.org/search> 
>> <https://www.rfc-editor.org/search> 
>> <https://www.rfc-editor.org/search&gt;>. -->
>> 
>> 
>> 
>> 
>> 3) <!-- [rfced] For this sentence in the Abstract, is "protection strictness"
>> okay, or would "protection enforcement" (like in the document title) 
>> be better?
>> 
>> 
>> Original:
>> This document also introduces a new flag for signalling protection 
>> strictness in PCEP.
>> -->
>> 
>> 
>> 
>> 
>> 4) <!-- [rfced] Please review "define enforcement, or strictness of 
>> the protection requirement" here. Would it be helpful to update to 
>> either "define the enforcement of the protection requirement" or 
>> "define the strictness of the protection enforcement requirement"?
>> 
>> 
>> Original:
>> It is desirable for an operator to be able to define the enforcement, 
>> or strictness of the protection requirement.
>> 
>> 
>> Perhaps:
>> It is desirable for an operator to be able to define the enforcement 
>> of the protection requirement.
>> 
>> 
>> Or:
>> It is desirable for an operator to be able to define the strictness 
>> of the protection enforcement requirement.
>> -->
>> 
>> 
>> 
>> 
>> 5) <!-- [rfced] Will readers understand what is meant by "reference 
>> notes"? Also, we revised "is path setup type and data plane 
>> technology agnostic" as follows to improve readability.
>> 
>> 
>> Original:
>> The document contains reference notes for Segment Routing, however 
>> the content described is path setup type and data plane technology 
>> agnostic.
>> 
>> 
>> Current:
>> The document contains reference notes for Segment Routing; however, 
>> the content described is agnostic in regard to path setup type and 
>> data plane technology.
>> -->
>> 
>> 
>> 
>> 
>> 6) <!-- [rfced] We are having trouble understanding how the last part 
>> of this sentence (i.e., "and the use case...") connects with the 
>> first part. Also, would a citation be helpful for "RSVP"?
>> 
>> 
>> Original:
>> The name of the flag uses the term "Desired", which by definition 
>> means "strongly wished for or intended" and the use case originated 
>> from the RSVP.
>> 
>> 
>> Perhaps:
>> The name of the flag uses the term "Desired", which by definition 
>> means "strongly wished for or intended". The use case for this flag 
>> originated in RSVP.
>> -->
>> 
>> 
>> 
>> 
>> 7) <!-- [rfced] May we update "Implementations of [RFC5440]" as 
>> follows for clarity?
>> 
>> 
>> Original:
>> Implementations of [RFC5440] have either interpreted the L flag as 
>> PROTECTION MANDATORY or PROTECTION PREFERRED, leading to operational 
>> differences.
>> 
>> 
>> Perhaps:
>> Implementations that use PCEP [RFC5440] have interpreted the L flag 
>> as either PROTECTION MANDATORY or PROTECTION PREFERRED, leading to 
>> operational differences.
>> -->
>> 
>> 
>> 
>> 
>> 8) <!-- [rfced] Should "service agreement definitions" here read 
>> "Service Level Agreement definitions" or "SLA definitions"? Or is the current correct?
>> 
>> 
>> Original:
>> A network may be providing transit to multiple service agreement 
>> definitions against the same base topology network, whose behavior 
>> could vary, such as wanting local protection to be invoked on some 
>> LSPs and not wanting local protection on others.
>> -->
>> 
>> 
>> 
>> 
>> 9) <!-- [rfced] Please review "The boolean bit L flag". Would one of 
>> the following options improve clarity and readability?
>> 
>> 
>> Original:
>> The boolean bit L flag is unable to distinguish between the different 
>> options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION 
>> PREFERRED and UNPROTECTED PREFERRED.
>> 
>> 
>> Perhaps:
>> The L flag is a boolean bit and thus unable to distinguish between 
>> the different options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, 
>> PROTECTION PREFERRED and UNPROTECTED PREFERRED.
>> 
>> 
>> Or:
>> Because it is a boolean bit, the L flag is unable to distinguish 
>> between the different options of PROTECTION MANDATORY, UNPROTECTED 
>> MANDATORY, PROTECTION PREFERRED, and UNPROTECTED PREFERRED.
>> -->
>> 
>> 
>> 
>> 
>> 10) <!-- [rfced] Two consecutive paragraphs in Section 4.2 begin with 
>> "For example". Is "For example" needed here? Or should the second one 
>> be updated to something like "As another example"? Please review.
>> 
>> 
>> Also, in the second paragraph below, we updated "is when an operator" 
>> to "is for use cases in which an operator" for clarity and for 
>> consistency with the previous paragraph. Please review.
>> 
>> 
>> Original:
>> For example, PROTECTION MANDATORY is for use cases where an operator 
>> may need the LSP to follow a path which has local protection provided 
>> along the full path, ensuring that if there is a failure anywhere 
>> along the path that traffic will be fast re-routed at the point.
>> 
>> 
>> For example, UNPROTECTED MANDATORY is when an operator may 
>> intentionally prefer an LSP to not be locally protected, and thus 
>> would rather local failures cause the LSP to go down. ...
>> 
>> 
>> Perhaps:
>> PROTECTION MANDATORY is for use cases in which an operator may need 
>> the LSP to follow a path that has local protection provided along the 
>> full path, ensuring that if there is a failure anywhere along the 
>> path that traffic will be fast re-routed at the point.
>> 
>> 
>> UNPROTECTED MANDATORY is for use cases in which an operator may 
>> intentionally prefer an LSP to not be locally protected and thus 
>> would rather local failures cause the LSP to go down.
>> -->
>> 
>> 
>> 
>> 
>> 11) <!-- [rfced] Please review "protected with path protection" here. 
>> Would updating to just "protected" retain the intended meaning?
>> 
>> 
>> Original:
>> An example
>> scenario is one where an LSP is protected with path protection via a 
>> secondary diverse LSP.
>> 
>> 
>> Perhaps:
>> An example
>> scenario is one where an LSP is protected via a secondary diverse LSP.
>> -->
>> 
>> 
>> 
>> 
>> 12) <!-- [rfced] In Table 1, would it be helpful to list bit 6 first 
>> and then bit 7 (matches IANA registry)? Or do you prefer the current 
>> (matches order mentioned in text before table)?
>> -->
>> 
>> 
>> 
>> 
>> 13) <!-- [rfced] We updated this sentence as follows to more 
>> accurately describe the figure. Please let us know any objections.
>> 
>> 
>> Original:
>> The format of the LSPA Object as defined in [RFC5440] is:
>> 
>> 
>> Current:
>> The following shows the format of the LSPA object as defined in 
>> [RFC5440] with the addition of the E flag defined in this document:
>> -->
>> 
>> 
>> 
>> 
>> 14) <!-- [rfced] May we rephrase this sentence to improve clarity?
>> 
>> 
>> Original:
>> Considerations in the message passing between the PCC and the PCE for 
>> the E flag bit which are not supported by the entity are outlined in 
>> this section, with requirements for the PCE and the PCC implementing 
>> this document described at the end.
>> 
>> 
>> Perhaps:
>> This section outlines considerations for the E flag bit in the 
>> message passing between the PCC and the PCE that are not supported by the entity.
>> The requirements for the PCE and the PCC implementing this document 
>> are described at the end.
>> -->
>> 
>> 
>> 
>> 
>> 15) <!-- [rfced] Should "PCUpd E flag (and L flag)" be updated to 
>> "the E flag (and L flag) in a PCUpd message" or something similar? 
>> Also, we used a semicolon and changed "therefore" to "so" for clarity. Please review.
>> 
>> 
>> Original:
>> For PCC-initiated LSPs, PCUpd E flag (and L flag) is an echo from the 
>> previous PCRpt however the bit value is ignored on the PCE from the 
>> previous PCRpt, therefore the E flag value set in the PCUpd is zero.
>> 
>> 
>> Perhaps:
>> For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message is 
>> an echo from the previous PCRpt message; however, the bit value is 
>> ignored on the PCE from the previous PCRpt message, so the E flag value set in the PCUpd message is 0.
>> -->
>> 
>> 
>> 
>> 
>> 16) <!-- [rfced] Will readers understand what "it" refers to here?
>> 
>> 
>> Original:
>> For a PCC which does support this document, it MAY set the E flag to
>> 1 depending on local configuration.
>> 
>> 
>> Perhaps:
>> A PCC that does support this document MAY set the E flag to
>> 1 depending on local configuration.
>> 
>> 
>> Or:
>> For a PCC that does support this document, the E flag MAY be set to
>> 1 depending on local configuration.
>> -->
>> 
>> 
>> 
>> 
>> 17) <!-- [rfced] Would you like the references to be alphabetized or 
>> left in their current order?
>> -->
>> 
>> 
>> 
>> 
>> 18) <!-- [rfced] Terminology
>> 
>> 
>> a) Please confirm the name/description for the E flag defined in this 
>> document. We see the following forms used in the document:
>> 
>> 
>> Enforcement
>> Protection Enforcement
>> Local Protection Enforcement
>> 
>> 
>> Note: The current name in the "LSPA Object Flag Field" registry is 
>> "Protection Enforcement" (see 
>> https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-fie
>> ld <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field> <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field> <https://www.iana.org/assignments/pcep/pcep.xhtml#lspa-object-flag-field&gt;>); if needed, we will request an update to the registry prior to publication.
>> 
>> 
>> 
>> 
>> b) Should "a local protection desired" here read "the L flag"?
>> 
>> 
>> Original:
>> Therefore, a local protection desired does not require the transit 
>> router to satisfy protection in order to establish the RSVP signalled 
>> path.
>> 
>> 
>> Perhaps:
>> Therefore, the L flag does
>> not require the transit router to satisfy protection in order to 
>> establish the RSVP-signaled path.
>> 
>> 
>> 
>> 
>> c) FYI - We have updated instances of "PCRpt", "PCUpd", "PCReq", and 
>> "PCInitiate" with the word "message" (i.e., "PCRpt message", "PCUpd 
>> message", "PCReq message", and "PCInitiate message").
>> 
>> 
>> 
>> 
>> d) We see "Session Attribute" (initial caps and no hyphen) in RFC 
>> 3209, but we do not see "SESSION-ATTRIBUTE" (all caps with hyphen). 
>> Please review and let us know if any updates are needed in the following sentence.
>> 
>> 
>> Original:
>> One such concept in PCEP is the 'Local Protection Desired' (L flag in 
>> the LSPA Object in [RFC5440]), which was originally defined in the 
>> SESSION-ATTRIBUTE Object in RFC3209.
>> 
>> 
>> 
>> 
>> e) "Segment Routed path" does not appear in RFC 8664, but "Segment 
>> Routing path" does. Are any changes needed in these sentences?
>> 
>> 
>> Original:
>> PCEP Extensions for Segment Routing ([RFC8664]) extends support in 
>> PCEP for Segment Routed paths.
>> ...
>> When computing a Segment Routed path, It is RECOMMENDED that a PCE 
>> assume a Node SID is protected.
>> 
>> 
>> f) We see that "LSP object" is used in both RFCs 8231 and 8281, but 
>> "LSP Attribute Object" (or "LSPA") is not used in either. Should the 
>> sentence below be updated to reflect usage in the cited documents?
>> 
>> 
>> Original:
>> It is
>> important to note that [RFC8231] and [RFC8281] permit the LSP 
>> Attribute Object to be included in PCUpd messages for PCC-initiated 
>> and PCE-initiated LSPs.
>> -->
>> 
>> 
>> 
>> 
>> 19) <!-- [rfced] FYI - We have added expansions for the following 
>> abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please 
>> review each expansion in the document carefully to ensure correctness.
>> 
>> 
>> Path Computation Element Communication Protocol (PCEP) Label Switched 
>> Path (LSP) Border Gateway Protocol - Link State (BGP-LS) Service 
>> Level Agreement (SLA)
>> -->
>> 
>> 
>> 
>> 
>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of 
>> the online Style Guide 
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> 
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;> 
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;> 
>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&amp;
>> gt;&gt;> and let us know if any changes are needed.
>> 
>> 
>> Note that our script did not flag any words in particular, but this 
>> should still be reviewed as a best practice.
>> -->
>> 
>> 
>> 
>> 
>> Thank you.
>> 
>> 
>> RFC Editor/rv/ap
>> 
>> 
>> On Sep 28, 2023, at 2:02 PM, [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> *****IMPORTANT*****
>> 
>> 
>> Updated 2023/09/28
>> 
>> 
>> 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/ <https://www.rfc-editor.org/faq/> <https://www.rfc-editor.org/faq/> <https://www.rfc-editor.org/faq/&gt;>).
>> 
>> 
>> 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/ <https://trustee.ietf.org/license-info/> <https://trustee.ietf.org/license-info/> <https://trustee.ietf.org/license-info/&gt;>).
>> 
>> 
>> * 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> <https://authors.ietf.org/rfcxml-vocabulary&gt;> <https://authors.ietf.org/rfcxml-vocabulary&gt;> <https://authors.ietf.org/rfcxml-vocabulary&amp;gt;&gt;>.
>> 
>> 
>> * 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] <mailto:[e-mail]> 
>> <mailto:[e-mail] <mailto:[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] <mailto:[e-mail]> 
>> <mailto:[e-mail] 
>> <mailto:[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-4Q9l2USx
>> IAe6P8O4Zc 
>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>> xIAe6P8O4Zc> 
>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>> xIAe6P8O4Zc> 
>> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>> xIAe6P8O4Zc&gt;>
>> 
>> 
>> * The archive itself:
>> https://mailarchive.ietf.org/arch/browse/auth48archive/ 
>> <https://mailarchive.ietf.org/arch/browse/auth48archive/> 
>> <https://mailarchive.ietf.org/arch/browse/auth48archive/> 
>> <https://mailarchive.ietf.org/arch/browse/auth48archive/&gt;>
>> 
>> 
>> * 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] <mailto:[e-mail]> 
>> <mailto:[e-mail] <mailto:[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/rfc9488.xml 
>> <https://www.rfc-editor.org/authors/rfc9488.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.xml&gt;>
>> https://www.rfc-editor.org/authors/rfc9488.html 
>> <https://www.rfc-editor.org/authors/rfc9488.html> 
>> <https://www.rfc-editor.org/authors/rfc9488.html> 
>> <https://www.rfc-editor.org/authors/rfc9488.html&gt;>
>> https://www.rfc-editor.org/authors/rfc9488.pdf 
>> <https://www.rfc-editor.org/authors/rfc9488.pdf> 
>> <https://www.rfc-editor.org/authors/rfc9488.pdf> 
>> <https://www.rfc-editor.org/authors/rfc9488.pdf&gt;>
>> https://www.rfc-editor.org/authors/rfc9488.txt 
>> <https://www.rfc-editor.org/authors/rfc9488.txt> 
>> <https://www.rfc-editor.org/authors/rfc9488.txt> 
>> <https://www.rfc-editor.org/authors/rfc9488.txt&gt;>
>> 
>> 
>> Diff file of the text:
>> https://www.rfc-editor.org/authors/rfc9488-diff.html 
>> <https://www.rfc-editor.org/authors/rfc9488-diff.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-diff.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-diff.html&gt;>
>> https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html 
>> <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-rfcdiff.html&gt;> (side 
>> by side)
>> 
>> 
>> Diff of the XML:
>> https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html 
>> <https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html> 
>> <https://www.rfc-editor.org/authors/rfc9488-xmldiff1.html&gt;>
>> 
>> 
>> 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/rfc9488.original.v2v3.xml 
>> <https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.original.v2v3.xml&gt;>
>> 
>> 
>> XMLv3 file that is a best effort to capture v3-related format updates
>> only:
>> https://www.rfc-editor.org/authors/rfc9488.form.xml 
>> <https://www.rfc-editor.org/authors/rfc9488.form.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.form.xml> 
>> <https://www.rfc-editor.org/authors/rfc9488.form.xml&gt;>
>> 
>> 
>> 
>> 
>> Tracking progress
>> -----------------
>> 
>> 
>> The details of the AUTH48 status of your document are here:
>> https://www.rfc-editor.org/auth48/rfc9488 
>> <https://www.rfc-editor.org/auth48/rfc9488> 
>> <https://www.rfc-editor.org/auth48/rfc9488> 
>> <https://www.rfc-editor.org/auth48/rfc9488&gt;>
>> 
>> 
>> Please let us know if you have any questions.
>> 
>> 
>> Thank you for your cooperation,
>> 
>> 
>> RFC Editor
>> 
>> 
>> --------------------------------------
>> RFC9488 (draft-ietf-pce-local-protection-enforcement-11)
>> 
>> 
>> Title : Local Protection Enforcement in PCEP
>> Author(s) : A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan WG Chair(s) 
>> : Julien Meuric, Dhruv Dhody
>> 
>> 
>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> <rfc9488-update-1.xml>
> 
> 
> 
> 
>