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]
