My device wants attribute X to be set before attribute Y. How do we implement it in an NMS/EMS?
My understanding is that irrespective of the protocol being used such as Netconf, SNMP, etc, my NMS has to send 2 SET/EDIT PDUs. But, ConfD Kick Start Guide mentioned that NMS doesn’t need to bother with the sequencing. How is that possible?
I have pasted ConfD Kick Start Guide below.
From this perspective, any requirements that certain parameters must be specified on the same command line, or must be sent in separate PDUs, or that attribute X must be sent before attribute Y are just pointless bottlenecks in the flow of ideas from the manager to device...... With a transactional interface, the network management application doesn’t need to bother with this serialization, sequencing or error recovery. With a suitable encoding like NETCONF, the whole idea can also be transferred directly, without any need to break it down into individual commands.
NETCONF provides the building components needed to implement transactional behavior when applying configuration changes to devices. They are built into the protocol. Your two configuration modifying PDUs may be sent in any order as parts of the same transaction or as a single PDU, which can also represent a single transaction.
The candidate datastore may be changed in steps (several operations) and changes made to it need not be valid (some constraints are not checked upon datastore content modifications), not until a commit or an explicit validation request is made - making it possible for Y to exist before X in device configuration, although unused.
It is also possible (normal) to set many configuration objects in a single operation (single <edit-config>/<edit-data>) and treat it as a single transaction with conditions in tow (set everything as requested or rollback on error, for example) - making it possible to set both X and Y at the same time and leave the sequencing issues for the device to handle.
You cannot achieve the same with SNMP unless the NMS/EMS handles all aspects of such transactional behavior itself.
This is most likely what the quoted text is referring to.