RFC Errata
Found 4 records.
Status: Verified (2)
RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019
Source of RFC: netmod (ops)
Errata ID: 7312
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12
Section A.1 says:
The "example-newco-acl" module is an example of a company's proprietary model that augments the "ietf-acl" module. It shows how to use 'augment' with an XML Path Language (XPath) expression to add additional match criteria, actions, and default actions for when no ACE matches are found. All these are company proprietary extensions or system feature extensions. "example-newco-acl" is just an example, and it is expected that vendors will create their own proprietary models.
It should say:
The "example-newco-acl" module is an example of a company's proprietary model that augments the "ietf-access-control-list" module. It shows how to use 'augment' with an XML Path Language (XPath) expression to add additional match criteria, actions, and default actions for when no ACE matches are found. All these are company proprietary extensions or system feature extensions. "example-newco-acl" is just an example, and it is expected that vendors will create their own proprietary models.
Notes:
There is no "ietf-acl" module in the document.
Errata ID: 7313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2023-01-18
Verifier Name: Robert Wilton
Date Verified: 2024-01-12
Section A.1 says:
The following figure is the tree diagram of example-newco-acl. In this example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ ietf-acl:matches are augmented with two new choices: protocol- payload-choice and metadata. The protocol-payload-choice uses a grouping with an enumeration of all supported protocol values. Metadata matches apply to fields associated with the packet, that are not in the packet header, such as overall packet length. In another example, /ietf-acl:acls/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ ietf-acl:actions are augmented with a new choice of actions.
It should say:
The following figure is the tree diagram of example-newco-acl. In this example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches are augmented with two new choices: protocol-payload-choice and metadata. The protocol-payload-choice uses a grouping with an enumeration of all supported protocol values. Metadata matches apply to fields associated with the packet, that are not in the packet header, such as overall packet length. In another example, /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions are augmented with a new choice of actions.
Notes:
The prefix is "acl" not "ietf-acl"
==
module ietf-access-control-list {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
prefix acl;
...
==
Status: Held for Document Update (1)
RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019
Source of RFC: netmod (ops)
Errata ID: 5908
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fanqiang Kong
Date Reported: 2019-11-14
Held for Document Update by: Robert Wilton
Date Held: 2024-01-12
Section section-4.1 says:
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";
}
It should say:
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.
Status: Rejected (1)
RFC 8519, "YANG Data Model for Network Access Control Lists (ACLs)", March 2019
Source of RFC: netmod (ops)
Errata ID: 5762
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Qin WU
Date Reported: 2019-06-24
Rejected by: Joel Jaeggli
Date Rejected: 2019-09-24
Section 4.1 says:
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.";
}
It should say:
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.
--VERIFIER NOTES--
Mahesh Jethanandani replied:
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.
The errata proposes a change to the standard and is not correcting an error in the document. additionaly it not clear why it would be appraise to set a default acl type.
The errata is declined.