Hi Sabrina, The changes look good, thank you!
Best regards, Alanna Paloma RFC Production Center > On Feb 27, 2026, at 10:51 PM, Sabrina Tanamal via RT <[email protected]> > wrote: > > Hi Alanna, > > These changes are complete: > > https://www.iana.org/assignments/pcep/pcep.xhtml#metric-object-t-field > > Thanks, > Sabrina > > On Fri Feb 27 19:12:33 2026, [email protected] wrote: >> IANA, >> >> Please update the capitalizations and hyphenation in the following >> descriptions in the “METRIC Object T Field” registry >> <https://www.iana.org/assignments/pcep/pcep.xhtml#metric-object-t- >> field>. >> >> Old: >> Value Description >> 22 Path Min Delay Metric >> 23 P2MP Path Min Delay Metric >> 24 Path Bandwidth Metric >> 25 P2MP Path Bandwidth Metric >> 128-255 User Defined Metric >> >> New: >> Value Description >> 22 Path Min Delay metric >> 23 P2MP Path Min Delay metric >> 24 Path Bandwidth metric >> 25 P2MP Path Bandwidth metric >> 128-255 User-defined metric >> >> Diff file is here: >> https://www.rfc-editor.org/authors/rfc9933-diff.html >> >> Best regards, >> Alanna Paloma >> RFC Production Center >> >>> On Feb 27, 2026, at 11:09 AM, Alanna Paloma <[email protected] >>> editor.org> wrote: >>> >>> Hi Authors, >>> >>> Zoey’s approval has been noted on the AUTH48 status page: >>> https://www.rfc-editor.org/auth48/rfc9933 >>> >>> Now that we’ve received approvals from each author, we will ask IANA >>> to update their registry accordingly. After the IANA updates are >>> complete, we will move forward with the publication process. >>> >>> Thank you, >>> Alanna Paloma >>> RFC Production Center >>> >>> >>>> On Feb 27, 2026, at 10:13 AM, Zoey Rose (atokar) <[email protected]> >>>> wrote: >>>> >>>> Hi Alanna, >>>> >>>> Many thanks for the updates! It looks good to me as well and I >>>> approve the changes. >>>> >>>> Thanks, >>>> Zoey >>>> >>>> From: Alanna Paloma <[email protected]> >>>> Date: Friday, February 27, 2026 at 10:40 AM >>>> To: Samuel Sidor (ssidor) <[email protected]>, Pengshuping (Peng >>>> Shuping) <[email protected]>, [email protected] >>>> <[email protected]> >>>> Cc: Andrew Stone (Nokia) <[email protected]>, rfc-editor@rfc- >>>> editor.org <[email protected]>, Zoey Rose (atokar) >>>> <[email protected]>, [email protected] <[email protected]>, pce- >>>> [email protected] <[email protected]>, [email protected] >>>> <[email protected]>, [email protected] <[email protected]>, >>>> [email protected] <[email protected]> >>>> Subject: Re: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> for >>>> your review >>>> >>>> Hi Shaofu, Shuping, and Samuel, >>>> >>>> Thank you for your replies. Your approvals have been noted: >>>> https://www.rfc-editor.org/auth48/rfc9933 >>>> >>>> Once we receive Zoey’s approval, we will move this document forward >>>> in the publication process. >>>> >>>> Best regards, >>>> Alanna Paloma >>>> RFC Production Center >>>> >>>> >>>>> On Feb 27, 2026, at 12:19 AM, Samuel Sidor (ssidor) >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Allana, >>>>> >>>>> Thanks a lot for your work. The diff looks fine to me and I’m >>>>> approving the changes for publication. >>>>> >>>>> Regards, >>>>> Samuel >>>>> >>>>> From: Pengshuping (Peng Shuping) <[email protected]> >>>>> Date: Friday, 27 February 2026 at 05:12 >>>>> To: Andrew Stone (Nokia) <[email protected]>, Alanna Paloma >>>>> <[email protected]>, Samuel Sidor (ssidor) >>>>> <[email protected]> >>>>> Cc: [email protected] <[email protected]>, Zoey >>>>> Rose (atokar) <[email protected]>, [email protected] >>>>> <[email protected]>, [email protected] <[email protected]>, pce- >>>>> [email protected] <[email protected]>, [email protected] >>>>> <[email protected]>, [email protected] <[email protected]>, >>>>> [email protected] <[email protected]> >>>>> Subject: RE: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> >>>>> for your review >>>>> >>>>> Hi Alanna, >>>>> Many thanks for your work! >>>>> I have gone through the diffs and approve all the changes for >>>>> publication. >>>>> Thank you! >>>>> Best Regards, >>>>> Shuping >>>>> From: Andrew Stone (Nokia) <[email protected]> >>>>> Sent: Friday, February 27, 2026 7:11 AM >>>>> To: Alanna Paloma <[email protected]>; Samuel Sidor >>>>> (ssidor) <[email protected]> >>>>> Cc: [email protected]; Zoey Rose (atokar) >>>>> <[email protected]>; [email protected]; Pengshuping (Peng >>>>> Shuping) <[email protected]>; [email protected]; pce- >>>>> [email protected]; [email protected]; [email protected]; >>>>> [email protected] >>>>> Subject: Re: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> >>>>> for your review >>>>> Hi RFC Editor, >>>>> As co-author, I have gone through the comprehensive diff and >>>>> approve of the changes for publication. >>>>> Thank you! >>>>> Andrew >>>>> From: Alanna Paloma <[email protected]> >>>>> Date: Tuesday, February 24, 2026 at 1:00 PM >>>>> To: Samuel Sidor (ssidor) <[email protected]> >>>>> Cc: [email protected] <[email protected]>, Zoey >>>>> Rose (atokar) <[email protected]>, [email protected] >>>>> <[email protected]>, [email protected] >>>>> <[email protected]>, Andrew Stone (Nokia) >>>>> <[email protected]>, [email protected] <[email protected]>, pce- >>>>> [email protected] <[email protected]>, [email protected] >>>>> <[email protected]>, [email protected] <[email protected]>, >>>>> [email protected] <[email protected]> >>>>> Subject: Re: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> >>>>> for your review >>>>> >>>>> CAUTION: This is an external email. Please be very careful when >>>>> clicking links or opening attachments. See the URL nok.it/ext for >>>>> additional information. >>>>> >>>>> >>>>> >>>>> Hi Samuel, >>>>> >>>>> Thank you for confirming. We’ve updated those notes accordingly. >>>>> >>>>> The files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9933.xml >>>>> https://www.rfc-editor.org/authors/rfc9933.txt >>>>> https://www.rfc-editor.org/authors/rfc9933.html >>>>> https://www.rfc-editor.org/authors/rfc9933.pdf >>>>> >>>>> The relevant diff files have been posted here: >>>>> https://www.rfc-editor.org/authors/rfc9933-diff .html >>>>> (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9933-auth48diff.html (AUTH48 >>>>> changes) >>>>> https://www.rfc-editor.org/authors/rfc9933-auth48rfcdiff.html >>>>> (AUTH48 changes side by side) >>>>> https://www.rfc-editor.org/authors/rfc9933-lastdiff.html (last >>>>> version to this one) >>>>> https://www.rfc-editor.org/authors/rfc9933-lastrfcdiff.html >>>>> (rfcdiff between last version and this) >>>>> >>>>> We will await approvals from each party listed on the AUTH48 status >>>>> page below prior to moving this document forward in the publication >>>>> process. >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9933 >>>>> >>>>> Thank you, >>>>> Alanna Paloma >>>>> RFC Production Center >>>>> >>>>>> On Feb 24, 2026, at 3:47 AM, Samuel Sidor (ssidor) >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Thanks a lot, Allana, >>>>>> >>>>>> I missed those originally. All 3 instances can be marked with >>>>>> <aside>. >>>>>> >>>>>> Regards, >>>>>> Samuel >>>>>> >>>>>> From: Alanna Paloma <[email protected]> >>>>>> Date: Monday, 23 February 2026 at 19:52 >>>>>> To: Samuel Sidor (ssidor) <[email protected]> >>>>>> Cc: [email protected] <[email protected]>, Zoey >>>>>> Rose (atokar) <[email protected]>, [email protected] >>>>>> <[email protected]>, [email protected] >>>>>> <[email protected]>, [email protected] >>>>>> <[email protected]>, [email protected] <[email protected]>, >>>>>> [email protected] <[email protected]>, [email protected] >>>>>> <[email protected]>, [email protected] >>>>>> <[email protected]>, [email protected] >>>>>> <[email protected]> >>>>>> Subject: Re: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> >>>>>> for your review >>>>>> >>>>>> Hi Samuel, >>>>>> >>>>>> Thank you for your reply. We have updated as requested and have >>>>>> one follow-up question. >>>>>> >>>>>>> 9) <!-- [rfced] Please review whether any of the notes in this >>>>>>> document >>>>>>> should be in the <aside> element. It is defined as "a container >>>>>>> for >>>>>>> content that is semantically less important or tangential to the >>>>>>> content that surrounds it" (https://authors.ietf.org/en/rfcxml- >>>>>>> vocabulary#aside). >>>>>>> --> >>>>>>> >>>>>>> <S> I don't see any such note. >>>>>> >>>>>> ) We see the following notes: >>>>>> >>>>>> Section 3: >>>>>> Note: In SRv6, the BSID can be allocated >>>>>> from an algorithm-specific SRv6 Locator, which will result in >>>>>> the >>>>>> path to that BSID PCC node following that algorithm-specific >>>>>> path. >>>>>> >>>>>> Section 4.3: >>>>>> Note: The Subobject Extension Block is applicable to the SRv6- >>>>>> ERO >>>>>> subobject but is not required by this specific specification as >>>>>> existing reserved space is used. When additional space is needed >>>>>> in >>>>>> the SRv6-ERO subobject, the future extensions SHOULD specify the >>>>>> usage of the Subobject Extension Block for the SRv6-ERO >>>>>> subobject. >>>>>> >>>>>> Section 4.5.2.1: >>>>>> Note: The link Bandwidth Metric utilized in the formula may be >>>>>> the original metric advertised on the link, which may have a >>>>>> value >>>>>> inversely proportional to the link capacity. >>>>>> >>>>>> Please let us know if the <aside> element should be used for any >>>>>> of these instances. >>>>>> >>>>>> --- >>>>>> The files have been posted here (please refresh): >>>>>> https://www.rfc-editor.org/authors/rfc9933.xml >>>>>> https://www.rfc-editor.org/authors/rfc9933.txt >>>>>> https://www.rfc-editor.org/authors/rfc9933.html >>>>>> https://www.rfc-editor.org/authors/rfc9933.pdf >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9933-diff.html >>>>>> (comprehensive diff) >>>>>> https://www.rfc-editor.org/authors/rfc9933-auth48diff.html (AUTH48 >>>>>> changes) >>>>>> https://www.rfc-editor.org/authors/rfc9933-auth48rfcdiff.html >>>>>> (AUTH48 changes side by side) >>>>>> >>>>>> Please review the document carefully and contact us with any >>>>>> further updates you may have. Note that we do not make changes >>>>>> once a document is published as an RFC. >>>>>> >>>>>> We will await approvals from each party listed on the AUTH48 >>>>>> status page below prior to moving this document forward in the >>>>>> publication process. >>>>>> >>>>>> For the AUTH48 status of this document, please see: >>>>>> https://www.rfc-editor.org/auth48/rfc9933 >>>>>> >>>>>> Thank you, >>>>>> Alanna Paloma >>>>>> RFC Production Center >>>>>> >>>>>> >>>>>>> On Feb 20, 2026, at 1:30 AM, Samuel Sidor (ssidor) >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi RFC Editor, >>>>>>> >>>>>>> Please find responses inline <S>. >>>>>>> >>>>>>> Thanks a lot, >>>>>>> Samuel >>>>>>> >>>>>>> From: [email protected] <[email protected]> >>>>>>> Date: Friday, 20 February 2026 at 01:23 >>>>>>> To: Samuel Sidor (ssidor) <[email protected]>, Zoey Rose (atokar) >>>>>>> <[email protected]>, [email protected] >>>>>>> <[email protected]>, [email protected] >>>>>>> <[email protected]>, [email protected] >>>>>>> <[email protected]> >>>>>>> Cc: [email protected] <[email protected]>, pce- >>>>>>> [email protected] <[email protected]>, [email protected] <pce- >>>>>>> [email protected]>, [email protected] <[email protected]>, >>>>>>> [email protected] <[email protected]>, auth48archive@rfc- >>>>>>> editor.org <[email protected]> >>>>>>> Subject: Re: AUTH48: RFC-to-be 9933 <draft-ietf-pce-sid-algo-29> >>>>>>> for your review >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>> necessary) the following questions, which are also in the source >>>>>>> file. >>>>>>> >>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that >>>>>>> appear in >>>>>>> the title) for use on https://www.rfc-editor.org/search. --> >>>>>>> >>>>>>> <S>"Prefix-SID Algorithm", "Flexible Algorithm", "IGP Algorithm >>>>>>> Types" >>>>>>> >>>>>>> 2) <!--[rfced] FYI - We removed the first paragraph in Section 2 >>>>>>> as it >>>>>>> repeats the same information in the second paragraph. Please let >>>>>>> us >>>>>>> know of any objections. >>>>>>> >>>>>>> Original: >>>>>>> This document uses the following terms defined in [RFC5440]: >>>>>>> ERO, >>>>>>> LSPA, PCC, PCE, PCEP, PCEP Peer, PCEP speaker, RRO, TED. >>>>>>> >>>>>>> This document uses the following terms defined in [RFC5440]: >>>>>>> Explicit >>>>>>> Route Object (ERO), Label Switched Path Attributes (LSPA), Path >>>>>>> Computation Client (PCC), Path Computation Element (PCE), Path >>>>>>> Computation Element Communication Protocol (PCEP), PCEP Peer, >>>>>>> PCEP >>>>>>> speaker, Record Route Object (RRO), and Traffic Engineering >>>>>>> Database >>>>>>> (TED). >>>>>>> --> >>>>>>> >>>>>>> <S> Thanks for remoing it >>>>>>> >>>>>>> 3) <!--[rfced] To parallel the structure of the first two bullet >>>>>>> items, may >>>>>>> we update the latter two bullet items as follows? >>>>>>> >>>>>>> Original: >>>>>>> * Define a new SEBF in the Flags field to indicate the >>>>>>> presence of >>>>>>> new extension, and specify the corresponding capability >>>>>>> signaling >>>>>>> for that extension. >>>>>>> >>>>>>> * Specify which parts of the reserved/extension block are used >>>>>>> and >>>>>>> how the block length is calculated when their extension is >>>>>>> present. >>>>>>> >>>>>>> * The reserved bits in the initial 4 bytes are used when >>>>>>> possible, >>>>>>> and the block is extended only when additional space is >>>>>>> necessary. >>>>>>> >>>>>>> * Future extensions may define additional SEBFs and >>>>>>> corresponding >>>>>>> fields, allowing the block to be increased in size beyond the >>>>>>> initial 4 bytes as needed. >>>>>>> >>>>>>> Perhaps: >>>>>>> * Define a new SEBF in the Flags field to indicate the >>>>>>> presence of >>>>>>> a new extension and specify the corresponding capability >>>>>>> signaling >>>>>>> for that extension. >>>>>>> >>>>>>> * Specify which parts of the reserved/extension block are used >>>>>>> and >>>>>>> how the block length is calculated when their extension is >>>>>>> present. >>>>>>> >>>>>>> * Ensure the reserved bits in the initial 4 bytes are used when >>>>>>> possible >>>>>>> and the block is extended only when additional space is >>>>>>> necessary. >>>>>>> >>>>>>> * Have future extensions define additional SEBFs and >>>>>>> corresponding >>>>>>> fields, allowing the block to be increased in size beyond the >>>>>>> initial 4 bytes as needed. >>>>>>> --> >>>>>>> >>>>>>> <S> Looks fine to me. >>>>>>> >>>>>>> 4) <!--[rfced] For clarity, may we update "PCInitiate, PCUpd >>>>>>> messages" to >>>>>>> "PCInitiate or PCUpd messages"? >>>>>>> >>>>>>> Original: >>>>>>> If a PCC receives an LSPA object with SR-Algorithm TLV as part >>>>>>> of >>>>>>> PCInitiate, PCUpd messages, then it MUST include LSPA object >>>>>>> with SR- >>>>>>> Algorithm TLV in PCRpt message as part of intended-attribute- >>>>>>> list. >>>>>>> >>>>>>> Perhaps: >>>>>>> If a PCC receives an LSPA object with SR-Algorithm TLV as part >>>>>>> of >>>>>>> PCInitiate or PCUpd messages, then it MUST include LSPA object >>>>>>> with SR- >>>>>>> Algorithm TLV in PCRpt message as part of intended-attribute- >>>>>>> list. >>>>>>> --> >>>>>>> >>>>>>> <S> Yes, please update. >>>>>>> >>>>>>> 5) <!--[rfced] May we update the punctuation in the latter part >>>>>>> of this >>>>>>> sentence to clarify that it is a list of what is used? >>>>>>> >>>>>>> Original: >>>>>>> If the PCE is unable to find a path with the given SR-Algorithm >>>>>>> constraint, it does not support a combination of specified >>>>>>> constraints or if the FAD contains constraints, optimization >>>>>>> metric >>>>>>> or other attributes, which the PCE does not support or >>>>>>> recognize, it >>>>>>> MUST use an empty ERO in PCInitiate for LSP instantiation or >>>>>>> PCUpd >>>>>>> message if an update is required or NO-PATH object in PCRep to >>>>>>> indicate that it was not able to find the valid path. >>>>>>> >>>>>>> Perhaps: >>>>>>> If the PCE is unable to find a path with the given SR-Algorithm >>>>>>> constraint, it does not support a combination of specified >>>>>>> constraints or if the FAD contains constraints, optimization >>>>>>> metrics, >>>>>>> or other attributes, which the PCE does not support or >>>>>>> recognize, it >>>>>>> MUST use an empty ERO in PCInitiate for LSP instantiation, a >>>>>>> PCUpd >>>>>>> message if an update is required, or a NO-PATH object in PCRep >>>>>>> to >>>>>>> indicate that it was not able to find the valid path. >>>>>>> --> >>>>>>> >>>>>>> <S> Sure, looks fine. >>>>>>> >>>>>>> 6) <!--[rfced] This note was left in the document: >>>>>>> >>>>>>> [Note to RFC Editor: The URL of the "IGP Flex-Algorithm Path >>>>>>> Computation Rules Registry" IANA registry to be inserted once it >>>>>>> will >>>>>>> get created after approval of >>>>>>> [I-D.ietf-lsr-igp-flex-algo-reverse-affinity].] >>>>>>> >>>>>>> Would you like an informative reference or an inline URL to be >>>>>>> added >>>>>>> for the "IGP Flex-Algorithm Path Computation Rules" registry >>>>>>> >>>>>>> Original: >>>>>>> [I-D.ietf-lsr-igp-flex-algo-reverse-affinity] created an IANA >>>>>>> registry called "IGP Flex-Algorithm Path Computation Rules >>>>>>> Registry" >>>>>>> within the "Interior Gateway Protocol (IGP) Parameters" >>>>>>> registry >>>>>>> group with the ordered set of rules that MUST be used to prune >>>>>>> links >>>>>>> from the topology during the Flexible Algorithm path >>>>>>> computation. >>>>>>> >>>>>>> Perhaps A (with an informative reference): >>>>>>> [RFC9917] created an IANA >>>>>>> registry called "IGP Flex-Algorithm Path Computation Rules" >>>>>>> [IANA-IGP-RULES] >>>>>>> within the "Interior Gateway Protocol (IGP) Parameters" >>>>>>> registry >>>>>>> group with the ordered set of rules that MUST be used to prune >>>>>>> links >>>>>>> from the topology during the Flexible Algorithm path >>>>>>> computation. >>>>>>> ... >>>>>>> [IANA-IGP-Rules] >>>>>>> IANA, "IGP Flex-Algorithm Path Computation Rules", >>>>>>> <https://www.iana.org/assignments/igp-parameters>. >>>>>>> >>>>>>> Perhaps B (with inline URL): >>>>>>> [RFC9917] created an IANA >>>>>>> registry called "IGP Flex-Algorithm Path Computation Rules" >>>>>>> <https://www.iana.org/assignments/igp-parameters> within the >>>>>>> "Interior >>>>>>> Gateway Protocol (IGP) Parameters" registry group with the >>>>>>> ordered set >>>>>>> of rules that MUST be used to prune links from the topology >>>>>>> during the >>>>>>> Flexible Algorithm path computation. >>>>>>> --> >>>>>>> >>>>>>> <S> Inline URL (option B) looks better to me. >>>>>>> >>>>>>> 7) <!--[rfced] We note that RFC 8281 does not list any >>>>>>> "manageability >>>>>>> requirements and considerations". All other RFCs in this sentence >>>>>>> have a specific section about that topic. May we remove RFC 8281 >>>>>>> from the list? >>>>>>> >>>>>>> Original: >>>>>>> All manageability requirements and considerations listed in >>>>>>> [RFC5440], [RFC8231], [RFC8281], [RFC8664] and [RFC9603] apply >>>>>>> to the >>>>>>> PCEP extensions defined in this document. >>>>>>> --> >>>>>>> >>>>>>> <S> Thanks for finding it, please drop it. >>>>>>> >>>>>>> 8) <!-- [rfced] Regarding [IEEE.754.2008], this IEEE Standard has >>>>>>> been >>>>>>> superseded by a newer version published in 2019 >>>>>>> (https://ieeexplore.ieee.org/document/8766229). Would you like us >>>>>>> to >>>>>>> update this reference to point to the most current version? >>>>>>> >>>>>>> Current: >>>>>>> [IEEE.754.2008] >>>>>>> IEEE, "IEEE Standard for Floating-Point Arithmetic", >>>>>>> IEEE >>>>>>> Std 754-2008, DOI 10.1109/IEEESTD.2008.4610935, >>>>>>> August >>>>>>> 2008, >>>>>>> <https://doi.org/10.1109/IEEESTD.2008.4610935>. >>>>>>> Perhaps: >>>>>>> [IEEE.754.2019] >>>>>>> IEEE, "IEEE Standard for Floating-Point Arithmetic", >>>>>>> IEEE >>>>>>> Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July >>>>>>> 2019, >>>>>>> <https://doi.org/10.1109/IEEESTD.2019.8766229>. >>>>>>> --> >>>>>>> >>>>>>> <S> Yes, please update to version published in 2019. >>>>>>> >>>>>>> 9) <!-- [rfced] Please review whether any of the notes in this >>>>>>> document >>>>>>> should be in the <aside> element. It is defined as "a container >>>>>>> for >>>>>>> content that is semantically less important or tangential to the >>>>>>> content that surrounds it" (https://authors.ietf.org/en/rfcxml- >>>>>>> vocabulary#aside). >>>>>>> --> >>>>>>> >>>>>>> <S> I don't see any such note. >>>>>>> >>>>>>> 10) <!--[rfced] Terminology >>>>>>> >>>>>>> a) We note that "object" and "Object" are both used throughout >>>>>>> the document. >>>>>>> Please review the terms below and let us know if/how this >>>>>>> capitalization should >>>>>>> be made consistent. >>>>>>> >>>>>>> METRIC object vs. METRIC Object >>>>>>> >>>>>>> LSPA Object vs. LSPA object >>>>>>> PCEP Object >>>>>>> LSP Object >>>>>>> NO-PATH object >>>>>>> BANDWIDTH Object (FYI - We capitalized "Bandwidth" to reflect >>>>>>> usage in RFC 5440.) >>>>>>> <S> Please keep "Object" in section titles and name of IANA >>>>>>> registry (e.g. "METRIC Object T Field", otherwise "object" can be >>>>>>> used. >>>>>>> >>>>>>> b) Similar to above, we note that "metric" and "Metric" are both >>>>>>> used throughout >>>>>>> the document. Please review the terms below and let us know >>>>>>> if/how this >>>>>>> capitalization should be made consistent. >>>>>>> >>>>>>> Path Min Delay metric vs. Path Min Delay Metric >>>>>>> P2MP Path Min Delay metric vs. P2MP Path Min Delay Metric >>>>>>> Path Bandwidth Metric vs. Path Bandwidth metric >>>>>>> P2MP Path Bandwidth Metric vs. P2MP Path Bandwidth metric >>>>>>> User-defined metric vs. User Defined metric vs. User Defined >>>>>>> Metric >>>>>>> Link Delay metric >>>>>>> Path Min Link Delay metric >>>>>>> Min Link Delay metric >>>>>>> P2P Path Min Delay metric >>>>>>> Bandwidth Metric vs. Bandwidth metric vs. bandwidth metric >>>>>>> P2P Bandwidth metric >>>>>>> --> >>>>>>> >>>>>>> <S>Please change to "metric" instead of "Metric" except section >>>>>>> titles (Value in IANA registry needs to be updated based on that >>>>>>> as well). >>>>>>> >>>>>>> For "User-defined" vs "User Defined" -> Please use "User-defined" >>>>>>> >>>>>>> For "Bandwidth Metric vs. Bandwidth metric vs. bandwidth metric" >>>>>>> -> Please use "Bandwidth metric" >>>>>>> >>>>>>> >>>>>>> 11) <!--[rfced] Abbreviations >>>>>>> >>>>>>> a) Both the expansion and the acronym for the following terms are >>>>>>> used >>>>>>> throughout the document. Would you like to update to using the >>>>>>> expansion >>>>>>> upon first usage and the acronym for the rest of the document for >>>>>>> consistency? >>>>>>> >>>>>>> Binding SID (BSID) >>>>>>> Interior Gateway Protocol (IGP) >>>>>>> Path Setup Type (PST) >>>>>>> Segment Routing (SR) >>>>>>> >>>>>>> b) FYI - We have expanded the following abbreviation per Section >>>>>>> 3.6 of >>>>>>> RFC 7322 ("RFC Style Guide"). Please review each expansion in the >>>>>>> document >>>>>>> carefully to ensure correctness. >>>>>>> >>>>>>> BGP - Link State (BGP-LS) >>>>>>> --> >>>>>>> >>>>>>> <S> >>>>>>> a) Yes, please use expansion upon first usage and the acronym for >>>>>>> the rest of the document. >>>>>>> b) Looks fine to me. >>>>>>> >>>>>>> 12) <!-- [rfced] Please review the "Inclusive Language" portion >>>>>>> of the online >>>>>>> Style Guide <https://www.rfc- >>>>>>> editor.org/styleguide/part2/#inclusive_language> >>>>>>> and let us know if any changes are needed. Updates of this >>>>>>> nature typically >>>>>>> result in more precise language, which is helpful for readers. >>>>>>> >>>>>>> Note that our script did not flag any words in particular, but >>>>>>> this should >>>>>>> still be reviewed as a best practice. >>>>>>> --> >>>>>>> >>>>>>> <S> No changes required. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Alanna Paloma and Alice Russo >>>>>>> RFC Production Center >>>>>>> >>>>>>> On Feb 19, 2026, [email protected] wrote: >>>>>>> >>>>>>> *****IMPORTANT***** >>>>>>> >>>>>>> Updated 2026/02/19 >>>>>>> >>>>>>> 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://www.rfc-editor.org/faq/). >>>>>>> >>>>>>> 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://trustee.ietf.org/license-info). >>>>>>> >>>>>>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>>>>>> >>>>>>> * 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 >>>>>>> >>>>>>> * [email protected] (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). >>>>>>> >>>>>>> * [email protected], which is a new archival mailing >>>>>>> list >>>>>>> to preserve AUTH48 conversations; it is not an active >>>>>>> discussion >>>>>>> list: >>>>>>> >>>>>>> * More info: >>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh- >>>>>>> 4Q9l2USxIAe6P8O4Zc >>>>>>> >>>>>>> * The archive itself: >>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>> >>>>>>> * 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, >>>>>>> [email protected] 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://www.rfc-editor.org/authors/rfc9933.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9933.html >>>>>>> https://www.rfc-editor.org/authors/rfc9933.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9933.txt >>>>>>> >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9933-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9933-rfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9933-xmldiff1.html >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9933 >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you for your cooperation, >>>>>>> >>>>>>> RFC Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9933 (draft-ietf-pce-sid-algo-29) >>>>>>> >>>>>>> Title : Carrying SR-Algorithm in Path Computation >>>>>>> Element Communication Protocol (PCEP) >>>>>>> Author(s) : S. Sidor, Z. Rose, S. Peng, S. Peng, A. Stone >>>>>>> WG Chair(s) : Julien Meuric, Dhruv Dhody >>>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de >>>>>>> Velde >>>>>> >>>> >>> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
