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

[Mirja Kuehlewind <[e-mail]>]

Hi Alvaro,

See below.

> On 30. Jul 2019, at 16:39, Alvaro Retana <[e-mail]> wrote:
> 
> 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.
> 
Ah, then I guess #3 should also be s/must/will/ …

Thanks for caring about this!

Mirja

> 
> 
> 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?