[YANG] key clause issues

[Andy Bierman <[e-mail]>]

Hi,

I have a few concerns with the key clause...

 From -00:
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 which specifies a space separated list of leaf identifiers of
    this list.  A leaf identifier MUST NOT appear more than once in the
    key.

Issue 1)

   From an interoperability perspective, the key needs to
   be defined any time there are multiple named instances
   of an element (i.e., every list).  Config vs. read-only is irrelevant.
   Operators and manager applications need to know how list entries
   are indexed for interoperability.  SNMP is mostly for monitoring.
   I can't imagine how operators and DM readers would be able to talk about
   tables and rows if all the INDEX clauses were removed from read-only tables.

Issue 2)

   Why is the CLR about a leaf appearing more than once in the key needed?
   It should be up to the DM writer to decide if this makes sense or not:

    list addr-pairs {
      key "addr-type src-addr addr-type dest-addr";

      leaf addr-type { type ietf:InetAddressType; }
      leaf src-addr { type ietf:InetAddress; }
      leaf dest-addr { type ietf:InetAddress; }
      // ... rest of list entry
    }

    Why is this illegal?
    It may be bad practice (according to RFC 4001), but should it be illegal?

Issue 3)

 From the ABNF:

      key-stmt               = key-keyword sep key-arg-str stmtend

      key-arg-str            = < a string which matches the rule
                                 key-arg >

      key-arg                = 1*(identifier sep)


   Why is the key statement limited to top-level sibling nodes
   within the list?  The unique-stmt (and keyref) allows
   descendant-schema-nodeid instead of just identifier:

       unique "foo/item1 foo/bar/item2";

   With this constraint on the key-stmt, YANG cannot support
   indexing using reusable containers.  (There needs to be
   exactly one instance of the key component per list entry,
   so 'list' and 'choice' nodes cannot be used within a key.)

   There are many use-cases, such as reusable (addr-type, addr) or
   (addr, port) data types.  The whole point of the container
   is that it provides the DM writer with an abstraction that
   represents a containerized set of objects, bound together for some reason.

   YANG has no support direct support for reusable complex types,
   but there is a workaround with grouping/uses:

    grouping addr-pair {
      leaf addr-type { type ietf:InetAddressType; }
      leaf addr { type ietf:InetAddress; }
    }

    list addr-pairs {
      key "src/addr-type src/addr dest/addr-type dest/addr";

      container src {
        uses addr-pair;
      }

      container dest {
        uses addr-pair;
      }
      // ... rest of list entry
    }

   This sort of indexing is very useful and needs to be supported by YANG.


Andy




_______________________________________________
YANG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/yang