Subject: [netmod] Y57: non-unique leaf-list

From: Balazs Lengyel <[email-masked]>
Date: Wed, 11 Feb 2015 14:33:20 +0100

Hello Juergen,

I still have an outstanding action point to update the current
proposal for non-unique-list.

The only comment I have received was that for replace/merge we
should have similar behavior as we have for lists:

For merge and replace if the insert attribute is
not present an existing leaf-list value shall not be moved.

Here are my modifications to what can be found on the issue-list
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58.

I merged the two solutions, as they were not real alternatives; the
second part about addressing by position, just built on the main
part.

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320 Tel: +36-1-437-7320
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 07:27:26 -0800

Hi,

I cannot tell if delete is supposed to be delete-first or delete-all.
It seems to be the latter from the text.
The other operations seem to affect only 1 leaf-list instance.

It seems that delete and re-create needs to be used
to move the 2nd - Nth instance of a leaf-list (with value 'foo').
A merge or replace (w/ insert attr to make it a move) will always
move the first instance. But delete affects only the first (or all?)
instances.  So I don't see how the 2nd to Nth instances can ever
be moved.  Seems like you would need to delete-all, then add back
each instance.  It seems the order the edits are applied (from 1 <edit-config>)
would be critical -- not something that is supported by NETCONF,
so N edits would be needed, not 1.

Andy

On Wed, Feb 11, 2015 at 5:33 AM, Balazs Lengyel
<[email-masked]> wrote:
> Hello Juergen,
> I still have an outstanding action point to update the current proposal for
> non-unique-list.
> The only comment I have received was that for replace/merge we should have
> similar behavior as we have for lists:
>
> For merge and replace if the insert attribute is not present an existing
> leaf-list value shall not be moved.
>
> I merged the two solutions, as they were not real alternatives; the second
> part about addressing by position, just built on the main part.
>
> regards Balazs
>
>
>
> --
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 08:13:57 -0800

Hi,

I don't know if it is such a good idea to add more whistles to a
broken construct.
IMO leaf-list is incomplete because (unlike list) the individual
values are really
managed as a group.  But there is no create-all, delete-all, get-all support
in any protocol. A leaf-list has to be placed in an NP-container by itself,
which adds a layer and complexity to the model.

I would be in favor of a comprehensive fix that made leaf-list as
useful as other YANG data node types. This would require
protocol changes.

I would really prefer not to continue defining NETCONF protocol behavior
in the YANG spec. YANG 1.1 could be obsolete before it is even
published, because it is so protocol-specific and new protocols will
be using it that are not mentioned.  IMO all protocol details need to be
moved out of YANG 1.1 into a NETCONF mapping document.
RESTCONF and other protocols can be specified in their own
mapping documents as well.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 11 Feb 2015 18:42:12 +0000

>mapping documents as well.

I agree with this sentiment.  So as to not introduce an immediate need for
6241bis, could YANG 1.1 move all its NETCONF-specific mapping text into an
Addendum section?  - how much such text is there?

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Feb 2015 20:33:20 +0100 (CET)

> Addendum section?  - how much such text is there?

It is quite a lot.  But my idea is to try to move the NETCONF text to
a separate document, but I don't want to do that until all other
issues are resolved.  It will be a big diff...  if it is possible at
all.  I think we need to keep the examples though.

/martin

---

From: Nabil <[email-masked]>
Date: Wed, 11 Feb 2015 12:06:03 -0800

Hi,

I don't quite understand how YANG is defined as the language to express NETCONF operations and the requirement now to make it protocol agnostic. Will the original definition change as well?

Thanks,
Nabil

