Internet Engineering Task Force (IETF) C. Hopps
Request for Comments: 8819 L. Berger
Updates: 8407 LabN Consulting, L.L.C.
Category: Standards Track D. Bogdanovic
ISSN: 2070-1721 Volta Networks
January 2021
YANG Module Tags
Теги модулей YANG
Аннотация
Этот документ связывает теги с модулями YANG. Предполагается, что использование таких тегов поможет классифицировать и организовать модули. Представлен метод определения, чтения и записи тегов модулей. Теги могут регистрироваться и назначаться в процессе создания модуля, назначаться при развертывании или динамически задаваться и устанавливаться пользователем. В документе также приведены рекомендации для разработчиков новых модулей, обновляющие RFC 8407.
Статус документа
Документ относится к категории Internet Standards Track.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информация о текущем статусе документа, найденных ошибках и способах обратной связи доступна по ссылке https://www.rfc-editor.org/info/rfc8819.
Авторские права
Copyright (c) 2021. Авторские права принадлежат 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. Введение
Применение тегов для классификации и организации достаточно широко распространено не только в протоколах IETF, но и в сети в целом (например, #хештеги). Одним из преимуществ использования тегов для организации по сравнению с жесткой структурой является гибкость и простота адаптации к новым технологиям. Теги можно регистрировать, но они могут также служить не регистрируемым механизмом, позволяющим пользователям самостоятельно задавать теги. В этом документе представлен механизм для определения тегов и гибкого связывания их с модулями YANG. В частности, теги можно регистрировать, а также назначать в процессе создания модулей, назначать при реализации или динамически задавать и устанавливать силами пользователя.
Этот документ определяет модуль YANG [RFC7950], включающий список записей для модулей, который позволяет добавлять и исключать теги, а также просматривать набор связанных с модулем тегов.
Документ определяет оператор расширения для указания тегов, которые следует автоматически добавлять реализации модуля (т. е. вне процедуры настройки).
Документ также задает реестр IANA для префиксов тегов и набора тегов глобального значения.
В разделе 6 приведены рекомендации для разработчиков моделей данных YANG.
Документ обновляет [RFC8407].
Модель данных YANG в этом документе соответствует архитектуре хранилища сетевого управления (Network Management Datastore Architecture или NMDA), определенной в [RFC8342].
1.1. Примеры возможного применения тегов модулей YANG
В процессе разработки этого документа возникали запросы на примеры использования тегов модулей. Ниже приведено несколько примеров применения тегов, список которых может быть расширен.
Одним из примеров служит помощь в фильтрации разных дискретных категорий модулей YANG, поддерживаемых устройством. Например, при задании для модулей подходящих тегов можно использовать запрос XPath для получения всех фирменных модулей, поддерживаемых устройством.
Теги можно также использовать для координации взаимодействия множества частично независимых клиентов с общим набором устройств. Например, один клиент управления может отметить, что некоторые модули не следует применять, поскольку корректность их поведения не проверена, чтобы другие клиенты управления избегали запроса данных, связанных с этими модулями.
Классификация по тегам полезна для пользователей при поиске в репозиториях модулей (например, каталог YANG). Запросы с тегом ietf:routing, например, можно использовать для получения лишь модулей IETF YANG, связанных с маршрутизацией. Без тега пользователю нужно знать имена всех модулей YANG для протоколов маршрутизации IETF.
Будущие расширения протоколов управления могут обеспечить фильтрацию запросов конфигурации или рабочего состояния на сервере по тегам (например, для получения рабочего состояния, связанного с управлением системой).
1.2. Используемые соглашения
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14 [RFC2119] [RFC8174] тогда и только тогда, когда они набраны заглавными буквами, как показано здесь.
2. Значения тегов
Всем тегам следует начинаться с префикса, указывающего владельца определения. Для поддержки регистрации префиксов тегов используется реестр IANA (параграф 7.1). В настоящее время определены 3 префикса. Этот документ не задает дополнительной структуры тега после префикса и значение тега может включать любые символы типа string в YANG, за исключением возврата каретки (CR), новой строки и табуляции.
За исключением префикса, служащего для предотвращения конфликтов, этот документ намеренно не задает какой-либо структуры (т. е. ограничений) для значений тегов. Цель этого состоит в предотвращении произвольных ограничений на значения тегов, которые могут применять разработчики, операторы и пользователи. Это позволяет cвободно выбирать структуру (или ее отсутствие) для создаваемых тегов.
2.1. Теги IETF
Теги IETF начинаются с префикса ietf: и регистрируются в реестре IANA (параграф 7.2).
2.2. Теги производителей
Теги производителей начинаются с префикса vendor: и определяются производителем, реализующим модуль. Такие теги не регистрируются, однако производителям рекомендуется включать в тег дополнительную идентификацию для предотвращения конфликтов (это может быть имя компании или организации после префикса vendor:, например, vendor:example.com:vendor-defined-classifier).
2.3. Пользовательские теги
Пользовательскими считаются любые теги с префиксом user:. Эти теги задаются пользователем или администратором и не регистрируются. От пользователей не требуется применение префикса user:, но это рекомендуется для предотвращения конфликтов.
2.4. Зарезервированные теги
Все теги, не имеющие префикса ietf:, vendor: или user:, зарезервированы на будущее. Значения таких тегов не являются недействительными и просто резервируются в контексте спецификаций (например, RFC).
3. Управление тегами
Теги можно связать с модулем разными способами. Их можно определить и связать с модулем в процессе его создания, во время развертывания или с помощью пользовательских средств администрирования. Поскольку основными потребителями тегов являются пользователи, они могут также удалять теги независимо от способа их связывания с модулем.
3.1. Теги при создании модуля
Определение модуля может указывать набор тегов для добавления при реализации модуля. Эти теги указываются с помощью оператора расширения module-tag.
Если модуль определен в документе IETF Standards Track, теги должны относиться к IETF (параграф 2.1). Таким образом, новые модули могут приводить к добавлению тегов IETF в реестр IANA, определенный в параграфе 7.2, и реестр IANA будет служить для предотвращения дубликатов.
3.2. Теги при реализации
Реализация может включать дополнительные теги, связанные с модулем, которым следует быть тегами IETF (т. е. зарегистрированными) или производителя.
3.3. Теги, устанавливаемые пользователем
Теги любого типа (с префиксом или без него) могут быть добавлены или удалены пользователем с помощью обычных механизмов настройки конфигурации. Для удаления тега из рабочего хранилища пользователь добавляет соответствующую запись максирования (masked-tag) для данного модуля.
4. Структура модуля тегов
4.1. Дерево модуля тегов
Ниже приведено дерево, связанное с модулем ietf-module-tags. Значение символов описано в [RFC8340].
module: ietf-module-tags
+--rw module-tags
+--rw module* [name]
+--rw name yang:yang-identifier
+--rw tag* tag
+--rw masked-tag* tag
Рисунок 1. Дерево тегов модуля YANG.
4.2. Модуль YANG
<CODE BEGINS> file "ietf-module-tags@2021-01-04.yang"
module ietf-module-tags {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags";
prefix tags;
import ietf-yang-types {
prefix yang;
}
organization
"IETF NetMod Working Group (NetMod)";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Christian Hopps
<mailto:chopps@chopps.org>
Author: Lou Berger
<mailto:lberger@labn.net>
Author: Dean Bogdanovic
<mailto:ivandean@gmail.com>";
description
"Этот модуль описывает механизм связывания тегов с модулями
YANG. Теги могут быть выделены IANA или определены приватно.
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
лицам, указанным как авторы кода. Все права защищены.
Распространение и использование в исходной или двоичной форме
с изменениями или без таковых разрешено в соответствии с
упрощенной лицензией BSD, как указано в параграфе 4.c
документа IETF Trust Legal Provisions применительно к
документам IETF (https://trustee.ietf.org/license-info).
Данная версия модуля YANG является частью RFC 8819
(https://www.rfc-editor.org/info/rfc8819), где правовые
аспекты изложены более полно.
Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ НУЖНО,
СЛЕДУЕТ, НЕ СЛЕДУЕТ, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО,
НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии
с BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
указаны заглавными буквами, как показано здесь.";
revision 2021-01-04 {
description
"Исходный выпуск.";
reference
"RFC 8819: YANG Module Tags";
}
typedef tag {
type string {
length "1..max";
pattern '[\S ]+';
}
description
"Тег является значением типа string, не включающим символов
возврата каретки, перевода строки и табулфции. Теги СЛЕДУЕТ
начинать с зарегистрированного префикса, однако теги без
такого префикса НЕ СЛЕДУЕТ считать недействительными.";
}
extension module-tag {
argument tag;
description
"Аргумент tag имеет тип tag. Этот оператор расширения применяется
авторами модулей для указания тегов, которые системе СЛЕДУЕТ
добавлять автоматически. Таким образом, источником значения для
предопределенных тегов следует устанавливать system [RFC8342].";
}
container module-tags {
description
"Содержит список модулей и связанных с ними тегов.";
list module {
key "name";
description
"Список модулей и связанных с ними тегов.";
leaf name {
type yang:yang-identifier;
mandatory true;
description
"Имя модуля YANG.";
}
leaf-list tag {
type tag;
description
"Теги, связанные с модулем. Зарезервированные префиксы
указаны в реестре IANA YANG Module Tag Prefixes, а теги
IETF - в реестре IANA IETF YANG Module Tags.
Состояние operational [RFC8342] для этого списка
создается, как показано ниже.
1) Системные теги (теги с источником system).
2) Заданные пользователем теги (теги с источником intended).
3) Все теги, соответствующие masked-tag удаляются.";
}
leaf-list masked-tag {
type tag;
description
"Список тегов, которые на следует связывать с этим модулем.
Пользователь может удалить (замаскировать) теги из рабочего
хранилища данных [RFC8342], добавляя их в этот список.
Добавление в список тега, не связанного с модулем, не
является ошибкой и не будет оказывать никакого влияния.";
}
}
}
}
<CODE ENDS>
Рисунок 2. Модуль тегов.
5. Другая классификация
Следует отметить наличие другого документа с классификацией модулей YANG [RFC8199]. Этот документ классифицирует модули логически и не включает тегов или иных механизмов. Модули YANG в нем разделены на две категории (service и element), для каждой из которых возможны 3 источника – standard, vendor или user. Это обеспечивает хороший способ обсуждения и идентификации модулей в целом. Определенные здесь теги IETF поддерживают стиль классификации, описанный в [RFC8199].
6. Рекомендации для создателей модулей
Этот раздел обновляет [RFC8407].
6.1. Определение стандартных тегов
Модуль может указывать (с помощью операторов расширения module-tag) набор тегов, автоматически связываемых с ним (т. е. не добавляемых при настройке конфигурации).
module example-module {
namespace "https://example.com/yang/example";
prefix "ex";
//...
import module-tags { prefix tags; }
tags:module-tag "ietf:some-new-tag";
tags:module-tag "ietf:some-other-tag";
// ...
}
Авторы модулей могут использовать имеющиеся стандартные теги или задавать новые в определении модели. Для стандартизованных IETF модулей новые теги должны включаться в реестр IANA, определенный в параграфе 7.2.
7. Взаимодействие с IANA
7.1. Реестр YANG Module Tag Prefixes
Агентство IANA создало субреестр YANG Module Tag Prefixes в реестре YANG Module Tags для регистрации префиксов тегов. Всем тегам модулей YANG следует начинаться с одного из префиксов, включенных в этот реестр.
Префиксам в этом реестре следует быть короткими строками алфавитно-цифровых символов ASCII в нижнем регистре, заканчивающимися символом :. Включение префиксов в этот реестр выполняется по процедуре Specification Required [RFC8126]. Значения Reference и Assignee должны позволять идентифицировать организацию, которой был выделен префикс, и ее контактные данные.
Начальные значения префиксов указаны в таблице 1.
Таблица 1.
|
Префикс |
Описание |
Документ |
Организация |
|---|---|---|---|
|
ietf: |
Теги IETF, включенные в реестр IANA IETF YANG Module Tags. |
RFC 8819 |
IETF |
|
vendor: |
Не регистрируемые теги, выделенные разработчиком модуля. |
RFC 8819 |
IETF |
|
user: |
Не регистрируемые теги, выделенные пользователем или для него. |
RFC 8819 |
IETF |
Другим органам стандартизации (standards development organization или SDO), желающим создать свой набор тегов, следует получить префикс из этого реестра.
7.2. Реестр IETF YANG Module Tags
Агентство IANA создало субреестр IETF YANG Module Tags в реестре YANG Module Tags ниже реестра YANG Module Tag Prefixes.
Этот реестр включает теги, имеющие зарегистрированный префикс ietf:. Новые значения тегов должны быть хорошо обдуманы и не должны представлять собой комбинацию уже имеющихся тегов IETF. Выделенные IANA теги должны соответствовать требованиям Net-Unicode [RFC5198] без нормализации. Значения тегов выделяются по процедуре IETF Review [RFC8126].
Начальные значения тегов приведены в таблице 2.
Таблица 2.
|
Tag |
Description |
Reference |
|---|---|---|
|
ietf:network-element-class |
Элемент сети в соответствии с [RFC8199]. |
[RFC8199] |
|
ietf:network-service-class |
Сетевая служба в соответствии с [RFC8199]. |
[RFC8199] |
|
ietf:sdo-defined-class |
Модуль, определенный органом стандартизации. |
[RFC8199] |
|
ietf:vendor-defined-class |
Модуль, определенный производителем. |
[RFC8199] |
|
ietf:user-defined-class |
Модуль, определенный пользователем. |
[RFC8199] |
|
ietf:hardware |
Связан с оборудованием (например, инвентаризация). |
RFC 8819 |
|
ietf:software |
Связан с программой (например, установленной ОС). |
RFC 8819 |
|
ietf:protocol |
Представляет протокол (часто с другим тегом для уточнения). |
RFC 8819 |
|
ietf:qos |
Связан с качеством обслуживания. |
RFC 8819 |
|
ietf:network-service-app |
Связан с приложением сетевых услуг (например, сервер NTP, DNS, DHCP и т. п.). |
RFC 8819 |
|
ietf:system-management |
Связан с управлением системой (например, протокол управления, такой как TACACS+, SNMP, NETCONF.). |
RFC 8819 |
|
ietf:oam |
Связан с OAM (Operations, Administration, Maintenance, например, BFD). |
RFC 8819 |
|
ietf:routing |
Связан с маршрутизацией. |
RFC 8819 |
|
ietf:security |
Связан с безопасностью. |
RFC 8819 |
|
ietf:signaling |
Связан с сигнализацией плоскости управления. |
RFC 8819 |
|
ietf:link-management |
Связан с управлением каналом. |
RFC 8819 |
7.3. Обновление реестра IETF XML
Этот документ регистрирует URI в IETF XML Registry [RFC3688] в соответствии с форматом [RFC3688].
URI: urn:ietf:params:xml:ns:yang:ietf-module-tags Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-module-tags-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace.
7.4. Обновление реестра YANG Module Names
Документ включает 2 модуля YANG в реестр YANG Module Names [RFC6020] в соответствии с форматом [RFC6020].
name: ietf-module-tags namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags prefix: tags reference: RFC 8819 name: ietf-module-tags-state namespace: urn:ietf:params:xml:ns:yang:ietf-module-tags-state prefix: tags-s reference: RFC 8819
8. Вопросы безопасности
Определенный в этом документе модуль YANG предназначен для доступа по протоколу NETCONF [RFC6241]. Нижним уровнем NETCONF является защищенный транспорт с обязательной реализацией Secure Shell (SSH) [RFC6242].
Этот документ добавляет возможность связать метаданные (теги) с модулями YANG. Документ не задает каких-либо действий на основе этих ассоциаций, поэтому сам по себе не создает новых проблем безопасности.
Пользователи тегов могут определять различные действия на основе метаданных из тегов. Такие действия и их определения выходят за рамки данного документа. Пользователи должны самостоятельно рассмотреть влияние определяемых действий на безопасность, включая возможность «маскирования» тегов другими пользователями.
9. Литература
9.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>.
[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, “YANG Module Classification”, RFC 8199, DOI 10.17487/RFC8199, July 2017, <https://www.rfc-editor.org/info/rfc8199>.
[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>.
[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>.
9.2. Дополнительная литература
[RFC3688] Mealling, M., “The IETF XML Registry”, BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC5198] Klensin, J. and M. Padlipsky, “Unicode Format for Network Interchange”, RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[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>.
[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>.
Приложение A. Примеры
Ниже приведен вымышленный пример вывода NETCONF, полученного по запросу списка тегов модулей. Для краткости показаны результаты лишь для нескольких модулей.
<ns0:data xmlns:ns0="urn:ietf:params:xml:ns:netconf:base:1.0">
<t:module-tags
xmlns:t="urn:ietf:params:xml:ns:yang:ietf-module-tags">
<t:module>
<t:name>ietf-bfd</t:name>
<t:tag>ietf:network-element-class</t:tag>
<t:tag>ietf:oam</t:tag>
<t:tag>ietf:protocol</t:tag>
<t:tag>ietf:sdo-defined-class</t:tag>
</t:module>
<t:module>
<t:name>ietf-isis</t:name>
<t:tag>ietf:network-element-class</t:tag>
<t:tag>ietf:protocol</t:tag>
<t:tag>ietf:sdo-defined-class</t:tag>
<t:tag>ietf:routing</t:tag>
</t:module>
<t:module>
<t:name>ietf-ssh-server</t:name>
<t:tag>ietf:network-element-class</t:tag>
<t:tag>ietf:protocol</t:tag>
<t:tag>ietf:sdo-defined-class</t:tag>
<t:tag>ietf:system-management</t:tag>
</t:module>
</t:module-tags>
</ns0:data>
Рисунок 3. Пример вывода для запроса NETCONF.
Приложение B. Модуль просмотра состояния не-NMDA
Ниже приведен модуль [RFC8407] для поддержки просмотра рабочего состояния сервера, не поддерживающего NMDA.
<CODE BEGINS> file "ietf-module-tags-state@2021-01-04.yang"
module ietf-module-tags-state {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-module-tags-state";
prefix tags-s;
import ietf-yang-types {
prefix yang;
}
import ietf-module-tags {
prefix tags;
}
organization
"IETF NetMod Working Group (NetMod)";
contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
Author: Christian Hopps
<mailto:chopps@chopps.org>
Author: Lou Berger
<mailto:lberger@labn.net>
Author: Dean Bogdanovic
<mailto:ivandean@gmail.com>";
description
"Этот модуль описывает механизм связывания тегов с модулем YANG.
Теги могут выделяться IANA или определяться приватно.
Это временный модуль, предназначенный для использования
реализациями, еще не поддерживающими NMDA.
Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
лицам, указанным как авторы кода. Все права защищены.
Распространение и использование в исходной или двоичной форме
с изменениями или без таковых разрешено в соответствии с
упрощенной лицензией BSD, как указано в параграфе 4.c
документа IETF Trust Legal Provisions применительно к
документам IETF (https://trustee.ietf.org/license-info).
Данная версия модуля YANG является частью RFC 8819
(https://www.rfc-editor.org/info/rfc8819), где правовые
аспекты изложены более полно.";
revision 2021-01-04 {
description
"Исходный выпуск.";
reference
"RFC 8819: YANG Module Tags";
}
container module-tags-state {
config false;
status deprecated;
description
"Содержит список модулей и связанных с ними тегов.";
list module {
key "name";
status deprecated;
description
"Список модулей и связанных с ними тегов.";
leaf name {
type yang:yang-identifier;
mandatory true;
status deprecated;
description
"Имя модуля YANG.";
}
leaf-list tag {
type tags:tag;
status deprecated;
description
"Теги, связанные с модулем. Зарезервированные префиксы
указаны в реестре IANA YANG Module Tag Prefixes, а теги
IETF - в реестре IANA IETF YANG Module Tags.
Содержимое этого списка создается, как показано ниже.
1) Системные теги (теги, добавленные системой).
2) Заданные пользователем теги (теги, заданные в конфигурации).
3) Все теги, соответствующие masked-tag в соответствующем
листе ietf-module-tags:module-tags:module-tag удаляются.";
}
}
}
}
<CODE ENDS>
Рисунок 4. Модуль состояния тегов модуля не-NMDA
Благодарности
Большое спасибо Robert Wilton за помощь в предоставлении примеров использования а также в создании модуля non-NMDA.
Адреса авторов
Christian Hopps
LabN Consulting, L.L.C.
Email: chopps@chopps.org
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Dean Bogdanovic
Volta Networks
Email: ivandean@gmail.com
Перевод на русский язык
Николай Малых
1Internet Engineering Task Force.
2Internet Engineering Steering Group.