Internet Engineering Task Force (IETF) M. Scott
Request for Comments: 6022 Ericsson
Category: Standards Track M. Bjorklund
ISSN: 2070-1721 Tail-f Systems
October 2010
YANG Module for NETCONF Monitoring
Модуль YANG для мониторинга NETCONF
Аннотация
В этом документе определена модель данных протокола управления сетью (Network Configuration Protocol или NETCONF) для мониторинга протокола NETCONF. Данные мониторинга включают сведения о хранилищах данных, сессиях, блокировках и статистике NETCONF, упрощающие управление сервером NETCONF. Документ также определяет для клиентов NETCONF методы обнаружения моделей данных, поддерживаемых сервером NETCONF, и новую операцию NETCONF <get-schema> для их извлечения.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 RFC 5741.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc6022.
Авторские права
Авторские права (Copyright (c) 2010) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.
1. Введение
Этот документ задаёт модель YANG [RFC6020] для мониторинга протокола NETCONF. Модель обеспечивает сведения о сессиях NETCONF и поддерживаемой схеме, как указано в [RFC4741].
Такие факторы, как разные форматы схем, необязательность функций (feature) и контроль доступа могут влиять на применимость и уровень детализации, которые сервер NETCONF передаёт клиенту при организации сессии. Заданные этим документом методы учитывают потребность в дополнительных средствах для запроса и извлечения сведений о схеме и состоянии NETCONF с сервера NETCONF. Они дополняют имеющиеся базовые возможности и операции NETCONF, не влияя на поведение сервера.
Определена новая операция <get-schema> для поддержки явного получения схемы через NETCONF.
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119].
2. Модель данных для мониторинга NETCONF
Заданная в этом документе модель данных для мониторинга NETCONF обеспечивает эксплуатационные сведения о сервере NETCONF. Это включает детали протокола NETCONF (например, протокольные счётчики, такие как in-sessions), а также данные, связанные с извлечением схем (например, список схем).
Сервер, реализующий эту модель (urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring), должен анонсировать возможность URI, как описано в [RFC6020].
В этом разделе представлен обхор модели данных для мониторинга. Подробное описание приведено в модуле YANG (5. Модель данных мониторинга NETCONF).
2.1. Ветвь /netconf-state
Контейнер netconf-state является корнем модели данных для мониторинга.
netconf-state
/capabilities
/datastores
/schemas
/sessions
/statistics
capabilities
Список возможностей NETCONF, поддерживаемых сервером.datastores
Список конфигурационных хранилищ NETCONF (например, running, startup, candidate), поддерживаемых устройством, и связанные с этим сведения.schemas
Список поддерживаемых сервером схем, включая сведения для идентификации схем и поддержки их извлечения.sessions
Список активных сессий NETCONF на устройстве, включая счётчики на уровне сессий для всех сессий NETCONF.statistics
Глобальные счётчики сервера NETCONF.2.1.1. Ветвь /netconf-state/capabilities
Ветвь /netconf-state/capabilities содержит возможности, поддерживаемые сервером NETCONF. Список должен включать все возможности, передаваемые в процессе организации сессии, которые применимы на момент запроса.
2.1.2. Ветвь /netconf-state/datastores
Ветвь /netconf-state/datastores содержит список всех доступных на сервере NETCONF хранилищ данных и сведения о состоянии их блокировки.
datastore
/name
/locks
name (leaf, netconf-datastore-type)
Перечисление поддерживаемых хранилищ – candidate, running, startup.locks (grouping, lock-info)
Список блокировок для хранилища данных с указанием глобальной и частичной блокировки [RFC5717]. Для частичных блокировок возвращается список заблокированных узлов и выражения, исходно применявшиеся для запроса блокировки.2.1.3. Ветвь /netconf-state/schemas
Список поддерживаемых сервером NETCONF схем.
schema
/identifier (key)
/version (key)
/format (key)
/namespace
/location
Элементы identifier, version, format служат ключами для списка схем и применяются в операции <get-schema>.
identifier (string)
Идентификатор записи списка схем, используемый в операции <get-schema>, который может применяться также иными методами, такими как извлечение файла.version (string)
Версия поддерживаемой схемы. Сервер NETCONF может одновременно поддерживать несколько версий. Каждая версия должна индивидуально указываться в списке, идентификаторы совпадают, местоположения могут различаться, а версии разные. Для моделей данных YANG версия указывается значением наиболее свежего оператора YANG revision в модуле или субмодуле или пустой строкой при отсутствии оператора revision.format (identifyref, schema-format)
Язык моделирования данных, использованный в схеме. Язык представляется как идентификатор (отождествление) YANG. Этот документ задаёт идентификаторы xsd, yang, yin, rng, rnc (5. Модель данных мониторинга NETCONF).namespace (inet:uri)
Пространство имён расширяемого языка разметки (Extensible Markup Language или XML) [XML-NAMES], заданное схемой.location (union: enum, inet:uri)
Одно или несколько мест, откуда можно извлечь эту схему. Для каждой схемы следует указывать хотя бы 1 место.2.1.4. Ветвь /netconf-state/sessions
Список сведений о сеансах управления NETCONF, который должен включать все активные сессии NETCONF.
session
/session-id (key)
/transport
/username
/source-host
/login-time
/in-rpcs
/in-bad-rpcs
/out-rpc-errors
/out-notifications
session-id (uint32, 1..max)
Уникальный идентификатор сессии NETCONF, как указано в [RFC4741].transport (identityref, transport)
Указывает транспорт для каждой сессии, представляемый идентификатором YANG. Этот документ определяет netconf-ssh, netconf-soap-over-beep, netconf-soap-over-https, netconf-beep, netconf-tls (см. раздел 5).username (string)
Идентификатор клиента, который был аутентифицирован транспортным протоколом NETCONF. Алгоритм выведения имени пользователя зависит от транспорта NETCONF и применяемого механизма аутентификации.source-host (inet:host)
Идентификатор хоста (IP-адрес или имя) клиента NETCONF.login-time (yang:date-and-time)
Время организации сессии по часам сервера.in-rpcs (yang:zero-based-counter32)
Число полученных корректных сообщений <rpc>.in-bad-rpcs (yang:zero-based-counter32)
Число сообщений, полученных, когда ожидалось сообщение <rpc>, и не являющихся корректными сообщениями <rpc>. Это включает ошибки синтаксического анализа XML и ошибки на уровне rpc.out-rpc-errors (yang:zero-based-counter32)
Число сообщения <rpc-reply>, переданных с элементом <rpc-error>.out-notifications (yang:zero-based-counter32)
Число переданных сообщения <notification>.2.1.5. Ветвь /netconf-state/statistics
Статистика производительности сервера NETCONF.
statistics
/netconf-start-time
/in-bad-hellos
/in-sessions
/dropped-sessions
/in-rpcs
/in-bad-rpcs
/out-rpc-errors
/out-notifications
statistics
Данные производительности сервера NETCONF, относящиеся к сеансам управления.netconf-start-time (yang:date-and-time)
Дата и время начала работы подсистемы управления.in-bad-hellos (yang:zero-based-counter32)
Число сеансов, отброшенных без уведомления по получению недействительного сообщения <hello>.in-sessions (yang:zero-based-counter32)
Число запущенных сессий.dropped-sessions (yang:zero-based-counter32)
Число сессий с аномальным завершением, например, по тайм-ауту или закрытию транспорта.in-rpcs (yang:zero-based-counter32)
Число принятых корректных сообщений <rpc>.in-bad-rpcs (yang:zero-based-counter32)
Число сообщений, полученных, когда ожидалось сообщение <rpc>, не являющихся корректными сообщениями <rpc>.out-rpc-errors (yang:zero-based-counter32)
Число сообщения <rpc-reply> переданных с элементом <rpc-error>.out-notifications (yang:zero-based-counter32)
Число переданных сообщений <notification>.3. Зависящие от схемы операции
3.1. <get-schema>
Эта операция служит для извлечения схемы с сервера NETCONF.
Параметры
identifier (string)
Идентификатор записи в списке схем. Обязательный параметр.version (string)
Запрашиваемая версия схемы. Необязательный параметр.format (identityref, schema-format)
Язык моделирования данных в схеме (по умолчанию yang). Необязательный параметр.Позитивный отклик
Сервер NETCONF возвращает запрошенную схему.
Негативный отклик
Если запрошенной схемы нет, возвращается <error-tag> invalid-value. Если запросу соответствует несколько схем, возвращается <error-tag> operation-failed и <error-app-tag> data-not-unique.
4. Примеры
4.1. Извлечение списка схем с помощью <get>
Клиент NETCONF получает список поддерживаемых схем от сервера NETCONF, извлекая ветвь /netconf-state/schemas с помощью операции <get>. Доступная схема для запрашивающей сессии возвращается в отклике с элементами <identifier>, <version>, <format>, <location>. Данные отклика можно использовать для определения доступной схемы и её версий. Сама схема (т. е. содержимое) не возвращается в отклике. Необязательный элемент <location> содержит URI, который можно использовать для извлечения схемы по другому протоколу, такому как ftp [RFC0959] или http(s) [RFC2616] [RFC2818], или специальное значение NETCONF, указывающее, что схему можно извлечь с помощью операции <get-schema>. Пример запроса приведён ниже.
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<netconf-state xmlns=
"urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas/>
</netconf-state>
</filter>
</get>
</rpc>
Сервер NETCONF возвращает список схем, доступных для извлечения.
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data>
<netconf-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<schemas>
<schema>
<identifier>foo</identifier>
<version>1.0</version>
<format>xsd</format>
<namespace>http://example.com/foo</namespace>
<location>ftp://ftp.example.com/schemas/foo_1.0.xsd</location>
<location>http://www.example.com/schema/foo_1.0.xsd</location>
<location>NETCONF</location>
</schema>
<schema>
<identifier>foo</identifier>
<version>1.1</version>
<format>xsd</format>
<namespace>http://example.com/foo</namespace>
<location>ftp://ftp.example.com/schemas/foo_1.1.xsd</location>
<location>http://www.example.com/schema/foo_1.1.xsd</location>
<location>NETCONF</location>
</schema>
<schema>
<identifier>bar</identifier>
<version>2008-06-01</version>
<format>yang</format>
<namespace>http://example.com/bar</namespace>
<location>
http://example.com/schema/bar@2008-06-01.yang
</location>
<location>NETCONF</location>
</schema>
<schema>
<identifier>bar-types</identifier>
<version>2008-06-01</version>
<format>yang</format>
<namespace>http://example.com/bar</namespace>
<location>
http://example.com/schema/bar-types@2008-06-01.yang
</location>
<location>NETCONF</location>
</schema>
</schemas>
</netconf-state>
</data>
</rpc-reply>
4.2. Извлечение экземпляров схем
На основе отклика из предыдущего параграфа ниже приведены примеры извлечения схем foo, bar, bar-types в нескольких форматах из нескольких мест.
-
Foo версии 1.0 в формате xsd:
-
по протоколу FTP из ftp://ftp.example.com/schemas/foo_1.0.xsd;
-
по протоколу HTTP из http://www.example.com/schema/foo_1.0.xsd;
-
с помощью <get-schema> с указанием идентификатора, версии и сормата
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <identifier>foo</identifier> <version>1.0</version> <format>xsd</format> </get-schema> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <!-- Здесь размещается содержимое схемы foo 1.0 xsd --> </xs:schema> </data></rpc-reply>
-
-
bar версии 2008-06-01 в формате YANG:
-
по протоколу HTTP из http://example.com/schema/bar@2008-06-01.yang;
-
с помощью <get-schema> с параметрами идентификатора и версии
<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-schema xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <identifier>bar</identifier> <version>2008-06-01</version> </get-schema> </rpc> <rpc-reply message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> module bar { // Возвращён принятый по умолчанию формат (yang) // Содержимое модуля yang bar версии 2008-06-01 } </data> </rpc-reply> -
-
bar-types версии 2008-06-01 в принятом по умолчанию формате YANG:
-
с помощью <get-schema> с параметром identifier
-
<rpc message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-schema
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
<identifier>bar-types</identifier>
</get-schema>
</rpc>
<rpc-reply message-id="103"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring">
module bar-types {
// Возвращён принятый по умолчанию формат (yang)
// Содержимое модуля yang bar-types последней версии (2008-06-01)
}
</data>
</rpc-reply>
5. Модель данных мониторинга NETCONF
Ниже представлена модель данных YANG заданная этим документом. Модуль YANG импортирует определения типов из [RFC6021] и ссылается на [RFC4741], [RFC4742], [RFC4743], [RFC4744], [RFC5539], [xmlschema-1], [RFC6020], [ISO/IEC19757-2:2008], [RFC5717].
<CODE BEGINS> file "ietf-netconf-monitoring@2010-10-04.yang"
module ietf-netconf-monitoring {
namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring";
prefix "ncm";
import ietf-yang-types { prefix yang; }
import ietf-inet-types { prefix inet; }
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"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>";
description
"Модуль мониторинга NETCONF. Все элементы доступны лишь для чтения.
Авторские права (Copyright (c) 2010) принадлежат IETF Trust
и лицам, указанным в качестве авторов кода. Все права защищены.
Распространение и использование в исходной или двоичной форме с
изменениями или без таковых разрешено в соответствии с лицензией
Simplified BSD, изложенной в разделе 4 IETF Trust's Legal
Provisions применительно к документам IETF
(http://trustee.ietf.org/license-info).
Эта версия данного модуля YANG является частью RFC 6022, где
правовые вопросы рассмотрены более полно.";
revision 2010-10-04 {
description
"Initial revision.";
reference
"RFC 6022: YANG Module for NETCONF Monitoring";
}
typedef netconf-datastore-type {
type enumeration {
enum running;
enum candidate;
enum startup;
}
description
"Перечисление возможных типов хранилищ NETCONF.";
reference
"RFC 4741: NETCONF Configuration Protocol";
}
identity transport {
description
"базовый идентификатор для типов транспорта NETCONF.";
}
identity netconf-ssh {
base transport;
description
"NETCONF по протоколу SSH.";
reference
"RFC 4742: Using the NETCONF Configuration Protocol
over Secure SHell (SSH)";
}
identity netconf-soap-over-beep {
base transport;
description
"NETCONF по протоколу SOAP на основе протокола BEEP.";
reference
"RFC 4743: Using NETCONF over the Simple Object
Access Protocol (SOAP)";
}
identity netconf-soap-over-https {
base transport;
description
"NETCONF по протоколу SOAP на основе протокола HTTPS.";
reference
"RFC 4743: Using NETCONF over the Simple Object
Access Protocol (SOAP)";
}
identity netconf-beep {
base transport;
description
"NETCONF по протоколу BEEP.";
reference
"RFC 4744: Using the NETCONF Protocol over the
Blocks Extensible Exchange Protocol (BEEP)";
}
identity netconf-tls {
base transport;
description
"NETCONF по протоколу TLS.";
reference
"RFC 5539: NETCONF over Transport Layer Security (TLS)";
}
identity schema-format {
description
"Базовый идентификатор языка моделирования данных в схеме.";
}
identity xsd {
base schema-format;
description
"Определение схемы W3C XML.";
reference
"W3C REC REC-xmlschema-1-20041028:
XML Schema Part 1: Structures";
}
identity yang {
base schema-format;
description
"Язык моделирования данных YANG для NETCONF.";
reference
"RFC 6020: YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)";
}
identity yin {
base schema-format;
description
"Синтаксис YIN для YANG.";
reference
"RFC 6020: YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)";
}
identity rng {
base schema-format;
description
"Обычный язык для XML Next Generation (RELAX NG).";
reference
"ISO/IEC 19757-2:2008: RELAX NG";
}
identity rnc {
base schema-format;
description
"Компактный синтаксис Relax NG";
reference
"ISO/IEC 19757-2:2008: RELAX NG";
}
grouping common-counters {
description
"Счётчики для сессий и глобальные с данными от всех сессий.";
leaf in-rpcs {
type yang:zero-based-counter32;
description
"Число принятых корректных сообщений <rpc>.";
}
leaf in-bad-rpcs {
type yang:zero-based-counter32;
description
"Число сообщений, полученных при ожидании <rpc>, которые не были
корректными сообщениями <rpc>. Учитываются ошибки анализа XML и
ошибки на уровне rpc.";
}
leaf out-rpc-errors {
type yang:zero-based-counter32;
description
"Число переданных сообщений <rpc-reply> с <rpc-error>.";
}
leaf out-notifications {
type yang:zero-based-counter32;
description
"Число переданных сообщений <notification>.";
}
}
container netconf-state {
config false;
description
"Контейнер netconf-state является корнем для модели данных
мониторинга.";
container capabilities {
description
"Список поддерживаемых сервером возможностей NETCONF.";
leaf-list capability {
type inet:uri;
description
"Список поддерживаемых сервером возможностей NETCONF.";
}
}
container datastores {
description
"Список хранилищ конфигурации NETCONF.";
list datastore {
key name;
description
"Список хранилищ конфигурации NETCONF, поддерживаемых
сервером NETCONF, и связанных с ними сведений.";
leaf name {
type netconf-datastore-type;
description
"Имя хранилища, связанного с этой записью списка.";
}
container locks {
presence
"Этот контейнер присутствует только при блокировке
хранилища.";
description
"Операции NETCONF <lock> и <partial-lock> позволяют клиенту
заблокировать конкретные ресурсы в хранилище. Сервер
NETCONF будет препятствовать изменению заблокированных
ресурсов всеми сессиями, кроме задавшей блокировку.
Данные мониторинга обеспечиваются для каждой записи
хранилища, включая такие детали, как сессия, задавшая
блокировку, тип блокировки (глобальная или частичная) и
список заблокированных ресурсов. Поддерживается множество
блокировок в хранилище.";
grouping lock-info {
description
"Связанные с блокировкой параметры, общие для глобальной
и частичной блокировки.";
leaf locked-by-session {
type uint32;
mandatory true;
description
"Идентификатор сессии, заблокировавшей этот ресурс.
Глобальные и частичные блокировки ДОЛЖНЫ включать
идентификатор сессии NETCONF.
Если блокировку держит сессия, не контролируемая
сервером NETCONF (например, CLI), указывается 0.";
reference
"RFC 4741: NETCONF Configuration Protocol";
}
leaf locked-time {
type yang:date-and-time;
mandatory true;
description
"Дата и время блокировки ресурса.";
}
}
choice lock-type {
description
"Тип блокировки (глобальная или частичная).";
container global-lock {
description
"Присутствует при глобальной блокировке.";
uses lock-info;
}
list partial-lock {
key lock-id;
description
"Список частичных блокировок.";
reference
"RFC 5717: Partial Lock Remote Procedure Call (RPC) for
NETCONF";
leaf lock-id {
type uint32;
description
"Идентификатор блокировки из отклика <partial-lock>.";
}
uses lock-info;
leaf-list select {
type yang:xpath1.0;
min-elements 1;
description
"Выражение xpath, использованное для запроса
блокировки. Выражение выбора указывает исходно
предусмотренную область действия блокировки.";
}
leaf-list locked-node {
type instance-identifier;
description
"Список идентификаторов экземпляров (т. е.
блокированных узлов).
Область действия частичной блокировки указывает
список блокированных узлов.";
}
}
}
}
}
}
container schemas {
description
"Список схем моделей данных, поддерживаемых сервером.";
list schema {
key "identifier version format";
description
"Список схем моделей данных, поддерживаемых сервером.";
leaf identifier {
type string;
description
"Идентификатор, однозначно указывающий схему. Указывается
в операции <get-schema> и может служить для других целей,
таких как извлечение файлов.
Для языков моделирования, поддерживающих или требующих
имя модели данных (например, модуля YANG), идентификатор
ДОЛЖЕН соответствовать имени. Для моделей данных YANG
идентификатором является имя модуля или субмодуля. В ином
случае МОЖНО применять такой идентификатор, как имя файла";
}
leaf version {
type string;
description
"Версия поддерживаемой схемы. Сервер NETCONF МОЖЕТ
поддерживать одновременно несколько версий. Каждая версия
ДОЛЖНА указываться отдельно в списке схем с тем же
идентификатором, возможно, другим местом, но со своей
версией.
Для моделей данных YANG версией служит значение самого
свежего оператора revision в модуле или субмодуле. При
отсутствии revision указывается пустая строка.";
}
leaf format {
type identityref {
base schema-format;
}
description
"Язык моделирования данных, используемый схемой (в настоящее
время это xsd, yang, yin, rng, rnc). Для моделей YANG
ДОЛЖЕН поддерживаться формат yang и МОЖЕТ поддерживаться
формат yin.";
}
leaf namespace {
type inet:uri;
mandatory true;
description
"Пространство имён XML, заданное моделью данных.
Для моделей YANG это пространство имён модуля. Если запись
списка описывает субмодуль, это поле содержит пространство
имён модуля, к которому относится субмодуль.";
}
leaf-list location {
type union {
type enumeration {
enum "NETCONF";
}
type inet:uri;
}
description
"Одно или несколько мест, откуда можно извлечь схему. В этом
списке СЛЕДУЕТ указывать хотя бы 1 записи на схему.
Схема может размещаться в удалённой файловой системе
(например, ссылка на извлечение по протоколу ftp) или
непосредственно на сервере, поддерживающем операцию
<get-schema> (указывается значением NETCONF).";
}
}
}
container sessions {
description
"Этот контейнер включает данные для сеансов управления NETCONF.
Список сессий ДОЛЖЕН включать все активные сессии NETCONF.";
list session {
key session-id;
description
"В этом списке ДОЛЖНЫ быть все активные сессии NETCONF,
поддерживаемые сервером NETCONF.";
leaf session-id {
type uint32 {
range "1..max";
}
description
"Уникальный идентификатор сессии NETCONF (RFC 4741).";
reference
"RFC 4741: NETCONF Configuration Protocol";
}
leaf transport {
type identityref {
base transport;
}
mandatory true;
description
"Указывает транспорт для сессии, например,
netconf-ssh, netconf-soap, и т. п.";
}
leaf username {
type string;
mandatory true;
description
"Имя пользователя, указывающее клиента, аутентифицированного
транспортным протоколом NETCONF. Алгоритм вывода имени
зависит от транспорта NETCONF и применяемого механизма
аутентификации.";
}
leaf source-host {
type inet:host;
description
"Идентификатор хоста клиента NETCONF. Значение зависит
от реализации (например, hostname, адрес IPv4 или IPv6)";
}
leaf login-time {
type yang:date-and-time;
mandatory true;
description
"Время организации сессии по часам сервера.";
}
uses common-counters {
description
"Счётчики для сессии. Отсчёт с 0 по сбросом при старте
сессии и достижении максимального значения.";
}
}
}
container statistics {
description
"Статистика, относящаяся в серверу NETCONF.";
leaf netconf-start-time {
type yang:date-and-time;
description
"Дата и время запуска подсистемы управления.";
}
leaf in-bad-hellos {
type yang:zero-based-counter32;
description
"Число сессий сброшенных без уведомления по получению
непригодного сообщения <hello>, включая <hello> с атрибутом
session-id, некорректным пространством имён, неверным
объявлением возможностей.";
}
leaf in-sessions {
type yang:zero-based-counter32;
description
"Число запущенных сессий. Счётчик инкрементируется при
передаче сообщения <hello> с <session-id>.
in-sessions - in-bad-hellos =
число корректно созданных сессий netconf";
}
leaf dropped-sessions {
type yang:zero-based-counter32;
description
"Число аварийно завершённых сессий, например, по тайм-ауту или
закрытию транспорта. Счётчик не увеличивается при корректном
завершении сессии операцией <close-session> или уничтожении
операцией <kill-session>.";
}
uses common-counters {
description
"Глобальные счётчики, собранные из всех сессий. Отсчёт с 0 со
сбросом при реинициализации сервера NETCONF или достижении
максимального значения.";
}
}
}
rpc get-schema {
description
"Операция извлечения схемы с сервера NETCONF.
Положительный отклик:
сервер NETCONF возвращает запрошенную схему.
Отрицательный отклик:
если запрошенной схемы нет, возвращается <error-tag>
invalid-value.
Если запросу соответствует не одна схема, возвращается
<error-tag> operation-failed и <error-app-tag>
data-not-unique.";
input {
leaf identifier {
type string;
mandatory true;
description
"Идентификатор записи в списке схем.";
}
leaf version {
type string;
description
"Версия запрошенной схемы. При отсутствии этого параметра и
наличии на сервере нескольких версий схемы возвращается
ошибка data-not-unique, как указано выше.";
}
leaf format {
type identityref {
base schema-format;
}
description
"Язык моделирования данных в схеме. Если параметр не указан и
на сервере имеется не 1 формат схемы, возвращается
ошибка data-not-unique, как указано выше.";
}
}
output {
anyxml data {
description
"Содержимое схемы.";
}
}
}
}
<CODE ENDS>
6. Вопросы безопасности
Заданный здесь модуль YANG предназначен для доступа по протоколу NETCONF [RFC4741]. Нижним уровнем NETCONF является защищённый транспорт с обязательной реализацией SSH [RFC4742].
Некоторые из доступных для чтения узлов модуля YANG могут быть конфиденциальными или уязвимыми в некоторых сетевых средах. Важно обеспечить контроль считывания таких узлов (например, через get, get-config, notification).
Контейнеры, листья и узлы данных с их чувствительностью или уязвимостью указаны ниже.
/netconf-state/sessions/session/username
Содержит идентификаторы, которые можно использовать для попытки аутентификации на сервере. Узел username нужен лишь для мониторинге и не следует применять его с иными целями, например, для контроля доступа, без внимательного учёта связанных с этим ограничений. Например, серверы A и B могут сообщать одно значение username, но применять его с разными целями.7. Благодарности
Авторы благодарны Andy Bierman, Mehmet Ersue, Washam Fan, David Harrington, Balazs Lengyel, Hideki Okita, Juergen Schoenwaelder, Bert Wijnen и многим другим членам рабочей группы NETCONF за важный вклад в этот документ. Хочется также особо отметить работу Sharon Chisholm над NETCONF Monitoring Schema [NETCONF] и вклад в этот документ.
8. Взаимодействие с IANA
Этот документ регистрирует URI в реестре The IETF XML Registry в соответствии с [RFC3688]
URI: urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
Registrant Contact: The IESG.
XML: N/A, запрошенный URI является пространством имён XML.
Документ регистрирует модуль в реестре YANG Module Names в соответствии с [RFC6020]
name: ietf-netconf-monitoring
namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring
prefix: ncm
reference: RFC 6022
9. Литература
9.1. Нормативные документы
[ISO/IEC19757-2:2008] ISO/IEC, “Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG”, December 2008, <http://www.iso.org/iso/catalogue_detail.htm?csnumber=37605>.
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC4741] Enns, R., “NETCONF Configuration Protocol”, RFC 4741, December 2006.
[RFC4742] Wasserman, M. and T. Goddard, “Using the NETCONF Configuration Protocol over Secure SHell (SSH)”, RFC 4742, December 2006.
[RFC4743] Goddard, T., “Using NETCONF over the Simple Object Access Protocol (SOAP)”, RFC 4743, December 2006.
[RFC4744] Lear, E. and K. Crozier, “Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)”, RFC 4744, December 2006.
[RFC5539] Badra, M., “NETCONF over Transport Layer Security (TLS)”, RFC 5539, May 2009.
[RFC5717] Lengyel, B. and M. Bjorklund, “Partial Lock Remote Procedure Call (RPC) for NETCONF”, RFC 5717, December 2009.
[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, October 2010.
[RFC6021] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6021, October 2010.
[XML-NAMES] Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Layman, “Namespaces in XML 1.0 (Third Edition)”, World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[xmlschema-1] Biron, Paul V. and Ashok. Malhotra, “XML Schema Part 1: Structures Second Edition W3C Recommendation 28 October 2004”, October 2004, <http://www.w3.org/TR/xmlschema-1>.
9.2. Дополнительная литература
[NETCONF] Chisholm, S. and H. Trevino, “NETCONF Monitoring Schema”, Work in Progress, February 2007.
[RFC0959] Postel, J. and J. Reynolds, “File Transfer Protocol”, STD 9, RFC 959, October 1985.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol — HTTP/1.1”, RFC 2616, June 1999.
[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, January 2004.
Адреса авторов
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.