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]> > 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]>, [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]> >> 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]>, >>> [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]; [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]>, [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]>, >>>>> [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 >>>>> >>>>> 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]
