Re: [YANG] key clause issues

Andy Bierman writes:
>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.)

This is exactly what it's there for.  Some lists are position, and
no key is available and we want to avoid having to create one for
data that can't be manipulated individually.

A simple example would be syslog entries (or any list of events),
which consist of many non-unique leafs, having no unique key.

>If this is true, and the manager knows that, then there is no
>problem leaving out the key.

Yup, exactly.

>(Other DMLs call this multiple
>instances of a container, not a list though).

Isn't it cool that YANG got this right? ;^)

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

MUST?  It's the designer's data model.  Are we going to MUST them?
This is a CBAR.

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

Yup, and the lack of a key tells the manager that there's no key
for this list.

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

So the modeler will say "Hey! I have a key" and use the in their
data model.

>Config vs. non-config is irrelevant here.

Config vs. non-config is _very_ relevant because we explicitly do
not allow lists in config data to be non-keyed.  The need to
manipulate the data overrides the modeler's need to avoid keys.

>Identification via named keys or identification via node position
>is the issue.

The more important use case is where position (in the absolute)
simply doesn't matter.  Events in a syslog file may matter in
relative terms, but never in absolute terms even those numbers
are subject to change as files roll over and low priority events
are discarded.

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

I'm lost here.  Why would you ever need to list the leaf more than once?

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

It's funny which features trigger our individual "running with
scissors" sensors, but this one (deep keys) fires off mine.  I can
see a couple of fairly weak use cases, but the number of potential
abuses is overwhelming.  Someone's guaranteed to put their eye out
with deep keys.

Thanks,
 Phil

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang