Re: [Idr] Document shepherd review for draft-ietf-idr-rfc7752bis

[Jeffrey Haas <[e-mail]>]

Ketan,

On Wed, Nov 10, 2021 at 08:56:00AM +0000, Ketan Talaulikar (ketant) wrote:
> > A critical detail is you've added "A BGP-LS Consumer would need the ability to merge..." and we're not asking routers carrying this information to do the work.
> [KT] Yes, that is correct. This distinction and boundary between the "BGP protocol module" and "BGP-LS Consumer module" is precisely why we've introduced these terminologies and clarifications in Sec 3. IIRC (it been a few years now), this was one of the key inputs that I got from Alvaro for this bis.

I'll spend some time hopefully today to try to re-read sections 3 and 7.2.

> > 447	   The TLVs within the BGP-LS Attribute MAY be ordered in ascending
> > 448	   order by TLV type.  BGP-LS Attribute with unordered TLVs MUST NOT be
> > 449	   considered malformed.
> > 
> > Probably "SHOULD be ordered"?  If it's MAY be ordered and MUST NOT be malformed, why mention it at all?
> > [KT] I am happy to drop both the sentences. The current text is more to clarify given the ambiguity in this regards in RFC7752.
> 
> I'd suggest leaving it and update to SHOULD.  Reinforcing that unordered isn't malformed will likely save us implementations that didn't deal with that.
> [KT] Just to be confirm - you are saying  "SHOULD be ordered; if not then MUST NOT be considered malformed" - if so, that sounds good to me.

That's the suggestion.

> > It'd be helpful to clarify that these are features from the OSPF protocol but that the code points are not defined within OSPF - or at least what OSPF code point feature they're intended to cover.
> [KT] How about the following?
> 
> s/ The OSPF Route Type field values are defined in the OSPF protocol and can be one of the following: / The OSPF Route Type field follows the route types defined in the OSPF protocol and can be one of the following:

That would clarify the point.

-- Jeff