[Idr] Re: Paul Wouters' No Objection on draft-ietf-idr-link-bandwidth-19: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Paul,

Thanks for your review. I haven't seen the authors respond (though Jeff has
provided clarifications).

Please check inline below for specific responses to your comments and
suggestions for the authors to consider.

On Mon, Oct 20, 2025 at 10:51 PM Paul Wouters via Datatracker <
[e-mail]> wrote:

> Paul Wouters has entered the following ballot position for
> draft-ietf-idr-link-bandwidth-19: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>         The encoding of 4-octet ASN is out of scope of this document.
>
> I'm not sure why this sentence is here, as it just referred to the spec on
> longer ASN numbers on how that is done?
>

KT> Jeff has explained the background in detail. For the purpose of this
document, I would like to offer the following suggestion.

CURRENT: The encoding of the full four-octet ASNs is out of scope for this
document.

SUGGEST: The encoding of the full four-octet ASNs is not supported by the
Link Bandwidth Extended Community. Such a capability, should the
operational need for it arise, may be provided by a new BGP extension.



>
>
> What is a "ships in the night" fashion? Can this be rewritten to be more
> direct for people without nautical backgrounds? :)
>
>
KT> How about?

CURRENT: As a result, such implementations would treat the use of the other
transitivity type in a "ships in the night" fashion.

SUGGEST: As a result, such implementations would ignore the other
transitivity type that they don't understand.

Thanks,
Ketan