Re: [YANG] key clause issues

[Andy Bierman <[e-mail]>]

Martin Bjorklund wrote:
> 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?
> 

The feature intent needs to be explained in the draft.
If a list has no key defined, then that means that
there is no distinction in the agent between any of
the entries, other than their relative position (foo[1], foo[2], etc.)

If this is true, and the manager knows that, then there is no
problem leaving out the key.  (Other DMLs call this multiple
instances of a container, not a list though).

But if the agent has some way of identifying list entries,
other than their relative position, then a key MUST be specified.
(Is this what the draft intends?)


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

Not true at all.  If the agent is using named entries
instead of position-identified entries, the manager needs to know.

Consider any XML table like the ifTable counters.
What if the agent has entries for interfaces 1, 2, and 3,
but after awhile, interface 2 is deleted.  If the agent
knows about 'ifIndex', but not the manager, how well do
you think the manager application will handle this common scenario?

Config vs. non-config is irrelevant here.
Identification via named keys or identification via node position
is the issue.


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

This table obviously cannot use the nested address.
By design, it uses separated fields.


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


The CLR is simple -- just like the use-case.
Only static container nodes can be listed as interior nodes
in a key.  All your fabricated cases below are invalid.
The key indicates the mandatory naming components for the list entry.
All key components MUST be present in every list entry.


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

This is really irrelevant in the context of standardization.
In other implementations (like mine) the position of the key
within the list element sub-tree is not a factor.

BTW, there is no text in the draft that says that the key components
must be defined first in the list.  In order to optimize the DML
design in favor of this implementation choice, the key components
can never be in reusable groupings (like address/port) and they
must always be the first leafs, defined in the same order as the key.

SMIv2 never had any massive CLRs like this for tables.
You can specify 'key' clauses in XSD for arbitrary nodes.

There is so much complexity in YANG wrt/ Xpath, local typedefs/groupings,
augments, that this hardly seems like an implementation burden
worthy of such drastic restrictions on data model design.


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


We need to understand what a key is, and when it is used.
A key identifies the static naming components so multiple
instances of a list node can be distinguished by an application.

I am not proposing that the key components be complex and/or non-static,
like you are, with this straw-man example.   It is not a CLR to
specify that key components must be static leafs.  This is
how SMIv2 works, and it should be how YANG works as well.

> 
> 
> /martin
> 
> 

Andy



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