Re: [auth48] [ADs] AUTH48: RFC-to-be 9504 <draft-ietf-pce-pcep-stateful-pce-gmpls-23> for your review

[John Scudder <[e-mail]>]

Regarding point 13, I have no objection to moving the reference to the Normative section.

—John

> On Oct 26, 2023, at 12:33 PM, [e-mail] wrote:
> 
> Authors and *ADs,
> 
> [ADs - please see question 13 below.]
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] In the following, it seems the parenthetical list is made
>     of GMPLS-controlled networks.  We propose to cut "etc.,
>     technologies".  Please let us know any objections.
> 
> Original:
> However, both documents omit the specification for technology-specific
> objects/TLVs, and do not cover GMPLS-controlled networks (e.g.,
> Wavelength Switched Optical Network (WSON), Optical Transport Network
> (OTN), Synchronous Optical Network (SONET)/Synchronous Digital
> Hierarchy (SDH), etc. technologies).
> 
> Perhaps:
> However, both documents omit the specification for technology-specific
> objects/TLVs, and do not cover GMPLS-controlled networks (e.g.,
> Wavelength Switched Optical Network (WSON), Optical Transport Network
> (OTN), Synchronous Optical Network (SONET) / Synchronous Digital
> Hierarchy (SDH)).
> -->
> 
> 
> 2) <!--[rfced] Please review our update to make this sentence end in a
>     list of three things (i.e., LSP update, LSP delegation, and LSP
>     state synchronization/report).  Let us know if this changed the
>     intended meaning.
> 
> Original:
> Many requirements are common across a variety of network types (e.g.,
> MPLS-TE networks and GMPLS networks) and the protocol extensions to
> meet the requirements are already described in [RFC8231], such as LSP
> update, delegation and state synchronization/report.
> 
> Current:
> Many requirements are common across a variety of network types (e.g.,
> MPLS-TE networks and GMPLS networks) and the protocol extensions to
> meet the requirements are already described in [RFC8231] (such as LSP
> update, delegation, and state synchronization/report).
> 
> -->
> 
> 
> 3) <!--[rfced] In the following we see frequent use of specif*.  Might
>     the following suggested text capture your intent?
> 
> Original:
> It also requires the specification of data flow specific traffic
> parameters (also known as Traffic Specification (Tspec)), which are
> technology specific.
> 
> Perhaps:
> It also requires that traffic parameters that are both data flow and
> technology specific be defined.  These traffic parameters are also
> known as "Traffic Specification" or "Tspec".
> -->
> 
> 
> 4) <!--[rfced] Looking at RFC 8231, we see LSP delegation described in
>     Section 5.7, but we don't see anything regarding a "cleanup
>     procedure".  We do see Section 6 of RFC 8281 is titled "LSP
>     Delegation and Cleanup".  Please review the citation and text and
>     let us know if/how we should update.
> 
>     Note also that some type of update will be necessary to take care
>     of the subject/verb agreement issue (procedure...are).
> 
> 
> Orignal:
>   LSP delegation and cleanup procedure specified in [RFC8231] are
>   equally applicable to GMPLS LSPs and this document does not modify
>   the associated usage.
> 
> -->
> 
> 
> 5) <!--[rfced] We had the following questions regarding the term
>     "END-POINTS":
> 
> a) Note that we have updated occurrences of "END-POINTS" as a noun to
> instead appear as "END-POINTS object" for consistency within the
> document and to avoid subject/verb agreement issues.  Please let us
> know any objections.
> 
> For example:
> 
> Original:
> Generalized END-POINTS was specified in [RFC8779] to include GMPLS
> capabilities.
> 
> Current:
> The generalized END-POINTS object was specified in [RFC8779] to
> include GMPLS capabilities.
> 
> Original:
> All Stateful PCEP messages MUST include the END-POINTS with
> Generalized Endpoint object type, containing the LABEL-REQUEST TLV.
> 
> Current:
> All Stateful PCEP messages MUST include the END-POINTS object with
> Generalized Endpoint object type, containing the LABEL-REQUEST TLV.
> 
> b) We note that RFC 8779 never uses "Generalized END-POINTS".  We see
> both "END-POINTS" object and "END-POINTS Generalized Endpoint object".
> Please review our same sentences above and let us know if any updates
> are necessary.
> -->
> 
> 
> 6) <!--[rfced] Does the following update correctly capture your intent?
>     If not, please let us know how to rephrase.
> 
> Original:
> The description by usage of non-GMPLS LSPs is not in the scope of this
> document.
> 
> Perhaps:
> A description of non-GMPLS LSP usage is not in the scope of this
> document.
> 
> -->
> 
> 
> 7) <!--[rfced] We note the following discrepancy between this document
>     and RFC 8779.  Please review and let us know if/how to update.
> 
> Original in this doc:
> RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG TLV. The
> value are defined as per [RFC8779]:
> 
> 00:    reserved
> 01:    node
> 10:    link
> 11:    label
> 
> RFC 8779:
> A new 2-bit Routing Granularity (RG) flag (bits 15-16) is defined in
> the RP object. The values are defined as follows:
> 
> 0:  reserved
> 1:  node
> 2:  link
> 3:  label
> 
> -->
> 
> 
> 8) <!--[rfced] May we rephrase this text as follows for the ease of the
>     reader?
> 
> Original:
> Optionally, it MAY also provide with the unrecognized symbolic path
> name information to the requesting PCC using the error reporting
> techniques described in [RFC5440].
> 
> Perhaps:
> Along with the unrecognized symbolic path name, it MAY also provide
> information to the requesting PCC using the error-reporting techniques
> described in [RFC5440].
> 
> -->
> 
> 
> 9) <!--[rfced] In light of the following text, should IANA update the
>     "LSP Exclusion Sub-Object Flag Field" registry at
>     https://urldefense.com/v3/__https://www.iana.org/assignments/pcep__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFI8BSp89g$  to use "Capability
>     Description" instead of "Description" as a column title?  This
>     would match the use in the "LSP-EXTENDED-FLAG TLV Flag field"
>     registry in the same group.  If so, please let us know and we can
>     communicate this change to IANA once AUTH48 completes.
> 
> Original:
>   New values are to be assigned by Standards Action [RFC8126].  Each
>   bit should be tracked with the following qualities:
> 
>   *  Bit number (counting from bit 0 as the most significant bit)
> 
>   *  Capability description
> 
>   *  Defining RFC
> 
> IANA registry:
> Bit     Description     Reference
> -->
> 
> 
> 10) <!--[rfced] We had a few questions regarding the IANA registration
>     "LSP-EXTENDED-FLAG TLV Flag Field" at
>     https://urldefense.com/v3/__https://www.iana.org/assignments/pcep__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFI8BSp89g$ :
> 
> a) May we cap "co-routed"?  Or is the capping scheme intended to be
> 1:1 with the abbreviations?  (See our note about closing
> "bi-directional" in a separate query.)
> 
> Original:
> 1       Bi-directional co-routed LSP (B)
> 
> Perhaps:
> 1       Bidirectional Co-routed LSP (B)
> 
> b) We note that only the Routing Granularity Flag (RG) has the word
> "Flag" in the "Capability Description" entry in the "LSP-EXTENDED-FLAG
> TLV Flag Field" registry (see https://urldefense.com/v3/__https://www.iana.org/assignments/pcep__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFI8BSp89g$ ).
> 
> From the text of this document and the registry title, it appears all
> entries in this registry are actually flags.  Should this entry (and
> the corresponding instances in the text in the document) be updated to
> simply "Routing Granularity (RG)"?
> 
> Original:
> 2-3     Routing Granularity Flag (RG)
> 
> Perhaps:
> 2-3     Routing Granularity (RG)
> 
> -->
> 
> 
> 11) <!--[rfced] Please review the capping of the Error-Types and
>     Error-values registered in the PCEP-ERROR Object Error Types and
>     Values registry at https://urldefense.com/v3/__https://www.iana.org/assignments/pcep__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFI8BSp89g$  for the
>     following:
> 
> a) Should the entries in this registry be made to have an initial
> capital and the following words lowercased?
> 
> Some existing examples that do not follow that pattern:
> 
> 28: use of Generalized Endpoint object type for non-GMPLS LSP
> 23: LSP state info unavailable for the Re-optimization
> 6:  Mandatory Object missing
> 
> b) The use of the definite article "the" in the following makes it
> feel as if text is missing after "Re-optimization".  Is this the case
> (i.e., the re-optimization of what?) or should we update as suggested?
> 
> As it currently appears in the IANA registry (and the document):
> 23: LSP state info unavailable for the Re-optimization
> 
> Perhaps:
> 23: LSP state info unavailable for Re-optimization
> 
> Note also that there is a mismatch between the way this value appears
> in the IANA registry and its use in the text of this document.
> 
> In-text usage:
> ...report the error "LSP state information unavailable for the LSP
> re-optimization" (Error Type = 19, Error value= 23),...
> 
> How may we make these uniform?
> 
> c) We see a mismatch between the IANA registry and the in-text usage
> for this Error-value.  Please let us know if/how we need to update for
> uniformity:
> 
> In the IANA registry:
> 24: LSP state info for route exclusion not found
> 
> In-text use in the document:
> ...Error-value = 24 ("The LSP state information for route exclusion
> purpose cannot be found").
> 
> 
> d) We see a mismatch between the IANA registry and the in-text usage
> for this Error-value.  Please let us know if/how we need to update for
> uniformity:
> 
> In the IANA registry:
> 25: Attempted LSP Update Request for GMPLS if stateful PCE capability
> not advertised
> 
> In-text use in the document:
> ...error-value 25 ("Attempted LSP Update Request for GMPLS if stateful
> PCE capability for GMPLS was not advertised")
> 
> e) We see a mismatch between the IANA registry and the in-text usage
> for this Error-value.  Please let us know if/how we need to update for
> uniformity:
> 
> In the IANA registry:
> 26: Attempted LSP State Report for GMPLS if stateful PCE capability
> not advertised
> 
> In-text use in the document:
> ...error-value 26 ("Attempted LSP Report Request for GMPLS if stateful
> PCE capability for GMPLS was not advertised")
> 
> f) We see a mismatch between the IANA registry and the in-text usage
> for this Error-value.  Please let us know if/how we need to update for
> uniformity:
> 
> In the IANA registry:
> 27: Attempted LSP Instantiation Request for GMPLS if stateful PCE
> instantiation capability not advertised
> 
> In-text use in the document:
> ...error-value 27 ("Attempted LSP Instantiation Request for GMPLS if
> stateful PCE instantiation capability for GMPLS was not advertised")
> 
> g) We recommend making the way the Error-Type and Error-values are
> referenced in the text consistent with regard to the following:
> 
> -spacing around the equals sign
> -what appears in parentheses: the description or the values.
> -note our further question about "Error-Type" and "Error-value" and
> how they should appear in the terminology query below.
> 
> Please let us know what general pattern these should follow so that we
> may update for consistency throughout.
> 
> Originals:
> 
> ...it SHOULD send an error message PCErr reporting Error-type = 19
> ("Invalid Operation"), Error-value = TBD7 ("The LSP state information
> for route exclusion purpose cannot be found").
> 
> ...it SHOULD generate a PCErr with error-type 19 ("Invalid
> Operation"), error- value TBDx ("Attempted LSP Update Request for
> GMPLS if stateful PCE capability for GMPLS was not advertised")
> 
> ...the stateful PCE SHOULD report the error "LSP state information
> unavailable for the LSP re-optimization" (Error Type = 19, Error
> value= TBD6)
> 
> -->
> 
> 
> 12) <!--[rfced] We have received guidance from Benoit Claise and the YANG
>     Doctors that "YANG module" and "YANG data model" are preferred.
>     We have updated the text to use these forms.  Please review.
> -->
> 
> 
> 13) <!--[rfced] *AD - Per
>    https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIgEbnY5Q$ :
> 
> "The use of a language requires a reference to the specification for
> that language. This reference is normative, and needs to fulfil the
> usual requirements for normative references (section 7 of RFC 2026). "
> 
> Should RFC 551 be moved to the Normative References section?  We note
> that the authors point out in the appendix that:
> 
> "The RBNF in this section is reproduced for informative purposes."
> 
> -->
> 
> 
> 14) <!-- [rfced] Please note that we have updated pointers to reference
>     [I-D.ietf-pce-lsp-extended-flags] to instead point to RFC 9357,
>     which is already listed as a normative reference.  Please let us
>     know any objection.
> 
> Original:
>   [I-D.ietf-pce-lsp-extended-flags]
>              Xiong, Q., "Label Switched Path (LSP) Object Flag
>              Extension for Stateful PCE", Work in Progress, Internet-
>              Draft, draft-ietf-pce-lsp-extended-flags-09, 23 October
>              2022, <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFLVOzVltA$
>              pce-lsp-extended-flags-09>.
> -->
> 
> 
> 15) <!-- [rfced] In Appendices A.1. and A.2., the text seems to indicate
>     that RFC 8779 augments the ERO with Explicit Label Control (ELC)
>     and Path Keys.
> 
>     We see that "explicit label control" appears in RFC 8779, but
>     "Path Keys" does not.  Please review and let us know if/how to update.
> 
> Original:
> <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5
> 440], augmented in [RFC8779] with explicit label control (ELC) and Path Keys.
> -->
> 
> 
> 16) <!--[rfced] In the last sentence below, should "message" actually be
>     "messages" (i.e., the PCInitiate message has the same fields as a
>     PCRpt message and a PCUpd message)?
> 
> Original:
>   The format of the PCInitiate message is unchanged from Section 5.1
>   of [RFC8281].  All fields are similar to the PCRpt and the PCUpd
>   message.
> 
> Perhaps:
>   The format of the PCInitiate message is unchanged from Section 5.1
>   of [RFC8281].  All fields are similar to the PCRpt and the PCUpd
>   messages.
> -->
> 
> 
> 17) <!-- [rfced] Please review the "type" attribute of each sourcecode
>     element in the XML file to ensure correctness. If the current
>     list of preferred values for "type"
>     (https://urldefense.com/v3/__https://www.rfc-editor.org/materials/sourcecode-types.txt__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJVaGTUHA$ ) does
>     not contain an applicable type, then feel free to let us
>     know. Also, it is acceptable to leave the "type" attribute not
>     set.
> 
> In addition, review each artwork element. Specifically, should any
> artwork element be tagged as sourcecode or another element?
> -->
> 
> 
> 18) <!--[rfced] Please review the following questions related to
>     abbreviations used throughout the document.
> 
> a) As the "O" in XRO and IRO stands for Object, might we update as
> follows to avoid redundancy?
> 
> Original:
> The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and
> Exclude Route Object (XRO) objects are extended for GMPLS in [RFC8779]
> and are also used in the PCRpt in the same manner.
> 
> Perhaps:
> The following objects are extended for GMPLS in [RFC8779] and are also
> used in the PCRpt in the same manner: BANDWIDTH, LSP Attributes
> (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO).
> 
> b) "G-PID" is expanded as "generalized payload" in this document.
> However, we see the following different expansions of G-PID across
> previously published RFCs.  Please let us know if/how we may update.
> 
> "Generalized PID" in RFC 3471
> "The Generalized Protocol Identifier" in RFCs 6163 and 8779
> "Generalized Payload Identifier" in RFC 6060
> 
> c) Please note that we expanded the following abbreviations.  Please
> review and let us know if any changes are necessary:
> 
> P2MP - Point-to-Multipoint
> RRO - Record Route Object
> RP - Request Parameter
> 
> d) May we remove the expansions from subsequent uses (i.e., after they
> have been expanded on first use) of the following abbreviations (to
> match the gudiance given under "Expanding Abbreviations upon First
> Use" at https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/)?__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJrqtG_VQ$
> 
> XRO
> ELC
> PCE
> MPLS
> GMPLS
> -->
> 
> 
> 19) <!-- [rfced] Please review the following questions related to
>     terminology that appears throughout the document.
> 
> a) The following terms appear sometimes with initial caps and
> sometimes in lowercase form throughout the document.  We plan to
> globally (excepting titles, proper nouns, and code) update to use
> lowercase throughout to match use in past RFCs (specifically those
> cited as normative references) unless we hear objection / further
> guidance.
> 
> Stateful
> Sub-object
> Object
> Object Type
> Message
> 
> b) We see the following inconsistent uses of similar terms.  Looking at
> the normative references and the "PCEP-ERROR Object Error Types and
> Values" registry (see https://urldefense.com/v3/__https://www.iana.org/assignments/pcep__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFI8BSp89g$ ),
> Error-Type and Error-value seem to be used most frequently (but not
> consistently).  May we update to use "Error-Type" and "Error-value"
> throughout?
> 
> Error-Type vs. Error-type vs. error-type vs. Error Type
> Error-value vs. Error value
> 
> c) We see mixed use of hyphenation in the following term (and some
> capped instances).  Past RFCs use the closed compound in lowercase far
> more frequently.  May we update to use the closed compound and
> lowercase throughout (excepting titles and proper nouns)?
> 
> Note that this change would affect IANA and be communicated to IANA
> after AUTH48 completes.
> 
> sub-object vs. subobject
> 
> Note also that we have already closed the following compounds due to
> overwhelming preference in recently published RFCs.  Please let us
> know any objections.
> 
> bidirection
> unidirection
> reoptimization
> 
> d) We see use of the following similar terms:
> 
> GMPLS technology-specific attributes
> GMPLS-technology specific Objects/TLVs
> GMPLS-specific extensions
> 
> We would expect "GMPLS technology-specific" or
> "GMPLS-technology-specific" in attributive position (depending on the
> relationship).
> 
> e) We see inconsistent capping schemes for the following terms.
> Please let us know if/how we may update for consistency.
> 
> Symbolic Path Name vs. symbolic path name
> LSP Exclusion vs. LSP exclusion
> 
> f) We see the following terms used in the normative references
> consistently in a way different from what is used in this document.
> We will update to match the style on the right (when not in a title or
> proper noun) to be consistent with past RFCs unless we hear objection.
> 
> Capability Advertisement / capability advertisement
> 
> g) We see both "SWITCH-LAYER" and "SWITCHING-LAYER".  RFC 8282 only
> uses "SWITCH-LAYER".  May we update the following text?
> 
> Original:
>   SWITCH-LAYER:  SWITCHING-LAYER definition in Section 3.2 of
>      [RFC8282] is applicable in Stateful PCEP messages for GMPLS
>      networks.
> 
> Perhaps:
>   SWITCH-LAYER:  The SWITCH-LAYER definition in Section 3.2 of
>      [RFC8282] is applicable in Stateful PCEP messages for GMPLS
>      networks.
> 
> 
> -->
> 
> 
> 20) <!--[rfced] We see a number of uses of the "/" character in this
>     document (see examples below - not an exhaustive list).  We
>     recommend reviewing these instances and updating with "and" or
>     "or" for the ease of the reader.
> 
> Examples:
> Any modifications to the Objects/TLVs that are identified...
> 
> For passive stateful PCEs, Path Computation Request (PCReq) / Path
> Computation Reply (PCRep) messages are used...
> 
> ...only LSPs that share the same headnode/PCC could be excluded.-->
> 
> 
> 21) <!--[rfced] Please review the use of articles before "stateful PCE"
>     and "stateful PCEP" throughout the document.  Should an article
>     (a/an or the) be added to cases like the following?  Or should
>     they be made plural (as in the example below)?  Use in the
>     original version of the document is mixed.  Please review each
>     instance and let us know how to update them.
> 
> Original:
> The requirements for GMPLS-specific stateful PCE are as follows:
> 
> Perhaps:
> The requirements for GMPLS-specific stateful PCEs are as follows:
> 
> -->
> 
> 
> 22) <!-- [rfced] Please review the "Inclusive Language" portion of the
>     online Style Guide
>     <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJ3ct_53g$ >
>     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/kf/mf
> 
> *****IMPORTANT*****
> 
> Updated 2023/10/26
> 
> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJnHRterw$ ).
> 
> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIBxoxpbg$ ).
> 
> *  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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJGYpG5lA$ >.
> 
> *  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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFKIeKk0Pg$
> 
>     *  The archive itself:
>        https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFL5PS3Nrw$
> 
>     *  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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504.xml__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIBrGNAvQ$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJbAQqnPw$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504.pdf__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJijATm3w$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504.txt__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFLzc85u4A$
> 
> Diff file of the text:
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504-diff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFK54a5sZA$
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504-rfcdiff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIOvBuf2A$  (side by side)
> 
> Diff of the XML:
>   https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9504-xmldiff1.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFKOVe1WzQ$
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>   https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9504__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJndIuFlQ$
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9504 (draft-ietf-pce-pcep-stateful-pce-gmpls-23)
> 
> Title            : Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-controlled Networks
> Author(s)        : Y. Lee, H. Zheng, O. Dios, V. Lopez, Z. Ali
> WG Chair(s)      : Julien Meuric, Dhruv Dhody
> 
> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
> 
>