Ladislav Lhotka <[email protected]> wrote: > Martin Bjorklund <[email protected]> writes: > > > Juergen Schoenwaelder <[email protected]> wrote: > >> - New feature: non-unique config false leaf-lists > >> > >> It is unclear where we are with this. While there was some > >> discussion at IETF 94, there was no clear indication whether this > >> change should be done or not. More input would be welcome. > > > > I think there are two options: > > > > A. Allow non-config leaf-lists to have duplicate values. > > > > B. Add a new keyword "allow-duplicates true|false" to leaf-list. > > It is an error if allow-duplicates is true in config. > > > > B feels more correct to me, but A is obviously simpler. > > I don't have a strong preference here. Could A cause any problems?
Well, I agree with what Andy wrote: It seems like a data model property, not a server implementation choice. > >> - Old function: make auto-delete for choice and when non-NETCONF specific > >> > >> Revision -08 of YANG 1.1 defines auto-deletion as a property of the > >> NETCONF edit-config operation and the issue is whether this > >> auto-deletion behaviour is a NETCONF specific edit-config property > >> or a general YANG datastore validation property that equally applies > >> to RESTCONF, COMI, ... > >> > >> It is unclear where we are with this. More input would be welcome. > > > > I think it would be very confusing if e.g. RESTCONF behaved > > differently than NETCONF. However, I can see how it might make sense > > I don't know whether auto-deletion is really the preferred choice of > every NETCONF/RESTCONF user but I think it would be countre-productive > to require all protocols that might use YANG to apply this behaviour. > > > for a server on a constrained device to not do auto-delete - but OTOH > > such a server probably don't do "must" and "when" checking at all. > > Why not? For example, such an implementation can do this validation with > DSDL schemas using off-the shelf RELAX NG and XSLT implementations. If a device can run off-the shelf XLST then it is not very constrained, and it can probably run any of the off-the shelf NETCONF servers that already handle this. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
