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

From: RFC Errata System <[email-masked]>
Date: Sun, 23 Jun 2019 20:58:35 -0700 (PDT)

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 <[email-masked]>

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 25 Jun 2019 15:50:41 -0700

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 <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 25 Jun 2019 19:08:49 -0700

> This errata should be rejected for the following reason.
This errata should be rejected because the Errata process cannot be used to
update a module.
The normal WG document process needs to be used instead.
 A new revision of the module is needed to add a default-stmt to a leaf.

Andy

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.
>
> > 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:
> > -------------
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>