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

[Rebecca VanRheenen <[e-mail]>]

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-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&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-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> <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-4Q9l2USxIAe6P8O4Zc <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc> <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc&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>
> 
> 
> 
> 
>