You are reviewing the pyang tree for YANG module example-ntp, used by a RESTCONF-managed NTP service: container ntp (rw) holds list server* keyed by [address], with leaves address (rw, inet:ip-address), prefer? (rw, boolean) and reach (ro, yang:counter32). A teammate plans a PUT for one server entry. How does the tree diagram constrain what the client may PUT?
Select an answer to reveal the explanation.
Short Explanation
The asterisk shows server is a list keyed by address, so a PUT representation for an entry must include its key, matching the entry identified by the request URI. The question mark after prefer marks it optional, while ro on reach means it is state data the client cannot send. It's like a form where some boxes are mandatory, some are optional, and some are filled in for you.
Full Explanation
The pyang tree uses RFC 8340 notation, and every symbol carries meaning about the modeled data. The asterisk on server marks a list, and the bracketed address identifies its key. For a RESTCONF PUT of a list entry, the representation must include the key, and its value must match the entry identified by the request URI. The question mark after prefer marks an optional node, so it may be omitted; the rw flag says it is writable when included. The ro flag on reach marks state data produced by the device, which a client must not include in an edit. Assuming reach is writable because it sits under a read-write container confuses parent access with node access, and the tree labels each node individually. Omitting the address under the impression that the list indexes itself ignores the key requirement. Reading the question mark as a demand for a mandatory value inverts its meaning. Exam caveat: pyang versions differ slightly in symbol spacing, so confirm the same module locally with a tree render. Practical check: PUT an entry with the key plus chosen writable leaves, then GET it back and confirm reach arrives as read-only state.