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

[Rebecca VanRheenen <[e-mail]>]

Hi Samuel,

Thank you for your 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.

Sincerely,
RFC Editor/rv



> On Oct 5, 2023, at 2:38 AM, Samuel Sidor (ssidor) <[e-mail]> wrote:
> 
> 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>
>> 
>> 
>> 
>> 
>> 
>