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]> wrote: > Hi Robert, > > > On Aug 23, 2025, at 10:37 AM, Robert Raszuk <[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/ 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/ > > 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]> 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 > > > > Many Thanks! > > Nat > > > > On Sat, Aug 23, 2025 at 6:46 AM Robert Raszuk <[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]> > 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]> 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]> > 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]> > 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]> 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 > > [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] > >> Subject: I-D Action: draft-chairs-idr-rfc4360-bis-00.txt > >> Date: August 22, 2025 at 2:46:40 PM EDT > >> To: <[email protected]> > >> Reply-To: [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/ > >> > >> There is also an HTMLized version available at: > >> https://datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00 > >> > >> Internet-Drafts are also available by rsync at: > >> rsync.ietf.org::internet-drafts > >> > >> > >> _______________________________________________ > >> I-D-Announce mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > BESS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > Idr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > Idr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > > BESS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
