Hi Karen, I approve the publication of this document once the discussion about the segment types description is resolved.
Best regards, Jie > -----Original Message----- > From: Karen Moore <[email protected]> > Sent: Friday, September 19, 2025 2:18 AM > To: Hannes Gredler <[email protected]>; [email protected]; John > Scudder <[email protected]>; Jeff Tantsura <[email protected]>; Dongjie > (Jimmy) <[email protected]>; Ketan Talaulikar <[email protected]> > Cc: Editor RFC <[email protected]>; [email protected]; idr-chairs > <[email protected]>; Sue Hares <[email protected]>; Shawn Zandi via > auth48archive <[email protected]> > Subject: Re: [AD] AUTH48: RFC-to-be 9857 <draft-ietf-idr-bgp-ls-sr-policy-17> > for your review > > 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 > > >>> KT> 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 > > >>> KT> 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 > > >>> KT> 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 > > >>> KT> 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 > > >>> KT> 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-4Q9l2 > > >>> USxIAe6P8O4Zc > > >>> > > >>> * 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]
