Subject: [netmod] 7.7 leaf-list

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Sep 2008 18:40:29 -0700

Hi,

7.7, para 2:

    The values in a leaf-list MUST be unique.

Why do the leaf-list values have to be unique?
Isn't that a data model decision, just like with list?
There can be duplicate list entries if the list is
non-config and has no keys defined.

IMO, leaf-list should have an 'allow-duplicates true/false'
sub-statement.

(e.g., consider a DM for an iPod playlist; the default is not
to allow duplicate songs, but the user can override it.)

7.7.6, para 1:

Why can't a leaf-list use merge with edit-config?
It can be ordered-by system (default) and insert
new entries last (default) or no-op if the entry already
exists.

7.7.6, para 6:

create and delete are 1-at-a-time.
The same issue was brought up for list.
There is no way to delete the entire leaf-list or list.

A note suggesting that if a delete operation for all
entries at once is desired for a leaf-list or list, then
it should be defined within its own NP container.
A 'delete' operation on the container will have the same
effect as a delete on every explicit leaf-list or list instance,
but with a much simpler <edit-config> PDU.

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Sun, 28 Sep 2008 14:31:55 +0800

Hi,
> to allow duplicate songs, but the user can override it.)
I think we should investigate the scenarios where duplicated leaf-list is neccessary.
basically, we should not repeat the same infomation unless there is an meaning for duplication.
> new entries last (default) or no-op if the entry already
7.7.6 3th para from end:
If the operation is "merge" or "replace" the leaf-list entry is created if it does not exist.
so merge is equivalent to create when node does not exsit or noop otherwise.
> but with a much simpler <edit-config> PDU.
I agree.
Best regards,
washam

---

From: Andy Bierman <[email-masked]>
Date: Sun, 28 Sep 2008 06:11:27 -0700

> basically, we should not repeat the same infomation unless there is an meaning for duplication.

It is up to the data model if duplicates have meaning,
not the YANG language.

Another use case is the representation of any sort of
'data point sequence', such as raw data associated with
an IPPM metric, or as config, some array of values to
seed a function for an IPPM metric collector.
RMON-style history buckets are another common non-config case.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 29 Sep 2008 00:28:20 -0400

>It is up to the data model if duplicates have meaning,

YANG doesn't model all data.  If YANG operations require each list
member to be uniquely identified (for delete and insert operations),
then YANG can't handle non-unique list members.  This implies that
if you want a series of values like:

   <she>
     <loves>me</loves>
     <loves>me not</loves>
     <loves>me</loves>
     <loves>me not</loves>
   </she>

you are forced to add a unique key like:

   <she>
     <loves>
       <name>one</name>
       <value>me</value>
     </loves>
     <loves>
       <name>one</name>
       <value>me not</value>
     </loves>
     <loves>
       <name>one</name>
       <value>me</value>
     </loves>
     <loves>
       <name>one</name>
       <value>me not</value>
     </loves>
   </she>

It's noisier, but allows YANG operations to be unambiguous.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Sep 2008 10:55:03 +0200 (CEST)

Hi,

> non-config and has no keys defined.

I agree that it would be consistent to allow duplicates in non-config
leaf-lists.

> IMO, leaf-list should have an 'allow-duplicates true/false'

... but do we really need a new keyword for this?  Can we just say
that duplicates are allowed in non-config leaf-lists, and leave it to
the description clause to specify the meaning of them, if applicable?

> Why can't a leaf-list use merge with edit-config?

It can, as described later in 7.7.6.

> create and delete are 1-at-a-time.

Yes, that's what we currently have.

> There is no way to delete the entire leaf-list or list.

But shouldn't we fix this?  I'd like to see a way to delete all
entries in a leaf-list and list.

> it should be defined within its own NP container.

I'd rather see this function (delete all entries) supported directly
w/o the data modeller having to worry about it.  I'd like to minimize
the number of "data model tricks" a user must do in order to use the
NETCONF protocol efficently.  This is one of the underlying design
ideas for YANG - a (resonable) YANG data model will work efficently
with NETCONF.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Sep 2008 08:03:37 -0700

> the description clause to specify the meaning of them, if applicable?

Yes -- that was my first idea, but it is not as expressive
for the DM designer.  I agree the read-only use case is far
more likely.

> entries in a leaf-list and list.

The leaf-list operations are consistent with list operations
now -- if you think of a leaf-list as a list with just a key
any nothing else.

An easy fix -- but possibly dangerous -- is to treat a missing key
as a wildcard if nc:operation='delete' is present in
the leaf-list or list node.  This is consistent with
the other node types (container, leaf).  No instance info
given in the delete means delete all instances.

