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

[David Dong via RT <[e-mail]>]

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