[netmod] [Errata Held for Document Update] RFC8519 (5908)

[RFC Errata System <[e-mail]>]

The following errata report has been held for document update 
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/eid5908

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Fanqiang Kong <[e-mail]>
Date Reported: 2019-11-14
Held by: Robert Wilton (IESG)

Section: section-4.1

Original Text
-------------
choice l2 {
              container eth {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:eth-acl-type')";
                if-feature "match-on-eth";
                uses pf:acl-eth-header-fields;
                description
                  "Rule set that matches Ethernet headers.";
              }
              description
                "Match Layer 2 headers, for example, Ethernet
                 header fields.";
            }

            choice l3 {
              container ipv4 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv4-acl-type')";
                if-feature "match-on-ipv4";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv4-header-fields;
                description
                  "Rule set that matches IPv4 headers.";
              }

              container ipv6 {
                when "derived-from-or-self(/acls/acl/type, "
                   + "'acl:ipv6-acl-type')";
                if-feature "match-on-ipv6";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv6-header-fields;
                description
                  "Rule set that matches IPv6 headers.";
              }
              description
                "Choice of either IPv4 or IPv6 headers";
            }

Corrected Text
--------------
choice l2 {
              container eth {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:eth-acl-type')";
                if-feature "match-on-eth";
                uses pf:acl-eth-header-fields;
                description
                  "Rule set that matches Ethernet headers.";
              }
              description
                "Match Layer 2 headers, for example, Ethernet
                 header fields.";
            }

            choice l3 {
              container ipv4 {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:ipv4-acl-type')";
                if-feature "match-on-ipv4";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv4-header-fields;
                description
                  "Rule set that matches IPv4 headers.";
              }

              container ipv6 {
                when "derived-from-or-self(../../../../type, "
                   + "'acl:ipv6-acl-type')";
                if-feature "match-on-ipv6";
                uses pf:acl-ip-header-fields;
                uses pf:acl-ipv6-header-fields;
                description
                  "Rule set that matches IPv6 headers.";
              }
              description
                "Choice of either IPv4 or IPv6 headers";
            }

Notes
-----
In access-list-control yang definition, the absolute path was used in when derived-from-or-self. This mean it will check all the type in configured acl lists one by one the return the first matched result (If there is any). For examples, I have acls acl acl_test1 configured, and type is set to ipv4-acl-type. Then if I create acl_test2 with ipv6-acl-type, when choice happened in acl_test2, it starts from acl_test1 because it's the first entry for acl list. Choice found there is ipv4-acl-type, then it chooses containter ipv4 rather than ipv6. This is not the correct behivour, it should choose ipv6 container because current acl type is ipv6-acl-type.
I think it should only check the current acl type not the whole acl list. So I changed it to relevant path only match the type field in current acl.
Please review my change and corret me if my understanding is not match your design.
If you need more information, please contact me directly.

AD Note: I agree that the errata is valid, but we cannot update a YANG module revision through the errata process, hence I've moved this errata to "Held for Document Update" so that it can be fixed by publishing a new revision of the YANG module.

--------------------------------------
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