Merge pull request #87 from netmod-wg/Per-review

Per review

draft-ietf-netmod-acl-extensions.md

@@ -82,6 +82,10 @@ informative:
               -
                 name: IEEE
 
+   YANG-XSLT:
+              title: "iana-yang"
+              target: https://github.com/llhotka/iana-yang
+
 --- abstract
 
 RFC 8519 defines a YANG data model for Access Control Lists
@@ -110,13 +114,13 @@ individual Access Control Entries (ACEs) for each IP address (or prefix). In
 doing so, implementations would optimize the performance of matching
 lists vs multiple rules matching.
 
-The enhanced ACL structure ({{sec-module}}) is also meant to facilitate the management of
+The enhanced ACL structure ("ietf-acl-enh", {{sec-module}}) is also meant to facilitate the management of
 network operators. Instead of entering the IP address or port number
 literals, using user-named lists decouples the creation of the rule
 from the management of the sets. Hence, it is possible to remove/add
  entries to the list without redefining the (parent) ACL rule.
 
-In addition, the notion of Access Control List (ACL) and defined sets
+In addition, the notion of ACL and defined sets
 is generalized so that it is not device-specific as per {{!RFC8519}}.  ACLs
 and defined sets may be defined at network/administrative domain level
 and associated to devices. This approach facilitates the reusability across multiple
@@ -129,7 +133,7 @@ e.g., deny-lists or accept-lists that are associated with those provided by a
 
 Note that ACLs are used locally in devices but are triggered by other
 tools such as DDoS mitigation {{?RFC9132}} or BGP Flow Spec {{?RFC8955}}
-{{!RFC8956}}. Therefore, supporting means to easily map to the filtering rules conveyed in
+{{?RFC8956}}. Therefore, supporting means to easily map to the filtering rules conveyed in
 messages triggered by  these tools is valuable from a network operation standpoint.
 
 The enhanced ACL module ({{sec-module}}) conforms to the Network
@@ -138,7 +142,7 @@ Management Datastore Architecture (NMDA) defined in {{!RFC8342}}.
 A set of examples to illustrate the use of the enhanced ACL module are provided in {{sec-examples}}.
 
 The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. The design of the modules adheres to the recommendations
-in {{?I-D.ietf-netmod-rfc8407bis}}. The templates to generate the modules are available in {{template}}, {{v6-template}}, and {{iana-ipv6-ext-template}}. Readers should refer to the IANA websites {{IANA_ICMPv4_YANG_URL}}, {{IANA_ICMPv6_YANG_URL}}, and {{IANA_IPV6_YANG_URL}} to retrieve the latest version of these IANA-maintained modules.
+in {{Section 4.30.2 of ?I-D.ietf-netmod-rfc8407bis}}. The templates to generate the modules are available in {{template}}, {{v6-template}}, and {{iana-ipv6-ext-template}}. The templates use an XSLT stylesheet from the 'iana-yang' project {{YANG-XSLT}}. Readers should refer to the IANA websites {{IANA_ICMPv4_YANG_URL}}, {{IANA_ICMPv6_YANG_URL}}, and {{IANA_IPV6_YANG_URL}} to retrieve the latest version of these IANA-maintained modules.
 
 ## Editorial Note (To be removed by RFC Editor)
 
@@ -235,7 +239,7 @@ Clients that support both 'ipv4-fragment' and 'flags' {{!RFC8519}} matching fiel
 
 Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof.
 
-A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC {{?RFC9000}} or for tunneling protocols.
+A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC {{?RFC9000}} or for tunneling protocols. This feature requires configuring a data offset, a length, and a binary pattern to macth data against using a specified operator.
 
 ## Match on MPLS Headers
 
@@ -259,6 +263,7 @@ The augmented ACL structure ({{enh-acl-tree}}) allows an operator to configure A
 Being able to filter all packets that are bridged within a VLAN or that
 are routed into or out of a bridge domain is part of the VPN control
 requirements for Ethernet VPN (EVPN) {{?RFC7209}}.
+
 All packets that are bridged within a VLAN or that are routed into or
 out of a VLAN can be captured, forwarded, translated, or discarded based
 on the network policy.
@@ -283,7 +288,9 @@ the EVNP-PBB configuration.
 
 ## Additional Actions
 
