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

[Megan Ferguson <[e-mail]>]

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_sV6n7O6m
> > >> 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_nfyo
> > >> FKIeKk0Pg$
> > >> 
> > >>    *  The archive itself:
> > >>       
> > >> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brows
> > >> e/auth48archive/__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5
> > >> _sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFL5PS3Nrw$
> > >> 
> > >>    *  Note: If only absolutely necessary, you may temporarily opt out
> > >>       of the archiving of messages (e.g., to discuss a sensitive matter).
> > >>       If needed, please add a note at the top of the message that you
> > >>       have dropped the address. When the discussion is concluded,
> > >>       [e-mail] will be re-added to the CC list and
> > >>       its addition will be noted at the top of the message.
> > >> 
> > >> You may submit your changes in one of two ways:
> > >> 
> > >> An update to the provided XML file
> > >> — OR —
> > >> An explicit list of changes in this format
> > >> 
> > >> Section # (or indicate Global)
> > >> 
> > >> OLD:
> > >> old text
> > >> 
> > >> NEW:
> > >> new text
> > >> 
> > >> You do not need to reply with both an updated XML file and an 
> > >> explicit list of changes, as either form is sufficient.
> > >> 
> > >> We will ask a stream manager to review and approve any changes that 
> > >> seem beyond editorial in nature, e.g., addition of new text, 
> > >> deletion of text, and technical changes.  Information about stream 
> > >> managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
> > >> 
> > >> 
> > >> Approving for publication
> > >> --------------------------
> > >> 
> > >> To approve your RFC for publication, please reply to this email 
> > >> stating that you approve this RFC for publication.  Please use 
> > >> ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.
> > >> 
> > >> 
> > >> Files
> > >> -----
> > >> 
> > >> The files are available here:
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504.xml__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6m
> > >> Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIBrGNAvQ$
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6
> > >> mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJbAQqnPw$
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504.pdf__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6m
> > >> Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFJijATm3w$
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504.txt__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6m
> > >> Yz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFLzc85u4A$
> > >> 
> > >> Diff file of the text:
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504-diff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV
> > >> 6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFK54a5sZA$
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504-rfcdiff.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5
> > >> _sV6n7O6mYz8M2whjmHsGcq4RWcjlLTspq5dKb_nfyoFIOvBuf2A$  (side by 
> > >> side)
> > >> 
> > >> Diff of the XML:
> > >>  
> > >> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9
> > >> 504-xmldiff1.html__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ
> > >> 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/rfc95
> > >> 04__;!!NEt6yMaO-gk!HoX-ItD7Q-c0a1HiDlALXSjmXWvs2l8RZ5_sV6n7O6mYz8M2
> > >> 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
> > >> 
> > >> 
> > > 
> > 
> > 
> > 
> > 
> > 
>