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

[Megan Ferguson <[e-mail]>]

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]; [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/>.