A script builds RESTCONF URIs by copying YANG schema paths and tree diagrams, and requests fail; which schema-path habits produce wrong data resource URIs?
answer
- schema tree is not data tree
- prefixes are local, module names global
- choice and case leave no trace
- groupings take the user's namespace
basics
~20 sSchema paths carry what a RESTCONF data path must not: import prefixes in place of module names, choice and case nodes absent from the data tree, and XPath predicates in place of name=key. Augmented nodes need their module name; grouping contents do not.
solid answer
~40 sA RESTCONF URI walks the **data** tree, while YANG source, tree diagrams and XPath describe the **schema** tree, so copying them introduces defects. First, augment targets and XPath use import prefixes such as `if:`; RFC 8040 wants the module name, `ietf-interfaces:`. Second, `choice` and `case` nodes appear in schema paths and, in parentheses, in tree diagrams, but RFC 7950 says they do not exist in the data tree, so they never become segments. Third, XPath selects entries with predicates such as `interface[name='eth0']`, where RESTCONF writes `interface=eth0`. Fourth, namespace switches: a node added by `augment` needs its module name, but nodes placed by `uses` of a grouping take the namespace of the module where `uses` appears, even when the grouping was imported, and a node from a submodule is named after its main module.
go deeper
Know that a RESTCONF path holds data nodes and module names, not every identifier that appears in a YANG file.
Explain the difference between a schema path and a data path, and why prefixes, choices and cases do not belong in a URI.
Diagnose a failing URI generator by checking prefixes, choice and case segments, predicate syntax and namespace switches, then fix it to walk the data tree.
Judge generating clients from YANG against hand-written paths, given model revisions, per-device augmentations and the value of encoding these rules once.
## Two trees with different jobs YANG (RFC 7950) describes a **schema tree**: every statement that shapes data, including statements that only organise or reuse it. The **data tree** is what actually exists on a device. RESTCONF (RFC 8040 §3.5.3) addresses data resources, so its path is a walk through the data tree. Most URI-building bugs in automation come from feeding RESTCONF a path written for the schema tree: one copied from an `augment` statement, a `when` or `must` expression, a tree diagram (RFC 8340) or an `instance-identifier` value. ## Defect 1: import prefixes instead of module names In YANG source, a module refers to another module's nodes through the **prefix** it declared on `import`. RFC 8343's augmentation example targets `"/if:interfaces/if:interface"`, and RFC 8349 augments `"/if:interfaces/if:interface/ip:ipv6"`. Those prefixes belong to the importing module's text; another module may import `ietf-interfaces` under any prefix it likes. RFC 8040 requires the globally unique **module name**: - schema path in YANG source: `/if:interfaces/if:interface/ip:ipv4` - RESTCONF path: `/ietf-interfaces:interfaces/interface=eth0/ietf-ip:ipv4` The XML encoding identifies modules by their namespace URI, such as `urn:ietf:params:xml:ns:yang:ietf-interfaces`; that does not belong in a RESTCONF path either. ## Defect 2: choice and case nodes A `choice` offers alternatives and each `case` is one branch. RFC 7950 §7.9 is explicit: a choice node does not exist in the data tree, and neither does a case node. They do appear in schema node identifiers and in tree diagrams, where RFC 8340 marks a choice as `(name)` and a case as `:(name)`, but the data nodes inside a case sit directly under the choice's parent. RFC 7950 also requires the names of child nodes to be unique across all cases of a choice, which is part of what makes dropping the choice and case names safe. A generator that copies `settings/(transport)/:(tcp)/tcp-port` into a URI asks for nodes that cannot exist; the right path is `settings/tcp-port`. Choice and case are not the only schema-only constructs. None of these ever becomes a segment: - a `choice` and each of its `case` branches; - a `grouping`, and the `uses` statement that places its contents; - an `augment` statement itself, although the nodes it adds do appear; - a `typedef` or an `identity`, which define types and values rather than data nodes. ## Defect 3: XPath predicates instead of keys XPath and the `instance-identifier` type select a list entry with predicates. RFC 7951's example is `/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip`. A RESTCONF path needs one segment, `interface=eth0`, with key values in key-statement order, comma-separated, canonical and percent-encoded. That instance-identifier already uses module names in the RFC 7951 way; only its predicate form differs from a RESTCONF path. ## Defect 4: namespace switches in the wrong places The module name is needed on the top-level node and wherever a node's module differs from its parent's. How the node got into the tree decides which module that is: | How the node got there | Namespace of the node | Module name in the URI? | |---|---|---| | defined directly beside its parent | the parent's module | no | | added by `augment` from another module | the augmenting module | yes, at that node | | placed by `uses` of a grouping, even an imported one | the module containing the `uses` | no, when that is the parent's module | | defined in a submodule | the main module the submodule belongs to | only if that differs from the parent's | RFC 7950 §7.13 says grouping identifiers are bound to the namespace of the current module when `uses` places them. RFC 7951 §4 says a node defined in a submodule is qualified with the name of its main module. RFC 8040 requires its identifiers to follow those RFC 7951 rules, which also call for the short form wherever the namespace does not change. ## How the failures show up - A copied prefix or namespace URI names a module the server does not know, so the segment cannot be resolved. - A choice or case segment names a node that cannot exist in the data tree. - A predicate segment is not valid `api-path` syntax at all. - A missing module name at an augmentation makes the server look for the node in the parent's module, where it is not defined. Each of these fails consistently, which makes them easy to catch with a test; a wrong canonical key value is subtler, because the URI is well formed and simply names no entry. ## Building URIs that survive 1. Generate paths from the data tree, not from schema text: skip `choice`, `case`, `grouping` and `uses`, and follow every `augment`. 2. Map each namespace to its module name, never to a prefix or a namespace URI. 3. Encode list entries as `name=key,key` from the `key` statement, with canonical, percent-encoded values. 4. Test generated URIs against the module set a device actually implements, since an augmentation the device lacks removes the nodes it would add.
- A grouping defined in module A is used inside a container of module B; do its leaves need A's module name in a RESTCONF URI?No. RFC 7950 binds a grouping's contents to the namespace of the module where `uses` places them, so the leaves belong to B, like their container, and are written without a module name. A's name would appear only if A added the leaves to B's container with `augment`.
- Why can a URI generator not simply reuse an augment statement's target string?The target is a schema node identifier written with the importing module's prefixes, and it may pass through choice or case nodes. A RESTCONF URI needs module names, data nodes only, and concrete list entries with key values, and that string carries none of these.
saying these in an interview costs you the question
- The YANG import prefix is what goes before the colon in a RESTCONF path.
- A choice name appears as a path segment above its case's nodes.
- Nodes from an imported grouping keep the grouping module's namespace.
- XPath predicates like [name='eth0'] work as RESTCONF list keys.
- A node from a submodule is qualified with the submodule's own name.