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

[Zhenghaomian <[e-mail]>]

Dear Editors, 

Thank you for the comments, please see the response inline:)

Best wishes,
Haomian

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Friday, October 27, 2023 12:33 AM
To: [e-mail]; Zhenghaomian <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [ADs] AUTH48: RFC-to-be 9504 <draft-ietf-pce-pcep-stateful-pce-gmpls-23> for your review

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)).
-->
[Haomian] Okay with the change. 

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).

-->
[Haomian] Okay with the change.

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".
-->
[Haomian] Okay with the change.

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.

-->
[Haomian] This is good catch, the RFC8231 said 'delegate' and 'revoke' while the RFC8281 said 'delegate' and 'cleanup'. I would prefer changing the reference to 'RFC8281' without term changes. 

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.

[Haomian] Understood and fine with the proposed changes. 

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.
-->
[Haomian] This is correct. Editorial could be made as follow: 
OLD: 
   *  END-POINTS: Generalized END-POINTS was specified in [RFC8779] to include GMPLS capabilities.  
NEW:
   *  END-POINTS: END-POINTS Object was specified in [RFC8779] to include GMPLS capabilities.  

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.

-->
[Haomian] A bit hesitating on this due to not understanding the difference. What we try to say here is that XRO sub-object can be used by both GMPLS LSPs and non-GMPLS LSPs, but our description in this document only focus on the GMPLS LSP usage, we don't care the non-GMPLS LSP usage of XRO sub-object as this document has a scope for GMPLS only. How about the following? (please feel free to tweak as native speaker)
OLD: 
The description by usage of non-GMPLS LSPs is not in the scope of this document.
NEW: 
The usage of XRO sub-object for any non-GMPLS LSPs 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

-->
[Haomian] The two representations are equivalent to me. I would prefer not to change the current text as the '10' is more straightforward representation as a '2-bit flag' than '2'. 

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].

-->
[Haomian] Okay with the change. 

9) <!--[rfced] In light of the following text, should IANA update the
     "LSP Exclusion Sub-Object Flag Field" registry at
     https://www.iana.org/assignments/pcep 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 
-->
[Haomian] I checked the iana website and found the 'description' and 'capability description' are both used. But I think you are right as we need to keep consistency with LSP-EXTENDED-FLAG. I am okay with this change and please sync up with IANA after editing, thanks. 

10) <!--[rfced] We had a few questions regarding the IANA registration
     "LSP-EXTENDED-FLAG TLV Flag Field" at
     https://www.iana.org/assignments/pcep:

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://www.iana.org/assignments/pcep).

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)

-->
[Haomian] Okay with both changes above. 

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://www.iana.org/assignments/pcep 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

[Haomian] Yes you are right we should be consistent on this, please go ahead to change. 

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:

[Haomian] Given the comments above, I would propose the IANA entry looks like "23: LSP state info unavailable for re-optimization". And meanwhile we change the in-text description as follow. I hope this addresses the issue. 
OLD: 
If no LSP state information is available to carry out re-optimization, the stateful PCE SHOULD report the error "LSP state information unavailable for the LSP re-optimization" (Error Type = 19, Error value= TBD6), although such a PCE MAY consider the re-optimization to have successfully completed.
NEW: 
If no LSP state information is available to carry out re-optimization, the stateful PCE SHOULD report the error "L LSP state info unavailable for re-optimization " (Error Type = 19, Error value= 23), although such a PCE MAY consider the re-optimization to have successfully completed.

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)

-->
[Haomian] All above are similar issues, please help all aligned to the IANA description and change at the in-text side. Let me know if more details needed. 

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.
-->
[Haomian] I am okay to follow the guidance. But I did not find the updated text, anything missed here? 

13) <!--[rfced] *AD - Per
    https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/:

"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."

-->
[Haomian] According to the guidance of how formal languages are used, we should move RFC 5511 to normative, even though the authors produce the RBNF only for informative purpose. Please help move to normative. 

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://datatracker.ietf.org/doc/html/draft-ietf-
              pce-lsp-extended-flags-09>.
-->

[Haomian] Agree, that's also our expectation. 


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.
-->
[Haomian] please remove Path Keys.
OLD:
<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.

NEW:
<intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label control (ELC).

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.
-->
[Haomian] Agree. 

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://www.rfc-editor.org/materials/sourcecode-types.txt) 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?
-->

