add guideline on container parent for each list

[abierman]

What is the convention for NP-containers for lists

container top {
   container foos {
      list foo { ... }
    }
    container bars {
      list bar { ... }
    }
}

OR no container parent

container top {
   list foo { ... }
   list bar { ... }
 }

[aashaikh]

We adopted the enclosing container convention for all lists in OpenConfig models, primarily because the feedback from server implementors (device vendors) was that it simplified retrieval semantics such as:

• retrieve the entire list (get on the enclosing container)
• retrieve the keys (get on the list node)
• retrieve a single list element (get on the list node with a selector)

I'd suggest to make sure we get implementor / vendor feedback before removing the guidance for enclosing containers -- we're trying to do the same with the engr teams at some of the vendors.

[plajjan]

@aashaikh but surely this has to do with the transport, right? The vendors solved the lack of a retrieve-keys-of-list by mangling what get does on a list but I suppose this isn't the standard way get operates on a list. Does gRPC, NETCONF and RESTCONF behave the same way? Different possibilities of solving this?

[aashaikh]

@plajjan I'm not sure this has as much to do with the RPC protocol as with how the backend server / device implementations interpret a get request on a list node. Eg., feedback from at least a couple of major vendors was independent of whether the request is delivered over NETCONF or gRPC.

[plajjan]

@aashaikh ah yes, I recognise this from XR which has the same construct in their proprietary models and so do Huawei. JUNOS however does not nor do ALU / Nokia SR-OS.

[aashaikh]

My info on JUNOS behavior is different :-) (from talking to engineers, i have not tried it myself yet to confirm). I suspect there is the added wrinkle of how the behavior might be affected when the system is supporting use of a non-native model which requires some form of mapping or translation (e.g., OpenConfig or IETF).

[plajjan]

@aashaikh ok. Yeah, I was just thinking of their proprietary YANG model which doesn't contain empty containers around lists. Now I'm looking at the YANG model of a translated configuration, uh non-native model, that we have for some custom stuff. It's lacking containers-around-lists but perhaps it wouldn't support get-keys-from-list. Unfortunately I don't have one of these routers spun up right now so can't test how it actually behaves.

[abierman]

Not going to add guideline to overload protocol operations

Added following text:

A non-presence container is used to organize data into specific subtrees.
It is not intended to have semantics within the data model beyond this
purpose, although YANG allows it (e.g., "must" statement within the
non-presence container).

Example using container wrappers:

container top {
   container foos {
      list foo { ... }
   }
   container bars {
      list bar { ... }
   }
}

Example without container wrappers:

container top {
   list foo { ... }
   list bar { ... }
}

Use of non-presence containers to organize data is a subjective matter
similar to use of sub-directories in a file system.
The NETCONF and RESTCONF protocols do not currently support the ability
to delete all list (or leaf-list) entries at once. This deficiency
is sometimes avoided by use of a parent container (i.e., deleting the
container also removes all child entries).

[abierman]

fixed in draft-07