IETF NETCONF (Network Configuration) Working Group WG Web: <http://tools.ietf.org/wg/netconf/> WG List: <mailto:netconf@ietf.org> WG Chair: Mehmet Ersue <mailto:mehmet.ersue@nsn.com> WG Chair: Bert Wijnen <mailto:bertietf@bwijnen.net> Editor: Mark Scott <mailto:mark.scott@ericsson.com> Editor: Martin Bjorklund <mailto:mbj@tail-f.com> NETCONF Monitoring Module. All elements in this module are read-only. Copyright (c) 2010 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 6022; see the RFC itself for full legal notices. Initial revision. RFC 6022: YANG Module for NETCONF Monitoring Enumeration of possible NETCONF datastore types. RFC 4741: NETCONF Configuration Protocol Base identity for NETCONF transport types. NETCONF over Secure Shell (SSH). RFC 4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) NETCONF over Simple Object Access Protocol (SOAP) over Blocks Extensible Exchange Protocol (BEEP). RFC 4743: Using NETCONF over the Simple Object Access Protocol (SOAP) NETCONF over Simple Object Access Protocol (SOAP) over Hypertext Transfer Protocol Secure (HTTPS). RFC 4743: Using NETCONF over the Simple Object Access Protocol (SOAP) NETCONF over Blocks Extensible Exchange Protocol (BEEP). RFC 4744: Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) NETCONF over Transport Layer Security (TLS). RFC 5539: NETCONF over Transport Layer Security (TLS) Base identity for data model schema languages. W3C XML Schema Definition. W3C REC REC-xmlschema-1-20041028: XML Schema Part 1: Structures The YANG data modeling language for NETCONF. RFC 6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) The YIN syntax for YANG. RFC 6020: YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) Regular Language for XML Next Generation (RELAX NG). ISO/IEC 19757-2:2008: RELAX NG Relax NG Compact Syntax ISO/IEC 19757-2:2008: RELAX NG Counters that exist both per session, and also globally, accumulated from all sessions. Number of correct <rpc> messages received. Number of messages received when an <rpc> message was expected, that were not correct <rpc> messages. This includes XML parse errors and errors on the rpc layer. Number of <rpc-reply> messages sent that contained an <rpc-error> element. Number of <notification> messages sent. The netconf-state container is the root of the monitoring data model. Contains the list of NETCONF capabilities supported by the server. List of NETCONF capabilities supported by the server. Contains the list of NETCONF configuration datastores. List of NETCONF configuration datastores supported by the NETCONF server and related information. Name of the datastore associated with this list entry. The NETCONF <lock> and <partial-lock> operations allow a client to lock specific resources in a datastore. The NETCONF server will prevent changes to the locked resources by all sessions except the one that acquired the lock(s). Monitoring information is provided for each datastore entry including details such as the session that acquired the lock, the type of lock (global or partial) and the list of locked resources. Multiple locks per datastore are supported. Lock related parameters, common to both global and partial locks. The session ID of the session that has locked this resource. Both a global lock and a partial lock MUST contain the NETCONF session-id. If the lock is held by a session that is not managed by the NETCONF server (e.g., a CLI session), a session id of 0 (zero) is reported. RFC 4741: NETCONF Configuration Protocol The date and time of when the resource was locked. Indicates if a global lock or a set of partial locks are set. Present if the global lock is set. List of partial locks. RFC 5717: Partial Lock Remote Procedure Call (RPC) for NETCONF This is the lock id returned in the <partial-lock> response. The xpath expression that was used to request the lock. The select expression indicates the original intended scope of the lock. The list of instance-identifiers (i.e., the locked nodes). The scope of the partial lock is defined by the list of locked nodes. Contains the list of data model schemas supported by the server. List of data model schemas supported by the server. Identifier to uniquely reference the schema. The identifier is used in the <get-schema> operation and may be used for other purposes such as file retrieval. For modeling languages that support or require a data model name (e.g., YANG module name) the identifier MUST match that name. For YANG data models, the identifier is the name of the module or submodule. In other cases, an identifier such as a filename MAY be used instead. Version of the schema supported. Multiple versions MAY be supported simultaneously by a NETCONF server. Each version MUST be reported individually in the schema list, i.e., with same identifier, possibly different location, but different version. For YANG data models, version is the value of the most recent YANG 'revision' statement in the module or submodule, or the empty string if no 'revision' statement is present. The data modeling language the schema is written in (currently xsd, yang, yin, rng, or rnc). For YANG data models, 'yang' format MUST be supported and 'yin' format MAY also be provided. The XML namespace defined by the data model. For YANG data models, this is the module's namespace. If the list entry describes a submodule, this field contains the namespace of the module to which the submodule belongs. One or more locations from which the schema can be retrieved. This list SHOULD contain at least one entry per schema. A schema entry may be located on a remote file system (e.g., reference to file system for ftp retrieval) or retrieved directly from a server supporting the <get-schema> operation (denoted by the value 'NETCONF'). The sessions container includes session-specific data for NETCONF management sessions. The session list MUST include all currently active NETCONF sessions. All NETCONF sessions managed by the NETCONF server MUST be reported in this list. Unique identifier for the session. This value is the NETCONF session identifier, as defined in RFC 4741. RFC 4741: NETCONF Configuration Protocol Identifies the transport for each session, e.g., 'netconf-ssh', 'netconf-soap', etc. The username is the client identity that was authenticated by the NETCONF transport protocol. The algorithm used to derive the username is NETCONF transport protocol specific and in addition specific to the authentication mechanism used by the NETCONF transport protocol. Host identifier of the NETCONF client. The value returned is implementation specific (e.g., hostname, IPv4 address, IPv6 address) Time at the server at which the session was established. Per-session counters. Zero based with following reset behaviour: - at start of a session - when max value is reached Statistical data pertaining to the NETCONF server. Date and time at which the management subsystem was started. Number of sessions silently dropped because an invalid <hello> message was received. This includes <hello> messages with a 'session-id' attribute, bad namespace, and bad capability declarations. Number of sessions started. This counter is incremented when a <hello> message with a <session-id> is sent. 'in-sessions' - 'in-bad-hellos' = 'number of correctly started netconf sessions' Number of sessions that were abnormally terminated, e.g., due to idle timeout or transport close. This counter is not incremented when a session is properly closed by a <close-session> operation, or killed by a <kill-session> operation. Global counters, accumulated from all sessions. Zero based with following reset behaviour: - re-initialization of NETCONF server - when max value is reached This operation is used to retrieve a schema from the NETCONF server. Positive Response: The NETCONF server returns the requested schema. Negative Response: If requested schema does not exist, the <error-tag> is 'invalid-value'. If more than one schema matches the requested parameters, the <error-tag> is 'operation-failed', and <error-app-tag> is 'data-not-unique'. Identifier for the schema list entry. Version of the schema requested. If this parameter is not present, and more than one version of the schema exists on the server, a 'data-not-unique' error is returned, as described above. The data modeling language of the schema. If this parameter is not present, and more than one formats of the schema exists on the server, a 'data-not-unique' error is returned, as described above.

Contains the schema content.