Re: [Idr] [BULK] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing?

[Christoph Loibl <[e-mail]>]

Hi all,



> On 29.09.2020, at 17:42, John Scudder <[e-mail]> wrote:
> (Co-chair hat is on)
> 
> Yes, agreed. This is not subject to re-litigation now, we are trying to clarify things if needed, but not change decisions that were made.
> 
> Thanks,
> 
> —John

Which brings me back to the point where this discussion started:


John suggested to extend that sentence from the doc:

OLD:

   A NLRI value not encoded as specified specified here is considered
   malformed and error handling according to Section 10
   is performed.


NEW:

   A NLRI value not encoded as specified here,
   including an NLRI that contains an unknown component type,
   is considered malformed and error handling according to 
   Section 10 is performed.


He also pointed out that a malformed NLRI (even when considering RFC7606) should lead to a session reset. If we want to make that even more clear (and based on all the discussion about opaque, non-opaque on the list (over months - if not years) this had very strong support) we can put it into the draft explicitly:

OLD: 
10.  Error Handling

   Error handling according to [RFC7606] and [RFC4760] applies to this
   specification.

   This document introduces Traffic Filtering Action Extended
   Communities.  Malformed Traffic Filtering Action Extended Communities
   in the sense of [RFC7606] Section 7.14. are Extended Community values
   that cannot be decoded according to Section 7 of this document.


NEW:
10.  Error Handling

   Error handling according to [RFC7606] and [RFC4760] applies to this
   specification. It needs to be pointed out that a malformed NLRI even
   when considering RFC7606 leads to a session reset.

   This document introduces Traffic Filtering Action Extended
   Communities.  Malformed Traffic Filtering Action Extended Communities
   in the sense of [RFC7606] Section 7.14. are Extended Community values
   that cannot be decoded according to Section 7 of this document.


I agree with the change since I want to make it as clear as possible, maybe someone can come up with a better solution/change to clarify what the WG already agreed on.

Cheers Christoph


-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at