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 >>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Didr_draft-2Dietf-2Didr-2Drfc4360-2Dbis&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=aA4LvJqHxTQVHX4BuMxr4ylT-OVoeP--MNCtTiw1BEg&e=> >>>>>> [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/ >>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dchairs-2Didr-2Drfc4360-2Dbis_&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=RsWS4MQQJQBvg31YK91w7KqUwmUR492AyXBTwhY74uw&e=> >>>>>> >>>>>> There is also an HTMLized version available at: >>>>>> https://datatracker.ietf.org/doc/html/draft-chairs-idr-rfc4360-bis-00 >>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dchairs-2Didr-2Drfc4360-2Dbis-2D00&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=V7Z_nufM6htxuC6g9hcYAkkpVQS-JyGNHK6Wm1Nuduy7mZoMhsd9pH2Tl1JJ59w8&s=bB2Do7F9QnSCpCWzWD7pnNgyfI_dNwSGpSCPEpFN6UU&e=> >>>>>> >>>>>> 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]
