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

[Megan Ferguson <[e-mail]>]

Thank you for the quick turnaround, David.

We will move this document forward in the publication process at this time.

RFC Editor/mf


> On Nov 30, 2023, at 2:10 PM, David Dong via RT <[e-mail]> wrote:
> 
> Hi Megan,
> 
> These changes are complete; please see:
> 
> https://www.iana.org/assignments/pcep/
> 
> Best regards,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> On Thu Nov 30 19:39:59 2023, [e-mail] wrote:
>> IANA,
>> 
>> Please review the following updates and let us know any
>> questions/comments/concerns.
>> 
>> Once these changes have been confirmed, this document will be ready to
>> move forward in the publication process.
>> 
>> Thank you.
>> 
>> RFC Editor/mf
>> 
>> 1) We have a few updates to the IANA registration "LSP-EXTENDED-FLAG
>> TLV Flag Field" at
>>    https://www.iana.org/assignments/pcep:
>> 
>> a) Please remove the hyphen from “Bi-directional” and cap “co-routed”:
>> 
>> Old:
>> 1       Bi-directional co-routed LSP (B)
>> 
>> New:
>> 1       Bidirectional Co-routed LSP (B)
>> 
>> b) Please remove the word “Flag”
>> 
>> Old:
>> 2-3     Routing Granularity Flag (RG)
>> 
>> New:
>> 2-3     Routing Granularity (RG)
>> 
>> 2) Please review the changes to the Error-values registered
>> in the PCEP-ERROR Object Error Types and Values registry at
>> https://www.iana.org/assignments/pcep
>> for the following changes:
>> 
>> Old:
>> 20: LSP state info unavailable for the Re-optimization
>> 
>> New:
>> 20: LSP state info unavailable for reoptimization
>> 
>> Old:
>> 25: Attempted LSP Update Request for GMPLS if stateful PCE capability
>> not advertised
>> 
>> New:
>> 25: Attempted LSP update request for GMPLS if stateful PCE capability
>> not advertised
>> 
>> Old:
>> 27: Attempted LSP Instantiation Request for GMPLS if stateful PCE
>> instantiation capability not advertised
>> 
>> New:
>> 27: Attempted LSP instantiation request for GMPLS if stateful PCE
>> instantiation capability not advertised
>> 
>> Old:
>> 28: use of Generalized Endpoint object type for non-GMPLS LSPs
>> 
>> New:
>> 28: Use of the Generalized Endpoint object type for non-GMPLS LSPs
>> 
>> 
>> 
>>> On Nov 29, 2023, at 1:11 AM, Oscar González de Dios
>>> <[e-mail]> wrote:
>>> 
>>> Dear RFC Editors,
>>> 
>>> I am OK with the changes done and I approve the AUTH48.
>>> 
>>> Thanks and best Regards,
>>> 
>>> Oscar
>>> 
>>> -----Mensaje original-----
>>> De: Megan Ferguson <[e-mail]>
>>> Enviado el: martes, 14 de noviembre de 2023 18:43
>>> Para: Dhruv Dhody <[e-mail]>; [e-mail];
>>> [e-mail]; Oscar González de Dios
>>> <[e-mail]>; John Scudder
>>> <jgs=[e-mail]>
>>> CC: Zafar Ali (zali) <[e-mail]>; Zhenghaomian
>>> <[e-mail]>; [e-mail]; pce-
>>> [e-mail]; [e-mail]; [e-mail]
>>> Asunto: Re: AUTH48: RFC-to-be 9504 <draft-ietf-pce-pcep-stateful-pce-
>>> gmpls-23> for your review
>>> 
>>> Greetings,
>>> 
>>> Just a friendly reminder that this document awaits attention from
>>> those listed as “Not Approved” at the AUTH48 status page (see below).
>>> Please see the document-specific questions, AUTH48 announcement, and
>>> other author communication in this thread and let us know if we can
>>> be of assistance as you begin the AUTH48 review process.
>>> 
>>> Please note that the AUTH48 status page of this document is viewable
>>> at:
>>> 
>>> http://www.rfc-editor.org/auth48/rf9504
>>> 
>>> AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48.
>>> 
>>> We look forward to hearing from you at your earliest convenience.
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/mf
>>> 
>>>> On Nov 8, 2023, at 11:15 AM, Megan Ferguson <[e-mail]>
>>>> wrote:
>>>> 
>>>> Zafar and Haomian,
>>>> 
>>>> Thank you for your replies.  We have updated the AUTH48 status page
>>>> to
>>>> reflect your approvals.
>>>> 
>>>> Please note that we will assume your assent to any further changes
>>>> submitted by your coauthors unless we hear otherwise at that time.
>>>> 
>>>> The AUTH48 status page is viewable at:
>>>> 
>>>> http://www.rfc-editor.org/auth48/rfc9504
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/mf
>>>> 
>>>>> On Nov 8, 2023, at 2:34 AM, Zafar Ali (zali) <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>> Hi
>>>>> 
>>>>> I am fine with the changes and approve the AUTH48.
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> Regards … Zafar
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Megan Ferguson [mailto:[e-mail]]
>>>>> Sent: Wednesday, November 8, 2023 5:35 AM
>>>>> To: Dhruv Dhody <[e-mail]>
>>>>> Cc: Zhenghaomian <[e-mail]>; John Scudder
>>>>> <jgs=[e-mail]>; [e-mail];
>>>>> [e-mail]; Oscar González de Dios
>>>>> <[e-mail]>; [e-mail];
>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Subject: Re: AUTH48: RFC-to-be 9504
>>>>> <draft-ietf-pce-pcep-stateful-pce-gmpls-23> for your review
>>>>> 
>>>>> Dhruv,
>>>>> 
>>>>> Thanks for the quick reply!  Updates implemented as requested (we
>>>>> believe your comment in response to question 1 indicates all
>>>>> instances of <sourcecode> in the document should have the type set
>>>>> to “rbnf”: please let us know if this is in error).
>>>>> 
>>>>> Please review the files carefully as we do not make changes after
>>>>> publication.
>>>>> 
>>>>> The files have been posted here (please refresh):
>>>>> https://www.rfc-editor.org/authors/rfc9504.txt
>>>>> https://www.rfc-editor.org/authors/rfc9504.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9504.html
>>>>> https://www.rfc-editor.org/authors/rfc9504.xml
>>>>> 
>>>>> The relevant diff files have been posted here (please refresh):
>>>>> https://www.rfc-editor.org/authors/rfc9504-diff.html
>>>>> (comprehensive diff)
>>>>> https://www.rfc-editor.org/authors/rfc9504-auth48diff.html (AUTH48
>>>>> changes only)
>>>>> https://www.rfc-editor.org/authors/rfc9504-lastdiff.html (changes
>>>>> from the previous version to this)
>>>>> https://www.rfc-editor.org/authors/rfc9504-lastrfcdiff.html
>>>>> (previous to this in side-by-side format)
>>>>> 
>>>>> Please contact us with any further updates/questions/comments you
>>>>> may have.
>>>>> 
>>>>> We will await approvals from each of the parties listed on the
>>>>> AUTH48 status page prior to moving forward to publication.  Note
>>>>> that IANA changes/updates will be communicated with IANA at the
>>>>> completion of AUTH48.
>>>>> 
>>>>> The AUTH48 status page for this document is available here:
>>>>> 
>>>>> https://www.rfc-editor.org/auth48/rfc9504
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor/mf
>>>>> 
>>>>> 
>>>>>> On Nov 7, 2023, at 2:18 PM, Dhruv Dhody <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi Megan,
>>>>>> 
>>>>>> On Tue, Nov 7, 2023 at 9:22 PM Megan Ferguson <[e-mail]>
>>>>>> wrote:
>>>>>> Haomian, Dhruv, and John,
>>>>>> 
>>>>>> Thank you for your replies.  We have worked through the responses
>>>>>> and updated as we think was intended.
>>>>>> We have also recorded John’s approval of the reference section
>>>>>> change for RFC 5511.
>>>>>> 
>>>>>> A few follow ups:
>>>>>> 
>>>>>> 1) With regard to sourcecode: only Sections A.1-A.3 have remaining
>>>>>> sourcecode entries that are not labelled “rbnf”.  Please let us
>>>>>> know if/how to update these.
>>>>>> 
>>>>>> 
>>>>>> They should be!
>>>>>> 
>>>>>> 
>>>>>> 2) Regarding the following:
>>>>>> 
>>>>>>> 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".
>>>>>> 
>>>>>> Please review the instances as they exist in the document and let
>>>>>> us know if/how to update using Old/New format.
>>>>>> 
>>>>>> 
>>>>>> OLD
>>>>>> The Symbolic Path Name in the LSP Exclusion subobject MUST only
>>>>>> vary from being a string of printable ASCII characters without a
>>>>>> NULL terminator when it is matching the value contained in another
>>>>>> subobject. It is worth noting that given that the Symbolic Path
>>>>>> Name is unique in the context of the headnode, only LSPs that
>>>>>> share the same headnode or PCC could be excluded.
>>>>>> NEW:
>>>>>> The symbolic path name in the LSP Exclusion subobject MUST only
>>>>>> vary from being a string of printable ASCII characters without a
>>>>>> NULL terminator when it is matching the value contained in another
>>>>>> subobject. It is worth noting that given that the symbolic path
>>>>>> name is unique in the context of the headnode, only LSPs that
>>>>>> share the same headnode or PCC could be excluded.
>>>>>> END
>>>>>> 
>>>>>> OLD
>>>>>> The LSP exclusion subobject is as follows:
>>>>>> NEW
>>>>>> The LSP Exclusion subobject is as follows:
>>>>>> END
>>>>>> 
>>>>>> OLD
>>>>>> Type:The subobject type for an LSP exclusion subobject. Value of
>>>>>> 11.
>>>>>> NEW
>>>>>> Type:The subobject type for an LSP EOLDxclusion subobject. Value
>>>>>> of 11.
>>>>>> END
>>>>>> 
>>>>>> OLD
>>>>>> The LSP exclusion subobject in XRO, as defined in Section 6.2.2 of
>>>>>> this document, NEW The LSP Exclusion subobject in XRO, as defined
>>>>>> in
>>>>>> Section 6.2.2 of this document, END
>>>>>> 
>>>>>> Thanks!
>>>>>> Dhruv
>>>>>> 
>>>>>> 
>>>>>> Please review the files carefully as we do not make changes after
>>>>>> publication.
>>>>>> 
>>>>>> The files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9504.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9504.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9504.html
>>>>>> https://www.rfc-editor.org/authors/rfc9504.xml
>>>>>> 
>>>>>> The relevant diff files have been posted here (please refresh):
>>>>>> https://www.rfc-editor.org/authors/rfc9504-diff.html
>>>>>> (comprehensive diff)
>>>>>> https://www.rfc-editor.org/authors/rfc9504-auth48diff.html
>>>>>> (AUTH48
>>>>>> changes only)
>>>>>> 
>>>>>> Please contact us with any further updates/questions/comments you
>>>>>> may have.
>>>>>> 
>>>>>> We will await approvals from each of the parties listed on the
>>>>>> AUTH48 status page prior to moving forward to publication.  Note
>>>>>> that IANA changes/updates will be communicated with IANA at the
>>>>>> completion of AUTH48.
>>>>>> 
>>>>>> The AUTH48 status page for this document is available here:
>>>>>> 
>>>>>> https://www.rfc-editor.org/auth48/rfc9504
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/mf
>>>>>> 
>>>>>> 
>>>>>>> On Oct 27, 2023, at 1:46 PM, John Scudder
>>>>>>> <jgs=[e-mail]> wrote:
>>>>>>> 
>>>>>>> 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/
>>>>>>>> p
>>>>>>>> art2/)?__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6
>>>>>>>> m Yz8M2whjmHsGcq4RWcjlLTspq5dKb_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/
>>>>>>>> i
>>>>>>>> etf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!HoX-
>>>>>>>> ItD7Q
>>>>>>>> -
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfy
>>>>>>>> o
>>>>>>>> FKIeKk0Pg$
>>>>>>>> 
>>>>>>>> *  The archive itself:
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brow
>>>>>>>> s
>>>>>>>> e/auth48archive/__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ
>>>>>>>> 5 _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/rfc
>>>>>>>> 9
>>>>>>>> 504.xml__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6
>>>>>>>> m Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIBrGNAvQ$
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504.html__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O
>>>>>>>> 6 mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJbAQqnPw$
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504.pdf__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6
>>>>>>>> m Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJijATm3w$
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504.txt__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6
>>>>>>>> m Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFLzc85u4A$
>>>>>>>> 
>>>>>>>> Diff file of the text:
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504-diff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_s
>>>>>>>> V 6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFK54a5sZA$
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504-rfcdiff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ
>>>>>>>> 5 _sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIOvBuf2A$  (side
>>>>>>>> by
>>>>>>>> side)
>>>>>>>> 
>>>>>>>> Diff of the XML:
>>>>>>>> 
>>>>>>>> https://urldefense.com/v3/__https://www.rfc-
>>>>>>>> editor.org/authors/rfc
>>>>>>>> 9
>>>>>>>> 504-xmldiff1.html__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8R
>>>>>>>> Z 5_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/rfc9
>>>>>>>> 5
>>>>>>>> 04__;!!NEt6yMaO-gk!HoX-ItD7Q-
>>>>>>>> c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M
>>>>>>>> 2 whjmHsGcq4RWcjlLTspq5dKb_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
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> ________________________________
>>> 
>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su
>>> destinatario, puede contener información privilegiada o confidencial
>>> y es para uso exclusivo de la persona o entidad de destino. Si no es
>>> usted. el destinatario indicado, queda notificado de que la lectura,
>>> utilización, divulgación y/o copia sin autorización puede estar
>>> prohibida en virtud de la legislación vigente. Si ha recibido este
>>> mensaje por error, le rogamos que nos lo comunique inmediatamente por
>>> esta misma vía y proceda a su destrucción.
>>> 
>>> The information contained in this transmission is confidential and
>>> privileged information intended only for the use of the individual or
>>> entity named above. If the reader of this message is not the intended
>>> recipient, you are hereby notified that any dissemination,
>>> distribution or copying of this communication is strictly prohibited.
>>> If you have received this transmission in error, do not read it.
>>> Please immediately reply to the sender that you have received this
>>> communication in error and then delete it.
>>> 
>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>> destinatário, pode conter informação privilegiada ou confidencial e é
>>> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa
>>> senhoria o destinatário indicado, fica notificado de que a leitura,
>>> utilização, divulgação e/ou cópia sem autorização pode estar proibida
>>> em virtude da legislação vigente. Se recebeu esta mensagem por erro,
>>> rogamos-lhe que nos o comunique imediatamente por esta mesma via e
>>> proceda a sua destruição
>>> ________________________________
>>> 
>>> Le informamos de que el responsable del tratamiento de sus datos es
>>> la entidad del Grupo Telefónica vinculada al remitente, con la
>>> finalidad de mantener el contacto profesional y gestionar la relación
>>> establecida con el destinatario o con la entidad a la que está
>>> vinculado. Puede contactar con el responsable del tratamiento y
>>> ejercitar sus derechos escribiendo a
>>> [e-mail]<mailto:[e-mail]>.
>>> Puede consultar información adicional sobre el tratamiento de sus
>>> datos en nuestra Política de
>>> Privacidad<https://www.telefonica.com/es/telefonica-politica-de-
>>> privacidad-de-terceros/>.
>>> 
>>> We inform you that the data controller is the Telefónica Group entity
>>> linked to the sender, for the purpose of maintaining professional
>>> contact and managing the relationship established with the recipient
>>> or with the entity to which it is linked. You may contact the data
>>> controller and exercise your rights by writing to
>>> [e-mail]<mailto:[e-mail]>.
>>> You may consult additional information on the processing of your data
>>> in our Privacy Policy<https://www.telefonica.com/en/wp-
>>> content/uploads/sites/5/2022/12/Telefonica-Third-data-subjects-
>>> Privacy-Policy.pdf>.
>>> 
>>> Informamos que o responsável pelo tratamento dos seus dados é a
>>> entidade do Grupo Telefónica vinculada ao remetente, a fim de manter
>>> o contato professional e administrar a relação estabelecida com o
>>> destinatário ou com a entidade à qual esteja vinculado. Você pode
>>> entrar em contato com o responsável do tratamento de dados e exercer
>>> os seus direitos escrevendo a
>>> [e-mail]<mailto:[e-mail]>.
>>> Você pode consultar informação adicional sobre o tratamento do seus
>>> dados na nossa Política de
>>> Privacidade<https://www.telefonica.com/es/politica-de-privacidade-de-
>>> terceiros/>.
>