yang path expressions to refer to data nodes and schema nodes etc

Question

consider the following yang module

module mod {
    yang-version 1;
    namespace "http://example.com/mod";
    prefix m;
    revision "2016-09-09" {
       description "Initial revision.";
    }
    container foo {
        description 'container foo';
        leaf l {
            type string;
        }
    }
}

Which path expression is correct in reaching to leaf l ?

/mod:foo/l
/m:foo/l
/foo/l

If I have 2 revisions of the same module active in my application, how does a client express which revision node he is interested in?

and, is there a path expression available to refer the 'description' of leaf l ?

You did not specify the context in which you wish to refer to `l`. A leafref path? An XPath expression (must, when)? An XPath expression in a NETCONF get/get-config? A RESTCONF query? — predi, Sep 19 '16 at 09:03
`I have 2 revisions of the same module active in my application`. A server MUST NOT implement more than one revision of a module, check the [RFC](https://tools.ietf.org/html/rfc7950#section-5.6.5). Note that in RFC6020, you will not find this explicitly mentioned, but the intention was the same. — predi, Sep 19 '16 at 09:08
There is no way to directly refer to a description of any node, since there is no need for such a thing. Can you explain your use-case for this in greater detail? — predi, Sep 19 '16 at 09:20
1. the path expression I am looking for is the target url in a GET, for ex. Which of those 3 expressions are correct ? — user19937, Sep 19 '16 at 16:02
my usecase for the 'description' is, something like this. A client submits a yang module to a server. Client wants to make sure that server is seeing the structure correctly. Client says , "show me the description of that leaf", or, "what is the default of a leaf" etc. I guess, it should be just a regular xpath expression w.r.t the yin file. server just needs to handle the expression in whatever way it needs to. — user19937, Sep 19 '16 at 16:09

score 1 · Accepted Answer · edited Oct 07 '21 at 11:10

Which path expression is correct in reaching to leaf l ?

In the context of a RESTCONF GET, the scheme described in draft-ietf-netconf-restconf-16, Section 3.5.3, Encoding Data Resource Identifiers in the Request URI is used.

A RESTCONF data resource identifier is encoded from left to right, starting with the top-level data node, according to the "api-path" rule in Section 3.5.3.1. The node name of each ancestor of the target resource node is encoded in order, ending with the node name for the target resource. If a node in the path is defined in another module than its parent node, or its parent is the datastore, then the module name followed by a colon character (":") MUST be prepended to the node name in the resource identifier. See Section 3.5.3.1 for details.

Therefore the correct URI would be something like this:

/restconf/data/mod:foo/l

If I have 2 revisions of the same module active in my application, how does a client express which revision node he is interested in?

You cannot express such a request. This is one of the reasons why a server is only allowed to implement a single revision of a YANG module. In YANG 1.1 this is explicitly prohibited, while in YANG 1.0, this is only implied. Note that respective implemented YANG modules may refer to (import) several revisions of the same module, but only a single one of those may be advertised as implemented (probably the newest one). Since module updating rules are quite strict, definitions will not just go missing in a newer revision of a module, so clients are safe.

is there a path expression available to refer the 'description' of leaf l ? my usecase for the 'description' is, something like this. A client submits a yang module to a server. Client wants to make sure that server is seeing the structure correctly. Client says , "show me the description of that leaf", or, "what is the default of a leaf" etc.

You seem to be misunderstanding the role of a YANG model. A client does not govern a server's model, it may only govern the data that is described in that model! Such a thing is in the domain of the server and its maintainer.

The only standard way of querying the YANG model (that I am aware of) and not the data modeled by it, would be to obtain the YANG/YIN file from the server (get-schema) and then parse it yourself.

As a side note. A client that implements your module and receives a valid response from a server is inherently aware of which description maps to which XML element/JSON object, because it already did the "mapping" between an instance document and the model (schema) during the validation phase.

yang path expressions to refer to data nodes and schema nodes etc

1 Answers1