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

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to