I prefer this approach because no changes to the NETCONF protocol
are needed at all.  It is also nearly pointless to 2nd guess all
the ways an application can get an <edit-config> PDU wrong.
The fewer special cases the better.

<tangent>
When deleting a mandatory node within a case/choice, then
do you delete the rest of the case nodes as well, and undo
the entire case/choice -- unless the choice is mandatory?
Or does a manager have to explicitly delete all the case arm nodes
at once to remove an optional choice?

This automatic deletion happens when any node from a different case
is selected.  It should work consistently for all edit operations.
</tangent>

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 Sep 2008 17:27:40 +0200

> The fewer special cases the better.
Isn't having a special case for delete only a CLR? Wont it hurt consistency? IMHO we are 
introducing a new concept: "addressing multiple nodes in one edit config operation". To 
introduce this just for one such specific case hits me as strange.

Or would you like to allow it for replace as well (merge, create)?

list foo {
     key bar;
     leaf bar {}
     leaf myLittleBit {}
}

<foo operation="replace">    // omiting key means myLittleBit in all foo entries ?
     <myLittleBit>newValue</myLittleBit>
</foo>

Would I be allowed to write

<foo>  // omiting key means all foo entries ?
     <myLittleBit operation="delete"/>
</foo>

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Mon, 29 Sep 2008 11:31:12 -0400

>the entire case/choice -- unless the choice is mandatory?

No.  You are making individual operations on a database.
Until commit time, the database need not fulfill the
mandatory constraint.

>is selected.  It should work consistently for all edit operations.

The auto-delete mechanism removes an obvious source of error
that can never be valid at commit time.

Compare these two cases to a web form with a mandatory field and a
set of radio button.  Selecting one radio button clears the other
choices, but clearing the mandatory field does nothing.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Sep 2008 09:52:19 -0700

> Until commit time, the database need not fulfill the

That may be true for <candidate> but not <running> or <url>
as the target.  But individual deletes are OK -- so the
manager is responsible for deleting all case nodes.

> that can never be valid at commit time.

IMO, deleting a mandatory node in an optional case
is either an error or the manager wants to delete the
entire choice, but calling it an error is fine.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Sep 2008 10:04:42 -0700

Balazs Lengyel wrote:
> Isn't having a special case for delete only a CLR? Wont it hurt 
> consistency? IMHO we are introducing a new concept: "addressing multiple 
> nodes in one edit config operation". To introduce this just for one such 
> specific case hits me as strange.
> 

No, because 'myLittleBit' is a leaf with just one instance.
You cannot start throwing in assumptions about the parent nodes.
If the delete attribute is on the <foo> list, then (as always)
the agent must decide which <foo> element(s) to delete.

The NETCONF protocol is silent on this issue
of how instances are specified for edit-config operations.

YANG should specify exactly which nodes (with or without values)
need to be present in an <edit-config> PDU, in order to perform
a NETCONF create, replace, merge, or delete.  It is fine if
all operations are 1-node-at-a-time, but that should be mentioned
in the sections on list and leaf-list.

IMO, YANG should only add CLRs that are needed for interoperability.
But instead, there are plenty of CLRs which presume how the
YANG language will be used forever, even though it is brand new.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Sep 2008 20:38:11 +0200 (CEST)

> given in the delete means delete all instances.

Yes, but as I wrote in the first email in the other thread ("delete on
list and leaf-list"), this is problematic b/c you cannot distinguish
between "missing a value" and "the empty string value" in a leaf-list:

   leaf-list foo {
       type string;
   }

Given the db:

   <foo>first entry</foo>
   <foo></foo>
   <foo>third entry</foo>

what does 

  <foo nc:operation="delete"/> 

mean?  Delete all entries or the entry whose value is the empty
string?

> The fewer special cases the better.

I agree with this.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Sep 2008 12:17:31 -0700

> mean?  Delete all entries or the entry whose value is the empty

good point.
I think we should stick with 1-at-a-time for now.
The 'correct' approach would be to add an explicit 'delete-all'
operation to NETCONF-bis, whenever that gets done.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 30 Sep 2008 08:12:01 +0200

Andy Bierman wrote:
>> consistency? IMHO we are introducing a new concept: "addressing 
>> multiple nodes in one edit config operation". To introduce this just 
>> for one such specific case hits me as strange.
>>
I see your point, but IMHO one could just as well say: when addressing list foo, if I don't 
specify the key, that means all keys (like in XPath).

But you sad in another mail, let's stick to 1-at-a-time for now, so this is a problem for 
another day.

Balazs