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

[Young Lee <[e-mail]>]

Hi,

I approve the AUTH 48.

Thanks.
Young

On Tue, Nov 14, 2023 at 11:42 AM Megan Ferguson <[e-mail]> wrote:

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