Subject: [netmod] Yang 1.1 - Semantics for state data leaf list

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Feb 2016 10:51:52 +0000

Hi Martin,

In Yang 1.0, all values in a leaf-list must be unique (i.e. section 7.7. 
states "The values in a leaf-list MUST be unique.".  I.e. a leaf-list 
actually represents an ordered set rather than a list.

In 6020bis#10, section 7.7, this statement has been changed to "In 
configuration data, the values in a leaf-list MUST be unique."

My interpretation is that this implies that elements in a config-false 
leaf list are no longer required to be unique, and in fact there is no 
clean way to specify that they have to be unique.

I just wanted to check that my interpretation was correct and that this 
change in behaviour was intentional.

Thanks,
Rob

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Feb 2016 12:14:26 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> Hi Martin,
> 
> In Yang 1.0, all values in a leaf-list must be unique (i.e. section
> 7.7. states "The values in a leaf-list MUST be unique.".  I.e. a
> leaf-list actually represents an ordered set rather than a list.
> 
> I just wanted to check that my interpretation was correct and that
> this change in behaviour was intentional.

Yes, this was added in -09 (see changelog) after some discussion
starting with
https://mailarchive.ietf.org/arch/msg/netmod/auQCnrLxrSKTTtea57SkfsHhGu4

/martin

---

From: Robert Wilton <[email-masked]>
Date: Mon, 15 Feb 2016 11:29:00 +0000

Hi Martin,

Thanks for confirming. I had only checked section 1.1.

Should this change in semantics be listed in "1.1.  Summary of Changes 
from RFC 6020"?

My concern being that this change could break existing clients if they 
are currently using sets as the underlying data structure to represent 
config-false leaf-lists.  Hence, I was wondering if this change should 
be flagged up higher up in the document to ensure that implementors are 
aware of this non backwards compatible change?

Thanks,
Rob

On 15/02/2016 11:14, Martin Bjorklund wrote:
> .

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 16 Feb 2016 08:43:07 +0100 (CET)

> Should this change in semantics be listed in "1.1.  Summary of Changes

Ok.

/martin

> be flagged up higher up in the document to ensure that implementors
> are aware of this non backwards compatible change?
> 
> Thanks,
> Rob
> 
>