Subject: [netmod] non-unique leaf-lists

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Oct 2014 13:19:38 +0200

Hello,
After the New York interim I volunteered to write a proposal about how 
to implement leaf-lists that might have non-unique (repeated) values. I 
attached my proposal for it. Please comment!
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: Mon, 6 Oct 2014 13:01:06 -0700

Hi,

On Mon, Oct 6, 2014 at 4:19 AM, Balazs Lengyel <[email-masked]>
wrote:

> Hello,
> After the New York interim I volunteered to write a proposal about how to
> implement leaf-lists that might have non-unique (repeated) values. I

There are two interesting data modeling issues raised in your proposal.
I think we should identify and agree on the problems first, and then pick
apart the
solution details after that.

I-1) Do all leaf-lists need to be edited as individual components?
[current: yes, propose: no]
Can the data model specify that all leaf-list values are provided/replaced
at once?
Or is this also a protocol issue?
Note that current "replace" operation for leaf-list is a no-op because
it replaces the individual value with the same value.

I-2) Do all leaf-lists need to contain unique values? [current: yes,
propose: no]
Depending on I-1, position-based editing may not be needed.
One work-around is to always put this sort of leaf-list in its own container
so the "replace" operation on the container can be used.

IMO both issues should be addressed in YANG 1.1 (and in NETCONF if needed).
The solution for position-based editing looks OK to me.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 8 Oct 2014 17:46:34 +0200

Hello Andy,

See below.

Balazs

On 2014-10-06 22:01, Andy Bierman
wrote:

Hi,

On Mon, Oct 6, 2014 at 4:19 AM,
Balazs Lengyel <[email-masked]>
wrote:

Hello,

After the New York interim I volunteered to write a
proposal about how to implement leaf-lists that might have
non-unique (repeated) values. I attached my proposal for
it. Please comment!

regards Balazs

There are two interesting data modeling issues raised
in your proposal.

I think we should identify and agree on the problems
first, and then pick apart the

I-1) Do all leaf-lists need to be edited as individual
components? [current: yes, propose: no]

[BALAZS] : While I proposed yes, I could live
with a No. Stating that nonUnique leaf-lists can only be handled
as a unit would make things _much_ easier. Its gained
functionality versus complexity. Any opinions?

Can the data model specify that all leaf-list values
are provided/replaced at once?

Note that current "replace" operation for leaf-list is
a no-op because

[BALAZS]: Not really, as written in 7.7.7
rfc6020, the value can be moved in the list. So the value stays,
but its position in the list changes.

I-2) Do all leaf-lists need to contain unique values?
[current: yes, propose: no]

[BALAZS]: Definitely NO That's my proposal.

Depending on I-1, position-based editing may not be
needed.

One work-around is to always put this sort of leaf-list
in its own container

so the "replace" operation on the container can be
used.

[BALAZS]: The work-around is feasible, we
actually use something like that in Ericsson.

IMO both issues should be addressed in YANG 1.1 (and in
NETCONF if needed).

Andy