Robert Wilton <rwil...@cisco.com> wrote: > 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"?
Ok. /martin > > 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 <rwil...@cisco.com> 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