> On Feb 11, 2015, at 11:33 AM, Martin Bjorklund <[email-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Feb 2015 12:28:08 -0800

> I don't quite understand how YANG is defined as the language to express NETCONF operations and the requirement now to make it protocol agnostic. Will the original definition change as well?

You mean the title? I guess so.

IMO YANG can be defined so it identifies the inputs, outputs,
and behavior of a data model property, and assigns a generic
protocol codepoint to it like "leaf-list insert function".
Each protocol will define the real mechanism in its mapping
document (or indicate it is not supported).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Feb 2015 21:29:32 +0100 (CET)

Nabil <[email-masked]> wrote:
> Hi,
> 
> I don't quite understand how YANG is defined as the language to
> express NETCONF operations and the requirement now to make it protocol
> agnostic. Will the original definition change as well?

The goal is NOT to make YANG protocol agnostic; we know that will
never work.  The goal is to separate the protocol-specific parts from
the language-definition parts.  As has been shown with RESTCONF and
JSON, YANG can be used by other protocols than NETCONF and other
encodings than XML - if the protocol is designed for YANG models.
(There are also proprietary protocols and encodings).

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 16 Feb 2015 16:20:18 -0500

>all.  I think we need to keep the examples though.

How would examples work without encoding rules?  IMHO they should
stay together.  Having the rules with the concepts makes the
document hang together and makes YANG more concrete to the reader.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 16 Feb 2015 16:21:30 -0500

>(There are also proprietary protocols and encodings).

We can allow reuse without inflicting separation on the base spec.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2015 13:06:46 +0100

Balazs,

I added the new writeup as Y57-03 to the issue tracker.

/js

On Wed, Feb 11, 2015 at 02:33:20PM +0100, Balazs Lengyel wrote:
>    Hello Juergen,
>    I still have an outstanding action point to update the current proposal
>    for non-unique-list.
>    [1]http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58.
> 
>  Mobile: +36-70-330-7909              email: [2][email-masked]
> 
> References
> 
>    Visible links
>    1. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-58
>    2. mailto:[email-masked]

> 
> Description
> ---------------
> 
> In YANG 1.0 all values in a leaf-list MUST be unique. The proposal is to relax this in YANG 1.1.
> 
> If the leaf-list is unique the handling does not change compared to YANG 1.0
> 
> A nonUnique leaf-list is still handled as a set of separate leafs as in YANG 1.0
> New mechanism to handle all values of a leaf-list toghether are NOT introduced.
> 
> If we have a leaf-list with nonUnique values in the datastore a value in the 
> edit-config addresses the first such value in the datastore. 
> This alternative is selected for simplicity.
> (Note: Alternatively it could address all such values in the datastore which 
> would be simple for delete/remove, but strange for replace and merge. Merge should 
> be additive but merging [a,a,a] with [a] would result in [a] which is not 
> additive. It would be very strange for insert-after; we want to insert one value, but suddenly 
> it can become multiple values.)
> 
> 
> Solution Y57-01
> 
>     Change to section 3:
> 
> leaf-list: Like the leaf node but defines a set of uniquely identifiable 
> nodes rather than a single node. Each node has a value but no child nodes.
> 
> change to
> 
> leaf-list: Like the leaf node but defines a set of nodes rather than a 
> single node. Each node has a value but no child nodes.
> 
>     Change to section 4.2.2.2:
> 
>     A leaf-list is a sequence of leaf nodes with exactly one value of a particular type per leaf.
> 
> What does this mean? Does it mean that leaf-lists need to have unique leafs? Change to:
> 
> A leaf-list is a sequence of leaf nodes.
> 
>     Remove from section 7.7:
> 
>     The values in a leaf-list MUST be unique.
>     
>     Add to section 7.7.2:
> 
>     unique-leaf-list cardinality 0..1
>     
>     Add a level 3 section before 7.7.6:
> 
>     7.7.5b The unique-leaf-list Statement
> 
>     The "unique-leaf-list" statement takes as an argument the string "true" or "false". 
>     If "unique-leaf-list" is "true", values within the leaf-lists must be unique. 
>     If "unique-leaf-list" is "false", values within the leaf-lists may be repeated. 
>     If "unique-leaf-list" is not specified, the default is true.
>     
>     Change section 7.7.7
> 
>     The operations way of working is dependent on the value of unique-leaf-list. 
>     If unique-leaf-list is true the current handling is unchanged. 
>     If unique-leaf-list is false the following applies:
> 
>     delete/remove: delete/remove the addressed value (first occurence) from the 
>     leaf-list. If a value exists multiple times in edit-config try to 
>     delete 2/3/.. instances of the value. For delete it is an error if 
>     insufficient value instances exist in datastore.
> 
>     create: create value. It succeeds even if value already exists, just adds the 
>     value once more. If no "insert" attribute is present in the "create" operation, 
>     it defaults to "last". If a value exists multiple times in edit-config repeat 
>     the steps.
> 
>     replace, merge: For each specific value, the number of instances of the value 
>     in edit-config and the datastore are matched against each other. 
>     
>     For each such value instance if insert is not specified the value in the datastore is left unchanged. 
> 
>     If the insert is specified, delete the (first/matching) value in the datastore, if 
>     it exists, and re-create it as specified by 
>     insert. If the insert attribute refers to a value, it is the first occurrence 
>     of the value that is indicated. If a value exists multiple times in edit-config 
>     repeat the steps.
>     
>     If edit-config contains more instances, the additional ones are created as 
>     in a create operation. If the datastore contains more instances, they are not modified.
>     
>     =================================================================================================
>     
> 
> 
> 
> Position can be used to select a leaf in a leaf-list, but only if it is "ordered-by user". 
> For system-ordered lists this leads to error. (Same as insert)
> 
> Position must be between 1 and the length of the leaf-list, if it is not, send an error message. 
> Indexing starts at 1 not 0, following XPATH conventions.
> 
> In a delete/remove operation if position is specified, the value of the leaf-instance, has no effect, 
> it may be omitted by the client. (Addressing by position takes precedence over addressing by value.)
> 
> If both the position and the value attributes are specified in edit-config for the same data node, 
> the value attribute has no effect and may be (should be) ommitted by the client.
> 
> If position is specified, the insert attribute can only take the values after and before. First 
> and last are error. (There is no sense in specifying position once the insert=first/last is specified, 
> it would just add one more useless and complicated case.)
> 
>     Further changes to section 7.7.9:
> 
>     In an "ordered-by user" leaf-list, the attribute "position" in the YANG XML namespace (Section 5.3.1) 
>     can be used to address specific values in the leaf-list.
> 
>     create: add: If position is specified but insert is not specified insert=after is implied.
> 
>     replace/merge: if position is specified but insert is not, replace the value specified by position. 
>     If both position and insert=after/before is specified, insert a new leaf with the value at the specified position. (replace/merge works differntly with and without position.)
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 18 Feb 2015 14:59:30 +0100

Hello,
"delete/remove: delete/remove the addressed value (first occurrence)" 
so  delete should only change one value, unless you have multiple values 
in the edit-config as well.

If you want to move the nth same value use position for addressing.

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 18 Feb 2015 15:00:58 +0100

Hello,
Netconf details are today in YANG. They could be removed, but that is 
not dependent on this proposal in any way.

Yes we have to choose whether we address the leaf-list or the 
leaf-instance in the leaf-list.  In YANG 1.0 as in my proposal we 
address the leaf-instance. I don't want to change that. It would be an 
incompatible change.
If you want addressing the whole leaf-list as a new feature, go ahead 
propose it.
regards Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 18 Feb 2015 15:04:54 +0100

Hello,
In one sense it is only a few items that should be moved from RFC6020 to 
a new "Netconf encoding of Yang data" RFC:
insert-after/before-position for lists and leaflists.

IMO really every chapter called "NETCONF <edit-config> Operations"  
chapter should be moved.
Maybe some details about canonical encoding as well, e.g. namespace are 
handled differently in Netconf and Restconf.
regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Feb 2015 15:27:41 +0100

Balazs,

I think we need a better problem statement. The text we have in Y57
says 'lets see whether we can relax the rules' but it does not provide
a rationale why we would do that. Which benefit do we get if we relax
the rules?

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 18 Feb 2015 15:50:05 +0100

Thanks.
As I see it the comments for the solution are:
- Why cant we address the full leaf-list? Yes it would be good, but that 
is a separate proposal
- Why don't we move netconf encoding to a separate document? Interesting 
idea, but not part of my proposal.
- Clarifications
regarrds Balazs

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 18 Feb 2015 16:37:44 +0000

I'd definitely support separation of YANG the data modeling language from
NETCONF the management protocol.  A document describing NETCONF encoding
would help make the separation clear IMO (understanding this is not in
scope for the current proposal).   As a relative newcomer to authoring and
consuming YANG models, I've run into limitations with YANG that seem to be
motivated by NETCONF-related considerations, but it's hard to be sure
without knowing all of the history.

thanks.
-- Anees

On Wed Feb 18 2015 at 6:50:16 AM Balazs Lengyel <[email-masked]>
wrote:

> second
> >>      If both position and insert=after/before is specified, insert a
> new leaf with the value at the specified position. (replace/merge works
> differntly with and without position.)
> >>
> >
>
> --

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 24 Feb 2015 18:42:27 +0100

Hello Juergen,
1) You misunderstood me. What is now under Y57-3 is actually a merge of 
Y57-1 and Y57-2.
-1 and -2 were never alternatives, they were two parts of the same 
proposal, so to make life easier they should be merged. Please remove 
the current -1 and -2 and use the updated/attached version of  -3 as the 
one and only new -1 proposal.

