[netmod] [Technical Errata Reported] RFC8519 (5762)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 24 June 2019 03:58 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 26E3F120033 for <netmod@ietfa.amsl.com>; Sun, 23 Jun 2019 20:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 3DeskmSvim27 for <netmod@ietfa.amsl.com>; Sun, 23 Jun 2019 20:58:38 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3557D120153 for <netmod@ietf.org>; Sun, 23 Jun 2019 20:58:36 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id A751EB81C64; Sun, 23 Jun 2019 20:58:35 -0700 (PDT)
To: mjethanandani@gmail.com, sagarwal12@gmail.com, huangyi_99@yahoo.com, dana@blairhome.com, ibagdona@gmail.com, warren@kumari.net, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: bill.wu@huawei.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190624035835.A751EB81C64@rfc-editor.org>
Date: Sun, 23 Jun 2019 20:58:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/HNP7Z8GHxrZ2-y_axbDqBkK4ydc>
X-Mailman-Approved-At: Tue, 25 Jun 2019 18:59:16 -0700
Subject: [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: Mon, 24 Jun 2019 03:58:40 -0000
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
- [netmod] [Technical Errata Reported] RFC8519 (576… RFC Errata System
- Re: [netmod] [Technical Errata Reported] RFC8519 … Mahesh Jethanandani
- Re: [netmod] [Technical Errata Reported] RFC8519 … Qin Wu
- Re: [netmod] [Technical Errata Reported] RFC8519 … Andy Bierman