Internet Engineering Task Force (IETF) B. Lengyel
Request for Comments: 9196 Ericsson
Category: Standards Track A. Clemm
ISSN: 2070-1721 Futurewei
B. Claise
Huawei
February 2022
YANG Modules Describing Capabilities for Systems and Datastore Update Notifications
Модули YANG для описания возможностей уведомлений об обновлениях системы и хранилища данных
Аннотация
Этот документ определяет модули YANG ietf-system-capabilities и ietf-notification-capabilities.
Модуль ietf-system-capabilities предоставляет шаблон структуры, который может служит для обнаружения связанных с YANG возможностей серверов. Модуль можно применять для передачи сведений о возможностях от сервера в процессе работы или при реализации, используя формат файла данных экземпляра YANG.
Модель ietf-notification-capabilities дополняет ietf-system-capabilities для указания возможностей, связанных с подпиской на уведомления YANG для обновлений хранилища данных (Subscription to YANG Notifications for Datastore Updates, RFC 8641).
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9196.
Авторские права
Авторские права (Copyright (c) 2022) принадлежат 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).
1. Введение
Серверы и издатели часто имеют возможности, которые можно представить значениями, определяющими рабочее поведение, которые нужно передавать клиентам. Заданные здесь модули YANG упрощают это.
Сведения о возможностях нужно публиковать, поскольку они являются частью интерфейса API между клиентом и сервером. Примерами служат максимальный размер данных, которые можно сохранить или передать, сведения о счётчиках (поддерживает ли узел передачу телеметрии при изменении – on-change) и т. п. Такие возможности часто зависят от реализации производителя или доступности ресурсов при развёртывании. Многие из таких возможностей специфичны для системы в целом, отдельных хранилищ данных YANG [RFC8342], конкретных частей схемы YANG или даже отдельных узлов данных. Целью этого документа является задание общего способа представления таких данных в формате, который:
-
не зависит от производителя;
-
понятен для машины;
-
доступен в процессе реализации и при работе (runtime).
Сведения процесса реализации нужны разработчикам систем управления сетью (Network Management System или NMS). Реализации NMS, поддерживающей уведомления, нужны сведения о возможностях системы, чтобы передавать уведомления об изменениях. Если сведения не документированы так, что их легко может получить разработчик NMS, а имеется лишь экземпляр данных от узла сети, где это развёрнуто, реализация NMS будет задержана, поскольку придётся ждать развёртывания узла. Кроме того, допущение о том, что все разработчики NMS будут иметь доступ к корректно настроенному узлу сети для извлечения данных, обойдётся дорого и не будет выполняться всегда (NMS может потребоваться возможность обрабатывать десятки типов узлов сети). Зачастую наличие полнофункциональной NMS является требованием при внедрении нового узла в сеть, поэтому задержка готовности NMS фактически ведёт к задержке развёртывания в сети новых узлов.
Сведения процесса реализации нужны системным интеграторам, поскольку при внедрении в сеть новых типов узлов операторам зачастую нужно интегрировать их в имеющуюся систему управления. В NMS могут применяться функции, зависящие от уведомлений об изменениях. Операторам нужно планировать свои методы управления и внедрять NMS до принятия решения о приобретении конкретного типа сетевого оборудования. Более того, решение о покупке узлов нового типа иногда зависит от возможностей управления ими.
Сведения о возможностях в процессе работы (runtime) требуются:
-
для приложений управления на основе модели (purely model-driven), например, браузеров NETCONF, зависящих от поддерживаемых моделей считывания и возможностей при работе, для полного использования функциональности;
-
в случаях смены возможностей в процессе работы, например, в результате лицензирования, аппаратных ограничений и т. п.;
-
для проверки соответствия анонсированных возможностей фактически реализованным.
1.1. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они выделены шрифтом, как показано здесь.
Термины YANG-Push, on-change subscription (подписка на обновления), periodic subscription (периодическая подписка) определены в [RFC8641].
Термины subscriber (подписчик), publisher (издатель), receiver (получатель) определены в [RFC8639].
Термин server определён в [RFC8342].
Термины instance data file (файл данных экземпляра), instance data (данные экземпляра), instance data set (набор данных экземпляра) определены в [RFC9195].
Этот документ определяет указанные ниже термины.
Implementation-time information – сведения процесса реализации
Сведения о поведении сервера, доступные в процессе реализации сервера, из источников, отличающихся от работающего сервера.Runtime information – сведения при работе
Сведения о поведении сервера, доступные от работающего экземпляра сервера по протоколам управления, таким как NETCONF [RFC6241] или RESTCONF [RFC8040].2. Предоставление сведений о возможностях системы
Информация о возможностях представляется экземпляром данных на основе одного или нескольких модулей YANG, определяющих возможности. Это позволяет пользователю обнаруживать возможности как во время реализации, так и при работе (runtime).
В процессе реализации
Разработчику следует представлять возможности как файлы экземпляров данных YANG, соответствующие [RFC9195]. Когда такой файл предоставляется, он должен быть доступен во время реализации и извлекаться независимо от наличия работающего (live) узла, например, путём загрузки с web-сайта.При работе
Возможности следует делать доступными по протоколу NETCONF [RFC6241] или RESTCONF [RFC8040] с работающего сервера (реализованного издателем). Реализациям, поддерживающим изменение возможностей в процессе работы, следует поддерживать уведомления об изменениях в контейнере system-capabilities.Модуль ietf-system-capabilities содержит шаблон структуры для задания любых возможностей системы, связанных с YANG. Модуль ietf-notification-capabilities позволяет издателю задать возможности, связанные с подпиской на уведомления YANG об обновлениях хранилищ данных (Subscription to YANG Notifications for Datastore Updates) [RFC8641], называемые также YANG-Push и дополняющие ietf-system-capabilities.
Модель данных YANG в этом документе соответствует архитектуре хранилищ данных управления сетью (Network Management Datastore Architecture или NMDA) [RFC8342].
3. Предоставление сведений о возможностях YANG-Push
Отдельным случаем является указание возможностей функциональности YANG-Push. Как указано в [RFC8641], издатель может позволить подписчикам подписываться на обновления от хранилища данных и последовательно выталкивать получателям уведомления о таких обновлениях. Уведомления могут отправляться периодически или при изменении (более или менее сразу после такого изменения).
Издатель, поддерживающий YANG-Push имеет множество возможностей, определенных в [RFC8641], которые часто задаются издателем в процессе реализации.
-
Поддерживаемые (сообщаемые) интервалы периодической отправки для подписки.
-
Максимальное число обектов, которые можно передать в обновлении.
-
Набор хранилищ или узлов данных, для которых поддерживаются периодические уведомления.
Дополнительные возможности необязательной функции on-change включают:
-
поддерживаемые периоды «демпфирования» для подписок on-change;
-
набор хранилищ или узлов данных, для которых поддерживаются уведомления при изменении.
У издателей могут быть возможности (или ограничения) для документов, например, число уведомлений или число обновлённых объектов хранилища, которые могут быть переданы за определённых интервал времени. Некоторые издатели могут не поддерживать периодической подписки для всех хранилищ. Иногда издатель, поддерживающий уведомления об изменениях, может быть неспособен выталкивать (push) обновления при изменении некоторых типов объектов. Причинами этого могут быть частые изменения данных в хранилище (например, счётчик октетов), частые и мелкие изменения, не имеющие важности для получателя (например, изменение температуры на 0,1 градуса в заданном и приемлемом диапазоне) или неспособность реализации передавать такие уведомления для некоторых уведомлений. Во всех таких случаях для приложений-подписчиков важно иметь способ объекты для которых поддерживаются и не поддерживаются уведомления об изменениях.
Поддержка уведомлений on-change не означает, что такие уведомления будут передаваться для любого конкретного узла данных, поскольку эат возможность может поддерживаться не для всех узлов. Поэтому управляющие приложения-подписчики не могут полагаться на функциональность on-change, пока они не знают, для каких объектов это поддерживается. Модели данных YANG предназначены для использования в качестве интерфейса. Без идентификации узлов данных, которые фактически поддерживают уведомления on-change, этот интерфейс может быть неполным.
Клиентам сервера (или подписчикам издателя, поскольку они являются клиентами) нужен метод сбора сведений о возможностях.
4. Модель возможностей системы
Модуль ietf-system-capabilities задаёт структуру, которую можно использовать для обнаружения (как рабочего состояния read-only) любых возможностей системы, связанных с YANG. Сам модуль не включает каких-либо возможностей, он обеспечивает точки дополнения (augment) для возможностей, которые будут определены в последующих модулях YANG. Этот модуль используется другими модулями для дополнения сведений о конкретных возможностях. Каждый набор таких возможностей должен помещаться в контейнер под оператором augment для чёткого разделения различных групп возможностей. Эти контейнеры-оболочки нужно добавлять в /sysc:system-capabilities и /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-capabilities.
Значения возможностей можно задавать на уровне системы, хранилища данных (выбирая все узлы этого хранилища) или конкретных узлов данных в определённом хранилище (и содержащихся в них ветвей). Значения возможностей, заданные для конкретного хранилища или набора узлов (node-set) переопределяют заданные на уровне системы значения.
Примечание. Это решение подходит для систем с поддержкой и без поддержки архитектуры NMDA. Для серверов без NMDA данные config false рассматриваются, как будто рни являются частью рабочего хранилища (running).
4.1. Диаграмма дерева
Диаграмма дерева использует нотацию, определённую в [RFC8340].
module: ietf-system-capabilities
+--ro system-capabilities
+--ro datastore-capabilities* [datastore]
+--ro datastore -> /yanglib:yang-library/datastore/name
+--ro per-node-capabilities* []
+--ro (node-selection)?
+--:(node-selector)
+--ro node-selector? nacm:node-instance-identifier
4.2. Модуль YANG
Этот модуль YANG импортирует определения типов из [RFC8341] и путь ссылок (reference path) из [RFC8525].
<CODE BEGINS> file "ietf-system-capabilities@2022-02-17.yang"
module ietf-system-capabilities {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-system-capabilities";
prefix sysc;
import ietf-netconf-acm {
prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
}
import ietf-yang-library {
prefix yanglib;
description
"Этот модуль требует реализации ietf-yang-library. ТРЕБУЕТСЯ
Revision 2019-01-04 или производный от него выпуск.";
reference
"RFC8525: YANG Library";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Editor: Balazs Lengyel
<mailto:balazs.lengyel@ericsson.com>";
description
"Этот модуль задаёт структуру для указания возможностей системы
для сервера или издателя. Возможности системы могут включать
возможности сервера NETCONF или RESTCONF или издателя
уведомлений.
Модуль не включает конкретных возможностей и лишь задаёт
структуру, кода можно добавлять контейнеры возможностей.
Значения возможностей можно задать на уровне системы, хранилища
данных (выбором всех узлов в хранилище) или конкретных узлов
данных в определённом хранилище (и из ветвей). Значения
возможностей для конкретного хранилища или node-set
переопределяют значения на уровне системы или издателя.
ДОЛЖНА применяться одна группировка для задания иерархических
возможностей на уровне системы и хранилища (узла данных).
Для поиска значения возможности конкретного узла данных в
заданном хранилище пользователю НУЖНО следующее.
1) Искать запись списка возможностей для заданного хранилища.
При указании конкретной возможности относительный путь для
любой конкретной возможности должен быть одинаковым в контейнере
возможностей системы и списке возможностей на уровне узла.
2) Если в этой записи найдена запись для хранилища данных,
обрабатываются все записи возможностей на уровне узла в порядке
указания в списке. Первая запись, указывающая конкретную
возможность и имеющая селектор узла, выбирающий конкретный узел
данных, определяет значение возможности.
3) Если значение возможности не найдено и конкретная возможность
задана в контейнере возможностей системы (вне списка
возможностей хранилища данных), нужно использовать это значение.
4) Если на предыдущих этапах значения не найдено, система
(издатель) не способна предоставить это значение. Причиной может
быть неизвестность возможности, изменение возможности по
какой-то причине, наличие ограничений и т. п. Для таких случаев
поведение системы не задано.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2022) принадлежат IETF Trust и
лицам, указанным как авторы. Все права защищены.
Распространение и применение модуля в исходной или двоичной
форме с изменениями или без таковых разрешено в соответствии с
лицензией Simplified BSD License, изложенной в параграфе 4.c
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 9196, где правовые
аспекты приведены более полно.";
revision 2022-02-17 {
description
"Исходный выпуск.";
reference
"RFC 9196: YANG Modules Describing Capabilities for Systems
and Datastore Update Notifications";
}
container system-capabilities {
config false;
description
"Возможности системы. Заданные здесь значения возможностей на
уровне системы действительны для всех хранилищ данных и
применяются, когда на уровне хранилищ или узлов данных
возможности не заданы.";
/*
* Точка добавления возможностей на уровне системы.
*/
list datastore-capabilities {
key "datastore";
description
"Значения возможностей на уровне хранилища.
Для серверов и издателей без поддержки NMDA данные с
config false рассматриваются как часть рабочего хранилища.";
leaf datastore {
type leafref {
path
"/yanglib:yang-library/yanglib:datastore/yanglib:name";
}
description
"Хранилище, для которого заданы возможности. Указать можно
лишь одно действительное хранилище, например, недопустимо
использовать ds:conventional, поскольку оно представляет
набор хранилищ конфигурации.";
}
list per-node-capabilities {
description
"Каждая запись списка задаёт возможности для выбранных
узлов данных. Одни и те же возможности относятся ко
всем узлам данных в ветвях выбранных узлов.
Системе НУЖНО упорядочивать записи по их предпочтениям.
Порядок записей НЕДОПУСТИМО менять, пока не меняются
базовые возможности.
Отметим, что самое длинное совпадение можно получить
путём упорядочения по размеру совпадения.";
choice node-selection {
description
"Метод выбора некоторых или всех узлов в хранилище.";
leaf node-selector {
type nacm:node-instance-identifier;
description
"Выбор узлов данных, для которых заданы возможности.
Значение / указывает все узлы данных в хранилище
в соответствии с узлом path (стр. 41 в [RFC8341]).";
reference
"RFC 8341: Network Configuration Access Control Model";
}
}
/*
* Точка добавления возможностей на уровне хранилища или
* узлов данных
*/
}
}
}
}
<CODE ENDS>
5. Модель возможностей уведомления
Модуль YANG ietf-notification-capabilities предоставляет сведения, связанные с возможностью YANG-Push.
5.1. Диаграмма дерева
Диаграмма дерева использует нотацию, определённую в [RFC8340].
module: ietf-notification-capabilities
augment /sysc:system-capabilities:
+--ro subscription-capabilities
+--ro max-nodes-per-update? uint32
+--ro periodic-notifications-supported? notification-support
+--ro (update-period)?
| +--:(minimum-update-period)
| | +--ro minimum-update-period? uint32
| +--:(supported-update-period)
| +--ro supported-update-period* uint32
+--ro on-change-supported? notification-support
| {yp:on-change}?
+--ro minimum-dampening-period? uint32
| {yp:on-change}?
+--ro supported-excluded-change-type* union
{yp:on-change}?
augment /sysc:system-capabilities/sysc:datastore-capabilities
/sysc:per-node-capabilities:
+--ro subscription-capabilities
+--ro max-nodes-per-update? uint32
+--ro periodic-notifications-supported? notification-support
+--ro (update-period)?
| +--:(minimum-update-period)
| | +--ro minimum-update-period? uint32
| +--:(supported-update-period)
| +--ro supported-update-period* uint32
+--ro on-change-supported? notification-support
| {yp:on-change}?
+--ro minimum-dampening-period? uint32
| {yp:on-change}?
+--ro supported-excluded-change-type* union
{yp:on-change}?
5.2. Модуль YANG
Этот модуль YANG импортирует свойство (feature) и определения типов из [RFC8641] а также заданный выше модуль ietf-system-capabilities.
<CODE BEGINS> file "ietf-notification-capabilities@2022-02-17.yang"
module ietf-notification-capabilities {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-notification-capabilities";
prefix notc;
import ietf-yang-push {
prefix yp;
description
"Этот модуль требует реализации ietf-yang-push.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates";
}
import ietf-system-capabilities {
prefix sysc;
description
"Этот модуль требует реализации ietf-system-capabilities.";
reference
"RFC 9196: YANG Modules Describing Capabilities for Systems
and Datastore Update Notifications";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Editor: Balazs Lengyel
<mailto:balazs.lengyel@ericsson.com>";
description
"Этот модуль задаёт возможности издателя, связанные с YANG-Push
(RFC 8641). Модуль включает:
- спецификацию узлов данных, поддерживающих уведомления
on-change или periodic;
- возможности, связанные с пропускной способностью для данных
уведомлений, которую может поддерживать издатель (отметим, что
для конкретной подписки издатель МОЖЕТ разрешать лишь более
долгие интервалы или меньшие обновления в зависимости,
например, от фактической нагрузки).
Значения возможностей можно задать на уровне системы (издателя),
хранилища данных или конкретных узлов указанного хранилища (и их
ветвей), как указано в модуле ietf-system-capabilities.
Если в одной подписке указаны разные узлы данных для конкретной
возможности, использование значений, которые приемлемы лишь для
части этих узлов, может приводить к отклонению подписки.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе трактуются в соответствии с
BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.
Авторские права (Copyright (c) 2022) принадлежат IETF Trust и
лицам, указанным как авторы. Все права защищены.
Распространение и применение модуля в исходной или двоичной
форме с изменениями или без таковых разрешено в соответствии с
лицензией Simplified BSD License, изложенной в параграфе 4.c
IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Эта версия модуля YANG является частью RFC 9196, где правовые
аспекты приведены более полно.";
revision 2022-02-17 {
description
"Исходный выпуск.";
reference
"RFC 9196: YANG Modules Describing Capabilities for Systems
and Datastore Update Notifications";
}
grouping subscription-capabilities {
description
"Возможности, связанные с подпиской и уведомлениями YANG-Push";
container subscription-capabilities {
description
"Возможности для подписки и уведомлений YANG-Push.";
typedef notification-support {
type bits {
bit config-changes {
description
"Издатель способен передавать уведомления для узлов
config true при соответствующей области действия и
типе подписки.";
}
bit state-changes {
description
"Издатель способен передавать уведомления для узлов
config false при соответствующей области действия и
типе подписки.";
}
}
description
"Определяет поддержку уведомлений on-change или periodic
для всех узлов, узлов config false или config true и
отсутствие такой поддержки.
Биты config-changes и state-changes не действуют для
хранилищ или набора узлов данных, где нет узлов с заданным
значением config (как будто поддержка не заявлена).
Примером служит указание поддержки state-changes для
хранилища candidate, которое не оказывает влияния.";
}
leaf max-nodes-per-update {
type uint32 {
range "1..max";
}
description
"Максимальное число узлов данных для передачи в обновлении.
Издатель МОЖЕТ поддерживать большее число и СЛЕДУЕТ
поддерживать хотя бы указанное количество.
Может служить для предотвращения ошибок update-too-big
при подписке.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates, the 'update-too-big' error/identity";
}
leaf periodic-notifications-supported {
type notification-support;
description
"Указывает, способен ли издатель передавать периодические
обновления для выбранных узлов данных, включая их ветви.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates, 'periodic' subscription concept";
}
choice update-period {
description
"Поддерживаемые интервалы периодических обновлений.";
leaf minimum-update-period {
type uint32;
units "centiseconds";
description
"Минимальный интервал для периодических обновлений.
Запрос подписки для выбранных узлов с интервалом меньше,
чем указан этим листом, ведёт к ошибке
period-unsupported.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates, the period leaf in the ietf-yang-push
YANG module";
}
leaf-list supported-update-period {
type uint32;
units "centiseconds";
description
"Поддерживаемый интервал периодических обновлений.
Запрос подписки для выбранных узлов с интервалом, не
указанным в этом leaf-list, ведёт к ошибке
'period-unsupported.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates, the period leaf in the ietf-yang-push
YANG module";
}
}
leaf on-change-supported {
if-feature "yp:on-change";
type notification-support;
description
"Указывает, способен ли издатель передавать уведомления
on-change для выбранных узлов данных и их ветвей.";
reference
"RFC 8641: Subscription to YANG Notifications for Datastore
Updates, on-change concept";
}
leaf minimum-dampening-period {
if-feature "yp:on-change";
type uint32;
units "centiseconds";
description
"Минимальный интервал демпфирования подписки on-change для
выбранных узлов данных.
Наличие здесь положительного значения означает
обязательность демпфирования.";
reference
"RFC 8641: Subscription to YANG Notifications for
Datastore Updates, the dampening-period leaf in the
ietf-yang-push YANG module";
}
leaf-list supported-excluded-change-type {
if-feature "yp:on-change";
type union {
type enumeration {
enum none {
value -2;
description
"Нельзя исключить ни один из типов изменений.";
}
enum all {
value -1;
description
"Можно исключить любую комбинацию изменений.";
}
}
type yp:change-type;
}
description
"Тип изменений, которые можно исключить из подписки
YANG-Push для выбранных узлов данных.";
reference
"RFC 8641: Subscription to YANG Notifications for Datastore
Updates, the change-type typedef in the ietf-yang-push
YANG module";
}
}
}
augment "/sysc:system-capabilities" {
description
"Добавляет возможности на уровне системы.";
uses subscription-capabilities {
refine
"subscription-capabilities/supported-excluded-change-type" {
default "none";
}
}
}
augment "/sysc:system-capabilities/sysc:datastore-capabilities"
+ "/sysc:per-node-capabilities" {
description
"Добавляет возможности на уровне хранилищ и узлов данных.";
uses subscription-capabilities {
refine
"subscription-capabilities/supported-excluded-change-type" {
default "none";
}
}
}
}
<CODE ENDS>
6. Вопросы безопасности
Заданные этим документом модули YANG определяют схему для данных, предназначенную для доступа через сеть с использованием протоколов управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF служит защищённый транспорт с обязательной поддержкой SSH (Secure Shell) [RFC6242]. Нижним уровнем RESTCONF служит протокол HTTPS с обязательной поддержкой защиты на транспортном уровне (TLS) [RFC8446].
Модель доступа к конфигурации сети (NACM – Network Configuration Access Control Model) [RFC8341] обеспечивает возможность разрешить доступ лишь определённых пользователей NETCONF или RESTCONF к заранее заданному подмножеству операций NETCONF или RESTCONF и содержимого.
Этот документ описывает структуру для передачи сведений о возможностях системы, которые по своей природе являются гибкими и расширяемыми. Хотя все варианты применения сейчас неизвестны, они могут варьироваться в зависимости от минимального интервала периодических обновлений и протоколов, применяемых для уведомления. Знание типа значения может помочь злоумышленнику узнать, как долго могут сохраняться активными несанкционированные изменения до их обнаружения и какие каналы можно нарушить для увеличения этого срока. В документах, добавляющих возможности через операторы augment в этом модуле, рекомендуется рассматривать вопросы безопасности новых узлов YANG в соответствии с рекомендациями BCP 216 [RFC8407].
Все доступные протоколам узлы данных в дополненных модулях открыты лишь для чтения и не могут быть изменены. Можно настроить контроль доступа для предотвращения раскрытия узлов данных read-only, которые указаны в документации модуля дополнения как чувствительные в плане безопасности.
Когда данные представлены в форме файла, их следует защищать от изменения и несанкционированного доступа с помощью обычных механизмов обработки файлов. К таким данным применимы соображения безопасности из [RFC9195], включая дополнительную защиту от считывания и разницу между стабильными и меняющимися данными.
7. Взаимодействие с IANA
7.1. Реестр IETF XML
Этот документ регистрирует URI в реестре IETF XML Registry [RFC3688]
URI: urn:ietf:params:xml:ns:yang:ietf-system-capabilities Registrant Contact: The IESG. XML: N/A, запрошенный URI является пространством имён XML. URI: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities Registrant Contact: The IESG. XML: N/A, запрошенный URI является пространством имён XML.
7.2. Реестр YANG Module Names
Документ регистрирует модули YANG в реестре YANG Module Names [RFC6020]
name: ietf-system-capabilities namespace: urn:ietf:params:xml:ns:yang:ietf-system-capabilities prefix: sysc reference: RFC 9196 name: ietf-notification-capabilities namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities prefix: notc reference: RFC 9196
8. Литература
8.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., “YANG – A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., “Using the NETCONF Protocol over Secure Shell (SSH)”, RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, “RESTCONF Protocol”, RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, “Network Configuration Access Control Model”, STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, “Network Management Datastore Architecture (NMDA)”, RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, “YANG Library”, RFC 8525, DOI 10.17487/RFC8525, March 2019, <https://www.rfc-editor.org/info/rfc8525>.
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, “Subscription to YANG Notifications”, RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, “Subscription to YANG Notifications for Datastore Updates”, RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[RFC9195] Lengyel, B. and B. Claise, “A File Format for YANG Instance Data”, RFC 9195, DOI 10.17487/RFC9195, February 2022, <https://www.rfc-editor.org/info/rfc9195>.
8.2. Дополнительная литература
[RFC8340] Bjorklund, M. and L. Berger, Ed., “YANG Tree Diagrams”, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.
[RFC8407] Bierman, A., “Guidelines for Authors and Reviewers of Documents Containing YANG Data Models”, BCP 216, RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/info/rfc8407>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, “Handling Long Lines in Content of Internet-Drafts and RFCs”, RFC 8792, DOI 10.17487/RFC8792, June 2020, <https://www.rfc-editor.org/info/rfc8792>.
Приложение A. Пример экземпляра данных 1
В приведённом ниже примере применяется форматирование с фальцовкой [RFC8792].
Экземпляр данных описывает возможности уведомлений гипотетического маршрутизатора acme-router, реализующего хранилища running и operational. Каждое изменение может быть сообщено в режиме on-change из хранилища running, но из operational – лишь узлы config false и некоторые данные config false. Статистика интерфейсов не передаётся в on-change и включены лишь два важных счётчика. Возможности подписки на хранилища не сообщаются в on-change, поскольку они не меняются в процессе работы acme-router.
========== NOTE: '\' line wrapping per RFC 8792) ===========
<?xml version="1.0" encoding="UTF-8"?>
<instance-data-set xmlns=\
"urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
<name>acme-router-notification-capabilities</name>
<content-schema>
<module>ietf-system-capabilities@2022-02-17</module>
<module>ietf-notification-capabilities@2022-02-17</module>
</content-schema>
<description>Указывает возможности уведомлений от acme-router.
Маршрутизатор имеет лишь хранилища running и operational. Каждое
изменение может быть указано on-change из хранилища running, но
из operational передаются лишь узлы config false и некоторые
данные config false в режиме on-change. Статистика не передаётся
on-change, за исключением двух важных счётчиков, где обязателен
малый период демпфирования.
</description>
<content-data>
<system-capabilities \
xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities" \
xmlns:notc=\
"urn:ietf:params:xml:ns:yang:ietf-notification-capabilities" \
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<notc:subscription-capabilities>
<notc:minimum-update-period>500</notc:minimum-update-period>
<notc:max-nodes-per-update>2000</notc:max-nodes-per-update>
<notc:minimum-dampening-period>\
100\
</notc:minimum-dampening-period>
<notc:periodic-notifications-supported>\
config-changes state-changes\
</notc:periodic-notifications-supported>
<notc:on-change-supported>\
config-changes state-changes\
</notc:on-change-supported>
<notc:supported-excluded-change-type>\
all\
</notc:supported-excluded-change-type>
</notc:subscription-capabilities>
<datastore-capabilities>
<datastore>ds:operational</datastore>
<per-node-capabilities>
<node-selector>\
/if:interfaces/if:interface[if:name='lo']\
</node-selector>
<notc:subscription-capabilities>
<notc:on-change-supported/>
<notc:periodic-notifications-supported/>
</notc:subscription-capabilities>
</per-node-capabilities>
<per-node-capabilities>
<node-selector>\
/if:interfaces/if:interface/if:statistics/if:in-octets\
</node-selector>
<notc:subscription-capabilities>
<notc:minimum-dampening-period>10
</notc:minimum-dampening-period>
<notc:on-change-supported>\
state-changes\
</notc:on-change-supported>
</notc:subscription-capabilities>
</per-node-capabilities>
<per-node-capabilities>
<node-selector>\
/if:interfaces/if:interface/if:statistics/if:out-octets\
</node-selector>
<notc:subscription-capabilities>
<notc:minimum-dampening-period>10
</notc:minimum-dampening-period>
<notc:on-change-supported>\
state-changes\
</notc:on-change-supported>
</notc:subscription-capabilities>
</per-node-capabilities>
<per-node-capabilities>
<node-selector>\
/if:interfaces/if:interface/if:statistics\
</node-selector>
<notc:subscription-capabilities>
<notc:on-change-supported/>
</notc:subscription-capabilities>
</per-node-capabilities>
</datastore-capabilities>
</system-capabilities>
</content-data>
</instance-data-set>
Рисунок 1. Возможности уведомлений с настройками для узла данных.
Приложение B. Пример экземпляра данных 2
В приведённом ниже примере применяется форматирование с фальцовкой [RFC8792].
Экземпляр данных описывает возможности уведомлений гипотетического коммутатора acme-switch, реализующего хранилища running, candidate и operational. Каждое изменение может быть передано on-change из хранилища running, при изменениях в хранилище candidate не передаётся ничего, а для operational могут передаваться все узлы config false. Периодические уведомления поддерживаются для хранилищ running и operational, но не для candidate.
========== NOTE: '\' line wrapping per RFC 8792) ===========
<?xml version="1.0" encoding="UTF-8"?>
<instance-data-set xmlns=\
"urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
<name>acme-switch-notification-capabilities</name>
<content-schema>
<module>ietf-system-capabilities@2022-02-17</module>
<module>ietf-notification-capabilities@2022-02-17</module>
</content-schema>
<description>Возможности уведомлений acme-switch, реализующего
хранилища running, candidate и operational. Каждое изменение
быть передано on-change из хранилища running, ничего не
передаётся из candidate, а из operational передаются изменения
для всех данных config false. Периодические уведомления
поддерживаются для running и operational, но не для candidate.
</description>
<content-data>
<system-capabilities \
xmlns="urn:ietf:params:xml:ns:yang:ietf-system-capabilities" \
xmlns:notc=\
"urn:ietf:params:xml:ns:yang:ietf-notification-capabilities" \
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<notc:subscription-capabilities>
<notc:minimum-update-period>500</notc:minimum-update-period>
<notc:max-nodes-per-update>2000</notc:max-nodes-per-update>
<notc:minimum-dampening-period>\
100\
</notc:minimum-dampening-period>
<notc:periodic-notifications-supported>\
config-changes state-changes\
</notc:periodic-notifications-supported>
</notc:subscription-capabilities>
<datastore-capabilities>
<datastore>ds:operational</datastore>
<per-node-capabilities>
<node-selector>/</node-selector>
<notc:subscription-capabilities>
<notc:on-change-supported>\
state-changes\
</notc:on-change-supported>
</notc:subscription-capabilities>
</per-node-capabilities>
</datastore-capabilities>
<datastore-capabilities>
<datastore>ds:candidate</datastore>
<per-node-capabilities>
<node-selector>/</node-selector>
<notc:subscription-capabilities>
<notc:on-change-supported/>
<notc:periodic-notifications-supported/>
</notc:subscription-capabilities>
</per-node-capabilities>
</datastore-capabilities>
<datastore-capabilities>
<datastore>ds:running</datastore>
<per-node-capabilities>
<node-selector>/</node-selector>
<notc:subscription-capabilities>
<notc:on-change-supported>\
config-changes\
</notc:on-change-supported>
</notc:subscription-capabilities>
</per-node-capabilities>
</datastore-capabilities>
</system-capabilities>
</content-data>
</instance-data-set>
Рисунок 2. Возможности уведомлений с настройками для хранилища данных.
Благодарности
Спасибо Andy Bierman, Juergen Schoenwaelder, Rob Wilton, Kent Watsen, Eric Voit, Joe Clarke, Martin Bjorklund, Ladislav Lhotka, Qin Wu, Mahesh Jethanandani, Ran Tao, Reshad Rahman и другим участникам рабочей группы Netmod за ценные замечания, дискуссии и отзывы.
Адреса авторов
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.