]> Error List and Error Identities Registries for YANG-driven protocols Ionio Systems
per.ietf@ionio.se
Equinix
mithun.ietf@gmail.com
ops NETCONF Internet-Draft This document defines IANA registries for the YANG Protocol Error List and YANG Protocol Error Identities.
Introduction In order to have a canonical source for all errors and error identities for YANG-driven procotols such as NETCONF and RESTCONF , two IANA registries are defined: YANG Protocol Error List and YANG Protocol Error Identities. These registries can be extended and updated as needed. It is an advantage for protocol evolution to have canonical sources to extend, instead of a set of documents that need to be compiled and referenced.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
IANA Considerations
YANG Protocol Error List Registry This document defines a registry for the YANG Protocol Error List defined in Appendix A of and an error from . The name of the registry is "YANG Protocol Error List". The review policy for this registry is "IETF Review" . The registry shall record the following for each entry: error-tag, mandatory error-app-tag, optional error-type, mandatory error-severity, mandatory error-info, optional: auxilary information described as data nodes (XML tags). Description, mandatory Reference: The reference for the document registering the value. Mandatory. The initial contents of the registry is defined in and inlined below:
: name of the missing attribute : name of the element that is supposed to contain the missing attribute Description: An expected attribute is missing. Reference: RFC 6241 error-tag: bad-attribute error-type: rpc, protocol, application error-severity: error error-info: : name of the attribute w/ bad value : name of the element that contains the attribute with the bad value Description: An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch. Reference: RFC 6241 error-tag: unknown-attribute error-type: rpc, protocol, application error-severity: error error-info: : name of the unexpected attribute : name of the element that contains the unexpected attribute Description: An unexpected attribute is present. Reference: RFC 6241 error-tag: missing-element error-type: protocol, application error-severity: error error-info: : name of the missing element Description: An expected element is missing. Reference: RFC 6241 error-tag: bad-element error-type: protocol, application error-severity: error error-info: : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. Reference: RFC 6241 error-tag: unknown-element error-type: protocol, application error-severity: error error-info: : name of the unexpected element Description: An unexpected element is present. Reference: RFC 6241 error-tag: unknown-namespace error-type: protocol, application error-severity: error error-info: : name of the element that contains the unexpected namespace : name of the unexpected namespace Description: An unexpected namespace is present. Reference: RFC 6241 error-tag: access-denied error-type: protocol, application error-severity: error error-info: none Description: Access to the requested protocol operation or data model is denied because authorization failed. Reference: RFC 6241 error-tag: lock-denied error-type: protocol error-severity: error error-info: : session ID of session holding the requested lock, or zero to indicate a non-NETCONF entity holds the lock Description: Access to the requested lock is denied because the lock is currently held by another entity. Reference: RFC 6241 error-tag: resource-denied error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: Request could not be completed because of insufficient resources. Reference: RFC 6241 error-tag: rollback-failed error-type: protocol, application error-severity: error error-info: none Description: Request to roll back some configuration change (via rollback-on-error or operations) was not completed for some reason. Reference: RFC 6241 error-tag: data-exists error-type: application error-severity: error error-info: none Description: 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. Reference: RFC 6241 error-tag: data-missing error-type: application error-severity: error error-info: none Description: 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. Reference: RFC 6241 error-tag: operation-not-supported error-type: protocol, application error-severity: error error-info: none Description: Request could not be completed because the requested operation is not supported by this implementation. Reference: RFC 6241 error-tag: partial-operation error-type: application error-severity: error error-info: : 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 container. : 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 container. : 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 container. Reference: RFC 6241 Description: This error-tag is obsolete, and SHOULD NOT be sent by servers conforming to this document. Some part of the requested operation failed or was not attempted for some reason. Full cleanup has not been performed (e.g., rollback not supported) by the server. The error-info container is used to identify which portions of the application data model content for which the requested operation has succeeded (), failed (), or not been attempted (). Reference: RFC 6241 error-tag: malformed-message error-type: rpc error-severity: error error-info: none Description: 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. This error-tag is new in :base:1.1 and MUST NOT be sent to old clients. Reference: RFC 6241 error-tag: operation-failed error-app-tag: loop-detected error-type: transport, application error-info: : A copy of the Via header field when the loop was detected. Description: An infinite loop has been detected when forwarding a requests via a proxy. Reference: RFC 8783 ]]>
YANG Protocol Error Identities Registry This document defines a registry for YANG Protocol Error Identities. The name of the registry is "YANG Protocol Error Identities". The review policy for this registry is "IETF Review" . The registry shall record the following for each entry: Identity name. Base identity, if applicable. Additional information. The reference for the document registering the value. The initial contents of the registry is defined in and and inlined below:
Network Configuration Protocol (NETCONF) The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] RESTCONF Protocol This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Subscription to YANG Notifications This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. Subscription to YANG Notifications for Datastore Updates This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782). Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
Acknowledgments TODO acknowledge.