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:
Robert Wilton <[email protected]> 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.
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.
Yes, this was added in -09 (see changelog) after some discussion
starting with
https://mailarchive.ietf.org/arch/msg/netmod/auQCnrLxrSKTTtea57SkfsHhGu4
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
