Converted from YANG file 'yuma-netconf.yang' by yangdump version 2.2.1737 Module: yuma-netconf Version: 2011-05-30 Contact: Translated by Andy Bierman. Send comments to <andy@netconfcentral.org>. NETCONF Protocol * Data Types * Abstract object for PDU components * RPCs Translated from RFC 4741. /usr/share/yuma/modules/netconfcentral/yuma-netconf.yang Translated by Andy Bierman. Send comments to <andy@netconfcentral.org>. 2011-05-30 Update for NETCONF base:1.1 version 2010-05-24 Align rpc statements with ietf-netconf.yang 2010-05-06 Remove nacm:secure on delete-config; Fix bugs in parameters that did not match ietf-netconf.yang. 2009-04-10 Remove rpc-type extension usage. 2009-02-24 Change yang:uri to inet:uri (import moved). 2008-08-30 Add some NCX extensions to automate some server processing. 2008-04-26 Change get-config and get output from 'config' to 'data'. 2008-04-16 Initial conversion from netconf.ncx version 0.6. XML language type for LangString NETCONF Session Id NETCONF Session Id or Zero to indicate none XML string with a language attribute. NETCONF message-id attribute NETCONF Error Type 0 1 2 3 NETCONF Error Tag RFC 6241, Appendix A. http://www.ietf.org/rfc/rfc6241.txt The request requires a resource that already is in use. 0 The request specifies an unacceptable value for one or more parameters. 1 The request or response (that would be generated) is too large for the implementation to handle. 2 An expected attribute is missing. 3 An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch. 4 An unexpected attribute is present. 5 An expected element is missing. 6 An element value is not correct; e.g., wrong type, out of range, pattern mismatch. 7 An unexpected element is present. 8 An unexpected namespace is present. 9 Access to the requested protocol operation, or data model is denied because authorization failed. 10 Access to the requested lock is denied because the lock is currently held by another entity. 11 Request could not be completed because of insufficient resources. 12 Request to rollback some configuration change (via rollback-on-error or discard-changes operations) was not completed for some reason. 13 Request could not be completed because the relevant data model content already exists. For example, a 'create' operation was attempted on data that already exists. 14 Request could not be completed because the relevant data model content does not exist. For example, a 'delete' operation was attempted on data that does not exist. 15 Request could not be completed because the requested operation is not supported by this implementation. 16 Request could not be completed because the requested operation failed for some reason not covered by any other error condition. 17 This error-tag is obsolete, and SHOULD NOT be sent by servers conforming to this document. 18 A message could not be handled because it failed to be parsed correctly. For example, the message is not well-formed XML or it uses an invalid character set. 19 NETCONF Error Severity 0 1 NETCONF 'test-option' Element Content. 0 1 2 NETCONF 'error-option' Element Content stop-on-error 0 1 2 NETCONF 'filter' Attribute Content subtree 0 1 XPath string used in the select attribute. NETCONF 'operation' Attribute Content merge 0 1 2 3 4 NETCONF 'default-operation' Element Content merge 0 1 2 NETCONF 'confirm-timeout' Element Content seconds 600 Generic Capabilities List. false One Generic Capability URI. system NETCONF standard 'error-info' Element Content; Name of the missing or invalid XSD attribute. Used with missing-attribute, bad-attribute, and unknown-attribute error-tag values. false system Name of the element that contains (or should contain) an invalid XSD attribute when used with missing-attribute, bad-attribute, unknown-attribute, error-tag values. Name of an invalid or missing element when used with then missing-element, bad-element, unknown-element, and unknown-namespace error-tag values. false system Identifies an element in the data model for which the requested operation has been completed for that node and all its child nodes. This element can appear zero or more times in the 'error-info' container. Used with the partial-operation error-tag value. false system Identifies an element in the data model for which the requested operation has failed for that node and all its child nodes. This element can appear zero or more times in the 'error-info' container. Used with the partial-operation error-tag value. false system Identifies an element in the data model for which the requested operation was not attempted for that node and all its child nodes. This element can appear zero or more times in the <error-info> container. Used with the partial-operation error-tag value. false system Session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock. false NETCONF 'rpc-error' Element Content Defines the conceptual layer that the error occurred. true Contains a string identifying the error condition. true Contains a string identifying the error severity, as determined by the device. true Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute. Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information. NETCONF 'rpc-reply' Error and/or Data Content false system Defines the conceptual layer that the error occurred. true Contains a string identifying the error condition. true Contains a string identifying the error severity, as determined by the device. true Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute. Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information. NETCONF 'rpc-reply' OK Content. ok-or-error ok Sent in 'rpc-reply' messages if no errors or warnings occurred during the processing of an 'rpc' request. false rpc-error false system Defines the conceptual layer that the error occurred. true Contains a string identifying the error condition. true Contains a string identifying the error severity, as determined by the device. true Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute. Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information. Generic NETCONF 'rpc-reply' content. ok-or-data-error ok Sent in 'rpc-reply' messages if no errors or warnings occurred during the processing of an 'rpc' request. data-error false system Defines the conceptual layer that the error occurred. true Contains a string identifying the error condition. true Contains a string identifying the error severity, as determined by the device. true Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute. Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information. Remote Procedure Call request message true RFC 4741, section 4.1 http://www.ietf.org/rfc/rfc4741.txt MessageId message-id Remote Procedure Call response message true RFC 4741, section 4.2 http://www.ietf.org/rfc/rfc4741.txt MessageId message-id ok-or-data-error ok Sent in 'rpc-reply' messages if no errors or warnings occurred during the processing of an 'rpc' request. data-error false system Defines the conceptual layer that the error occurred. true Contains a string identifying the error condition. true Contains a string identifying the error severity, as determined by the device. true Contains a string identifying the data-model-specific or implementation-specific error condition, if one exists. This element will not be present if no appropriate application error tag can be associated with a particular error condition. Contains the absolute XPath [2] expression identifying the element path to the node that is associated with the error being reported in a particular rpc-error element. This element will not be present if no appropriate payload element can be associated with a particular error condition, or if the 'bad-element' QString returned in the 'error-info' container is sufficient to identify the node associated with the error. When the XPath expression is interpreted, the set of namespace declarations are those in scope on the rpc-error element, including the default namespace. Contains a string suitable for human display that describes the error condition. This element will not be present if no appropriate message is provided for a particular error condition. This element SHOULD include an xml:lang attribute. Contains protocol- or data-model-specific error content. This element will not be present if no such error content is provided for a particular error condition. The list in RFC 4741, Appendix A, defines any mandatory error-info content for each error. After any protocol-mandated content, a data model definition may mandate that certain application-layer error information be included in the error-info container. An implementation may include additional elements to provide extended and/or implementation-specific debugging information. Copy of the source database subset which matched the filter criteria (if any). true An empty data container indicates that the request did not produce any results. Retrieve all or part of a specified configuration. get-config_output_type__ RFC 4741, section 7.2 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to retrieve. config-source true candidate running startup This is optional-to-implement on the server because not all servers will support filtering for this database. Subtree or Xpath filter to use. FilterType type SelectString select The 'edit-config' operation loads all or part of a specified configuration to the specified target configuration. This operation allows the new configuration to be expressed in several ways, such as using a local file, a remote file, or inline. If the target configuration does not exist, it will be created. If a NETCONF peer supports the :url capability (Section 8.8), the <url> element can appear instead of the <config> parameter and should identify a local configuration file. The device analyzes the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced, as with the <copy-config> message. Instead, the target configuration is changed in accordance with the source's data and requested operations. edit-config_output_type__ RFC 4741, section 7.2 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to edit. config-target true candidate running Default operation to apply if not explicitly set. Test option if validate capability supported. The 'validate' capability must be present to set this object to 'test-then-set'. Error recovery option. edit-content true config Inline Config content: 'config' element. true url Pointer to Config content: 'url' element. Create or replace an entire configuration datastore with the contents of another complete configuration datastore. If the target datastore exists, it is overwritten. Otherwise, a new one is created, if allowed. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the <source> or <target> parameter. Even if it advertises the :writable-running capability, a device may choose not to support the <running/> configuration datastore as the <target> parameter of a <copy-config> operation. A device may choose not to support remote-to-remote copy operations, where both the <source> and <target> parameters use the <url> element. If the source and target parameters identify the same URL or configuration datastore, an error MUST be returned with an error- tag containing invalid-value. copy-config_output_type__ RFC 4741, section 7.3 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to copy to. config-target true candidate running This is optional-to-implement on the server. startup url Particular configuration to copy from. config-source true candidate running startup url config Inline Config content: 'config' element. Represents an entire 'stand-alone' configuration database, not a subset of the running database. true Delete a configuration datastore. The 'running' configuration datastore cannot be deleted. If a NETCONF peer supports the :url capability (Section 8.8), the 'url' element can appear as the <target> parameter. delete-config_output_type__ RFC 4741, section 7.4 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to delete. config-target true startup url The lock operation allows the client to lock the configuration system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non-NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users. ... lock_output_type__ RFC 4741, section 7.5 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to lock config-target true candidate running startup The unlock operation is used to release a configuration lock, previously obtained with the 'lock' operation. An unlock operation will not succeed if any of the following conditions are true: * the specified lock is not currently active * the session issuing the <unlock> operation is not the same session that obtained the lock The server MUST respond with either an <ok> element or an 'rpc-error'. unlock_output_type__ RFC 4741, section 7.6 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to unlock. config-target true candidate running startup Copy of the 'running' database subset and/or state data which matched the filter criteria (if any). true An empty data container indicates that the filter request did not match any results. Retrieve running configuration and device state information. get_output_type__ RFC 4741, section 7.7 http://www.ietf.org/rfc/rfc4741.txt This parameter specifies the portion of the system configuration and state data to retrieve. If this parameter is empty, all the device configuration and state information is returned. The filter element may optionally contain a 'type' attribute. This attribute indicates the type of filtering syntax used within the filter element. The default filtering mechanism in NETCONF is referred to as subtree filtering and is described in Section 6. The value 'subtree' explicitly identifies this type of filtering. If the NETCONF peer supports the :xpath capability (Section 8.9), the value 'xpath' may be used to indicate that the select attribute of the filter element contains an XPath expression. FilterType type string select Request graceful termination of a NETCONF session. When a NETCONF server receives a <close-session> request, it will gracefully close the session. The server will release any locks and resources associated with the session and gracefully close any associated connections. Any NETCONF requests received after a 'close-session' request will be ignored. close-session_output_type__ RFC 4741, section 7.8 http://www.ietf.org/rfc/rfc4741.txt Force the termination of a NETCONF session. When a NETCONF entity receives a <kill-session> request for an open session, it will abort any operations currently in process, release any locks and resources associated with the session, and close any associated connections. If a NETCONF server receives a <kill-session> request while processing a confirmed commit (Section 8.4), it must restore the configuration to its state before the confirmed commit was issued. Otherwise, the <kill-session> operation does not roll back configuration or other device state modifications made by the entity holding the lock. kill-session_output_type__ RFC 4741, section 7.9 http://www.ietf.org/rfc/rfc4741.txt Particular session to kill. true When a candidate configuration's content is complete, the configuration data can be committed, publishing the data set to the rest of the device and requesting the device to conform to the behavior described in the new configuration. To commit the candidate configuration as the device's new current configuration, use the <commit> operation. The 'commit' operation instructs the device to implement the configuration data contained in the candidate configuration. If the device is unable to commit all of the changes in the candidate configuration datastore, then the running configuration MUST remain unchanged. If the device does succeed in committing, the running configuration MUST be updated with the contents of the candidate configuration. If the system does not have the :candidate capability, the 'commit' operation is not available. commit_output_type__ RFC 4741, section 8.3.4.1 http://www.ietf.org/rfc/rfc4741.txt Request a confirmed commit. RFC 4741, section 8.4.5.1 http://www.ietf.org/rfc/rfc4741.txt Request a specific timeout period for a confirmed commit if 'confirmed-commit' capability supported. seconds RFC 4741, section 8.4.5.1 http://www.ietf.org/rfc/rfc4741.txt This parameter is used to make a confirmed commit persistent. A persistent confirmed commit is not aborted if the NETCONF session terminates. The only way to abort a persistent confirmed commit it to let the timer expire, or to use the cancel-commit operation. The value of this parameter is a token that must be given in the 'persist-id' parameter of commit or cancel-commit in order to confirm or cancel the persistent confirmed commit. The token should be a random string. RFC 6241, section 8.3.4.1. http://www.ietf.org/rfc/rfc6241.txt This parameter is given in order to commit a persistent confirmed commit. The value must be equal to the value given in the 'persist' parameter to the commit operation. If it does not match, the operation fails with an 'invalid-value' error. RFC 6241, section 8.3.4.1. http://www.ietf.org/rfc/rfc6241.txt If the client decides that the candidate configuration should not be committed, the 'discard-changes' operation can be used to revert the candidate configuration to the current running configuration. This operation discards any uncommitted changes by resetting the candidate configuration with the content of the running configuration. discard-changes_output_type__ RFC 4741, section 8.3.4.2 http://www.ietf.org/rfc/rfc4741.txt This operation is used to cancel an ongoing confirmed commit. If the confirmed commit is persistent, the parameter 'persist-id' must be given, and it must match the value of the 'persist' parameter. cancel-commit_output_type__ RFC 6241, section 8.4.4.1. http://www.ietf.org/rfc/rfc6241.txt This parameter is given in order to cancel a persistent confirmed commit. The value must be equal to the value given in the 'persist' parameter to the commit operation. If it does not match, the operation fails with an 'invalid-value' error. Validates the contents of the specified configuration. validate_output_type__ RFC 4741, section 8.6.4.1 http://www.ietf.org/rfc/rfc4741.txt Particular configuration to validate. config-source true candidate running startup url config Inline Config content: 'config' element. Represents an entire 'stand-alone' configuration database, not a subset of the running database. true Used as the container for NETCONF object definitions. true