nning> 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 : n etconf: base : 1.0" > <rpc-error> <error-type>RPC Connection</error-type> <error-tag>Device not found</error-tag> kerror-severity>Major</error-severity> <error-info> <!-- Details of the error --> </error-info> </rpc-error> </rpc-reply> The request and reply both include the same message-id number. In case of an error, the rpc-error is encapsulated in the rpc-reply. The NETCONF reply can Fundamentals of EMS, NMS and OSS/BSS indicate one or more errors of varying severity. The error message is mapped to a specific type, along with severity to identif