be extended using "Capabilities." The main purpose of capability is to augment the base operations with new com- mands. These new commands can have a unique set of parameters, values, and entities that need not be limited by the base operations. Datastores: The device statistics and configuration data associated with a device and required to get the device from its initial state to a desired operational state is termed as datastores of the device. NETCONF com- mands operate on the data stores that constitute different versions of a device state. The <running> configuration datastore represents the cur- rent configuration of the device. This is the only default data store for the NETCONF device. Datastores like <startup> and <candidate> are added by capabilities. <startup> represents the device startup state. This con- figuration datastore can be used to represent the configuration that will be used during the next startup. Temporary states are handled by <can- didate>. The <candidate> configuration can be changed to a <running> configuration. While the configuration data can be changed, the state data is read-only. XML-Based Protocols NETCONF requests are XML documents encapsulated in the <rpc> tag. There is a unique message identifier associated with each request along with the XML namespace. Example NETCONF Request <rpc message-id="412" xmlns="urn:ietf:params:xml:ns:netconf - : base:1.0"> <get-config> <source> <running/> </source> </get-config> </rpc> The request here is using the "get-config" command to get the current (running) configuration from the device. The response can be the whole configuration record as specific fields are not specified, or an error with details why the NETCONF request could not get the desired response from the agent. Example NETCONF response without error <rpc-reply message-id="412" xmlns="urn:ietf:params:xml:ns: n etconf: base 1.0" > <data> <!- Configuration Record --> </data> </rpc-reply> Example NETCONF error response <rpc-reply message-id="412" xmlns="urn:ietf: params : xml : ns