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

"Susan Hares" <shares@ndzh.com> Tue, 30 July 2019 18:31 UTC

Return-Path: <shares@ndzh.com>
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 C4F5D1202BF; Tue, 30 Jul 2019 11:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HkMEA-y_8ZII; Tue, 30 Jul 2019 11:31:01 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 B93E41202C1; Tue, 30 Jul 2019 11:30:59 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.161.218;
From: "Susan Hares" <shares@ndzh.com>
To: "'Mirja Kuehlewind'" <ietf@kuehlewind.net>
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>
References: <156449387998.2643.18137174091685834097.idtracker@ietfa.amsl.com> <CAMMESsz6gDtk=CytjQPDRSPiWvRB0X-R4MP2fZeiTRH_Z-2c_w@mail.gmail.com> <003b01d546f2$ebf946f0$c3ebd4d0$@ndzh.com> <8545413E-768D-4764-939E-C4861B21344F@kuehlewind.net>
In-Reply-To: <8545413E-768D-4764-939E-C4861B21344F@kuehlewind.net>
Date: Tue, 30 Jul 2019 14:30:50 -0400
Message-ID: <00ae01d54704$ea34fc80$be9ef580$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHOmb0+S0HtjOtDEV+BauB+7nkX8wMOHf7uAhyMangCLHTV5qa2HJTA
Content-Language: en-us
X-Antivirus: AVG (VPS 190730-2, 07/30/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/IuL_YLacuHTu5zpsGEZdtbItYuE>
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 18:31:03 -0000

 Mirja:

Thank you for the email and for caring enough to ask the question.    As an co-author on RFC4271, I had my personal view on this topic.   As a chair, I listened to another opinion. 

I'll follow-up with Alvaro. 

Sue Hares 


-----Original Message-----
From: Mirja Kuehlewind [mailto:ietf@kuehlewind.net] 
Sent: Tuesday, July 30, 2019 12:33 PM
To: Susan Hares
Cc: Alvaro Retana; The IESG; 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)

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?