Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <003b01d546f2$ebf946f0$c3ebd4d0$@ndzh.com>
Date: Tue, 30 Jul 2019 18:33:16 +0200
Cc: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>,
 idr-chairs@ietf.org, draft-ietf-idr-bgp-extended-messages@ietf.org,
 idr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8545413E-768D-4764-939E-C4861B21344F@kuehlewind.net>
References: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com>
 <CAMMESsz6gDtk=CytjQPDRSPiWvRB0X-R4MP2fZeiTRH_Z-2c_w@mail.gmail.com>
 <003b01d546f2$ebf946f0$c3ebd4d0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mrIv_oDkN3JrRGYsnJJ67ucUBts>
Subject: Re: [Idr] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?=
 =?utf-8?q?etf-idr-bgp-extended-messages-33=3A_=28with_COMMENT=29?=
Precedence: list

Hi Susan,

These are only comments from my side (no discusses), so Alvaro can =
determine the right solution without me intervening. However, my =
personal view regarding #2 that if this is not clearly defined in =
RFC4271, the document should state that and update RFC4271 accordingly.

Mirja


> On 30. Jul 2019, at 18:22, Susan Hares <shares@ndzh.com> wrote:
>=20
> Alvaro:
> =20
> On #3, I=E2=80=99ve not seen the separate thread you=E2=80=99ve =
started with the authors.  Did I miss something as the shepherd?=20
> =20
> On #2, the Discussion from the WG (over long period of time) suggested =
that this exact statement was not clearly stated in RFC4271.  =20
> =20
> Given that point, we allowed the normative case.  It is a judgment =
case.  Do you want to engage in an argument pro/con with Mirja on the WG =
list or do you want to determine at AD level that the text should be =
non-normative?=20
> =20
> Sue Hares
> Shepherd=20
> =20
> =20
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alvaro Retana
> Sent: Tuesday, July 30, 2019 10:39 AM
> To: Mirja K=C3=BChlewind; The IESG
> Cc: idr-chairs@ietf.org; =
draft-ietf-idr-bgp-extended-messages@ietf.org; idr@ietf.org
> Subject: Re: [Idr] Mirja K=C3=BChlewind's No Objection on =
draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
> =20
> On July 30, 2019 at 9:38:01 AM, Mirja K=C3=BChlewind via Datatracker =
(noreply@ietf.org) wrote:
> =20
> Mirja:
> =20
> Hi!
> =20
> Thanks for your review.
> =20
> ...
>> ---------------------------------------------------------------------=20=

>> COMMENT:=20
>> =
----------------------------------------------------------------------=20=

>>=20
>> Some comment on use of normative language:=20
>>=20
>> 1) I know what the intention is here but this normative language is =
not used correctly (sec 4):=20
>> "A BGP speaker=20
>> MAY send Extended Messages to a peer only if the Extended Message=20
>> Capability was advertised by both peers."=20
>> This should be a MUST anyway (and moving the "only"):=20
>> "A BGP speaker=20
>> MUST only send Extended Messages to a peer if the Extended Message=20
>> Capability was advertised by both peers."=20
>> Or you go for the MUST NOT (and maybe even two sentence) to make it =
crystal clear, e.g.=20
>> "A BGP speaker=20
>> MUST NOT send Extended Messages to a peer if the Extended Message=20
>> Capability was not advertised by both peers. A BGP speaker=20
>> MAY send Extended Messages to a peer if the Extended Message=20
>> Capability was advertised by both peers."=20
> This point (and your last one) should be clarified in light of =
clarifications to rfc5492 (Capabilities Advertisement) that were =
discussed in Montreal last week.  I=E2=80=99ve started a separate thread =
with the authors.
>=20
> =20
>=20
>> 2) sec 4:=20
>> "If a BGP message with a Length greater than 4,096 octets is received=20=

>> by a BGP listener who has not advertised the Extended Message=20
>> Capability, the listener MUST treat this as a malformed message, and=20=

>> MUST generate a NOTIFICATION with the Error Subcode set to Bad=20
>> Message Length (see [RFC4271] Sec 6..1)."=20
>> If this is specified normatively in RFC4271, you should not use =
normative language here as well.=20
>> I suggest s/MUST/will/=20
>>=20
>> 3) sec 4:=20
>> s/then it must NOT be sent to the neighbor/then it MUST NOT be sent =
to the neighbor/=20
>> and=20
>> s/it must be withdrawn from service/it MUST be withdrawn from =
service/=20
> All the actions on these two points are in fact normatively specified =
in rfc4271 (which is the reason for the specific references)=E2=80=A6so =
we should use non-Normative text in both cases. =20
>=20
> IOW: your point in #2 is accurate, but the changes suggested in #3 =
should not be applied.
>=20
> =20
>=20
> Thanks!!
>=20
> Alvaro.
>=20
> =20
>=20
>> 4) sec 4=20
>> "In an iBGP mesh, if BGP Extended Messages are to be advertized, all=20=

>> peers MUST advertize the BGP Extended Message capability."=20
>> Which action(s) should be taken if that is not the case?