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

On Tue, Jun 25, 2019 at 6:59 PM Mahesh Jethanandani <mjethanandani@gmail.com>
wrote:

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