2) About, motivation (a.k.a problem statement) I propose to change the 
beginning of the text to:
"In the number of cases we need to model a list of simple items that do 
not need or have a key value. Leaf-lists are used for this in YANG. 
However sometimes a value needs to be included multiple times in the 
leaf-list.  In YANG 1.0 all values in a leaf-list MUST be unique. The 
proposal is to relax this in YANG 1.1.
Examples where nonUnique leaf-list are needed include:
- list of AS-Paths
- list of queuing weights in a scheduler"

So the new text of Y57 considering 1) and 2) above should be the text I 
attached here. That should replace everything that is in Y57 today.

3) As there were no opposing emails on the list can we move it forward 
to EDIT status?

regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Feb 2015 11:21:55 +0100

> single node. Each node has a value but no child nodes.

I think the term "node" as used here is confusing. According to sec. 3
in RFC 6020(bis), a leaf-list is in any case only a single "data node"
or "schema node".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 26 Feb 2015 17:27:59 +0100

Hello Lada,
This terminology is not new, it was not created by Y57. The terminology 
is not perfect in YANG 1.0 either. The problem is with data-node.
"data node: A node in the schema tree that can be instantiated in a data 
tree. One of container, leaf, leaf-list, list, and anyxml."
A  single leaf in a leaf-list or a list-entry can be instantiated 
individual, but it is still the "collection" the list itself or the 
leaf-list that is listed as a data node. So we may need a new name for 
these piece of data leaf-list or a list-entry.

My first proposal is that on better inspection I do not need to change 
chapter 3 at all for Y57.

If we want to change it would you agree with:
"leaf-list: Like the leaf node but while the leaf can have only a single 
value, a
leaf-list can have multiple values at the same time.
A leaf-list has zero, one or more values but no child nodes."

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 27 Feb 2015 12:56:36 +0100

> is not perfect in YANG 1.0 either. The problem is with data-node.

Yes, I know, and the cited formulations should IMO be improved in
6020bis in any case. Perhaps a new non-XML-centric term should be
introduced for what is denoted as "element" in XML. How about
"instance"?

Lada