YANG Data Model for System ManagementYumaWorksandy@yumaworks.comTail-f Systemsmbj@tail-f.com
This document defines a YANG data model for the configuration
and identification of the management system of a device.
This document defines a YANG data model for the
configuration and identification of the management system of a device.
Devices that are managed by NETCONF and perhaps other mechanisms
have common properties that need to be configured and monitored
in a standard way.
The "ietf‑system" YANG module defined in this document provides the
following features:
system administrative data configuration
system identification monitoring
system time-of-day configuration and monitoring
user authentication configuration
local users configuration
The keywords "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, .
The following terms are used within this document:
system: This term refers to the embodiment
of the entire set of management interfaces that a
single NETCONF server is supporting
at a given moment. The set of physical entities
managed by a single NETCONF server can be static
or it can change dynamically.
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these
diagrams is as follows:
Brackets "[" and "]" enclose list keys.
Abbreviations before data node names: "rw" means configuration
(read-write) and "ro" state data (read-only).
Symbols after data node names: "?" means an optional node and "*"
denotes a "leaf‑list".
Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
Ellipsis ("...") stands for contents of subtrees that are not shown.
There are many common properties used to identify devices,
operating systems, software versions, etc. that need to
be supported in the system data module.
These objects are defined
as operational data and intended to be specific to the
device vendor.
Some user-configurable administrative strings are also
provided such as the system location and description.
The management of the date and time used by the system
need to be supported. Use of one or more NTP servers
to automatically set the system date and time need to be possible.
Utilization of the Timezone database
also need to be supported.
The authentication mechanism need to support password authentication over
RADIUS, to support deployment scenarios with centralized
authentication servers. Additionally, local users need to be supported,
for scenarios when no centralized authentication server exists, or for
situations where the centralized authentication server cannot be
reached from the device.
Since the mandatory transport protocol for NETCONF is SSH
the authentication model need to support
SSH's "publickey" and "password" authentication methods .
The model for authentication configuration should be flexible enough
to support authentication methods defined by other standard documents
or by vendors.
The data model for system identification has the following
structure:
The data model for system time management has the following
structure:
The data model for configuration of the DNS resolver has the following
structure:
The data model for configuration of the RADIUS client has the
following structure:
This document defines three authentication methods for use with
NETCONF:
publickey for local users over SSH
password for local users over any transport
password for RADIUS users over any transport
Additional methods can be defined by other standard documents or by
vendors.
This document defines two optional YANG features, "local‑users" and
"radius‑authentication", which the server advertises to indicate
support for configuring local users on the device, and support for
using RADIUS for authentication, respectively.
The authentication parameters defined in this document are primarily
used to configure authentication of NETCONF users, but MAY also be
used by other interfaces, e.g., a Command Line Interface or a
Web-based User Interface.
The data model for user authentication has the following structure:
If the NETCONF server advertises the "local‑users" feature,
configuration of local users and their SSH public keys is supported in
the /system/authentication/user list.
Public key authentication is requested by the SSH client. If the
"local‑users" feature is supported, then when a NETCONF client starts
an SSH session towards the server using the "publickey" authentication
"method name" , the SSH server looks up the user name given
in the SSH authentication request in the /system/authentication/user
list, and verifies the key as described in .
If the NETCONF server advertises the "local‑users" feature,
configuration of local users and their passwords is supported in the
/system/authentication/user list.
For NETCONF transport protocols that support password authentication,
the leaf-list "user‑authentication‑order" is used to control if local
user password authentication should be used.
In SSH, password authentication is requested by the client. Other
NETCONF transport protocols MAY also support password authentication.
When local user password authentication is requested, the NETCONF
transport looks up the user name provided by the client in the
/system/ authentication/user list, and verifies the password.
If the NETCONF server advertises the "radius‑authentication" feature,
the device supports user authentication using RADIUS.
For NETCONF transport protocols that support password authentication,
the leaf-list "user‑authentication‑order" is used to control if RADIUS
password authentication should be used.
In SSH, password authentication is requested by the client. Other
NETCONF transport protocols MAY also support password authentication.
Two protocol operations are included to restart or shutdown
the system. The 'system‑restart' operation can be used to
restart the entire system (not just the NETCONF server).
The 'system‑shutdown' operation can be used to power off
the entire system.
This YANG module imports YANG extensions from
, and imports YANG types from
and .
It also references , , , ,
, and .
RFC Ed.: update the date below with the date of RFC publication and
remove this note.
<CODE BEGINS> file "ietf-system@2013-02-25.yang"<CODE ENDS>
This document registers one URI in the IETF XML registry
. Following the format in RFC 3688, the following
registration is requested to be made.
This document registers one YANG module in the YANG Module Names
registry .
The YANG module defined in this memo is designed to be accessed
via the NETCONF protocol . The lowest NETCONF layer is
the secure transport layer and the mandatory-to-implement secure
transport is SSH .
There are a number of data nodes defined in this YANG module
which are writable/creatable/deletable (i.e., config true, which
is the default). These data nodes may be considered sensitive
or vulnerable in some network environments. Write operations
(e.g., edit-config) to these data nodes without proper protection
can have a negative effect on network operations. These are
the subtrees and data nodes and their sensitivity/vulnerability:
/system/clock/timezone: This choice contains the objects used to
control the timezone used by the device.
/system/ntp: This container contains the objects used to
control the Network Time Protocol servers used by the device.
/system/dns: This container contains the objects used to
control the Domain Name System servers used by the device.
/system/radius: This container contains the objects used to
control the Remote Authentication Dial-In User Service
servers used by the device.
/system/authentication/user-authentication-order: This leaf
controls how user login attempts are authenticated by the device.
/system/authentication/user: This list contains the
local users enabled on the system.
Some of the readable data nodes in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g., via get,
get-config, or notification) to these data nodes. These are the
subtrees and data nodes and their sensitivity/vulnerability:
/system/platform: This container has objects which may help
identify the specific NETCONF server and/or operating system
implementation used on the device.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the
operations and their sensitivity/vulnerability:
set-current-datetime: Changes the current date and time on the device.
system-restart: Reboots the device.
system-shutdown: Shuts down the device.
added configuration-source identities
added configuration-source leaf to ntp and dns (via grouping) to
choose configuration source
added association-type, iburst, prefer, and true leafs to the
ntp-server list
extended the ssh keys for a user to a list of keys. support all
defined key algorithms, not just dsa and rsa
clarified timezone-utc-offset description-stmt
removed '/system/ntp/server/true' leaf from data model
added default-stmts to ntp-server/iburst and ntp-server/prefer leafs
changed timezone-location leaf to use iana-timezone typedef instead
of a string
removed configuration-source identities and leafs
removed ndots dns resolver option
added radius-authentication-type identity, and identities for pap
and chap, and a leaf to control which authentication type to use
when communicating with the radius server
made 0 an invalid value for timeouts and attempts
updated tree diagram explanation text
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityIn 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.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.The Secure Shell (SSH) Authentication ProtocolThe Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]The Secure Shell (SSH) Transport Layer ProtocolThe Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network.</t><t> This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression.</t><t> Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated.</t><t> This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. [STANDARDS-TRACK]Network Configuration Protocol (NETCONF)Using the NETCONF Protocol over Secure Shell (SSH)This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]Procedures for Maintaining the Time Zone DatabaseTime zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. This memo documents an Internet Best Current Practice.Network Configuration Protocol (NETCONF) Access Control ModelThe standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS TRACK]Common YANG Data TypesThis document introduces a collection of common data types to be used with the YANG data modeling language. [STANDARDS-TRACK]The MD5 Message-Digest AlgorithmMassachusetts Institute of Technology, (MIT) Laboratory for Computer Science545 Technology SquareNE43-324CambridgeMA02139-1986US+1 617 253 5880rivest@theory.lcs.mit.eduRemote Authentication Dial In User Service (RADIUS)This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)This document defines managed objects which describe the behavior of a Simple Network Management Protocol (SNMP) entity. This document obsoletes RFC 1907, Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). [STANDARDS-TRACK]Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) ManagementThis document specifies Remote Authentication Dial-In User Service (RADIUS) attributes for authorizing management access to a Network Access Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. [STANDARDS-TRACK]Secure Hash StandardNational Institute of Standards and TechnologyPOSIX.1-2008Institute of Electrical and Electronics EngineersIANA Timezone Database YANG ModuleGE Digital Energy