Re: [YANG] key clause issues

[Martin Bjorklund <[e-mail]>]

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

I dont't follow.  How does it matter to interoperability if the agent
has some way of identifying list entries?  Which protocol operation
will suffer?


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

ifIndex is a leaf that the manager knows about, and so does the
agent.  What will not work well?

[I am playing the devil's advocate here.  I would be perfectly happy
with keys for non-config data as well.]

Ah, now I remember the other reason.  If I use a list in an rpc or
notification, do I still need to have a key?
  
> 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.

You lost me again.  What does nested address have to do with the
single-occurance of leaf in the key?

I still don't understand what the key above actually is supposed to
mean.

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

[...]

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

Is it?  Even XSD puts restrictions on the XPath used in keys "In order
to reduce the burden on implementers, in particular implementers of
streaming processors"
[http://www.w3.org/TR/xmlschema-1/#cIdentity-constraint_Definitions].

Wasn't one of the reasons for not doing XPath filtering only in
NETCONF that it would require more resources on the device?

If we get a YANG WG, I think it is very important the WG really
understands the implementation/resource implications of constructs
like this.

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

The keys don't have to be defined first.  They will be encoded first
in the XML.

> SMIv2 never had any massive CLRs like this for tables.

Well, in SMI there were no deep structures.

> You can specify 'key' clauses in XSD for arbitrary nodes.

Right.  Are you arguing that we should support the same flexibility of
keys as XSD?

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

First of all, YANG does not require an XPath engine on the device, for
the same reason - to reduce the implementation burden on the device.

Local typedefs / groupings might add complexity to the compiler, but
not to the engine.

And again, it is the resource consumption on the device that I'm
worried about.  By allowing this you essentially say that streaming
processing is out of the question.


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

Again, SMI does not have deep structures in tables so I don't think
the comparison helps.


Out of curiosity - how do you handle deep keys in your CLI?


/martin


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