-In order to support rate-limiting (see {{ps-rate}}), a new action called 'rate-limit' is defined in this document. Also, the "ietf-acl-enh" module supports new actions to complement existing ones: Log ('log-action') and write a counter ('counter-action'). The version of the module defined in this document supports only local actions.
+In order to support rate-limiting (see {{ps-rate}}), a new action called 'rate-limit' is defined in this document.
+
+Also, the "ietf-acl-enh" module supports new actions to complement existing ones: Log ('log-action') and write a counter ('counter-action'). The version of the module defined in this document supports only local actions.
 
 # Enhanced ACL YANG Module {#sec-module}
 
@@ -307,7 +314,14 @@ QUIC {{?RFC9000}}) and have to use mutual authentication.
 
 The Network Configuration Access Control Model (NACM) {{!RFC8341}} provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
 
-There are a number of data nodes defined in the "ietf-acl-enh" YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:
+There are a number of data nodes defined in this YANG module that are
+writable/creatable/deletable (i.e., "config true", which is the
+default).  All writable data nodes are likely to be reasonably
+sensitive or vulnerable in some network environments.  Write
+operations (e.g., edit-config) and delete operations to these data
+nodes without proper protection or authentication can have a negative
+effect on network operations. The following subtrees and data nodes
+have particular sensitivities/vulnerabilities:
 
  'defined-sets':
  : These lists specify a set of sets and aliases. Similar to {{!RFC8519}}, unauthorized write access to these
@@ -316,17 +330,20 @@ There are a number of data nodes defined in the "ietf-acl-enh" YANG module that
       be permitted.  The former may result in a DoS attack, or
       compromise a device.  The latter may result in a DoS attack.
 
-Some of the readable data nodes in the "ietf-acl-enh" YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:
+Some of the readable data nodes in this YANG module may be considered
+sensitive or vulnerable in some network environments.  It is thus
+important to control read access (e.g., via get, get-config, or
+notification) to these data nodes. Specifically, the following
+subtrees and data nodes have particular sensitivities/vulnerabilities:
 
  'defined-sets':
  : Unauthorized read access of these lists will allow
    an attacker to identify the actual resources that are bound
    to ACLs.
 
-The document defines a match policy based on a pattern that can be observed in a packet. For example, such a policy can be combined with header-based matches in the context of DDoS mitigation. Filtering based on a pattern match is deterministic for packets with unencrypted data. However, the efficiency for encrypted
-packets depend on the presence of an unvarying pattern.
+The document defines a match policy based on a pattern that can be observed in a packet. For example, such a policy can be combined with header-based matches in the context of DDoS mitigation. Filtering based on a pattern match is deterministic for packets with unencrypted data. However, the efficiency for encrypted packets depend on the presence of an unvarying pattern.
 
-The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-ipv6-ext-types defines" a set of types. These nodes are intended to be reused by other YANG
+The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-ipv6-ext-types" define a set of types. These nodes are intended to be reused by other YANG
 modules. Each of these modules by itself does not expose any data nodes that
 are writable, data nodes that contain read-only state, or RPCs.
 As such, there are no additional security issues related to
@@ -455,7 +472,7 @@ NEW:
 IANA is requested to create and post
 the initial version of the "iana-icmpv6-types" YANG module by
 applying the XSLT stylesheet from {{v6-template}} to the XML version of
-{{IANA-ICMPv4}}.
+{{IANA-ICMPv6}}.
 
 This document defines the initial version of the IANA-maintained
 "iana-icmpv6-types" YANG module.  The most recent version of the YANG module
@@ -523,7 +540,7 @@ is available from the "YANG Parameters" registry
 
 IANA is requested to add this note to the registry {{IANA-YANG-PARAMETERS}}:
 
-> New values must not be directly added to the "iana-ipv6-ext-types" YANG module.  They must instead be added to the "IPv6 Extension Header Types" registry {{IANA-ICMPv6}}.
+> New values must not be directly added to the "iana-ipv6-ext-types" YANG module.  They must instead be added to the "IPv6 Extension Header Types" registry {{IANA-IPv6}}.
 
 When a value is added to the "IPv6 Extension Header Types" registry, a new "enum" statement
 must be added to the "iana-ipv6-ext-types" YANG module.  The "enum" statement,
