> On 16 Dec 2015, at 18:08, Martin Bjorklund <[email protected]> wrote: > > Anees Shaikh <[email protected]> wrote: >> I'm not suggesting this is necessarily standard behavior :-) > > I think this demonstrates that it is probably not a good idea to > design (standard) data models to optimize for a single protocol / > implementation. For NETCONF, the problem is clearly in the protocol, > and it should be fixed in the protocol (Andy already showed a > solution).
Agreed. This deficiency also blocks the introduction of keyless config lists that several people requested. > > Going back to the original question, I don't think there's a single > rule to be used. Sometimes the additional container makes sense, but > in some cases (normally further down in the hierarchy, for "smaller" > lists) it just adds noise. Also, it is usually a good idea to use a wrapper container for user-ordered lists. Lada > > > /martin > > > , but some >> major implementations behave this way (it could be useful in some >> circumstances) -- on those platforms, the enclosing container makes a >> request for the whole list arguably less ambiguous. >> >> thanks. >> -- Anees >> >> On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps <[email protected]> wrote: >> >>> >>> Anees Shaikh <[email protected]> writes: >>> >>> hi Chris, in OpenConfig models we use enclosing containers on lists based >>>> on feedback from some implementors who claimed that it made it more >>>> efficient to, for example, retrieve the entire list (ask for the >>>> container), retrieve the keys in the list (ask for the list node), or >>>> retrieve a particular element of the list (specify the key). >>>> >>> >>> But, I don't think asking for the list node returns only keys, I think it >>> returns the entire content of the node, i.e., it's equivalent to asking for >>> the out container if that container only contains a single list (the model >>> in question here). >>> Thanks, >>> Chris. >>> >>> >>> Aside from some stuttering in the paths (which can be a little annoying >>>> but I don't expect to write the config instances by hand), there didn't >>>> seem to be a major downside. So we try to be consistent across the models >>>> with this approach. After getting some more experience with the >>>> implementations, we might revisit. >>>> >>>> thanks. -- Anees >>>> >>>> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman <[email protected]> wrote: >>>> >>>> Hi, >>>>> >>>>> Use of NP-containers are subjective, based on how you want to organize >>>>> your data. The extra layer of containment may be a waste, but it >>>>> sometimes >>>>> has a purpose >>>>> >>>>> - 2 or more sibling lists with lots of entries can be mixed in >>>>> JSON, so putting each list in its container prevents that. - There is >>>>> no standard way to 'delete-all' in NETCONF or RESTCONF but a >>>>> 'replace' >>>>> on the parent container can be used for this purpose. (container of >>>>> list or leaf-list) - container servers as a conceptual 'root' for >>>>> external augments >>>>> >>>>> Andy >>>>> >>>>> >>>>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> Some models seem to place a single list of things inside a container >>>>>> also named after the items in the list, e.g., >>>>>> >>>>>> +--ro modulename +--rw ribs +--rw rib* [name] +--rw name >>>>>> I don't see the purpose of these containers. It seems to me that one can >>>>>> model and query the exact same data without the outer container. That is, >>>>>> >>>>>> +--ro modulename +--rw rib* [name] +--rw name Is there something >>>>>> useful about these containers that I've missed, as it's a fairly common >>>>>> pattern in the models I've been looking at. Example comparisons below.. >>>>>> Thanks, Chris. >>>>>> >>>>>> >>>>>> w/ container: <modulename> <ribs> <rib> >>>>>> <name>foo</name> </rib> <rib> <name>bar</name> </rib> ... >>>>>> </ribs> </modulename> w/o container: <modulename> <rib> >>>>>> <name>foo</name> </rib> <rib> <name>bar</name> </rib> ... >>>>>> </modulename> Likewise if you want to fetch all ribs you can either way: >>>>>> >>>>>> <filter> <modulename> <ribs/> </modulename> >>>>>> </filter> or >>>>>> >>>>>> <filter> <modulename> <rib/> </modulename> >>>>>> </filter> Or a particular rib >>>>>> >>>>>> <filter> <modulename> <ribs> <rib> >>>>>> <name>foo</name> </rib> </ribs> </modulename> >>>>>> </filter> or >>>>>> >>>>>> <filter> <modulename> <rib> <name>foo</name> >>>>>> </rib> </modulename> </filter> Using xpath: >>>>>> >>>>>> /modulename/ribs/rib[name='foo'] or >>>>>> >>>>>> /modulename/rib[name='foo'] >>>>>> >>>>>> _______________________________________________ netmod mailing list >>>>>> [email protected] https://www.ietf.org/mailman/listinfo/netmod >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ netmod mailing list >>>>> [email protected] https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> >>>>> >>> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
