Re: [YANG] key clause issues

[Martin Bjorklund <[e-mail]>]

Hi Andy,

Andy Bierman <[e-mail]> wrote:
> 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).

Exactly what will not be interoperable by not having keys for
non-config data?

(One problem might be how to define access control.  W/o keys you
might have to fall back to generic XPath, which we want to avoid...)

>    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.

In SNMP, the INDEX is needed by the protocol.  Not so in NETCONF for
non-config data.


> 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";

What does this mean?  What is the difference between this and:

        key "addr-type src-addr dest-addr";

What does an instance identifier for your example look like?


> Issue 3)
>    Why is the key statement limited to top-level sibling nodes
>    within the list?

Several reasons.  Have you seen any CLIs with arbitrarly deep keys?
(is it really needed?)

What does this mean:

   list foo {
     key "a/b/c";
     container a {
        container b {
           precense "...";
	   leaf c;
        }
     }
               
Or this:

   list foo {
     key "a/b/c";
     container a {
        list b {
           ...
	   leaf c;
        }
     }

Or this:

   list foo {
     key "a/b";
     container a {
        choice x {
	   leaf b;
	   leaf c;
        }
     }
  

Also, by allowing deep keys, you force an agent implementation to do
buffering of - in the worst case - the entire configuration.  You
influence the protocol characteristics to the worse.  W/o deep keys
implementations _can_ do minimal buffering, and thus make the NETCONF
protocol usable in smaller devices.  I know at least three
implementations that work this way today (and I know one that does
buffering).

>    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.)

I can also argue that this is an CLR.  Why don't you allow:

   list foo {
      key address;
      container address {
         choice type {
            leaf ipv4address;
            leaf ipv6address;
            leaf name;
         };
         leaf port;
      }
   }



/martin


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