Hello, I see the motivation for 4360-bis is to provide clarification for Transitivity. I would have picked this work up, but I’m glad to see Nat has already taken initiative for this. I’ll welcome him as editor for that. Would have liked to see Dan and Yakov comment on this, but we know they are not reachable now.
Thanks & Regards, srihari… Juniper Business Use Only From: Robert Raszuk <[email protected]> Date: Saturday, 23 August 2025 at 10:29 PM To: Acee Lindem <[email protected]> Cc: Nat Kao <[email protected]>, Enke Chen <[email protected]>, idr <[email protected]>, BESS <[email protected]>, Jeffrey Haas <[email protected]> Subject: [bess] Re: [Idr] Re: Working Group adoption check, RFC 4360-bis, ending 5 September, 2025. [External Email. Be cautious of content] Hey Acee, > So, it is possible to retain authors and contributors without IPR poll and > AUTH48 participation. Great news ! Thank you for sharing ... Hope IDR WG adopts this On Sat, Aug 23, 2025 at 6:23 PM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hi Robert, > On Aug 23, 2025, at 10:37 AM, Robert Raszuk > <[email protected]<mailto:[email protected]>> wrote: > > Hi Nat, > > What you are referring to was just some working snapshot. The ultimate > RFC5575bis was published as new RFC8955 > > https://datatracker.ietf.org/doc/rfc8955/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc8955/__;!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyWS0Eqpoo$> > with most of the original authors still listed. > > Those skilled in IETF process can comment if formal Contributors are required > to answer all the approval or IPR emails before publication or is there a way > to proxy such checks. Unfortunately that is the normal IETF process, but I was able to get around it by verifying that a couple of the authors of the RFC 5340 had truly discontinued IETF participation. https://datatracker.ietf.org/doc/rfc5340/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/rfc5340/__;!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyWERpfW6w$> So, it is possible to retain authors and contributors without IPR poll and AUTH48 participation. . Thanks, Acee > > Thx, > R. > > > > On Sat, Aug 23, 2025 at 1:09 PM Nat Kao > <[email protected]<mailto:[email protected]>> wrote: > Hi, All. > > Should we consider the format that existed in RFC5575-bis? > https://datatracker.ietf.org/doc/html/draft-hr-idr-rfc5575bis-00#section-13<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hr-idr-rfc5575bis-00*section-13__;Iw!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyWHkI6iSs$> > > Many Thanks! > Nat > > On Sat, Aug 23, 2025 at 6:46 AM Robert Raszuk > <[email protected]<mailto:[email protected]>> wrote: > Yup ! That would be fair. But then current IETF process needs an update in > respect to all of those emails from authors of anything which get's published. > > On Sat, Aug 23, 2025 at 12:43 AM Enke Chen > <[email protected]<mailto:[email protected]>> wrote: > Hi, Robert: > > Here is a simple idea: for "bis", make the author list accumulative *when* > there is a need for a new editor? > > Thanks. -- Enke > > > On Fri, Aug 22, 2025 at 3:27 PM Robert Raszuk > <[email protected]<mailto:[email protected]>> wrote: > Hi Enke, > > I hope this is and was the case here. > > But my point goes a bit further ... what if they do not want to reply to all > of the administrative emails IETF process requires to push any doc further ? > > And what if they moved to a different universe ? Should they be forgotten > just because we are doing a few sentences -bis on their work ? > > Thx, > R. > > > On Sat, Aug 23, 2025 at 12:18 AM Enke Chen > <[email protected]<mailto:[email protected]>> wrote: > As I recall, the original authors would be given an opportunity for the "bis" > in the past. Has there been a change to the practice? > > Thanks. -- Enke > > > On Fri, Aug 22, 2025 at 12:41 PM Robert Raszuk > <[email protected]<mailto:[email protected]>> wrote: > Hi Jeff and WGs, > > #1 > > Could you kindly elaborate how changing the definition of T bit in -bis draft > does address this scope: > > - Address the origination and reception of non-transitive routes across eBGP > boundaries. > > With that please kindly clarify up front what T bit of extended community has > to do with routes ? Then please explain what is the issue with current > definition of T bit in RFC4360 in respect to draft-ietf-bess-ebgp-dmz while > in the same time it does not collide in any way or form with > draft-ietf-idr-link-bandwidth (which is proceeding fine forward). > > #2 > > I am completely not comfortable to adopt this document. To me RFC4360 was > always very clearly written and in fact flexibility of having opaque > transitiveness across ASNs was a good feature not a bug. > > #3 > > I am against wiping out original authors of RFC4360 with just a few lines of > pretty much at best cosmetic changes ... replacing them with a single name - > even if such practice complies with IETF process (not sure if -bis is even > needed here). > > Network Working Group S. Sangli > Request for Comments: 4360 D. Tappan > Category: Standards Track Cisco Systems > Y. Rekhter > Juniper Networks > February 2006 > > > Kind regards, > Robert > > > > On Fri, Aug 22, 2025 at 9:23 PM Jeffrey Haas > <[email protected]<mailto:[email protected]>> wrote: > IDR, BESS, > > During the work driven by draft-ietf-idr-link-bandwidth, the issue of > originating non-transitive was brought up and partially discussed in the use > case work for draft-ietf-bess-ebgp-dmz. As discussed during IDR sessions at > IETFs 122 and 123, the preferred solution for addressing the ambiguities in > non-transitivity was to do a small -bis for RFC 4360. Nat Kao has kindly > agreed to be our editor to move this process along. This document, and issues > vs. it, will be managed in the IDR github.[1] > > Since this is IDR chair commissioned work to address this gap, it's our > intention to adopt this work. However, the chairs would like to provide a > review period to OBJECT to adoption. That said, if you'd like to offer > support for the work, or other technical comments, please do so in this > thread! > > This adoption check ends on 5 September. Please note this overlaps the US > Labor Day holiday and consider that in the timing of your request, in case > that's relevant. > > The scope of the commissioned work is: > > - Address open errata vs. RFC 4360 > - Address the origination and reception of non-transitive routes across eBGP > boundaries. > > The current text of the draft currently addresses these items. > > As part of reviewing this problem, the IETF archives show that there was > prior work covering this issue in draft-decraene-idr-rfc4360-clarification-00 > [2]. We've made sure to acknowledge those prior efforts in the -bis and > would request review from those authors on this -bis. > > -- Jeff (for the IDR Chairs) > > [1] > https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis<https://urldefense.com/v3/__https:/github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis__;!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyW8bKxQfE$> > [2] Bruno and company are to be commended for pressing this issue for several > years. While prior IDR mail threads seem to suggest "this works fine was the > answer", the fact that we had non-transitive behaviors as a point of > contention in the BESS LBW work means it's past time to enshrine fixing the > original criticisms in an RFC update. > >> Begin forwarded message: >> >> From: [email protected]<mailto:[email protected]> >> Subject: I-D Action: draft-chairs-idr-rfc4360-bis-00.txt >> Date: August 22, 2025 at 2:46:40 PM EDT >> To: <[email protected]<mailto:[email protected]>> >> Reply-To: [email protected]<mailto:[email protected]> >> >> Internet-Draft draft-chairs-idr-rfc4360-bis-00.txt is now available. >> >> Title: BGP Extended Communities Attribute >> Author: Nat Kao >> Name: draft-chairs-idr-rfc4360-bis-00.txt >> Pages: 13 >> Dates: 2025-08-22 >> >> Abstract: >> >> This document describes the "extended community" BGP-4 attribute. >> This attribute provides a mechanism for labeling information carried >> in BGP-4. These labels can be used to control the distribution of >> this information, or for other applications. >> >> This document obsoletes [RFC4360]. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-chairs-idr-rfc4360-bis/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-chairs-idr-rfc4360-bis/__;!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyWDTLob4M$> >> >> There is also an HTMLized version available at: >> https://datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00__;!!NEt6yMaO-gk!DnMCaDdg_S4rQ-MJ_TUgHpTpBVNiIBduKIyqQWkCwMOK-IN1_zo8tV7lLRaQ9OYDvBLVJZyWkMNkZlU$> >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list -- >> [email protected]<mailto:[email protected]> >> To unsubscribe send an email to >> [email protected]<mailto:[email protected]> > > _______________________________________________ > BESS mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> > _______________________________________________ > Idr mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]> > _______________________________________________ > Idr mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]> > _______________________________________________ > BESS mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
