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

[Ketan Talaulikar <[e-mail]>]

Hi Deb,

I see that the authors have not responded to your comments and so I will
attempt to clarify. The authors/WG should feel to respond/clarify.

Authors, please check for some suggested changes.

Please check inline below.


On Wed, Oct 22, 2025 at 1:15 AM Deb Cooley via Datatracker <[e-mail]>
wrote:

> Deb Cooley 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:
> ----------------------------------------------------------------------
>
> Thanks to Ivaylo Petrov for their secdir review.
>
> Section 6, para 1:  This specification points to RFC 4360, which points to
> RFC
> 1997, which says that Security Issues are not discussed. I'm guessing it
> isn't
> that part of the RFC 4360 Sec Con section that is being referred?  RFC 4360
> does also have a short note on the need for a 'transitive trust
> relationship
> back to the source of the information' and that the mechanism for that
> relationship is out of scope. If this concept is still an issue, perhaps it
> should be in 'Operational Considerations?
>

KT> Looks like RFC4360 skimmed through reviews on this front. If it is any
consolation, the IDR WG is working on RFC 4360bis and this comment is
better addressed there. I will drop a message to the authors of that draft
to point this out. That said, it seems not appropriate for this specific
type of Extended Community to take the burden of security considerations
applicable to all extended communities in general. Does that work?


>
> Section 6, para 2: I am unfamiliar with how a policy can filter out private
> information.  But maybe this is clear to the users that will use the
> specification.
>

KT> These are route policies common in all BGP implementations. The
abilities vary based on implementations and allow for removal of specific
types of extended communities or all extended communities before route
updates are sent to specific neighbors. And yes, this should be clear to
the users of this spec.


>
> Section 7:  While I like sayings, I don't think it is quite the right
> thing in
> a specification.  Please replace 'ships in the night' phrase.
>

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