A script opens a NETCONF session and sends a get for the WLAN list. The engineer expects a WLAN to be renamed. The name does not change. Why not?
Select an answer to reveal the explanation.
Short Explanation
You asked the controller to show you the list, and then you waited for it to change a name. A get is a read. Renaming takes an edit, and the session being up does not turn a read into a write.
Full Explanation
NETCONF get retrieves data. It does not change it. This script sent a get for the WLAN list, so the name stays as it was no matter how healthy the session is. A get is not the edit operation. A failed rename is not evidence the session was down. The session was able to return the list. YANG describes the data. It does not forbid a read, and a get does not rename a WLAN because a read was attempted. SSH is the usual transport for NETCONF. The transport being SSH does not make a get into a rename. The script sends a NETCONF get and the engineer expects the WLAN name to change. A get does not edit the configuration. Check one live client after the change and leave the rest of the floor alone until that client matches the result you expected. Read the live counters after you retest. Exam caveat: an edit can still fail after you send one, if the node is not in the model or the session lacks permission. That is a different failure from a get that was never going to write. Operational check: send an edit that the model allows, then get the WLAN again and confirm the name changed.