]> Ionio Systems

per.ietf@ionio.se

Equinix

mithun.ietf@gmail.com

ops NETCONF Internet-Draft This document defines IANA registries for the NETCONF Error List and NETCONF Error Identities.

Introduction In order to have a canonical source for all NETCONF Error and NETCONF Error Identities, two IANA registries are defined. 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

NETCONF Error List Registry This document defines a registry for the NETCONF Error List defined in Appendix A of . The name of the registry is "NETCONF Error List". The review policy for this registry is "IETF Review" . The registry shall record the following for each entry: error-tag, TBD error-type, TBD error-severity, TBD error-info, auxilary information described as data nodes (XML tags). Description The reference for the document registering the value. 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. 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. ]]>

NETCONF Error Identities This document defines a registry for NETCONF Error Identities. The name of the registry is "NETCONF 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:

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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] 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. 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. 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. 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.