skip to content

What RESTCONF URI targets the IPv4 MTU of interface eth0/1 in ietf-interfaces augmented by ietf-ip, and why is each segment written that way?

level: middleimportance: must knowfreq 15%

answer

  1. follow the model, not a device CLI
  2. MTU sits per address family
  3. an augmentation switches the namespace
  4. a slash inside a key value

basics

~10 s

{+restconf}/data/ietf-interfaces:interfaces/interface=eth0%2F1/ietf-ip:ipv4/mtu: the module name on the top node, the key's slash percent-encoded, and ietf-ip: again on ipv4 because the ietf-ip augmentation defines that container.

solid answer

~40 s

With the root at `/restconf`, the URI is `/restconf/data/ietf-interfaces:interfaces/interface=eth0%2F1/ietf-ip:ipv4/mtu`. `ietf-interfaces:interfaces` is the top-level container, so it carries its module name. `interface` is a list keyed by `name`; the value `eth0/1` contains `/`, a reserved character RFC 8040 §3.5.3 requires to be percent-encoded, so it becomes `eth0%2F1`, and left raw it would split into an entry `eth0` and a child node called `1`. `ietf-interfaces` itself has no MTU leaf: the `ietf-ip` module (RFC 8344) augments each interface entry with `ipv4` and `ipv6` containers, and because `ipv4` comes from a different module than its parent it is written `ietf-ip:ipv4`. `mtu` shares its parent's module, so it is written bare.

code

http · 8 lines
http
GET /restconf/data/ietf-interfaces:interfaces/interface=eth0%2F1/ietf-ip:ipv4/mtu HTTP/1.1
Host: example.com
Accept: application/yang-data+json

HTTP/1.1 200 OK
Content-Type: application/yang-data+json

{ "ietf-ip:mtu": 1500 }

go deeper

for a junior

Know that the URI follows the model's tree and that the top node carries its module name; be able to write the path to a simple interface leaf.

for a middle

Walk the eth0/1 MTU path aloud: the %2F in the key, ietf-ip: on the augmented container, and why mtu itself is bare.

for a senior

Name what breaks generated automation here, raw slashes in names, prefixes copied from YANG source, MTU sought in the wrong module, and how you would test URI building.

for a principal

Weigh how augmentations shape client design: which URIs exist depends on the modules a device implements, so clients should learn the module set rather than assume one.

