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). 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. /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