[Haomian] not xml expert and just read txt/html, perhaps these were copied from other xml segments. Do you have any explicit places that we should pay attention to? Good to learn from this:)


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
[Haomian] I would prefer G-PID expanded as Generalized Payload Identifier, as it maps (not one to one) the payload types in ITU-T G.709.  

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://www.rfc-editor.org/styleguide/part2/)?

XRO
ELC
PCE
MPLS
GMPLS
-->
[Haomian] okay for c) and d)

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

[Haomian] Okay. 

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://www.iana.org/assignments/pcep),
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

[Haomian] Okay, update to "Error-Type" and "Error-value" according to RFC5440 and IANA.

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
[Haomian] Okay to use either of with or without hyphen, the objective is to keep consistency with other RFCs, please help on this. 

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).

[Haomian] Let's use "GMPLS-specific". 

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
[Haomian] For TLV it is "SYMBOLIC-PATH-NAME" and in text we use "symbolic path name". For Sub-Object Flag Field we use "LSP Exclusion" and in text we use "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
[Haomian] Agree. 

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.


-->
[Haomian] Agree. 

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.-->

[Haomian] "Objects/TLVs " should be "Objects and TLVs", " GMPLS LSP creation/modification/deletion " should be "GMPLS LSP creation, modification and deletion", " headnode/PCC " should be "head node or PCC", "Path Computation Request (PCReq)/ Path   Computation Reply (PCRep) messages " should be "Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages ". Let me know if any more need to be confirmed. 

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:

-->
[Haomian] For "stateful PCE" we need the articles, the change in the raised example is fine. For "stateful PCEP" it refers to the protocol design and I don't think we need articles. I am struggling in English grammar and open to suggestions. 

22) <!-- [rfced] Please review the "Inclusive Language" portion of the
     online Style Guide
     <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
     and let us know if any changes are needed.

Note that our script did not flag any words in particular, but this should still be reviewed as a best practice.

-->
[Haomian] This is noted and so far it's fine. 

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://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.

Planning your review
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

   Please review and resolve any questions raised by the RFC Editor 
   that have been included in the XML file as comments marked as 
   follows:

   <!-- [rfced] ... -->

   These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

   Please ensure that you review any changes submitted by your 
   coauthors.  We assume that if you do not speak up that you 
   agree to changes submitted by your coauthors.

*  Content 

   Please review the full content of the document, as this cannot 
   change once the RFC is published.  Please pay particular attention to:
   - IANA considerations updates (if applicable)
   - contact information
   - references

*  Copyright notices and legends

   Please review the copyright notice and legends as defined in
   RFC 5378 and the Trust Legal Provisions 
   (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

   Please review the markup in the XML file to ensure that elements of  
   content are correctly tagged.  For example, ensure that <sourcecode> 
   and <artwork> are set correctly.  See details at 
   <https://authors.ietf.org/rfcxml-vocabulary>.

*  Formatted output

   Please review the PDF, HTML, and TXT files to ensure that the 
   formatted output, as generated from the markup in the XML file, is 
   reasonable.  Please note that the TXT will have formatting 
   limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties
include:

   *  your coauthors
   
   *  [e-mail] (the RPC team)

   *  other document participants, depending on the stream (e.g., 
      IETF Stream participants are your working group chairs, the 
      responsible ADs, and the document shepherd).
     
   *  [e-mail], which is a new archival mailing list 
      to preserve AUTH48 conversations; it is not an active discussion 
      list:
     
     *  More info:
        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
     
     *  The archive itself:
        https://mailarchive.ietf.org/arch/browse/auth48archive/

     *  Note: If only absolutely necessary, you may temporarily opt out 
        of the archiving of messages (e.g., to discuss a sensitive matter).
        If needed, please add a note at the top of the message that you 
        have dropped the address. When the discussion is concluded, 
        [e-mail] will be re-added to the CC list and 
        its addition will be noted at the top of the message. 

You may submit your changes in one of two ways:

An update to the provided XML file
 — OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.


Files
-----

The files are available here:
   https://www.rfc-editor.org/authors/rfc9504.xml
   https://www.rfc-editor.org/authors/rfc9504.html
   https://www.rfc-editor.org/authors/rfc9504.pdf
   https://www.rfc-editor.org/authors/rfc9504.txt

Diff file of the text:
   https://www.rfc-editor.org/authors/rfc9504-diff.html
   https://www.rfc-editor.org/authors/rfc9504-rfcdiff.html (side by side)

Diff of the XML: 
   https://www.rfc-editor.org/authors/rfc9504-xmldiff1.html

Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
   https://www.rfc-editor.org/auth48/rfc9504

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