Re: [YANG] key clause issues

Phil Shafer wrote:
> 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.

Then the concept is correct and the text is wrong.
The intent is:
All config lists must have named entries and therefore must a key.
A non-config list must have a key if it has named entries,
otherwise the non-config list has only position-identified entries.

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

I didn't mean the agent -- I meant the DM writer.

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

Good -- we just need to make the text more clear

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

Fine -- leave this CLR in the draft.  Just explain why it is needed.

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

IMO, the 'my implementation uses more memory' argument
is really weak to justify huge CLRs that are
more restrictive than SMIv2 tables.

The draft does not force all the key components to be first.
That means that an agent implementation has to buffer NETCONF PDUs
that contain non-key nodes (deep or not) until all the key nodes
are received anyway.  What difference does it make if
the static key is 'foo' or 'foo/bar' or '/foo/bar/baz'.

I do not see the ability to index even 1 layer deep into a reusable
container as a weak use case.  Not every DM writer is going
to want to place every leaf at the same sibling level.
That is what SMIv2 has to offer, and it isn't good enough.

> 
> Thanks,
>  Phil
> 
> 

Abdy

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