## The scenario An automation job must read or set the IPv4 MTU of interface `eth0/1` on a device that implements two standard YANG modules: `ietf-interfaces` (RFC 8343, which obsoletes RFC 7223) and `ietf-ip` (RFC 8344). The interview test is to write the URI straight from the model, without browsing the device or reading product documentation. With the RESTCONF root discovered as `/restconf`, the answer is: `/restconf/data/ietf-interfaces:interfaces/interface=eth0%2F1/ietf-ip:ipv4/mtu` ## Segment by segment | Segment | YANG node | Why it looks like this | |---|---|---| | `/restconf` | none, the API root | discovered by the client; `/restconf` is the value RFC 8040's examples use | | `/data` | the datastore resource | every data resource lives under `{+restconf}/data` | | `/ietf-interfaces:interfaces` | top-level container | its parent is the datastore, so the module name is mandatory | | `/interface=eth0%2F1` | list `interface`, key `name` | one segment: list name, `=`, the key with its `/` percent-encoded | | `/ietf-ip:ipv4` | container added by `augment` | defined in `ietf-ip`, not in its parent's module | | `/mtu` | leaf inside `ipv4` | same module as its parent, so no module name | ## Why the slash must be encoded RFC 8040 §3.5.3 says a list's key values are encoded in **one path segment**, as the canonical string form of the key's type, and that any **reserved character** in them must be percent-encoded as RFC 3986 defines it. The `/` is the path separator, so: - `interface=eth0%2F1` is one segment: the entry whose `name` is `eth0/1`. - `interface=eth0/1` is two segments: the entry `eth0`, then a child node called `1`, which the model does not define, so the request cannot reach the intended leaf. - Only the key value is encoded. The `/` characters between segments stay literal; percent-encoding the whole path destroys its structure. RFC 8040's own example encodes a key containing a comma, a single quote, a colon, a space and a slash as `%2C%27"%3A"%20%2F`, so a colon or a space in an interface name is treated the same way. Inside a JSON or XML body the same name is written plainly, `"name": "eth0/1"`; percent-encoding belongs to the URI only. ## Why `ietf-ip:` appears in the middle YANG gives every module its own namespace. `ietf-interfaces` defines the `interfaces` container, the `interface` list and leaves such as `name`, `description`, `type` and `enabled`, but no MTU. The `ietf-ip` module adds IP configuration to every interface entry with an `augment` statement whose target is that list; in YANG source such a target is written with import prefixes, for example `/if:interfaces/if:interface`. Among other nodes, the augmentation adds: 1. a container `ipv4`, holding a leaf `mtu`, the IPv4 addresses and a `forwarding` leaf; 2. a container `ipv6`, holding its own `mtu` leaf and the IPv6 addresses. RFC 8040 requires the module name wherever a node is defined in a different module from its parent. `ipv4` is defined in `ietf-ip` and its parent `interface` in `ietf-interfaces`, so the segment is `ietf-ip:ipv4`. Its child `mtu` is in the same module as `ipv4`, so it is bare. RFC 7951 applies the same rule to JSON member names, and its instance-identifier example, `/ietf-interfaces:interfaces/interface[name='eth0']/ietf-ip:ipv4/ip`, shows the identical namespace switch at `ipv4`. ## What comes back A GET on the URI returns that one leaf. The reply is a document of its own, so its top-level member carries the module name even though the last path segment did not: - with `Accept: application/yang-data+json`, the body is `{"ietf-ip:mtu": 1500}`; - the IPv6 MTU of the same interface is a separate leaf, `.../interface=eth0%2F1/ietf-ip:ipv6/mtu`, and a request to one leaf neither reads nor changes the other. ## Checking the answer against the model The path is not memorised; it is read off the modules in four steps, and each step can be checked: 1. Find the module that defines each node on the way down: `interfaces`, `interface` and `name` in `ietf-interfaces`, `ipv4` and `mtu` in `ietf-ip`. 2. Mark every point where the defining module changes. Here there are two: the datastore-to-`interfaces` step and the `interface`-to-`ipv4` step, and each gets a module name. 3. For every list on the way, take its `key` statement, here the single string leaf `name`, and write its canonical value. 4. Percent-encode the reserved characters in that value, and nothing else. ## Mistakes interviewers listen for - Looking for `mtu` directly under `interface`, where `ietf-interfaces` defines none. - Writing the YANG prefixes `if:` or `ip:` instead of the module names. - Leaving the `/` raw in the key, or percent-encoding the separators as well. - Qualifying every node, or forgetting the module name at the augmentation. - Hard-coding `/restconf` instead of using the root the client discovered.

  • Why is mtu written without a module name when ipv4 needs one?
    RFC 8040 asks for the module name only on the top-level node and wherever a node is defined in a different module from its parent. `ipv4` comes from `ietf-ip` while its parent comes from `ietf-interfaces`; `mtu` comes from `ietf-ip` like its parent, so the namespace does not change and the short form is used.
  • Where does the IPv6 MTU of the same interface live, and is it the same leaf?
    It is `.../interface=eth0%2F1/ietf-ip:ipv6/mtu`, a separate leaf in the `ipv6` container. The ietf-ip model keeps one MTU per address family, so reading or setting the IPv4 leaf does nothing to the IPv6 one.
  • How is the interface name written when the same entry is sent in a JSON body?
    Plainly, as `"name": "eth0/1"`. Percent-encoding is a rule for the URI path, where `/` separates segments; inside a JSON or XML body the key leaf carries its ordinary string value.

saying these in an interview costs you the question

  • The MTU is a leaf directly under the interface entry in ietf-interfaces.
  • The URI uses YANG prefixes, as in if:interfaces and ip:ipv4.
  • A slash in an interface name can stay raw in the RESTCONF path.
  • Percent-encode the whole path, separators included, to be safe.
  • Only the first node of a RESTCONF path ever carries a module name.