Re: [Netconf] "depth" parameter: nest-level semantics

["Alberto Gonzalez Prieto (albertgo)" <[e-mail]>]

Thanks Andy,

So I understand that (in the context of data resources) a nest level is composed by all the "real" nodes that share parent. I.e., container, list, leaf, leaf-list, anyxml.
Two follow-up questions. Two use cases:

  *   a GET for a container w/ depth =1,
     *   should it just return an empty container if it exists? This makes sense for presence containers. How about non-presence ones? Would it return an empty container it the containers contains data?
  *   a GET for a list w/ depth =1,
     *   should it return just an empty list if it exists (I.e., if the list has at least 1 element) ?

Thanks,


Alberto


From: Andy Bierman <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, December 3, 2013 1:53 PM
To: Alberto Gonzalez Prieto <[e-mail]<mailto:[e-mail]>>
Cc: Netconf <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Netconf] "depth" parameter: nest-level semantics




On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez Prieto (albertgo) <[e-mail]<mailto:[e-mail]>> wrote:
Hello,

I wanted to confirm my understanding of the semantics of a nest-level.

I understand that a nest-level is composed of a resource + its children.
Data resources are: containers and lists.
Children of a data resource are: leaves, leaf-lists, anyxml. How about presence containers?


This is changing in restconf-03.
In order to allow optional YANG terminals to be deleted without
requiring implementation of YANG Patch, all YANG node types
will be considered data resources.



1) In the example of 3.8.1, for a depth of 2, the response includes  2 containers (I.e., jukebox and library) and 1 list (I.e., artist). Would that make it 3 resources, and therefore 3 nest-levels?

2) I am assuming that choice and case nodes are "transparent"  wrt nest-levels. Is this the case?


yes -- the depth applies to real nodes.


That is, for the following resource


Container alpha {

     choice interface-type {
         case a {
             leaf foo { ... }
         }
         case b {
             container bar { ...}
         }
     }


}


For a get for "alpha" and depth = 1, the leaf "foo" should be returned if it existed. "Bar" would not be returned if it existed.

Not in restconf-03.  The approach above is kind of broken
because there is no way for a client to just test for the existence
of a container without retrieving all the leafs.

depth=2 would return the leaf foo and an empty container bar.
depth=3 would return the leaf foo, the container bar, and the children of bar.


Thanks,

Alberto




Andy