Hi Sue and *John (AD), Thank you for your reply and for letting us know that the IDR chairs had no objection to the changes in Table 6 or to the changes to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11.
*John, as the responsible AD when this draft was approved, please let us know if you also approve of the changes made to Table 6 and to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11. If approval is provided, we will ask IANA to update the "BGP-LS SR Segment Descriptor Types” registry to match the edited document. Please review the updates in this file: <https://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. Best regards, Karen Moore RFC Production Center —Files (please refresh)— Updated XML file: https://www.rfc-editor.org/authors/rfc9857.xml Updated output files: https://www.rfc-editor.org/authors/rfc9857.txt https://www.rfc-editor.org/authors/rfc9857.pdf https://www.rfc-editor.org/authors/rfc9857.html Diff files showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9857-auth48diff.html https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side by side) Diff files showing only changes made during the last editing round: https://www.rfc-editor.org/authors/rfc9857-lastdiff.html https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9857-diff.html https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9857 > > On Oct 9, 2025, at 3:55 PM, Susan Hares <[email protected]> wrote: > > Karen, Ketan, and authors (Jie, Hannes, Jeff, and Stefano): > The IDR chairs did a 2 week call for any objection to the Auth-48 changes, > and no objection was made. > (see https://mailarchive.ietf.org/arch/msg/idr/3SxFo0UK76CFb6cPLgJMVLBPvGY/) > I announced the result: > https://mailarchive.ietf.org/arch/msg/idr/D3OmHDe8O7Whn6kaFiWC0iW1V1s/ > Please go ahead with the publication process. > Cheerily, Sue From: Karen Moore <[email protected]> > From: Karen Moore <[email protected]> > Sent: Friday, October 3, 2025 3:32 PM > To: Ketan Talaulikar <[email protected]>; Dongjie (Jimmy) > <[email protected]>; Hannes Gredler <[email protected]>; Jeff Tantsura > <[email protected]>; Stefano Previdi <[email protected]> > Cc: John Scudder <[email protected]>; Editor RFC <[email protected]>; > [email protected]; idr-chairs <[email protected]>; Susan Hares > <[email protected]>; Shawn Zandi via auth48archive > <[email protected]> > Subject: Re: AUTH48: RFC-to-be 9857 <draft-ietf-idr-bgp-ls-sr-policy-17> for > your review > Hi Ketan, > Checking in to see how the reivew of this document is going with the WG. > Best regards, > Karen Moore > RFC Production Center > > On Sep 23, 2025, at 10:36 PM, Ketan Talaulikar <[email protected]> > wrote: > > > Hi Karen, > > > John (as the responsible AD when this draft was approved by the previous > > > IESG) has already approved the rest of the AUTH48 and asked that this one > > > point be taken to the WG to check their views. This is what is going to > > > happen soon. > > > Of course, no concerns from my side if Jim (or Gunter) needs to step in. > > > Thanks, > > Ketan > > > > On Tue, Sep 23, 2025 at 11:39 PM Karen Moore > > > > <[email protected]> wrote: > > Hi Ketan, > > > Thanks for letting us know the status. If there are changes as a result > > > of your consultation, please let us know if we should perhaps ask another > > > AD to approve the updates (perhaps Jim Guichard as he is listed as a > > > Routing AD). > > > Best regards, > > > Karen Moore > > RFC Production Center > > > > On Sep 22, 2025, at 11:02 PM, Ketan Talaulikar <[email protected]> > > > > wrote: > > > > > Hi Karen, > > > > > With my current role as the responsible AD for IDR WG, I find myself > > > > > a bit conflicted to take this to the WG myself and would prefer if > > > > > one of the IDR chairs does this. > > > > > However, the shepherding co-chair Sue may be away on personal > > > > > exigencies and Jeff is also on PTO. So, I will take it to the WG with > > > > > my "editor of this document" hat, in case the IDR chairs are unable > > > > > to get to this in the next couple of days. > > > > > Thanks, > > > Ketan > > > > > > > On Tue, Sep 23, 2025 at 12:06 AM Karen Moore > > > > > > > <[email protected]> wrote: > > > Hello Stefano and Jie, > > > > > We have noted your approval of the document on the AUTH48 status page > > > > > (https://www.rfc-editor.org/auth48/rfc9857). We will assume your > > > > > assent to any further changes proposed by your coauthor(s) unless we > > > > > hear otherwise at that time. > > > > > We now await potential updates to the document per the recent > > > > > discussion on this thread prior to moving forward with publication. > > > > > Best regards, > > > > > Karen Moore > > > RFC Production Center > > > > > > > > On Sep 22, 2025, at 2:22 AM, Dongjie (Jimmy) via auth48archive > > > > > > > > <[email protected]> wrote: > > > > > > > Hi Karen, > > > > > > I approve the publication of this document > > > > > > > once the discussion about the segment types description is > > > > > > > resolved. > > > > > > > Best regards, > > > > Jie > > > > > > On Sep 19, 2025, at 4:21 AM, Stefano Previdi <[email protected]> > > > > > > wrote: > > > > > > > Hi, > > > > > > > I approve. > > > > > > > Thanks. > > > > s. > > > > > > > On Thu, Sep 18, 2025, 20:18 Karen Moore > > > > > > > <[email protected]> wrote: > > > > Hi Hannes, Jeff, Ketan, and John, > > > > > > > Thank you for your replies. We have noted approval of the > > > > > > > document for Hannes and Jeff on the AUTH48 status page. Hannes > > > > > > > and Jeff, we will assume your assent to any further changes > > > > > > > proposed by your coauthors unless we hear otherwise. > > > > > > > We will stand by as Ketan consults with the WG per the discussion > > > > > > > with John. > > > > > > > Best regards, > > > > > > > Karen Moore > > > > RPC Production Center > > > > > > > > > > > On Sep 16, 2025, at 12:07 PM, Hannes Gredler > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > Hi Karen, > > > > > > > > > approved. > > > > > > > > > thanks. > > > > > > > > > /hannes > > > > > > > > > On Tue, Sep 16, 2025 at 8:21 PM Karen Moore > > > > > > > > > <[email protected]> wrote: > > > > > Hi Jeff and *John (AD), > > > > > > > > > Thank you for providing your approval of the document; we > > > > > > > > > have noted it here > > > > > > > > > <https://www.rfc-editor.org/auth48/rfc9857>. We now await > > > > > > > > > approvals from Hannes, Jie, and Stefano. > > > > > > > > > *John, please review the following updates and let us know if > > > > > > > > > you approve. The changes can be reviewed here: > > > > > > > > > <https://www.rfc-editor.org/authors/rfc9857-auth48diff.html>. > > > > > > > > > 1) Update to the description of “V-Flag” in Section 5.3 > > > > > > > > > (added “MUST”) > > > > > 2) Updates to Table 1 in Section 5.7.1.1 to match the descriptions in > > > > > RFCs 9256, 9830, and 9831 > > > > > 3) Updates to Table 6 in Section 8.5 (FYI: updates will be needed to > > > > > the "BGP-LS SR > > > > > Segment Descriptor Types” IANA registry at > > > > > <https://www.iana.org/assignments/bgp-ls-parameters/>) > > > > > 4) Updates to the titles of Sections 5.7.1.1.1 - 5.7.1.1.11 to more > > > > > closely match Table 6 > > > > > > > > > > > > > > > > On Sep 16, 2025, at 7:56 AM, Jeff Tantsura > > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > Hi Karen, > > > > > > > > > Approved. > > > > > Thanks! > > > > > > > > > Cheers, > > > > > Jeff > > > > > > > > > > > > > > > —Files (please refresh)— > > > > > > > > > Updated XML file: > > > > > https://www.rfc-editor.org/authors/rfc9857.xml > > > > > > > > > Updated output files: > > > > > https://www.rfc-editor.org/authors/rfc9857.txt > > > > > https://www.rfc-editor.org/authors/rfc9857.pdf > > > > > https://www.rfc-editor.org/authors/rfc9857.html > > > > > > > > > Diff files showing all changes made during AUTH48: > > > > > https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > > https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html (side > > > > > by side) > > > > > > > > > Diff files showing only changes made during the last editing > > > > > > > > > round: > > > > > https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > > > > > https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > > > > > > > > Diff files showing all changes: > > > > > https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > > https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by side) > > > > > > > > > For the AUTH48 status of this document, please see: > > > > > https://www.rfc-editor.org/auth48/rfc9857 > > > > > > > > > Best regards, > > > > > > > > > Karen Moore > > > > > RFC Production Center > > > > > > > > > > > > > > On Sep 16, 2025, at 7:56 AM, Jeff Tantsura > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > Hi Karen, > > > > > > > > > > > Approved. > > > > > > Thanks! > > > > > > > > > > > Cheers, > > > > > > Jeff > > > > > > > > > > >> On Sep 15, 2025, at 13:00, Karen Moore > > > > > > > > > > >> <[email protected]> wrote: > > > > > >> > > > > >> Hi Ketan, > > > > > >> > > > > >> Thank you for the clarifications. We have updated 2 > > > > > >> > > > > >> instances of “RESERVED” as advised in Section 5.7 and > > > > > >> > > > > >> have updated Table 1 to match the descriptions in RFCs > > > > > >> > > > > >> 9256, 9830, and 9831. Please review. We have also noted > > > > > >> > > > > >> your approval of the document. > > > > > >> > > > > >> If any further updates are needed in Sections 5.7.1.1.1 > > > > > >> > > > > >> - 5.7.1.1.11 to more closely match the wording/changes > > > > > >> > > > > >> in Table 1, please let us know. > > > > > >> > > > > >> Note that we await approvals of the document from all > > > > > >> > > > > >> coauthors listed at > > > > > >> > > > > >> https://www.rfc-editor.org/auth48/rfc9857 prior to > > > > > >> > > > > >> moving forward with publicaiton. > > > > > >> > > > > >> —Files (please refresh)— > > > > > >> > > > > >> Updated XML file: > > > > > >> https://www.rfc-editor.org/authors/rfc9857.xml > > > > > >> > > > > >> Updated output files: > > > > > >> https://www.rfc-editor.org/authors/rfc9857.txt > > > > > >> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > > >> https://www.rfc-editor.org/authors/rfc9857.html > > > > > >> > > > > >> Diff files showing all changes made during AUTH48: > > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html > > > > > >> (side by side) > > > > > >> > > > > >> Diff files showing only changes made during the last > > > > > >> > > > > >> editing round: > > > > > >> https://www.rfc-editor.org/authors/rfc9857-lastdiff.html > > > > > >> https://www.rfc-editor.org/authors/rfc9857-lastrfcdiff.html > > > > > >> > > > > >> Diff files showing all changes: > > > > > >> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > > >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > > >> side) > > > > > >> > > > > >> For the AUTH48 status of this document, please see: > > > > > >> https://www.rfc-editor.org/auth48/rfc9857 > > > > > >> > > > > >> Best regards, > > > > > >> > > > > >> Karen Moore > > > > > >> RFC Production Center > > > > > >> > > > > >> > > > > >> > > > > >> On Sep 14, 2025, at 8:18 PM, > > > > > >> > > > > >> > > > > >> > > > > >> Ketan Talaulikar > > > > > >> > > > > >> > > > > >> > > > > >> <[email protected]> wrote: > > > > > >> > > > > >> Hi Karen, > > > > > >> > > > > >> Please check inline below for responses. > > > > > >> > > > > >> Besides the comment below about Table 1, there is only > > > > > >> > > > > >> one minor update needed: For the fields that were > > > > > >> > > > > >> marked as RESERVED1 and 2 in the figures, please make > > > > > >> > > > > >> the same change in the individual field descriptions > > > > > >> > > > > >> below those figures as well. > > > > > >> > > > > >> Once these are taken care of, please consider this > > > > > >> > > > > >> email as my approval for publication. > > > > > >> > > > > >> > > > > >> On Sat, Sep 13, 2025 at 5:35 AM Karen Moore > > > > > >> > > > > >> > > > > >> <[email protected]> wrote: > > > > > >> Hi Ketan, > > > > > >> > > > > >> Thank you for your comment and close review of the > > > > > >> > > > > >> questions/document. We have updated our files per your > > > > > >> > > > > >> suggestions. Please note that we have a few additional > > > > > >> > > > > >> questions. > > > > > >> > > > > >> 1) Regarding the comments below, we updated the titles > > > > > >> > > > > >> of Sections 5.7.1.1.1 - 5.7.1.1.11 accordingly. We also > > > > > >> > > > > >> updated the descriptions in Table 6, which we agree > > > > > >> > > > > >> will align better with RFCs-to-be 9830 and 9831. Please > > > > > >> > > > > >> review to ensure the changes are correct. > > > > > >> > > > > >> KT> Ack > > > > > >> > > > > >>> Comparing this to RFC9830/1, the Table 1 is what is > > > > > >> > > > > >>> listed > > > > > >>> in > > > > > >>> https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 > > > > > >>> and Table 6 is what is listed in > > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - > > > > > >>> more specifically, I would prefer > > > > > >>> that we have alignment for the Table 1 column Segment Description > > > > > >>> with the other two RFCs > > > > > >>> with one change that we want to keep the (Type X) as a prefix in > > > > > >>> this document. > > > > > >>> > > > > >>> KT> There is no change required for Table 1, however, > > > > > >>> > > > > >>> we can and perhaps should > > > > > >> > > > > >>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 > > > > > >> > > > > >>> to reflect RFC9830 sections > > > > > >>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. > > > > > >>> > > > > >>> As an example: Type 1: SR-MPLS Label (Type A) -> Type > > > > > >>> > > > > >>> 1: Segment Type A > > > > > >>> > > > > >>> This will make the section headings short and align > > > > > >>> > > > > >>> with the other two RFCs that specify > > > > > >>> the southbound BGP signaling while this document specifies its > > > > > >>> northbound reporting. > > > > > >>> > > > > >>> The titles for figures are ok. > > > > > >>> > > > > >>> The descriptions can then be changed along the lines > > > > > >>> > > > > >>> of > > > > > >>> > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 > > > > > >>> > > > > >>> As an example: (Type A) SR-MPLS Label -> Type A > > > > > >>> > > > > >>> Segment > > > > > >>> > > > > >>> Please let me know your views from the perspective of > > > > > >>> > > > > >>> readability and alignment across RFC9256 and > > > > > >>> the 3 BGP RFCs under RFC Editor currently including this document. > > > > > >> > > > > >> 2) It was mentioned that no changes were required for > > > > > >> > > > > >> Table 1 - want to clarify if that is still the case or > > > > > >> > > > > >> if any further updates are needed for consistency with > > > > > >> > > > > >> the wording/style in Table 2 of RFC 9256. > > > > > >> > > > > >> KT> The descriptions originate from > > > > > >> > > > > >> https://www.rfc-editor.org/rfc/rfc9256.html#table-2 and > > > > > >> > > > > >> so, we should try to make things consistent with that. > > > > > >> > > > > >> The same is there in > > > > > >> > > > > >> https://www.rfc-editor.org/rfc/rfc9830#section-2.4.4.2 > > > > > >> > > > > >> and https://www.rfc-editor.org/rfc/rfc9831#section-2 - > > > > > >> > > > > >> therefore, the Table 1 descriptions should be the same. > > > > > >> > > > > >> The only exception is that the alphabetical Type is > > > > > >> > > > > >> indicated in brackets to provide the necessary > > > > > >> > > > > >> correlation between the two separate code point spaces. > > > > > >> > > > > >> I hope this also covers the queries below. > > > > > >> > > > > >> Thanks, > > > > > >> Ketan > > > > > >> > > > > >> > > > > >> > > > > >> Please also consider the > > > > > >> > > > > >> > > > > >> > > > > >> following. > > > > > >> > > > > >> a) Section 5.7.1.1.6 describes the IPv4 Local & Remote > > > > > >> > > > > >> Interface Addresses as a “pair”; is “pair" correct to > > > > > >> > > > > >> add to the description of Type F in Table 1? > > > > > >> > > > > >> Current: > > > > > >> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface > > > > > >> Addresses > > > > > >> > > > > >> Perhaps A: > > > > > >> (Type F) SR-MPLS Adjacency SID as pair of IPv4 Local & Remote > > > > > >> Interface Addresses > > > > > >> > > > > >> Perhaps B (in attempt to follow the style of RFC 9256): > > > > > >> (Type F) IPv4 Interface Addresses for SR-MPLS Adjacency SID as > > > > > >> Local, Remote pair > > > > > >> > > > > >> b) Does the pair consist of one IPv6 global address and > > > > > >> > > > > >> one interface ID? Please let us know if any > > > > > >> > > > > >> clarifcation is needed. This applies to Types G > > > > > >> > > > > >> (Section 5.7.1.1.7) and J (Section 5.7.1.1.10). > > > > > >> > > > > >> Table 1: > > > > > >> Current: > > > > > >> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global Address & > > > > > >> Interface ID for > > > > > >> Local & Remote nodes > > > > > >> > > > > >> Perhaps A: > > > > > >> (Type G) SR-MPLS Adjacency SID as pair of an IPv6 Global > > > > > >> Address & > > > > > >> Interface ID for Local & Remote Nodes > > > > > >> > > > > >> Perhaps B (in attempt to follow the style of RFC 9256): > > > > > >> (Type G) IPv6 Global Address & Interface ID for SR-MPLS > > > > > >> Adjacency SID as > > > > > >> Local, Remote Node pair > > > > > >> > > > > >> Section 5.7.1.1.7 > > > > > >> Current: > > > > > >> The Segment is an SR-MPLS Adjacency SID type and is specified as > > > > > >> a > > > > > >> pair of IPv6 global address and interface ID for local and remote > > > > > >> nodes. > > > > > >> > > > > >> Perhaps: > > > > > >> The Segment is an SR-MPLS Adjacency SID type and is specified as > > > > > >> a > > > > > >> pair of one IPv6 global address and one interface ID for local > > > > > >> and remote > > > > > >> nodes. > > > > > >> > > > > >> --Files-- > > > > > >> Note that it may be necessary for you to refresh your browser to > > > > > >> view the most recent version. Please review the document carefully > > > > > >> to ensure satisfaction as we do not make changes once it has been > > > > > >> published as an RFC. > > > > > >> > > > > >> We will await approvals from each author prior to > > > > > >> > > > > >> moving forward in the publication process. > > > > > >> > > > > >> Updated XML file: > > > > > >> https://www.rfc-editor.org/authors/rfc9857.xml > > > > > >> > > > > >> Updated output files: > > > > > >> https://www.rfc-editor.org/authors/rfc9857.txt > > > > > >> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > > >> https://www.rfc-editor.org/authors/rfc9857.html > > > > > >> > > > > >> Diff files showing all changes made during AUTH48: > > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48diff.html > > > > > >> https://www.rfc-editor.org/authors/rfc9857-auth48rfcdiff.html > > > > > >> (side by side) > > > > > >> > > > > >> Diff files showing all changes: > > > > > >> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > > >> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > > >> side) > > > > > >> > > > > >> For the AUTH48 status of this document, please see: > > > > > >> https://www.rfc-editor.org/auth48/rfc9857 > > > > > >> > > > > >> Best regards, > > > > > >> > > > > >> Karen Moore > > > > > >> RFC Production Center > > > > > >> > > > > >> > > > > >>> On Sep 11, 2025, at 5:14 AM, Ketan > > > > > >> > > > > >> > > > > >>> Talaulikar <[email protected]> wrote: > > > > > >>> > > > > >>> Hi Karen & Allana, > > > > > >>> > > > > >>> Thanks for your help with this document. I realize it > > > > > >>> > > > > >>> was challenging given the inconsistent use of terms > > > > > >>> > > > > >>> within the document and across its related documents. > > > > > >>> > > > > >>> Appreciate your tidying it up for publication. > > > > > >>> > > > > >>> Please check inline below for responses. > > > > > >>> > > > > >>> > > > > >>> On Thu, Sep 11, 2025 at 3:39 AM > > > > > >>> > > > > >>> > > > > >>> <[email protected]> wrote: > > > > > >>> Authors, > > > > > >>> > > > > >>> While reviewing this document during AUTH48, please > > > > > >>> > > > > >>> resolve (as necessary) the following questions, which > > > > > >>> > > > > >>> are also in the source file. > > > > > >>> > > > > >>> 1) <!--[rfced] May we update "PCEP protocol" to > > > > > >>> > > > > >>> simply read "PCEP" to > > > > > >>> avoid redundancy? If expanded, "PCEP protocol" would read as "Path > > > > > >>> Computation Element Communication Protocol protocol". > > > > > >>> > > > > >>> Original: > > > > > >>> As illustrated in the figure below, the > > > > > >>> PCC is not an LSR in the routing domain, thus the head-end nodes > > > > > >>> of > > > > > >>> the SR Policies may not implement the PCEP protocol. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> As illustrated in the figure below, the > > > > > >>> PCC is not an LSR in the routing domain, thus the head-end nodes > > > > > >>> of > > > > > >>> the SR Policies may not implement the PCEP. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 2) <!--[rfced] In Section 3, > > > > > >>> > > > > >>> > > > > >>> > > > > >>> should the list be formatted > > > > > >>> > > > > >>> > > > > >>> > > > > >>> as a definition > > > > > >>> list for ease of reading and consistency with other sections? > > > > > >>> > > > > >>> Original: > > > > > >>> Where: > > > > > >>> > > > > >>> * Protocol-ID field specifies the component that > > > > > >>> > > > > >>> owns the SR Policy > > > > > >>> state in the advertising node. An additional Protocol-ID > > > > > >>> "Segment > > > > > >>> Routing" (value 9) is introduced by this document that MUST be > > > > > >>> used for advertisement of SR Policies. > > > > > >>> > > > > >>> * "Identifier" is an 8 octet value as defined in > > > > > >>> > > > > >>> section 5.2 of > > > > > >>> [RFC9552]. > > > > > >>> > > > > >>> * "Local Node Descriptor" (TLV 256) [RFC9552] is > > > > > >>> > > > > >>> used as specified > > > > > >>> further in this section. > > > > > >>> > > > > >>> * The SR Policy Candidate Path Descriptor TLV is > > > > > >>> > > > > >>> specified in > > > > > >>> Section 4. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> Where: > > > > > >>> > > > > >>> * Protocol-ID field: Specifies the component that > > > > > >>> > > > > >>> owns the SR Policy > > > > > >>> state in the advertising node. An additional Protocol-ID > > > > > >>> "Segment > > > > > >>> Routing" (value 9) is introduced by this document that MUST be > > > > > >>> used for the advertisement of SR Policies. > > > > > >>> > > > > >>> * Identifier: 8-octet value as defined in Section > > > > > >>> > > > > >>> 5.2 of [RFC9552]. > > > > > >>> > > > > >>> * Local Node Descriptors (TLV 256): Defined in > > > > > >>> > > > > >>> [RFC9552] and used as > > > > > >>> specified further in this section. > > > > > >>> > > > > >>> * SR Policy Candidate Path Descriptor TLV: > > > > > >>> > > > > >>> Specified in Section 4. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 3) <!--[rfced] As shown > > > > > >>> > > > > >>> > > > > >>> > > > > >>> below, we removed "Number" > > > > > >>> > > > > >>> > > > > >>> > > > > >>> from "Autonomous > > > > > >>> System Number (TLV 512)" per RFC 9552, and we removed "ASN" > > > > > >>> following "AS Confederation Identifier" as it is not present in > > > > > >>> RFC 5065. Note that this change was also applied to similar text > > > > > >>> in Section 3.2. Please let us know of any objections. > > > > > >>> > > > > >>> Note that "ASN" was expanded only on the first > > > > > >>> > > > > >>> mention. > > > > > >>> > > > > >>> Original: > > > > > >>> * Autonomous System Number (TLV 512) [RFC9552], which contains > > > > > >>> the > > > > > >>> ASN (or AS Confederation Identifier (ASN) [RFC5065], if > > > > > >>> confederations are used) of the headend node of the SR Policy. > > > > > >>> > > > > >>> Current: > > > > > >>> * Autonomous System (TLV 512) [RFC9552], which contains the > > > > > >>> Autonomous System Number (ASN) (or AS Confederation Identifier > > > > > >>> [RFC5065], if confederations are used) of the headend node of > > > > > >>> the SR Policy. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 4) <!--[rfced] In RFC 9552, > > > > > >>> > > > > >>> > > > > >>> > > > > >>> we note that "IGP Router-ID" > > > > > >>> > > > > >>> > > > > >>> > > > > >>> is listed as > > > > > >>> both a sub-TLV and a TLV code point. As "sub-TLV" and "TLV" are > > > > > >>> not included in the description, how may we update "IGP Router-ID > > > > > >>> sub-TLV (TLV 515)" for conciseness? Would "IGP Router-ID > > > > > >>> (sub-TLV/TLV 515)" be correct? Note that there are two instances > > > > > >>> in the document. > > > > > >>> > > > > >>> Original: > > > > > >>> The determination of whether the > > > > > >>> IGP Router-ID sub-TLV (TLV 515) contains a 4-octet OSPF Router-ID > > > > > >>> or a 6-octet ISO System-ID is to be done based on the length of > > > > > >>> that sub-TLV since the Protocol-ID in the NLRI is always going to > > > > > >>> be "Segment Routing". > > > > > >>> > > > > >>> Perhaps: > > > > > >>> The determination of whether the > > > > > >>> IGP Router-ID (sub-TLV/TLV 515) contains a 4-octet OSPF Router-ID > > > > > >>> or a 6-octet ISO System-ID is to be done based on the length of > > > > > >>> that sub-TLV because the Protocol-ID in the NLRI is always going > > > > > >>> to be "Segment Routing". > > > > > >>> --> > > > > > >>> > > > > >>> KT> The reference here is to the TLV and the IANA > > > > > >>> > > > > >>> registry is for TLV codepoints but they can also be > > > > > >>> > > > > >>> used as sub-TLVs. So, I agree that your suggestion is > > > > > >>> > > > > >>> better, but how about "IGP Router-ID (TLV 515)" ? > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5) <!-- [rfced] We note that > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Section 6.2.3 of RFC 9256 uses > > > > > >>> "Specified-BSID-only". Given this, should "Specified BSID" be > > > > > >>> updated for consistency? > > > > > >>> > > > > >>> Original: > > > > > >>> The TLV MAY also optionally contain the Specified BSID value for > > > > > >>> reporting as described in section 6.2.3 of [RFC9256]. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> The TLV MAY also optionally contain the Specified-BSID-only value > > > > > >>> for reporting as described in Section 6.2.3 of [RFC9256]. > > > > > >>> --> > > > > > >>> > > > > >>> KT> This change is not appropriate. Here, the idea is > > > > > >>> > > > > >>> to signal the Specified-BSID value. Whether or not > > > > > >>> > > > > >>> the Specified-BSID-only is to be used is indicated by > > > > > >>> > > > > >>> a different flag. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 6) <!--[rfced] Please clarify > > > > > >>> > > > > >>> > > > > >>> > > > > >>> if "BSID" should be singular > > > > > >>> > > > > >>> > > > > >>> > > > > >>> (option A) or > > > > > >>> plural (option B) in the following: > > > > > >>> > > > > >>> Original: > > > > > >>> D-Flag: Indicates the dataplane for the BSIDs and if they are > > > > > >>> 16 octet SRv6 SID (when set) or are 4 octet SR/MPLS > > > > > >>> label value (when clear). > > > > > >>> > > > > >>> Perhaps A: > > > > > >>> D-Flag: Indicates the data plane for the BSIDs and if a BSID is > > > > > >>> a 16-octet SRv6 SID (when set) or a 4-octet SR/MPLS > > > > > >>> label value (when clear). > > > > > >>> > > > > >>> Perhaps B: > > > > > >>> D-Flag: Indicates the data plane for the BSIDs and if the BSIDs > > > > > >>> are 16-octet SRv6 SIDs (when set) or 4-octet SR/MPLS > > > > > >>> label values (when clear). > > > > > >>> --> > > > > > >>> > > > > >>> KT> A is better. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 7) <!--[rfced] We note that > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Figures 7 and 19 use > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "Sub-TLVs" (capitalized), > > > > > >>> while Figures 11 and 18 use "sub-TLVs" (lowercased). Should these > > > > > >>> be > > > > > >>> consistent? If yes, which form is preferred? > > > > > >>> --> > > > > > >>> > > > > >>> KT> Here "sub-TLVs" is appropriate as it is not > > > > > >>> > > > > >>> referring to a specific sub-TLV name. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> 8) <!--[rfced] We > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> note multiple > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> instances of > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> "MUST be set to 0 > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> by the > > > > > >>> originator and MUST be ignored by a receiver". Should the one > > > > > >>> instance below that contains only one "MUST" be updated > > > > > >>> accordingly (see Section 5.3)? > > > > > >>> > > > > >>> Original: > > > > > >>> V-Flag: Indicates the candidate path has at least one valid > > > > > >>> SID-List > > > > > >>> when set and indicates no valid SID-List is available or > > > > > >>> evaluated > > > > > >>> when clear. When the E-Flag is clear (i.e. the candidate path > > > > > >>> has not > > > > > >>> been evaluated), then this flag MUST be set to 0 by the > > > > > >>> originator and > > > > > >>> ignored by the receiver. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> V-Flag: Indicates that the candidate path has at least one valid > > > > > >>> SID-List > > > > > >>> when set and that no valid SID-List is available or evaluated > > > > > >>> when clear. > > > > > >>> When the E-Flag is clear (i.e., the candidate path has not been > > > > > >>> evaluated), > > > > > >>> then this flag MUST be set to 0 by the originator and MUST be > > > > > >>> ignored by a > > > > > >>> receiver. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 9) <!--[rfced] Please review > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 2 instances of the term > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "NULL" in this > > > > > >>> document. Should "NULL terminator" be "NUL terminator" or "null > > > > > >>> terminator" for correctness? We ask per guidance received from a > > > > > >>> Gen Art reviewer. Note that RFC 9256 uses "null endpoint", > > > > > >>> "Explicit Null Label Policy", and "IPv6 Explicit NULL Label". > > > > > >>> > > > > >>> Current: > > > > > >>> SR Policy Name: Symbolic name for the SR Policy without a NULL > > > > > >>> terminator as specified in Section 2.1 of [RFC9256]. > > > > > >>> > > > > >>> Candidate Path Name: Symbolic name for the SR Policy > > > > > >>> > > > > >>> candidate path > > > > > >>> without a NULL terminator as specified in Section 2.6 of > > > > > >>> [RFC9256]. > > > > > >>> --> > > > > > >>> > > > > >>> KT> It should be the NUL - which is what I believe it > > > > > >>> > > > > >>> is called in ASCII. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 10) <!--[rfced] How may we > > > > > >>> > > > > >>> > > > > >>> > > > > >>> clarify this "either" > > > > > >>> > > > > >>> > > > > >>> > > > > >>> sentence. Is the intended > > > > > >>> meaning that the dynamic path is computed by the headend or > > > > > >>> delegated to a controller (option A)? Or that the dynamic path is > > > > > >>> computed by the headend or by delegation to a controller (option > > > > > >>> B)? > > > > > >>> > > > > >>> Original: > > > > > >>> The constraints are generally applied to a dynamic candidate > > > > > >>> path which is > > > > > >>> computed either by the headend or may be delegated to a > > > > > >>> controller. > > > > > >>> > > > > >>> Perhaps A: > > > > > >>> The constraints are generally applied to a dynamic candidate > > > > > >>> path that is > > > > > >>> either computed by the headend or delegated to a controller. > > > > > >>> > > > > >>> Perhaps B: > > > > > >>> The constraints are generally applied to a dynamic candidate > > > > > >>> path that is > > > > > >>> computed by either the headend or delegation to a controller. > > > > > >>> --> > > > > > >>> > > > > >>> KT> A is correct. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 11) <!--[rfced] We note that > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Figure 15 uses > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "Request-Flags" and > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "Status-Flags" > > > > > >>> (hyphenated), while the definitions of these fields use "Request > > > > > >>> Flags" > > > > > >>> and "Status Flags" (unhyphenated). To make these consistent, > > > > > >>> which form is > > > > > >>> preferred? > > > > > >>> --> > > > > > >>> > > > > >>> KT> the unhyphenated please > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 12) <!-- [rfced] For > > > > > >>> > > > > >>> > > > > >>> > > > > >>> consistency, should > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "Association Object" be > > > > > >>> > > > > >>> > > > > >>> > > > > >>> updated > > > > > >>> to "ASSOCIATION object" per use in Section 6.1 of [RFC8697]? Note > > > > > >>> that there are four instances. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 13) <!--[rfced] How may we > > > > > >>> > > > > >>> > > > > >>> > > > > >>> rephrase the text in Section > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5.6.6 for clarity? > > > > > >>> > > > > >>> KT> I think a copy/paste error from my side in > > > > > >>> > > > > >>> section 5.6.6 with referencine Table 1 has caused a > > > > > >>> > > > > >>> confusion between metric types and segment types. > > > > > >>> > > > > >>> In the first sentence, we note that Table 1 (Section > > > > > >>> > > > > >>> 5.7.1.1) > > > > > >>> does not list references for the types. Should the term > > > > > >>> "reference" be replaced with "Segment Descriptor" or other for > > > > > >>> conciseness? And may we rephrase the second sentence as shown > > > > > >>> below for clarity and to make it parallel? > > > > > >>> > > > > >>> We also note that Tables 1 and 6 contain the same > > > > > >>> > > > > >>> information. Should > > > > > >>> Table 1 be removed and references to Table 1 (in Sections 5.6.6 > > > > > >>> and > > > > > >>> 5.7.1.1) be updated to point to Table 6? > > > > > >>> > > > > >>> KT> The two tables have different purposes. The Table > > > > > >>> > > > > >>> 1 provides the mapping between the > > > > > >>> segment types (A to K) defined in RFC 9256 with the code points > > > > > >>> of the types defined in > > > > > >>> this document. While table 6 represents the initial allocations > > > > > >>> for the codepoints > > > > > >>> for the segment types for IANA. Comparing this to RFC9830/1, the > > > > > >>> Table 1 is what is listed > > > > > >>> in > > > > > >>> https://www.rfc-editor.org/authors/rfc9830.html#section-2.4.4.2 > > > > > >>> and Table 6 is what is listed in > > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 - > > > > > >>> more specifically, I would prefer > > > > > >>> that we have alignment for the Table 1 column Segment Description > > > > > >>> with the other two RFCs > > > > > >>> with one change that we want to keep the (Type X) as a prefix in > > > > > >>> this document. > > > > > >>> > > > > >>> KT> There is no change required for Table 1, however, > > > > > >>> > > > > >>> we can and perhaps should > > > > > >>> change the section titles 5.7.1.1.1 through 5.7.1.1.11 to reflect > > > > > >>> RFC9830 sections > > > > > >>> 2.4.4.2.1 - 2.4.4.22 and RFC9831 sections 2.1 through 2.10. > > > > > >>> > > > > >>> As an example: Type 1: SR-MPLS Label (Type A) -> Type > > > > > >>> > > > > >>> 1: Segment Type A > > > > > >>> > > > > >>> This will make the section headings short and align > > > > > >>> > > > > >>> with the other two RFCs that specify > > > > > >>> the southbound BGP signaling while this document specifies its > > > > > >>> northbound reporting. > > > > > >>> > > > > >>> The titles for figures are ok. > > > > > >>> > > > > >>> The descriptions can then be changed along the lines > > > > > >>> > > > > >>> of > > > > > >>> > > > > >>> https://www.rfc-editor.org/authors/rfc9831.html#section-3.1 > > > > > >>> > > > > >>> As an example: (Type A) SR-MPLS Label -> Type A > > > > > >>> > > > > >>> Segment > > > > > >>> > > > > >>> Please let me know your views from the perspective of > > > > > >>> > > > > >>> readability and alignment across RFC9256 and > > > > > >>> the 3 BGP RFCs under RFC Editor currently including this document. > > > > > >>> > > > > >>> > > > > >>> Original (Section 5.6.6): > > > > > >>> The Table 1 below lists the metric types introduced by this > > > > > >>> document > > > > > >>> along with reference for each. Where the references are for IS-IS > > > > > >>> and OSPF specifications, those metric types are defined for a > > > > > >>> link > > > > > >>> while in the SR Policy context those relate to the candidate path > > > > > >>> or the segment list. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> Table 6 lists the metric types introduced by this document along > > > > > >>> with a Segment Descriptor for each. Where the Segment Descriptors > > > > > >>> relate to IS-IS and OSPF specifications, the metric types are > > > > > >>> defined > > > > > >>> for a link. Where the Segment Descriptors relate to the SR > > > > > >>> Policy, > > > > > >>> the metric types are defined for a candidate path or a segment > > > > > >>> list. > > > > > >>> > > > > >>> > > > > >>> KT> Can you please fix/update this blob > > > > > >>> > > > > >>> > > > > >>> as below? > > > > > >>> > > > > >>> Below is a list of metric types introduced by > > > > > >>> > > > > >>> this document > > > > > >>> along with references for each. Where the references are for > > > > > >>> IS-IS > > > > > >>> and OSPF specifications, those metric types are defined for a > > > > > >>> link > > > > > >>> while in the SR Policy context those relate to the candidate > > > > > >>> path > > > > > >>> or the segment list. > > > > > >>> > > > > >>> The "list" is actually right after the paragraph with > > > > > >>> > > > > >>> this text and the reference to Table 1 > > > > > >>> was an error. I hope this clarifies. > > > > > >>> > > > > >>> ... > > > > > >>> Original (Section 5.7.1.1) > > > > > >>> The following types are currently defined and their mapping to > > > > > >>> the > > > > > >>> respective segment types defined in [RFC9256]: > > > > > >>> > > > > >>> Perhaps: > > > > > >>> See Table 6 for the type definitions and their mappings to the > > > > > >>> respective segment types defined in [RFC9256]. > > > > > >>> --> > > > > > >>> > > > > >>> KT> The above change is now not necessary. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 14) <!--[rfced] For clarity, > > > > > >>> > > > > >>> > > > > >>> > > > > >>> should the registry that the > > > > > >>> > > > > >>> > > > > >>> > > > > >>> metric types are > > > > > >>> taken from be listed here instead of only the registry that they > > > > > >>> are > > > > > >>> not listed in? > > > > > >>> > > > > >>> Original: > > > > > >>> Note that the metric type in this field is not taken from the > > > > > >>> "IGP > > > > > >>> Metric Type" registry from IANA "IGP Parameters" and is a > > > > > >>> separate > > > > > >>> registry that includes IGP Metric Types as well as metric types > > > > > >>> specific to SR Policy path computation. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> Note that the metric types in this field are taken from the > > > > > >>> "BGP-LS SR Policy Metric Types" IANA registry, which includes > > > > > >>> IGP Metric Types as well as metric types specific to SR Policy > > > > > >>> path computation (i.e., the metric types are not from the > > > > > >>> "IGP Metric-Type" registry). > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 15) <!--[rfced] In Section > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5.6.6, we updated "Average" > > > > > >>> > > > > >>> > > > > >>> > > > > >>> to "Avg" to > > > > > >>> match use in Table 7 and the "BGP-LS SR Policy Metric Types" > > > > > >>> registry. If you prefer to update the registry to reflect > > > > > >>> "Average" instead of "Avg", please let us know. > > > > > >>> > > > > >>> Link to registry: > > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types>. > > > > > >>> > > > > >>> Original: > > > > > >>> Type 6: Average Unidirectional Delay: > > > > > >>> > > > > >>> Current: > > > > > >>> Type 6: Avg Unidirectional Delay: > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 16) <!--[rfced] We note that > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Figure 18 contains two > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "RESERVED" fields. > > > > > >>> As these are two distinctly different fields, should they be > > > > > >>> updated > > > > > >>> as "RESERVED1" and "RESERVED2", which would reflect Figure 11? > > > > > >>> --> > > > > > >>> > > > > >>> KT> Yes, please do the same for Figure 11 > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> 17) <!--[rfced] > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> Table 6 (Section > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> 8.5) specifies > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> the SRv6 SID as > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> an "IPv6 > > > > > >>> address", but Section 5.7.1.1.2 specifies it as an "SRv6 SID > > > > > >>> address". > > > > > >>> Is an update needed in Section 5.7.1.1.2 for consistency with > > > > > >>> Table 6? > > > > > >>> > > > > >>> Original: > > > > > >>> The Segment is SRv6 type and is specified simply as the SRv6 SID > > > > > >>> address. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> The Segment is an SRv6 type and is specified simply as the IPv6 > > > > > >>> address. > > > > > >>> --> > > > > > >>> > > > > >>> KT> It should just say "SRv6 SID" in 7.7.1.1.2 and in > > > > > >>> > > > > >>> Table 6. But please refer to the previous suggestion > > > > > >>> > > > > >>> on Table 6. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 18) <!--[rfced] In Section > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5.7.1.1.6, should "interface" > > > > > >>> > > > > >>> > > > > >>> > > > > >>> be added to more > > > > > >>> closely match Table 6 (the "BGP-LS SR Segment Descriptor Types" > > > > > >>> registry)? > > > > > >>> > > > > >>> Link to registry: > > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types > > > > > >>> > > > > >>> Original: > > > > > >>> IPv4 Local Address: > > > > > >>> IPv4 Remote Address: > > > > > >>> > > > > >>> Perhaps: > > > > > >>> IPv4 Local Interface Address: > > > > > >>> IPv4 Remote Interface Address: > > > > > >>> > > > > >>> ... > > > > > >>> Original (Figure 25): > > > > > >>> IPv4 Local Address (4 octets) > > > > > >>> IPv4 Remote Address (4 octets) > > > > > >>> > > > > >>> Perhaps: > > > > > >>> IPv4 Local Interface Address (4 octets) > > > > > >>> IPv4 Remote Interface Address (4 octets) > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack for both > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 19) <!--[rfced] In Sections > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 5.7.1.1.8 and 5.7.1.1.11, > > > > > >>> > > > > >>> > > > > >>> > > > > >>> should the following > > > > > >>> be updated for consistency with the descriptions in Table 6 (the > > > > > >>> "BGP-LS SR Segment Descriptor Types" registry)? > > > > > >>> > > > > >>> Link to registry: > > > > > >>> https://www.iana.org/assignments/bgp-ls-parameters/ > > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types? > > > > > >>> > > > > >>> Original: > > > > > >>> IPv6 Local Address: > > > > > >>> IPv6 Remote Address: > > > > > >>> > > > > >>> Perhaps: > > > > > >>> IPv6 Local Global Address: > > > > > >>> IPv6 Remote Global Address: > > > > > >>> > > > > >>> ... > > > > > >>> Original (Figures 27 and 30): > > > > > >>> Global IPv6 Local Interface Address (16 octets) > > > > > >>> Global IPv6 Remote Interface Address (16 octets) > > > > > >>> > > > > >>> Perhaps: > > > > > >>> IPv6 Local Interface Global Address (16 octets) > > > > > >>> IPv6 Remote Interface Global Address (16 octets) > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack for both. > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 20) <!-- [rfced] Section 4 of > > > > > >>> > > > > >>> > > > > >>> > > > > >>> this document as well as RFC > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 9256 uses > > > > > >>> "Protocol-Origin" rather than "Protocol Origin". Are any updates > > > > > >>> needed to the "SR Policy Protocol Origin" registry name, two > > > > > >>> instances of "SR Protocol Origin", or "Protocol Origin field"? > > > > > >>> > > > > >>> Original: > > > > > >>> Per this document, IANA has created and maintains a new registry > > > > > >>> called "SR Policy Protocol Origin" under the "Segment Routing" > > > > > >>> registry group with the allocation policy of Expert Review > > > > > >>> [RFC8126] > > > > > >>> using the guidelines for designated experts as specified in > > > > > >>> [RFC9256]. This registry contains the code points allocated to > > > > > >>> the > > > > > >>> "Protocol Origin" field defined in Section 4. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Lets use "Protocol-Origin" to be consistent with > > > > > >>> > > > > >>> RFC9256 > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 21) <!--[rfced] Under the > > > > > >>> > > > > >>> > > > > >>> > > > > >>> "Segment Descriptor" column > > > > > >>> > > > > >>> > > > > >>> > > > > >>> in the "BGP-LS SR > > > > > >>> Segment Descriptor Types" registry, should the following changes > > > > > >>> be made to the code point descriptions? That is, add articles, > > > > > >>> make names following "pair" plural, and capitalize instances of > > > > > >>> "address" and "node", accordingly. > > > > > >>> > > > > >>> The form to the right of the arrow is suggested. If > > > > > >>> > > > > >>> changes are made, > > > > > >>> we will update the running text accordingly (namely the > > > > > >>> subsections > > > > > >>> under Section 5.7.1.1) as well as the IANA registry. > > > > > >>> > > > > >>> Link to registry: > > > > > >>> <https://www.iana.org/assignments/bgp-ls-parameters/ > > > > > >>> bgp-ls-parameters.xhtml#bgp-ls-sr-segment-descriptor-types> > > > > > >>> > > > > >>> (Type B) SRv6 SID as IPv6 address -> (Type B) SRv6 > > > > > >>> > > > > >>> SID as an IPv6 Address > > > > > >>> > > > > >>> > > > > >>> (Type C) SR-MPLS Prefix SID as IPv4 Node > > > > > >>> > > > > >>> > > > > >>> Address -> > > > > > >>> (Type C) SR-MPLS Prefix SID as an IPv4 Node Address > > > > > >>> > > > > >>> (Type D) SR-MPLS Prefix SID as IPv6 Node Global > > > > > >>> > > > > >>> Address -> > > > > > >>> (Type D) SR-MPLS Prefix SID as an IPv6 Node Global Address > > > > > >>> > > > > >>> (Type E) SR-MPLS Adjacency SID as IPv4 Node Address & > > > > > >>> > > > > >>> Local Interface ID -> > > > > > >>> (Type E) SR-MPLS Adjacency SID as an IPv4 Node Address & a > > > > > >>> Local Interface ID > > > > > >>> > > > > >>> (Note: Section 5.7.1.1.6 describes Type F as a > > > > > >>> > > > > >>> "pair"; is that correct to add?) > > > > > >>> (Type F) SR-MPLS Adjacency SID as IPv4 Local & Remote Interface > > > > > >>> Addresses -> > > > > > >>> (Type F) SR-MPLS Adjacency SID as a pair of IPv4 Local & Remote > > > > > >>> Interface Addresses > > > > > >>> > > > > >>> (Type G) SR-MPLS Adjacency SID as pair of IPv6 Global > > > > > >>> > > > > >>> Address & Interface ID for > > > > > >>> Local & Remote nodes -> > > > > > >>> (Type G) SR-MPLS Adjacency SID as a pair of IPv6 Global > > > > > >>> Addresses & > > > > > >>> Interface IDs for Local & Remote Nodes > > > > > >>> > > > > >>> (Type H) SR-MPLS Adjacency SID as pair of IPv6 Global > > > > > >>> > > > > >>> Addresses for the > > > > > >>> Local & Remote Interface -> > > > > > >>> (Type H) SR-MPLS Adjacency SID as a pair of IPv6 Global > > > > > >>> Addresses for > > > > > >>> Local & Remote Interface Addresses > > > > > >>> > > > > >>> (Type I) SRv6 END SID as IPv6 Node Global Address -> > > > > > >>> (Type I) SRv6 END SID as an IPv6 Node Global Address > > > > > >>> > > > > >>> (Type J) SRv6 END.X SID as pair of IPv6 Global > > > > > >>> > > > > >>> Address & Interface ID > > > > > >>> for Local & Remote nodes -> > > > > > >>> (Type J) SRv6 END.X SID as a pair of IPv6 Global Addresses & > > > > > >>> Interface IDs > > > > > >>> for Local & Remote Nodes > > > > > >>> > > > > >>> (Type K) SRv6 END.X SID as pair of IPv6 Global > > > > > >>> > > > > >>> Addresses for the Local & > > > > > >>> Remote Interface -> > > > > > >>> (Type K) SRv6 END.X SID as a pair of IPv6 Global Addresses > > > > > >>> for Local & > > > > > >>> Remote Interface Addresses > > > > > >>> --> > > > > > >>> > > > > >>> KT> Please refer to my response to your point 13 that > > > > > >>> > > > > >>> impacts this. With that in mind, I would think > > > > > >>> that these queries are no longer relevant? > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 22) <!--[rfced] FYI: In the > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Contributors section, we > > > > > >>> > > > > >>> > > > > >>> > > > > >>> updated the lead-in > > > > > >>> text as follows to indicate that the individuals listed are > > > > > >>> coauthors. > > > > > >>> > > > > >>> Original: > > > > > >>> The following people have substantially contributed to the > > > > > >>> editing of > > > > > >>> this document: > > > > > >>> > > > > >>> Current: > > > > > >>> The following people have contributed substantially to the > > > > > >>> content of this document and should be considered coauthors: > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 23) <!-- [rfced] Terminology > > > > > >>> > > > > >>> a) Throughout the text, the following terminology > > > > > >>> > > > > >>> appears to be used > > > > > >>> inconsistently. Please review these occurrences and let us know > > > > > >>> if/how they > > > > > >>> may be made consistent. > > > > > >>> > > > > >>> -Flag vs. -flag > > > > > >>> (e.g., "D-Flag" vs. "A-flag" in the running text) > > > > > >>> > > > > >>> KT> -flag > > > > > >>> > > > > >>> Metric Type field vs. "metric type" field > > > > > >>> (Note: the companion document uses "metric type field" with no > > > > > >>> quote marks) > > > > > >>> > > > > >>> KT> metric type field - without the quotes > > > > > >>> > > > > >>> Segment Descriptor vs. Segment descriptor > > > > > >>> > > > > >>> KT> segment descriptor (except when used in titles > > > > > >>> > > > > >>> where capitalization is used) > > > > > >>> > > > > >>> Segment List vs. segment list > > > > > >>> > > > > >>> KT> 2nd > > > > > >>> > > > > >>> SID-List vs. SID-list vs. SID-LIST vs. SID List > > > > > >>> > > > > >>> KT> SID list to be consistent with a single usage in > > > > > >>> > > > > >>> RFC9256 > > > > > >>> > > > > >>> SR Policy Candidate Path NLRI Type vs. SR Policy > > > > > >>> > > > > >>> Candidate Path NLRI type > > > > > >>> > > > > >>> KT> 2nd > > > > > >>> > > > > >>> > > > > >>> SR Policy Candidate Path vs. SR Policy > > > > > >>> > > > > >>> > > > > >>> Candidate path vs. SR Policy candidate > > > > > >>> > > > > >>> > > > > >>> path > > > > > >>> > > > > >>> KT> Capitalization when used in name (1st) and > > > > > >>> > > > > >>> otherwise (3rd) > > > > > >>> > > > > >>> > > > > >>> > > > > >>> b) We updated the following > > > > > >>> > > > > >>> > > > > >>> > > > > >>> terms for consistency. Please > > > > > >>> > > > > >>> > > > > >>> > > > > >>> let us know of any objections. > > > > > >>> > > > > >>> codepoint -> code point (per IANA registries) > > > > > >>> dataplane -> data plane > > > > > >>> drop upon invalid -> Drop-Upon-Invalid (per RFC 9256) > > > > > >>> Global address -> global address (2 instances in the running text) > > > > > >>> head-end -> headend > > > > > >>> nexthop -> next hop > > > > > >>> traffic engineering -> Traffic Engineering (per RFC 9552 and the > > > > > >>> companion document) > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> c) FYI: We made "Constraints" in the > > > > > >>> > > > > >>> > > > > >>> following sub-TLV names singular for > > > > > >>> > > > > >>> > > > > >>> consistency > > > > > >>> with Table 4. > > > > > >>> > > > > >>> SR Affinity Constraints Sub-TLV -> SR Affinity > > > > > >>> > > > > >>> Constraint Sub-TLV (Figure 12) > > > > > >>> SR Bandwidth Constraints Sub-TLV -> SR Bandwidth Constraint > > > > > >>> Sub-TLV (Figure 14) > > > > > >>> > > > > >>> SR Bidirectional Group Constraints Sub-TLV -> > > > > > >>> SR Bidirectional Group Constraint Sub-TLV (Figure 16) > > > > > >>> > > > > >>> SR Disjoint Group Constraints Sub-TLV -> SR Disjoint > > > > > >>> > > > > >>> Group Constraint Sub-TLV (Figure 15) > > > > > >>> SR Metric Constraints Sub-TLV -> SR Metric Constraint Sub-TLV > > > > > >>> (Figure 17 and Section 5.7.2) > > > > > >>> SR SRLG Constraints Sub-TLV -> SR SRLG Constraint Sub-TLV (Figure > > > > > >>> 13) > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> d) FYI: We updated 7 instances of > > > > > >>> > > > > >>> > > > > >>> "Descriptor" to "Descriptors" > > > > > >>> for TLV 256 per RFC 9552. > > > > > >>> > > > > >>> Local Node Descriptor (TLV 256) -> Local Node > > > > > >>> > > > > >>> Descriptors (TLV 256) > > > > > >>> --> > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 24) <!-- [rfced] Abbreviations > > > > > >>> > > > > >>> a) FYI - We have added expansions for the following > > > > > >>> > > > > >>> abbreviations > > > > > >>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > > > > > >>> each > > > > > >>> expansion in the document carefully to ensure correctness. > > > > > >>> > > > > >>> Autonomous System Number (ASN) > > > > > >>> Bidirectional Forwarding Detection (BFD) > > > > > >>> External BGP (EBGP) > > > > > >>> Label Edge Routers (LERs) > > > > > >>> Label Switched Path (LSP) > > > > > >>> Label Switching Router (LSR) > > > > > >>> Network Layer Reachability Information (NLRI) > > > > > >>> Path Computation Element Communication Protocol (PCEP) > > > > > >>> > > > > >>> KT> Ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> b) To reflect more common > > > > > >>> > > > > >>> > > > > >>> > > > > >>> usage in previously published > > > > > >>> > > > > >>> > > > > >>> > > > > >>> RFCs, may we update > > > > > >>> the expansion of "BGP-LS" from "BGP Link-State" to "BGP - Link > > > > > >>> State"? If yes, > > > > > >>> note that the title of this document would also be updated > > > > > >>> accordingly. > > > > > >>> > > > > >>> Original: > > > > > >>> Advertisement of Segment Routing Policies using BGP Link-State > > > > > >>> ... > > > > > >>> This document describes a mechanism to collect the Segment > > > > > >>> Routing > > > > > >>> Policy information that is locally available in a node and > > > > > >>> advertise > > > > > >>> it into BGP Link-State (BGP-LS) updates. > > > > > >>> > > > > >>> Perhaps: > > > > > >>> Advertisement of Segment Routing Policies using BGP - Link State > > > > > >>> ... > > > > > >>> This document describes a mechanism to collect the Segment > > > > > >>> Routing > > > > > >>> Policy information that is locally available in a node and > > > > > >>> advertise > > > > > >>> it into BGP - Link State (BGP-LS) updates. > > > > > >>> --> > > > > > >>> > > > > >>> KT> ack > > > > > >>> > > > > >>> > > > > >>> > > > > >>> 25) <!-- [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. > > > > > >>> --> > > > > > >>> > > > > >>> KT> Looks good to me. > > > > > >>> > > > > >>> Thanks, > > > > > >>> Ketan > > > > > >>> > > > > >>> > > > > >>> > > > > >>> Thank you. > > > > > >>> > > > > >>> Karen Moore and Alanna Paloma > > > > > >>> RFC Production Center > > > > > >>> > > > > >>> > > > > >>> On Sep 10, 2025, at 3:08 PM, > > > > > >>> > > > > >>> > > > > >>> [email protected] wrote: > > > > > >>> > > > > >>> *****IMPORTANT***** > > > > > >>> > > > > >>> Updated 2025/09/10 > > > > > >>> > > > > >>> 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/rfc9857.xml > > > > > >>> https://www.rfc-editor.org/authors/rfc9857.html > > > > > >>> https://www.rfc-editor.org/authors/rfc9857.pdf > > > > > >>> https://www.rfc-editor.org/authors/rfc9857.txt > > > > > >>> > > > > >>> Diff file of the text: > > > > > >>> https://www.rfc-editor.org/authors/rfc9857-diff.html > > > > > >>> https://www.rfc-editor.org/authors/rfc9857-rfcdiff.html (side by > > > > > >>> side) > > > > > >>> > > > > >>> Diff of the XML: > > > > > >>> https://www.rfc-editor.org/authors/rfc9857-xmldiff1.html > > > > > >>> > > > > >>> > > > > >>> Tracking progress > > > > > >>> ----------------- > > > > > >>> > > > > >>> The details of the AUTH48 status of your document are > > > > > >>> > > > > >>> here: > > > > > >>> https://www.rfc-editor.org/auth48/rfc9857 > > > > > >>> > > > > >>> Please let us know if you have any questions. > > > > > >>> > > > > >>> Thank you for your cooperation, > > > > > >>> > > > > >>> RFC Editor > > > > > >>> > > > > >>> -------------------------------------- > > > > > >>> RFC9857 (draft-ietf-idr-bgp-ls-sr-policy-17) > > > > > >>> > > > > >>> Title : Advertisement of Segment Routing > > > > > >>> > > > > >>> Policies using BGP Link-State > > > > > >>> Author(s) : S. Previdi, K. Talaulikar, Ed., J. Dong, H. > > > > > >>> Gredler, J. Tantsura > > > > > >>> WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas > > > > > >>> > > > > >>> Area Director(s) : Jim Guichard, Ketan Talaulikar, > > > > > >>> > > > > >>> Gunter Van de Velde > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > NOTICE > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > TO > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > RECIPIENT > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > This > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > e-mail > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > message > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > and any > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > attachments > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > are > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > confidential > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > and > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > may be > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > privileged. > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > If you > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > received > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > this > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > e-mail > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > in > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > error, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > any > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > review, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > use, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > dissemination, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > distribution, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > or > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > copying > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > of this > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > e-mail > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > is > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > strictly > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > prohibited. > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > Please > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > notify > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > us > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > immediately > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > of the > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > error > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > by > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > return > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > e-mail > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > and > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > please > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > delete > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > this > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > message > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > from > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > your > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > system. > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > For > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > more > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > information > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > about > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > Rtbrick, > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > please > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > visit > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > us at > > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > www.rtbrick.com > > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
