Authors, Now that we have all necessary approvals, the IANA updates have been confirmed, and the other documents in the cluster have completed AUTH48, we will move the three documents from Cluster C534 forward in the publication process at this time.
The relevant cluster information can be found here: https://www.rfc-editor.org/cluster_info.php?cid=C534 Thank you all for your time and attention during AUTH48. Megan Ferguson RPC Production Center > On Sep 4, 2025, at 7:32 AM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > Sabrina, > > Looks great - thanks! > > Megan Ferguson > RPC Production Center > > >> On Aug 29, 2025, at 4:52 PM, Sabrina Tanamal via RT <iana-mat...@iana.org> >> wrote: >> >> Hi Megan, all, >> >> These changes are complete: >> >> https://www.iana.org/assignments/bgp-tunnel-encapsulation >> >> Thanks, >> Sabrina >> >> On Fri Aug 29 17:50:52 2025, mfergu...@staff.rfc-editor.org wrote: >>> IANA, >>> >>> Please make the following updates to the SR Policy Segment List Sub- >>> TLVs registry at https://www.iana.org/assignments/bgp-tunnel- >>> encapsulation: >>> >>> Old: >>> 3 Segment Type C sub-TLV >>> 4 Segment Type D sub-TLV >>> 5 Segment Type E sub-TLV >>> 6 Segment Type F sub-TLV >>> 7 Segment Type G sub-TLV >>> 8 Segment Type H sub-TLV >>> 14 Segment Type I sub-TLV >>> 15 Segment Type J sub-TLV >>> 16 Segment Type K sub-TLV >>> >>> New (flip the placement of Segment): >>> 3 Type C Segment sub-TLV >>> 4 Type D Segment sub-TLV >>> 5 Type E Segment sub-TLV >>> 6 Type F Segment sub-TLV >>> 7 Type G Segment sub-TLV >>> 8 Type H Segment sub-TLV >>> 14 Type I Segment sub-TLV >>> 15 Type J Segment sub-TLV >>> 16 Type K Segment sub-TLV >>> >>> Please let us know once these updates are complete. >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>>> On Aug 29, 2025, at 11:12 AM, Stefano Previdi <stef...@previdi.net> >>>> wrote: >>>> >>>> Hi, >>>> >>>> Sorry for being late, I approve the publication. >>>> >>>> Thanks. >>>> s. >>>> >>>> >>>> On Fri, Aug 29, 2025, 18:41 Megan Ferguson <mfergu...@staff.rfc- >>>> editor.org> wrote: >>>> Authors (*Stafano), >>>> >>>> Thank you for the approvals we have received thus far: we have marked >>>> them on the AUTH48 status page (see below). We believe the only >>>> author approval outstanding is *Stefano’s. >>>> >>>> Once we receive all author approvals, we will request that IANA >>>> update to match any relevant changes made during AUTH48 (same for >>>> RFC-to-be 9830; the update has already been requested for RFC-to-be >>>> 9832). Once we receive confirmation of the registry/document >>>> matching for all documents in the cluster, we will move forward in >>>> the publication process. >>>> >>>> The files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9831.txt >>>> https://www.rfc-editor.org/authors/rfc9831.pdf >>>> https://www.rfc-editor.org/authors/rfc9831.html >>>> https://www.rfc-editor.org/authors/rfc9831.xml >>>> >>>> The relevant diff files have been posted here: >>>> https://www.rfc-editor.org/authors/rfc9831-diff.html (comprehensive) >>>> https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by >>>> side) >>>> >>>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 >>>> changes only) >>>> https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html (side >>>> by side) >>>> >>>> The AUTH48 status page for this document can be found here: >>>> https://www.rfc-editor.org/auth48/rfc9831 >>>> >>>> The relevant cluster information can be found here: >>>> https://www.rfc-editor.org/cluster_info.php?cid=C534 >>>> >>>> Thank you. >>>> >>>> Megan Ferguson >>>> RFC Production Center >>>> >>>> >>>> >>>> >>>>> On Aug 26, 2025, at 1:46 AM, Clarence Filsfils (cfilsfil) >>>>> <cfils...@cisco.com> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I approve this document for publication. >>>>> >>>>> Cheers, >>>>> Clarence >>>>> >>>>>> -----Original Message----- >>>>>> From: Megan Ferguson <mfergu...@staff.rfc-editor.org> >>>>>> Sent: Monday, August 25, 2025 17:53 >>>>>> To: Ketan Talaulikar <ketant.i...@gmail.com> >>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Clarence Filsfils >>>>>> (cfilsfil) >>>>>> <cfils...@cisco.com>; stef...@previdi.net; pamat...@microsoft.com; >>>>>> dhanendra.i...@gmail.com; idr-...@ietf.org; idr-cha...@ietf.org; >>>>>> sha...@ndzh.com; Roman Danyliw <r...@cert.org>; auth48archive@rfc- >>>>>> editor.org >>>>>> Subject: Re: AUTH48: RFC-to-be 9831 <draft-ietf-idr-bgp-sr- >>>>>> segtypes-ext-08> >>>>>> for your review >>>>>> >>>>>> Hi Ketan, >>>>>> >>>>>> Thank you for spotting that! We have updated as requested (please >>>>>> refresh). >>>>>> >>>>>> We have also marked you as “approved” at the AUTH48 status page >>>>>> (see >>>>>> below). Once we have approvals from your coauthors, we will >>>>>> forward the >>>>>> necessary updates to IANA. >>>>>> >>>>>> The files have been posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9831.txt >>>>>> https://www.rfc-editor.org/authors/rfc9831.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9831.html >>>>>> https://www.rfc-editor.org/authors/rfc9831.xml >>>>>> >>>>>> The relevant diff files have been posted here: >>>>>> https://www.rfc-editor.org/authors/rfc9831-diff.html >>>>>> (comprehensive) >>>>>> https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html (AUTH48 >>>>>> changes only) >>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html >>>>>> (side by side) >>>>>> >>>>>> The AUTH48 status page for this document can be found here: >>>>>> https://www.rfc-editor.org/auth48/rfc9831 >>>>>> >>>>>> The relevant cluster information can be found here: >>>>>> https://www.rfc-editor.org/cluster_info.php?cid=C534 >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Megan Ferguson >>>>>> RFC Production Center >>>>>> >>>>>>> On Aug 22, 2025, at 11:52 PM, Ketan Talaulikar >>>>>>> <ketant.i...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi Megan, >>>>>>> >>>>>>> I had a look at the >>>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html and >>>>>>> there >>>>>>> is still this change that needs to be reverted in section 2.7 >>>>>>> >>>>>>> SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY >>>>>>> be >>>>>>> used when the controller wants to indicate the desired SRv6 >>>>>>> Endpoint Behavior >>>>>>> or and SID Structure without specifying the SID. >>>>>>> Besides that, everything looks good and please take this email as >>>>>>> my >>>>>> approval for publication. >>>>>>> >>>>>>> Thanks, >>>>>>> Ketan >>>>>>> >>>>>>> >>>>>>> On Sat, Aug 23, 2025 at 1:35 AM Megan Ferguson >>>>>>> <mfergu...@staff.rfc- >>>>>> editor.org> wrote: >>>>>>> Hi Ketan, >>>>>>> >>>>>>> Thank you for your prompt reply! >>>>>>> >>>>>>> We have updated as suggested and added these changes to the >>>>>>> current >>>>>> files/diffs (please refresh). >>>>>>> >>>>>>> The files have been posted here: >>>>>>> https://www.rfc-editor.org/authors/rfc9831.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9831.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9831.html >>>>>>> https://www.rfc-editor.org/authors/rfc9831.xml >>>>>>> >>>>>>> The relevant diff files have been posted here: >>>>>>> https://www.rfc-editor.org/authors/rfc9831-diff.html >>>>>>> (comprehensive) >>>>>>> https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html >>>>>>> (AUTH48 >>>>>> changes only) >>>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html >>>>>>> (side >>>>>>> by side) >>>>>>> >>>>>>> The AUTH48 status page for this document can be found here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9831 >>>>>>> >>>>>>> The relevant cluster information can be found here: >>>>>>> https://www.rfc-editor.org/cluster_info.php?cid=C534 >>>>>>> >>>>>>> Please let us know if any further updates are necessary. We will >>>>>>> await >>>>>> approvals from each party listed at the AUTH48 status page prior >>>>>> to moving >>>>>> forward in the publication process. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/mf >>>>>>> >>>>>>>> On Aug 22, 2025, at 2:30 AM, Ketan Talaulikar >>>>>>>> <ketant.i...@gmail.com> >>>>>> wrote: >>>>>>>> >>>>>>>> Hi Megan, >>>>>>>> >>>>>>>> Please check inline below for responses with KT2. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 22, 2025 at 12:23 AM Megan Ferguson >>>>>>>> <mfergu...@staff.rfc- >>>>>> editor.org> wrote: >>>>>>>> Hi Ketan, >>>>>>>> >>>>>>>> Thank you for your response and guidance. >>>>>>>> >>>>>>>> Some further questions/comments below marked with [rfced]. >>>>>>>> >>>>>>>>> >>>>>>>>> 4) <!-- [rfced] The following text from Section 2 may require >>>>>>>>> clarification: >>>>>>>>> >>>>>>>>> "As specified in Sections 2.4.4 and 2.4.4.2 of [RFC9830], >>>>>>>>> validation of an explicit path encoded by the Segment List sub- >>>>>>>>> TLV >>>>>>>>> is beyond the scope of BGP and performed by the Segment Routing >>>>>>>>> Policy Module (SRPM) as described in Section 5 of [RFC9256]." >>>>>>>>> >>>>>>>>> The term "Segment Routing Policy Module (SRPM)" doesn't appear >>>>>>>>> in >>>>>>>>> [RFC9256]. >>>>>>>>> >>>>>>>>> --> >>>>>>>>> >>>>>>>>> KT> It should be RFC9830 >>>>>>>> >>>>>>>> [rfced] We believe the citation in the sentence following should >>>>>>>> be >>>>>> updated as well (and have made the update). Please review and let >>>>>> us know >>>>>> if this is in error. >>>>>>>> >>>>>>>> KT2> That 2nd sentence should refer to RFC9256 so please revert >>>>>>>> KT2> that >>>>>> change to the original. >>>>>>>> >>>>>>>> What is being referenced is the following text >>>>>>>> https://www.rfc-editor.org/rfc/rfc9256.html#section-5.1 >>>>>>>> >>>>>>>> Additionally, an explicit candidate path MAY be declared invalid >>>>>>>> when its >>>>>> constituent segment lists (valid or invalid) are using segment >>>>>> types of different >>>>>> SR data planes. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 5) <!--[rfced] The following text led us to believe that the >>>>>>>>> subsection >>>>>>>>> titles of Section 2 would match the Type names listed in >>>>>>>>> Section >>>>>>>>> 2 itself: but they do not. Please review and let us know >>>>>>>>> if a >>>>>>>>> closer 1:1 matchup is desired between these. >>>>>>>>> >>>>>>>>> Original: >>>>>>>>> [I-D.ietf-idr-sr-policy-safi] specifies Segment Type Sub-TLVs >>>>>>>>> for >>>>>>>>> the segment types A and B. The following sub-sections specify >>>>>>>>> the >>>>>>>>> sub- TLVs used for encoding each of the other Segment Types >>>>>>>>> above. >>>>>>>>> >>>>>>>>> >>>>>>>>> KT> They look ok to me, but perhaps I don't follow your point. >>>>>>>>> KT> Could >>>>>> you please illustrate with an example? >>>>>>>>> >>>>>>>>> >>>>>>>>> --> >>>>>>>> >>>>>>>> [rfced] Sorry for any confusion. Just curious if the wording >>>>>>>> should be >>>>>> made the same in the “names” of the Types. We see: >>>>>>>> >>>>>>>> Original ToC: >>>>>>>> 2. Segment Type Sub-TLVs . . . . . . . . . . . . . . . . . . >>>>>>>> . . 3 >>>>>>>> 2.1. Segment Type C - SR-MPLS Prefix SID for IPv4 . . . . >>>>>>>> . . 4 >>>>>>>> 2.2. Segment Type D - SR-MPLS Prefix SID for IPv6 . . . . >>>>>>>> . . 5 >>>>>>>> 2.3. Segment Type E - SR-MPLS Adjacency SID for IPv4 with >>>>>>>> an >>>>>>>> Interface ID . . . . . . . . . . . . . . . . . . . . >>>>>>>> . . 5 >>>>>>>> 2.4. Segment Type F - SR-MPLS Adjacency SID for IPv4 with >>>>>>>> an >>>>>>>> Interface Address . . . . . . . . . . . . . . . . . >>>>>>>> . . 6 >>>>>>>> 2.5. Segment Type G - SR-MPLS Adjacency SID for IPv6 with >>>>>>>> an >>>>>>>> Interface ID . . . . . . . . . . . . . . . . . . . . >>>>>>>> . . 7 >>>>>>>> 2.6. Segment Type H - SR-MPLS Adjacency SID for IPv6 with >>>>>>>> an >>>>>>>> Interface Address . . . . . . . . . . . . . . . . . >>>>>>>> . . 9 >>>>>>>> 2.7. Segment Type I - SRv6 END SID as IPv6 Node Address . >>>>>>>> . . 9 >>>>>>>> 2.8. Segment Type J - SRv6 END.X SID as an Interface ID . >>>>>>>> . . 11 >>>>>>>> 2.9. Segment Type K - SRv6 END.X SID as an Interface >>>>>>>> Address . . . . . . . . . . . . . . . . . . . . . . >>>>>>>> . . >>>>>>>> 12 >>>>>>>> >>>>>>>> Original list in Section 2: >>>>>>>> Type A: SR-MPLS Label >>>>>>>> Type B: SRv6 SID >>>>>>>> Type C: IPv4 Prefix with optional SR Algorithm >>>>>>>> Type D: IPv6 Global Prefix with optional SR Algorithm for SR- >>>>>>>> MPLS >>>>>>>> Type E: IPv4 Prefix with Local Interface ID >>>>>>>> Type F: IPv4 Addresses for link endpoints as Local, Remote >>>>>>>> pair >>>>>>>> Type G: IPv6 Prefix and Interface ID for link endpoints as >>>>>>>> Local, >>>>>>>> Remote pair for SR-MPLS >>>>>>>> Type H: IPv6 Addresses for link endpoints as Local, Remote >>>>>>>> pair >>>>>>>> for SR-MPLS >>>>>>>> Type I: IPv6 Global Prefix with optional SR Algorithm for >>>>>>>> SRv6 >>>>>>>> Type J: IPv6 Prefix and Interface ID for link endpoints as >>>>>>>> Local, >>>>>>>> Remote pair for SRv6 >>>>>>>> Type K: IPv6 Addresses for link endpoints as Local, Remote >>>>>>>> pair >>>>>>>> for SRv6 >>>>>>>> >>>>>>>> >>>>>>>> Perhaps the section titles of Section 2’s subsections should be >>>>>>>> updated as >>>>>> follows to match their descriptions in the ToC above (or vice >>>>>> versa (with the >>>>>> list in Section 2 being updated to match the styling in the >>>>>> original ToC))? >>>>>>>> >>>>>>>> For example, make the section titles be: >>>>>>>> 2.1. Segment Type C: IPv4 Prefix with Optional SR Algorithm >>>>>>>> 2.2. Segment Type D: IPv6 Global Prefix with Optional SR >>>>>>>> Algorithm for >>>>>> SR-MPLS >>>>>>>> 2.3. Segment Type E: IPv4 Prefix with Local Interface ID >>>>>>>> 2.4. Segment Type F: IPv4 Addresses for Link Endpoints as >>>>>>>> Local, >>>>>> Remote Pair >>>>>>>> 2.5. Segment Type G: IPv6 Prefix and Interface ID for Link >>>>>>>> Endpoints as >>>>>> Local, Remote Pair for SRMPLS >>>>>>>> 2.6. Segment Type H: IPv6 Addresses for Link Endpoints as >>>>>>>> Local, >>>>>> Remote Pair for SR-MPLS >>>>>>>> 2.7. Segment Type I: IPv6 Global Prefix with Optional SR >>>>>>>> Algorithm for >>>>>> SRv6 >>>>>>>> 2.8. Segment Type J: IPv6 Prefix and Interface ID for Link >>>>>>>> Endpoints as >>>>>> Local, Remote Pair for IPv6 >>>>>>>> 2.9. Segment Type K: IPv6 for Link Endpoints as Local, Remote >>>>>>>> Pair for SRv6 >>>>>>>> >>>>>>>> >>>>>>>> If this close of a relationship is not necessary/desired, it is >>>>>>>> fine to leave >>>>>> them as they are. >>>>>>>> >>>>>>>> KT2> I see your point. However, now that you bring this up, the >>>>>>>> KT2> section >>>>>> titles seem too long. How about we just have "Segment Type X" and >>>>>> then it >>>>>> would be consistent with https://www.rfc- >>>>>> editor.org/authors/rfc9830.html#section-2.4.4.2.1 as well and much >>>>>> shorter? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 7) <!-- [rfced] We note that Section 2.4.4.2.4 of [RFC9830] >>>>>>>>> uses the term >>>>>>>>> "SRv6 SID Endpoint Behavior and Structure" rather than >>>>>>>>> "SRv6 >>>>>>>>> Endpoint Behavior and SID Structure". Please let us know >>>>>>>>> if/how >>>>>>>>> these uses may be made consistent. >>>>>>>>> --> >>>>>>>>> >>>>>>>>> KT> I would prefer the latter, but then we'll also need to make >>>>>>>>> KT> it >>>>>>>>> KT> consistent in RFC9830 (e.g., >>>>>>>>> KT> https://www.rfc-editor.org/authors/rfc9830.html#section- >>>>>>>>> KT> 2.4.4. >>>>>>>>> KT> 2.4 ) >>>>>>>>> >>>>>>>> [rfced] We have updated to use the latter throughout this >>>>>>>> document and >>>>>> consistently throughout RFC-to-be 9830. Please review the use in >>>>>> both >>>>>> documents (as an author of each) and reply to each specific email >>>>>> thread >>>>>> with any further updates and/or approval of the changes. Note >>>>>> that we also >>>>>> changed some instances in which “or” was used instead of “and” to >>>>>> be “and” >>>>>> consistently. Please let us know if this was in error. >>>>>>>> >>>>>>>> KT2> The changes where the "or" was replaced by "and" are >>>>>>>> KT2> incorrect. In >>>>>> those cases, we mean that when either the "SRv6 Endpoint Behavior" >>>>>> or "SID >>>>>> Structure" then the SID can be set to 0. Please revert that >>>>>> change. The rest >>>>>> looks good to me. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 8) <!--[rfced] Please review the entries in Table 1 in light of >>>>>>>>> this response >>>>>> regarding the names of sub-TLVs from Ketan when we discussed this >>>>>> topic for >>>>>> RFC-to-be 9830: >>>>>>>>> >>>>>>>>> Ketan: >>>>>>>>> "The names of the segments (titles) are to be "Segment Type X" >>>>>>>>> while >>>>>> the name of the sub-TLVs are to be "Type X Segment sub-TLV" (I've >>>>>> seen both >>>>>> sub-TLV and Sub-TLV - either is OK but we should have been >>>>>> consistent). The >>>>>> "Type-1" is actually "Type A Segment sub-TLV"." >>>>>>>>> >>>>>>>>> If updates are necessary to the corresponding IANA registry, we >>>>>>>>> will communicate them on your behalf once AUTH48 concludes. >>>>>>>>> >>>>>>>>> KT> Yes, please apply the same to this document as well for >>>>>>>>> KT> consistency. However, I notice that the IANA sections in >>>>>>>>> KT> both >>>>>>>>> KT> 9830 and 9831 are not matching the sub-TLV names. Could you >>>>>>>>> KT> please fix that? >>>>>>>>> KT> https://www.rfc-editor.org/authors/rfc9830.html#section-6.5 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> —> >>>>>>>> [rfced] We have made the necessary updates to Table 1 and will >>>>>> communicate these changes to IANA once AUTH48 completes. >>>>>>>> >>>>>>>> With regard to RFC-to-be 9830: We believe you are referring to >>>>>>>> values 1 >>>>>> and 13 in Table 5 (of Section 6.5) and have updated the document >>>>>> and will >>>>>> communicate this change to IANA along with the changes to this >>>>>> document >>>>>> (once AUTH48 for RFC-to-be 9831 concludes). >>>>>>>> >>>>>>>> KT2> Correct. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> We ask again that you review the changes to RFC 9830 and >>>>>>>> communicate >>>>>> your approval or need for further updates in that email thread >>>>>> (for other >>>>>> authors’ benefit as well as the AUTH48 archive). >>>>>>>> >>>>>>>> KT2> Done. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ketan >>>>>>>> >>>>>>>> >>>>>>>> Any other changes have been incorporated as requested. Please >>>>>>>> review >>>>>> carefully as we do not make changes once the document is published >>>>>> as an >>>>>> RFC. >>>>>>>> >>>>>>>> The files have been posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9831.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9831.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9831.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9831.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here: >>>>>>>> https://www.rfc-editor.org/authors/rfc9831-diff.html >>>>>>>> (comprehensive) >>>>>>>> https://www.rfc-editor.org/authors/rfc9831-rfcdiff.html (side >>>>>>>> by >>>>>>>> side) >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48diff.html >>>>>>>> (AUTH48 >>>>>> changes only) >>>>>>>> https://www.rfc-editor.org/authors/rfc9831-auth48rfcdiff.html >>>>>>>> (side by side) >>>>>>>> >>>>>>>> The AUTH48 status page for this document can be found here: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9831 >>>>>>>> >>>>>>>> The relevant cluster information can be found here: >>>>>>>> https://www.rfc-editor.org/cluster_info.php?cid=C534 >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> RFC Editor/mf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
