> On Aug 22, 2025, at 3:22 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 is a good and needed update, and I support its adoption and prompt
progression.
I have a couple of minor comments:
1. I suggest this change, for clarity (second line is inserted, otherwise as
written):
OLD:
* If the BGP speaker is not attaching the community,
it MUST NOT send the community over external BGP
sessions. The BGP speaker SHALL remove the
community before announcing the corresponding route
over external BGP sessions.
NEW:
* If the BGP speaker is not attaching the community,
but instead is propagating it,
it MUST NOT send the community over external BGP
sessions. The BGP speaker SHALL remove the
community before announcing the corresponding route
over external BGP sessions.
2. I don’t think it’s necessary to add "the Early IANA Allocation process
defined in [RFC7120]” — that process applies regardless of whether it’s called
out or not, it’s automatically applicable to any Standards Action registry.
It’s not a big deal, the clause is not wrong, but I admire Antoine de
Saint-Exupéry’s maxim that “Perfection is achieved, not when there is nothing
more to add, but when there is nothing left to take away.”
$0.02, and thanks for doing this work,
—John
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