@@ -1085,9 +1102,9 @@ Thanks to Qiufang Ma, Victor Lopez, Joe Clarke, and Mahesh Jethanandani for the
 
 Thanks to Lou Berger for Shepherding the document.
 
-Thanks to David Black for the TSV review and Tim Wicinski for the intdir review.
+Thanks to David Black for the TSV review, Tim Wicinski for the intdir review, and Per Andersson for the yangdoctors review.
 
-The IANA-maintained modules were generated using an XSLT stylesheet from the 'iana-yang' project (https://github.com/llhotka/iana-yang).
+The IANA-maintained modules were generated using an XSLT stylesheet from the 'iana-yang' project {{YANG-XSLT}}).
 
 This work is partially supported by the European Commission under   Horizon 2020 Secured autonomic traffic management for a Tera of SDN
 flows (Teraflow) project (grant agreement number 101015857).

yang/enh-tree.txt

@@ -5,8 +5,8 @@ module: ietf-acl-enh
        +---u defined-sets
   augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
     +--rw (payload)?
-    |  +--:(prefix-pattern)
-    |     +--rw prefix-pattern {match-on-payload}?
+    |  +--:(pattern)
+    |     +--rw pattern {match-on-payload}?
     |        +---u payload-match
     +--rw (alias)?
     |  +--:(alias-name)

yang/groupings.txt

@@ -17,9 +17,9 @@
     +-- ttl-value?           uint8
   grouping payload-match:
     +-- offset?       identityref
-    +-- offset-end?   uint64
+    +-- length?   uint64
     +-- operator?     operator
-    +-- prefix?       binary
+    +-- pattern?       binary
   grouping alias:
     +-- vlan*         uint16
     +-- prefix*       inet:ip-prefix

yang/iana-icmpv4-types.xsl

@@ -63,8 +63,8 @@
 		  '(Deprecated)')),' ','')"/>
 	  </when>
 	  <otherwise>
-	    <value-of select="translate(normalize-space
-		    (iana:description),' ','')"/>
+           <value-of select="substring-before(translate(normalize-space
+                  (iana:description),' ',''),'suchasSeamoby')"/>  
 	  </otherwise>
 	</choose>
       </with-param>

yang/iana-icmpv4-types.yang

@@ -276,8 +276,7 @@ module iana-icmpv4-types {
         reference
           "RFC 2521";
       }
-      enum \
-ICMPmessagesutilizedbyexperimentalmobilityprotocolssuchasSeamoby {
+      enum ICMPmessagesutilizedbyexperimentalmobilityprotocols {
         value 41;
         description
           "ICMP messages utilized by experimental mobility protocols

yang/ietf-acl-enh.yang

@@ -391,7 +391,7 @@ module ietf-acl-enh {
       case explicit {
         leaf-list explicit-tcp-flag {
           type identityref {
-            base tcp-flag;
+            base acl-enh:tcp-flag;
           }
           description
             "An explicit list of the TCP flags that are to be
@@ -448,7 +448,7 @@ module ietf-acl-enh {
     }
     leaf label-position {
       type identityref {
-        base label-position;
+        base acl-enh:label-position;
       }
       description
         "Position of the label.";
@@ -495,14 +495,14 @@ module ietf-acl-enh {
       "Operations on payload match.";
     leaf offset {
       type identityref {
-        base offset-type;
+        base acl-enh:offset-type;
       }
       description
         "Indicates the payload offset. This will indicate
          the position of the data in packet to use for
          the match.";
     }
-    leaf offset-end {
+    leaf length {
       type uint64;
       units "bytes";
       description
@@ -515,7 +515,7 @@ module ietf-acl-enh {
       description
         "How to interpret the prefix match.";
     }
-    leaf prefix {
+    leaf pattern {
       type binary;
       description
         "The binary pattern to match against.";
@@ -934,7 +934,7 @@ module ietf-acl-enh {
     choice payload {
       description
         "Matches based upon a prefix pattern.";
-      container prefix-pattern {
+      container pattern {
         if-feature "match-on-payload";
         description
           "Indicates the rule to perform the payload-based match.";