[netmod] Open Errata 5762 rfc 8519 https://www.rfc-editor.org/errata/eid5762

Joel Jaeggli <joelja@bogus.com> Tue, 24 September 2019 06:35 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0395C120119 for <netmod@ietfa.amsl.com>; Mon, 23 Sep 2019 23:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ggOHi1spWY5U for <netmod@ietfa.amsl.com>; Mon, 23 Sep 2019 23:35:08 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F80120115 for <netmod@ietf.org>; Mon, 23 Sep 2019 23:35:08 -0700 (PDT)
Received: from [192.168.0.107] (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id x8O6Z0ki085329 for <netmod@ietf.org>; Tue, 24 Sep 2019 06:35:07 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be [192.168.0.107]
From: Joel Jaeggli <joelja@bogus.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E24DAF8-E349-47AB-B3E5-80B663916169"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <4C06B86E-8EC7-4DD0-867B-9FAFEE0F4B9C@bogus.com>
Date: Mon, 23 Sep 2019 23:34:53 -0700
To: NETMOD Working Group <netmod@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/spA_b0wjAlzVZ4eF0eIHpeAY2do>
Subject: [netmod] Open Errata 5762 rfc 8519 https://www.rfc-editor.org/errata/eid5762
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Sep 2019 06:35:10 -0000

Qin wu wrote in the errata:


I am wondering why not set default value for acl-type,e.g., set default value as "ipv4-acl-type" otherwise, how to determine which field under which choice will be matched upon and which action should be taken on them if the opetional parameter type under acl list is not set.

Also I want to better understand why acl type is removed from key indexes of access list and keep it as optional parameter under acl list. One case I am thinking in my mind is we add a mixed Ethernet, IPv4, and IPv6 ACL entry when we already have Ethernet ACL entry,IPv4 ACL entry , we don't need to remove existing ethernet entry and existing IPv4 entry in the list ("aces") and create a new entry with mixed ethernet, IPv4, IPv6 ACL, instead, we just add a new identity called mixed-eth-ipv4-ipv6-acl-type and add a new IPv6 entry.

--------

Mahesh Jethanandani replied:

This errata should be rejected for the following reason.

The whole idea of defining the identities for acl-type was to allow vendors to specify what capabilities their box is capable of supporting and then to specify what capabilities the vendors want to support. As such there is no “default capability" for every vendor. Besides, if a device advertises a mixed-eth-ipv4 feature, it is because it can only support Ethernet and IPv4 ACL combinations, and it cannot support IPv6 ACL matches. You do not add a capability of IPv6 match on the fly. It either has it, or it does not. If it does, advertise mixed-eth-ipv4-ipv6 capability to begin with.

The errata proposes a change to the standard and is not correcting an error in the document.  additionaly it not clear why it would be appraise to set a default acl type.

The errata is declined.

Thanks
Joel