Re: [netmod] [Technical Errata Reported] RFC8519 (5762)

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 25 June 2019 22:50 UTC

Return-Path: <mjethanandani@gmail.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 B65E31200D8 for <netmod@ietfa.amsl.com>; Tue, 25 Jun 2019 15:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9hAI5smWP1Ne for <netmod@ietfa.amsl.com>; Tue, 25 Jun 2019 15:50:44 -0700 (PDT)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 5D9B9120094 for <netmod@ietf.org>; Tue, 25 Jun 2019 15:50:44 -0700 (PDT)
Received: by mail-pf1-x42a.google.com with SMTP id x15so191767pfq.0 for <netmod@ietf.org>; Tue, 25 Jun 2019 15:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vRLnHLbuigN1RoBHJkocmENpfg9F9MxUYgyOfdCTdaM=; b=lfVrIfww5IwVnXP4CcJiRpDNWNtGHAUpa6i3zFa+mNfSQB6/mWRHmvVOWIGK9AcTYB bD5mXwqbX/R5X5FUHrdthcshOwDXrYUnPBh3vg9EsLjtsev1Vakrb9DvnsG2hMccxvtF E1HDlLF5+3XUHDCJ00UvW18uZY3uAdHYn4IY5MKoj6n8BS1v37Wqex/5KiVA/7cdppx4 B5qo3u+NW2asVjMIMfPeqWnNpbLC0TO2/PlOm2s3zweDgGQyZTzC1xTK/+GJTwqO1KcF LhYWQ9zBRmiOfcUjebE/50JCmZvKRr+n7lHpOnGYw+ZlKxTtjtK6AoAJicaG+R9LWJUv MtNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vRLnHLbuigN1RoBHJkocmENpfg9F9MxUYgyOfdCTdaM=; b=XCt2qACMchHq4SC5RJMuLnwsaosbfX19Pk3npXYLXiWxa67P+mHCiKUfU2v5c5ARhd GonPyD004NHSfEkxM/qbn1ZB/0n5zf0qGhmyO7re2XmqL4k/+K+IcGEsthGYiiRL8jHu fnIwRIVxzr8Bx4StY5SmUmVais6yPkRHRZGIV86W0JNEVcuv23rW7GuTJ2tlxV+Prmsx YA3LcXbnVtQE1pBxpwR/5zEWdinlmRBZoipi8fecfVTDbkRP/z23ro0M3IXYwx4EJnjt fJeAR2wggypWcSagCYpzmuO8Ze07nit8/MXuMRYCml1IWGypbomD8RQ2uWlRaTRxrKo4 Z9ZA==
X-Gm-Message-State: APjAAAXAp6hoYeMYtYpp3LMwpreZictAIklmB1s9hX2hVECWvomJozlu pYdoon1mHBI34spap+XdKTQ=
X-Google-Smtp-Source: APXvYqyQv0BtHVc0KPCyJjAH2RsIA67eR4yK5owbdq90iSgQ8b/1nzEKCDOgUKc4us50xLnoeM/+Kg==
X-Received: by 2002:a17:90a:ae12:: with SMTP id t18mr382973pjq.32.1561503043681; Tue, 25 Jun 2019 15:50:43 -0700 (PDT)
Received: from [10.33.123.154] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id r2sm27620220pfl.67.2019.06.25.15.50.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jun 2019 15:50:42 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <20190624035835.A751EB81C64@rfc-editor.org>
Date: Tue, 25 Jun 2019 15:50:41 -0700
Cc: Sonal Agarwal <sagarwal12@gmail.com>, Yi Huang <huangyi_99@yahoo.com>, dana@blairhome.com, Ignas Bagdonas <ibagdona@gmail.com>, Warren Kumari <warren@kumari.net>, joelja@bogus.com, Kent Watsen <kent+ietf@watsen.net>, Lou Berger <lberger@labn.net>, bill.wu@huawei.com, netmod@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <572CA971-312C-4EED-BB09-9D866FFDAD16@gmail.com>
References: <20190624035835.A751EB81C64@rfc-editor.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ec-LtQtJXoZTD6ApwVeDkNvVy0k>
X-Mailman-Approved-At: Tue, 25 Jun 2019 18:59:16 -0700
Subject: Re: [netmod] [Technical Errata Reported] RFC8519 (5762)
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, 25 Jun 2019 22:50:47 -0000

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.

> On Jun 23, 2019, at 8:58 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC8519,
> "YANG Data Model for Network Access Control Lists (ACLs)".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5762
> 
> --------------------------------------
> Type: Technical
> Reported by: Qin WU <bill.wu@huawei.com>
> 
> Section: 4.1
> 
> Original Text
> -------------
> leaf type {
> type acl-type;
> description
>  "Type of ACL.  Indicates the primary intended
>   type of match criteria (e.g., Ethernet, 
>   IPv4, IPv6, mixed, etc.) used in the list
>   instance.";
> }
> 
> Corrected Text
> --------------
> leaf type {
> type acl-type;
> default "ipv4-acl-type";
> description
>  "Type of ACL.  Indicates the primary intended
>   type of match criteria (e.g., Ethernet, 
>   IPv4, IPv6, mixed, etc.) used in the list
>   instance.";
> }
> 
> Notes
> -----
> 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.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8519 (draft-ietf-netmod-acl-model-21)
> --------------------------------------
> Title               : YANG Data Model for Network Access Control Lists (ACLs)
> Publication Date    : March 2019
> Author(s)           : M. Jethanandani, S. Agarwal, L. Huang, D. Blair
> Category            : PROPOSED STANDARD
> Source              : Network Modeling
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG

Mahesh Jethanandani
mjethanandani@gmail.com