[YANG] deep keys and unique statements

[Andy Bierman <[e-mail]>]

Hi,

I share Ladislav's concern that YANG requires all key components
to be leafs at the very top-level within the list.

IMO, there is no harm or massive complexity introduced if
a key leaf is allowed to be nested within N containers.
A key must be mandatory, and have only one instance per list entry,
therefore nested lists or choices cannot contain key leafs.

This 'container only' is not a CLR -- just the properties of a key.
The implementation burden of buffering input does not seem
that important, since key leafs can appear anywhere in list,
and there may be a lot of XML-on-the-wire before the key leaf
shows up.  Key components do not have to be used in 'XML order'
either, which also requires buffering to support.

On the other hand, the unique-stmt allows arbitrary combinations
of leaf instances anywhere within the list.  The complexity
built into the unique-stmt is extensive, as even a 2-d table shows:


   list foo {
     // all nodes except the key leafs (x, c, d) are optional
     config true;
     key x;
     unique "y bar/a baz/e baz/c";

     list bar {
       config false;
       leaf a { type int32; }
       leaf b { type string; }
     }

     list baz {
       key "d c";
       leaf c { type float32; }
       leaf d { type float64; }
       leaf e { type binary; }
     }

     leaf x { type instance-identifier; }
     leaf y { type keyref { path "baz/c"; } }

   }


The agent has to check all the instances of all the leafs and only
enforce uniqueness in the entries that are complete.  One missing
optional leaf, and the entire unique-stmt is ignored instead (for that
entry).

Besides this unbounded complexity, it seems very odd for
the leafs within the nested lists (bar and baz) to have
uniqueness constraints placed 'from above', since they are
not required to be unique within the list that defines the leafs.

It also seems broken that config and non-config leafs can be
combined in the uniqueness test.  The 'config' and 'unique'
statements are not relevant in notification data, so is it
an error or just no-op if they are entered for notification
data-def-stmts?  (Could be from uses expansion as well.)
(Note that keyref adds an indirection twist to the complexity.)

Andy




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