Re: [YANG] key clause issues

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> Martin Bjorklund wrote:
> >>> Hi Andy,
> >>>
> >>> Andy Bierman <ietf@andybierman.com> 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?
> > 
> 
> See below
> 
> > 
> >>> (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?
> 
> 
> Yes, the manager knows about all the leafs (ifIndex, ifInOctets, ifMtu, etc.)
> Without the magic text 'key ifIndex;', the manager has no idea what
> makes one blob called <ifEntry> from another one.
> 
> Without a key, the manager has to identify each list node
> by its position:
> 
>    <ifEntry>
>      <ifIndex>1</ifIndex>
>      <ifMtu>1500</ifMtu>
>      ...
>    </ifEntry>
>    <ifEntry>
>      <ifIndex>2</ifIndex>
>      <ifMtu>9600</ifMtu>
>      ...
>    </ifEntry>
>    <ifEntry>
>      <ifIndex>3</ifIndex>
>      <ifMtu>9600</ifMtu>
>      ...
>    </ifEntry>
> 
> Now, if the manager application has no idea that 'ifIndex' is the
> key, and the entire <ifEntry> for entry '2' is deleted,
> then the manager has no idea it is collecting data
> for entries 1 and 3, not 1 and 2.
> 
> 
> > 
> > [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?
> 
> 
> yes -- if there are named entries in the list
> no -- if the list has unnamed entries, just position tells them apart

Why don't the same rules apply to non-config data?  In the ifIndex
example above, by this rule you would specify a key.

> >>>> 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.
> 
> Instance ID:
> 
>    /addr-pairs[addr-type='ipv4'][src-addr='192.168.0.1'][dest-addr='192.168.0.4']

So the key statement above has addr-type twice, but in the IID it
occurs just once?

/martin

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