Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

Mirja Kuehlewind <ietf@kuehlewind.net> Tue, 30 July 2019 16:33 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53E120120; Tue, 30 Jul 2019 09:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPs-JYtvp8Qs; Tue, 30 Jul 2019 09:33:20 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41DC7120089; Tue, 30 Jul 2019 09:33:20 -0700 (PDT)
Received: from 200116b82cf82f009860c8f8757e3ab5.dip.versatel-1u1.de ([2001:16b8:2cf8:2f00:9860:c8f8:757e:3ab5]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hsV3t-0007Zj-06; Tue, 30 Jul 2019 18:33:17 +0200
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>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1564504400;0ab85e85;
X-HE-SMSGID: 1hsV3t-0007Zj-06
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?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 16:33:23 -0000

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:
> 
> Alvaro:
>  
> On #3, I’ve not seen the separate thread you’ve started with the authors.  Did I miss something as the shepherd? 
>  
> On #2, the Discussion from the WG (over long period of time) suggested that this exact statement was not clearly stated in RFC4271.   
>  
> 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? 
>  
> Sue Hares
> Shepherd 
>  
>  
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Alvaro Retana
> Sent: Tuesday, July 30, 2019 10:39 AM
> To: Mirja Kühlewind; The IESG
> Cc: idr-chairs@ietf.org; draft-ietf-idr-bgp-extended-messages@ietf.org; idr@ietf.org
> Subject: Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)
>  
> On July 30, 2019 at 9:38:01 AM, Mirja Kühlewind via Datatracker (noreply@ietf.org) wrote:
>  
> Mirja:
>  
> Hi!
>  
> Thanks for your review.
>  
> ...
>> --------------------------------------------------------------------- 
>> COMMENT: 
>> ---------------------------------------------------------------------- 
>> 
>> Some comment on use of normative language: 
>> 
>> 1) I know what the intention is here but this normative language is not used correctly (sec 4): 
>> "A BGP speaker 
>> MAY send Extended Messages to a peer only if the Extended Message 
>> Capability was advertised by both peers." 
>> This should be a MUST anyway (and moving the "only"): 
>> "A BGP speaker 
>> MUST only send Extended Messages to a peer if the Extended Message 
>> Capability was advertised by both peers." 
>> Or you go for the MUST NOT (and maybe even two sentence) to make it crystal clear, e.g. 
>> "A BGP speaker 
>> MUST NOT send Extended Messages to a peer if the Extended Message 
>> Capability was not advertised by both peers. A BGP speaker 
>> MAY send Extended Messages to a peer if the Extended Message 
>> Capability was advertised by both peers." 
> 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’ve started a separate thread with the authors.
> 
>  
> 
>> 2) sec 4: 
>> "If a BGP message with a Length greater than 4,096 octets is received 
>> by a BGP listener who has not advertised the Extended Message 
>> Capability, the listener MUST treat this as a malformed message, and 
>> MUST generate a NOTIFICATION with the Error Subcode set to Bad 
>> Message Length (see [RFC4271] Sec 6..1)." 
>> If this is specified normatively in RFC4271, you should not use normative language here as well. 
>> I suggest s/MUST/will/ 
>> 
>> 3) sec 4: 
>> s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the neighbor/ 
>> and 
>> s/it must be withdrawn from service/it MUST be withdrawn from service/ 
> All the actions on these two points are in fact normatively specified in rfc4271 (which is the reason for the specific references)…so we should use non-Normative text in both cases.  
> 
> IOW: your point in #2 is accurate, but the changes suggested in #3 should not be applied.
> 
>  
> 
> Thanks!!
> 
> Alvaro.
> 
>  
> 
>> 4) sec 4 
>> "In an iBGP mesh, if BGP Extended Messages are to be advertized, all 
>> peers MUST advertize the BGP Extended Message capability." 
>> Which action(s) should be taken if that is not the case?