From nobody Fri Oct 2 13:57:45 2020 Return-Path: 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 BB3903A16DA; Fri, 2 Oct 2020 13:57:44 -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 JIE-AkusDagc; Fri, 2 Oct 2020 13:57:43 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 CC48F3A16D8; Fri, 2 Oct 2020 13:57:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.164.118; From: "Susan Hares" To: "'Christoph Loibl'" , "'John Scudder'" Cc: "'Robert Raszuk'" , "'Jakob Heitz \(jheitz\)'" , "'idr@ietf. org'" , , References: <303E54F6-833A-4458-B3E6-DE90E7CA121B@juniper.net> <22341_1601052988_5F6E213C_22341_268_1_53C29892C857584299CBF5D05346208A48F82C17@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <3366_1601300732_5F71E8FC_3366_6_3_53C29892C857584299CBF5D05346208A48F86028@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <21B4E52C-38F4-4C94-985C-8C1DF88F4A92@juniper.net> <57A5696C-4AD1-46E3-85C8-21867D821A3D@juniper.net> <493732DD-ADAE-44F2-A5BE-2AE7FEAA3222@tix.at> <1A29EA15-3585-4F26-8AAC-BD926FA2CD17@ tix.at> In-Reply-To: <1A29EA15-3585-4F26-8AAC-BD926FA2CD17@tix.at> Date: Fri, 2 Oct 2020 16:57:32 -0400 Message-ID: <02d801d698fe$a6683290$f33897b0$@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: AQJFO/98nG4CXpcqgpkjUdeb0RRdigIhl7wCAmAFbBACjYZjawGNusElAavd4aUA2w2+NQKIG+yUAJ6HCjABzify9wFzYpbRAXGVW7cA18zMzQEj13S7AoyDjIGn602JIA== Content-Language: en-us X-Antivirus: AVG (VPS 201001-2, 10/01/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] [BULK] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth fixing? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 20:57:45 -0000 John =20 =20 On Tuesday 9/29/2020, Christoph sent this request to confirm these are = the changes for the document.=20 The only other changes suggested was a clarification to:=20 4.2.2.12 Type 12 - Fragment Old text:=20 / IsF - Is a fragment - match if [RFC0791] IP Header Fragment Offset is not 0 / New text:=20 IsF - Is a fragment other than the first - match if [RFC0791] IP = Header Fragment Offset is not 0 / Please confirm that we have all the changes between these two.=20 I think it time to close this discussion. Christoph has agreed up = provided an updated draft (-27) so the RFC editor can published the = document.=20 The rest of the issues point up the need to begin Flow-spec v2 with TLV = and other improvements.=20 Thank you, Sue=20 -----Original Message----- From: Christoph Loibl [mailto:c@tix.at]=20 Sent: Tuesday, September 29, 2020 2:04 PM To: John Scudder Cc: Robert Raszuk; Jakob Heitz (jheitz); idr@ietf. org; = draft-ietf-idr-rfc5575bis@ietf.org; bruno.decraene@orange.com; Hares = Susan Subject: Re: [BULK] [Idr] [BULK] Bug in draft-ietf-idr-rfc5575bis, worth = fixing? Hi all, > On 29.09.2020, at 17:42, John Scudder wrote: > (Co-chair hat is on) >=20 > 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. >=20 > Thanks, >=20 > =E2=80=94John 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=20 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:=20 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 --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at