[netmod] A few comments on draft-dbb-netmod-acl

[Qin Wu <[e-mail]>]

Hi, Oscar:
I have read the latest version of draft-dbb-netmod-acl, the problem statement and gap analysis are interesting, here are a few comments on this draft:
1.For problem statement in section 4.3 and section 4.5, I am wondering how  do you feel encrypted traffic at the transport layer, e.g., TLS layer or QUIC layer,
I feel it is hard, you might read one of presentation slides for IAB MTEN workshop, one gap we identify is ACL fall short to deal with encrypted traffic.
But for unencrypted traffic, yes, the ACL extension provide fine granularity access control.

2.For section 3.2, I feel the solution seems not complete, how defined set is used, in the match, it lack a example to explain how it is used.

3.For section 3.1, it is a good extension, but I understand the idea is to apply the same action to a set of prefixes, let's say two prefixes, since the destination-ipv6-network is defined as an array, I am wondering whether the action should be changes into 2 actions in an array:
   {
     "ietf-access-control-list:acls": {
       "acl": [
         {
           "name": "prefix-list-support",
           "type": "ipv6-acl-type",
           "aces": {
             "ace": [
               {
                 "name": "my-test-ace",
                 "matches": {
                   "ipv6": {
                     "destination-ipv6-network": [
                       "2001:db8:6401:1::/64",
                       "2001:db8:6401:c::/64"
                     ],
                     "source-ipv6-network":
                       "2001:db8:1234::/96",
                     "protocol": 17,
                     "flow-label": 10000
                   },
                 },
                 "actions": {
                   "forwarding": [ "accept","accept"]
                 }
               }
             ]
           }
         }
       ]
     }
   }
Maybe one alternative solution is to use template, if we want to Manipulate Lists of Prefixes

4.I feel flags defined in RFC9519 is confusing, how does the controller know which packet is the last fragment, which packet is not, which packet needs to be fragmented, which one not,the fragment action is controlled by the ingress node, configuring flags seems wrong to me.

5. For section 3.3 "Bind ACLs to Devices, Not Only Interfaces", do we have solution to this problem? If not, I think draft-ma-opsawg-ucl-acl-00 provide excatly the solution you are looking for if my understanding is correct, to address the limitation of IP address based access control, no need to tie to the specific interface of the device, or a single device.

-Qin