YANG: how to model nested lists configuration data without key

Question

I am trying to build YANG model for this configuration file that has lists without keys. However, Due to the necessity of key in YANG list, I wasn't able to build exact YANG model. Is there any idea how to represents list of list without key in YANG.

The file includes acls in which there could be many acl like acl1, acl2 named by users and has rules as in the example below.

acls:
  acl1:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 1
  - rule:
      actions:
        allow: 0
  acl2:
  - rule:
      nw_src: 192.168.1.1/24  
      actions:
        allow: 0
  - rule:
      actions:
        allow: 1

My YANG model is

list acls{
     description "list of acls ";
      key "acl-name";
      ordered-by user;
      leaf acl-name {
        type string {
          length "1..64";
        }
      }
 list acle {
      description "This is a list of users in the system.";
      key "acle-name";
      ordered-by user;
      leaf acle-name {
        type string {
          length "1..64";
        }
        description
          "The name of access-list. A device MAY restrict the length
           and value of this name, possibly space and special
           characters are not allowed.";
      }

      container actions {
        description "actions for this acl entry ";    
        leaf allow {
          type uint8;
         }              
      } // end actions container       
   container match{
        description "match fields for this acl entry ";
    leaf nw_src{
         type inet:ipv4-address;
         }
    }
 }//match cont
 }//acle
} //acls

And hence the corresponding valid data file has extra fields that are necessary for YANG but not exist in my original configuration file above like (aclname, acle, aclename).

acls:
  acl1:
    aclname: acl1
    acle:
      rule11:
        aclename: rule11
        nw_src: 192.168.1.1/24
        actions:
          allow: 1
      rule12:
        aclename: rule12
        actions:
          allow: 0
  acl2:
    aclname: acl2
    acle:
      rule21:
        nw_src: 192.168.1.1/24    
        aclename: rule21
        actions:
          allow: 0
      rule22:
        aclename: rule22
        actions:
          allow: 1

Answer 1

RFC7950, 7.8.2. The list's "key" Statement

The "key" statement, which MUST be present if the list represents configuration and MAY be present otherwise, takes as an argument a string that specifies a space-separated list of one or more leaf identifiers of this list. A leaf identifier MUST NOT appear more than once in the key. Each such leaf identifier MUST refer to a child leaf of the list. The leafs can be defined directly in substatements to the list or in groupings used in the list.

The combined values of all the leafs specified in the key are used to uniquely identify a list entry. All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. Any "mandatory" statements in the key leafs are ignored.

Lists that model configuration data (whether nested or not) must have a key. There is no way around this, because each configuration list instance must be uniquely identifiable, so that constructs like instance-identifiers work as expected. You would have a hard time telling a device to modify (or even simply obtain) a specific entry in your configuration, if there were no keys. What you are proposing to do is therefore not achievable - it is not the YANG way of things.

Only state data (config false;) lists may exist without keys because they do not have to be modified in a standard way - their instantiation/modification/removal is governed by implementation details of a device.

Besides, you are already using keys in your example. The "acl1" and "acl2" are clearly instances of an "acl" list, which have their key encoded into their name.