An engineer reads a pyang tree before writing a NETCONF edit-config that adds a sensor: container monitor (rw) holds list sensor* keyed by [name], with leaves name (rw, string), interval? (rw, uint32) and last-sample (ro, int32). Which node in this pyang tree must be supplied when the sensor entry is created, and why?
Select an answer to reveal the explanation.
Short Explanation
In a pyang tree the square brackets flag the list key, so that bracketed name is the value you must hand over to open a new entry. The rw flag in front of a node just tells you it lives in configuration. It's like the name tag that makes each entry findable.
Full Explanation
Reading a pyang tree starts with the flags and marks in front of each name: rw means the node lives in the configuration datastore and can be written through NETCONF or RESTCONF, while ro means the server reports it as state and refuses to accept it from a client. The square brackets after sensor name the leaf that forms the list key, and a key leaf is the identifier the server needs before it can index a new entry, which is why name is the value your edit-config must carry. The question mark on interval marks an optional leaf, so a writable node is not automatically a required one. Treating a read-only leaf such as last-sample as input fails because state data is produced by the device and never accepted in an edit. Supplying some other writable leaf fails because the server cannot build a list entry without its key, so the whole edit is rejected even when the rest is valid. Caveat: read the flags, the brackets and the question marks together rather than trusting one symbol. A practical check is to load the module in pyang and confirm the bracketed key before you write the request.