MIME-Version: 1.0
References: 
 <176107589259.922.7123160603901796938@dt-datatracker-675c8fd764-bsflw>
In-Reply-To: 
 <176107589259.922.7123160603901796938@dt-datatracker-675c8fd764-bsflw>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Wed, 19 Nov 2025 22:36:34 +0530
Message-ID: 
 <CAH6gdPyJ55853-UdL6RuDnHcd4nohMARY6JyeaCehXg_zZnarA@mail.gmail.com>
To: Deb Cooley <debcooley1@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000ed035d0643f59ac0"
Message-ID-Hash: S55UGDGJTPFFM3BH5BTO7HRPK4LKSMZB
CC: The IESG <iesg@ietf.org>, draft-ietf-idr-link-bandwidth@ietf.org,
 idr-chairs@ietf.org, idr@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BIdr=5D_Re=3A_Deb_Cooley=27s_No_Objection_on_draft-ietf-idr-link?=
 =?utf-8?q?-bandwidth-19=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/idr/IaGwPsH7gLTJoeRrbI1ney1RgD0>

--000000000000ed035d0643f59ac0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Deb Cooley via Datatracker <noreply=
@ietf.org>
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-positio=
ns/
> 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 t=
o
> 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 43=
60
> 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 priva=
te
> 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

--000000000000ed035d0643f59ac0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Deb,<div><br></div><div>I see that the=
 authors have not responded to your comments and so I will attempt to clari=
fy. The authors/WG should feel to respond/clarify.</div><div><br></div><div=
>Authors, please check for some suggested changes.</div><div><br></div><div=
>Please check inline below.</div><div><br></div></div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On We=
d, Oct 22, 2025 at 1:15=E2=80=AFAM Deb Cooley via Datatracker &lt;<a href=
=3D"mailto:noreply@ietf.org">noreply@ietf.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Deb Cooley has entered the fol=
lowing ballot position for<br>
draft-ietf-idr-link-bandwidth-19: No Objection<br>
<br>
When responding, please keep the subject line intact and reply to all<br>
email addresses included in the To and CC lines. (Feel free to cut this<br>
introductory paragraph, however.)<br>
<br>
<br>
Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/statement=
s/handling-ballot-positions/" rel=3D"noreferrer" target=3D"_blank">https://=
www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/</a> <b=
r>
for more information about how to handle DISCUSS and COMMENT positions.<br>
<br>
<br>
The document, along with other ballot positions, can be found here:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/"=
 rel=3D"noreferrer" target=3D"_blank">https://datatracker.ietf.org/doc/draf=
t-ietf-idr-link-bandwidth/</a><br>
<br>
<br>
<br>
----------------------------------------------------------------------<br>
COMMENT:<br>
----------------------------------------------------------------------<br>
<br>
Thanks to Ivaylo Petrov for their secdir review.<br>
<br>
Section 6, para 1:=C2=A0 This specification points to RFC 4360, which point=
s to RFC<br>
1997, which says that Security Issues are not discussed. I&#39;m guessing i=
t isn&#39;t<br>
that part of the RFC 4360 Sec Con section that is being referred?=C2=A0 RFC=
 4360<br>
does also have a short note on the need for a &#39;transitive trust relatio=
nship<br>
back to the source of the information&#39; and that the mechanism for that<=
br>
relationship is out of scope. If this concept is still an issue, perhaps it=
<br>
should be in &#39;Operational Considerations?<br></blockquote><div><br></di=
v><div>KT&gt; Looks like RFC4360 skimmed through reviews on this front. If =
it is any consolation, the IDR WG is working on RFC 4360bis and this commen=
t is better addressed there. I will drop a message to the authors of that d=
raft to point this out. That said, it seems not appropriate for this specif=
ic type of Extended Community to take the burden of security considerations=
 applicable to all extended communities in general. Does that work?</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Section 6, para 2: I am unfamiliar with how a policy can filter out private=
<br>
information.=C2=A0 But maybe this is clear to the users that will use the<b=
r>
specification.<br></blockquote><div><br></div><div>KT&gt; These are route p=
olicies common in all BGP implementations. The abilities vary based on impl=
ementations and allow for removal of specific types of extended communities=
 or all extended communities before route updates are sent to specific neig=
hbors. And yes, this should be clear to the users of this spec.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Section 7:=C2=A0 While I like sayings, I don&#39;t think it is quite the ri=
ght thing in<br>
a specification.=C2=A0 Please replace &#39;ships in the night&#39; phrase.<=
br></blockquote><div><br></div><div>KT&gt; How about:</div><div><br></div><=
div>CURRENT:=C2=A0<span style=3D"font-family:&quot;Noto Sans&quot;,Arial,He=
lvetica,sans-serif;font-size:14px">As a result, such implementations would =
treat the use of the other transitivity type in a &quot;ships in the night&=
quot; fashion.</span></div><div><br></div><div>SUGGEST:=C2=A0<span style=3D=
"font-family:&quot;Noto Sans&quot;,Arial,Helvetica,sans-serif;font-size:14p=
x">As a result, such implementations would ignore the other transitivity ty=
pe that=C2=A0they don&#39;t understand.</span></div><div><br></div><div>Tha=
nks,</div><div>Ketan</div><div><br></div></div></div>

--000000000000ed035d0643f59ac0--