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

["Susan Hares" <[e-mail]>]

 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:[e-mail]] 
Sent: Tuesday, July 30, 2019 12:33 PM
To: Susan Hares
Cc: Alvaro Retana; The IESG; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]> 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:[e-mail]] On Behalf Of Alvaro Retana
> Sent: Tuesday, July 30, 2019 10:39 AM
> To: Mirja Kühlewind; The IESG
> Cc: [e-mail]; 
> [e-mail]; [e-mail]
> 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 ([e-mail]) 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?