RFC 7952 Defining and Using Metadata with YANG

Опубликовано 14.08.2016 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                         L. Lhotka
Request for Comments: 7952                                        CZ.NIC
Updates: 6110                                                August 2016
Category: Standards Track
ISSN: 2070-1721

Defining and Using Metadata with YANG

Определение и использование метаданных в YANG

PDF

Аннотация

Документ определяет расширение YANG, позволяющее определять аннотации метаданных в моделях YANG, а также задаёт кодирование аннотаций в формате XML и JSON и другие правила аннотирования экземпляров узлов данных YANG.

Статус документа

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7952.

Авторские права

Авторские права (Copyright (c) 2016) принадлежат 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 [RFC7950] с метаданными. Ниже приведены примеры использования аннотаций.

  • Дополнение модели данных сведениями с метаданными экземпляров, комментариями и т. п.

  • Предоставление информации о разборе данных на пользовательских интерфейсах.

  • Деактивация субдерева в хранилище данных конфигурации с сохранением самих данных.

  • Протоколы управления сетью часто используют аннотации метаданных для различных целях в запросах операций и откликах. Например, операция <edit-config> в протоколе NETCONF (см. параграф в [RFC6241]) использует аннотации в форме атрибутов XML для идентификации местоположения в хранилище конфигурации и типа операции.

Однако аннотации метаданных могут создавать проблемы взаимодействия, если они применяются нерегулярно разными сторонами и/или без надлежащего документирования. Поэтому надёжной схеме метаданных для YANG следует соответствовать приведённым ниже требованиям.

  1. Набор аннотаций должен быть расширяемым децентрализованно, чтобы можно было задавать новые аннотации без риска конфликтов с имеющимися и используемыми другими.

  2. Синтаксис и семантика аннотаций должны документироваться, а документаций должна быть легко доступна.

  3. Клиенты протоколов управления сетью, таких как NETCONF [RFC6241] и RESTCONF [RESTCONF], должны быть способны найти все аннотации, поддерживаемые сервером, и корректно идентифицировать каждую.

  4. Передаваемым серверам аннотациям не следует создавать помех клиентам, не понимающим аннотации.

Этот документ предлагает систематизированный путь определения аннотаций метаданных, для чего в модуле ietf-yang-metadata (раздел 7) определяется расширение YANG annotation. Модули YANG, импортирующие этот модуль, могут применять оператор annotation для определения аннотация.

Ниже указаны преимущества определения аннотаций метаданных в модуле YANG.

  • Каждая аннотация привязывается к имени модуля YANG и URI пространства имён. Это делает её представление в экземплярах документов (XML и JSON) прямым и согласованным с представлением экземпляров узлов данных YANG.

  • Аннотации в документах IETF Standards Track опосредованно регистрируются в реестре IANA YANG Module Names [RFC6020].

  • Аннотации включаются в модель данных. Компиляторы YANG и инструменты, поддерживающие определённые аннотации, могут учитывать их и соответственно менять своё поведение.

  • Семантика аннотаций задаётся в операторах description и reference.

  • Аннотации можно задавать по условию, используя оператор if-feature.

  • Тип каждой аннотации указывается явно, это может быть также встроенный или производный тип YANG, доступный для узлов leaf или leaf-list.

В представлении XML атрибуты XML служат естественным способом присоединения аннотаций к экземплярам узлов данных. Этот документ преднамеренно принимает ряд ограничений для сохранения совместимости с XML-кодированием экземпляров узлов данных YANG и ограничениями атрибутов XML. В частности:

  • аннотации могут быть лишь скалярными значениями;

  • аннотации не могут быть прикреплены к экземпляру list или leaf-list в целом и должны прикрепляться к отдельным записям list или leaf-list.

В соответствии с правилами для расширений YANG (параграф 6.3.1 в [RFC7950]) для определений аннотаций задаются относительно слабые требования по соответствию. Рассматривалась возможность введения нового встроенного оператора YANG для задания аннотаций, но это было сочтено серьёзным изменением языка, не подходящим для языка YANG 1.1, считающегося поддерживаемым выпуском. После оценки реального применения аннотаций метаданных возможно добавление встроенного оператора в будущий выпуск YANG.

2. Терминология

2.1. Уровни требований

Ключевые слова должно (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

2.2. Термины из других документов

Ниже перечислены термины, определённые в [RFC6241].

  • capability — возможность, свойство;

  • client — клиент;

  • datastore — хранилище данных;

  • message — сообщение;

  • protocol operation — протокольная операция;

  • server — сервер.

Ниже перечислены термины, определённые в [RFC7950].

  • action — действие;

  • anydata — любые данные;

  • anyxml — любые данные XML;

  • built-in type — встроенный тип;

  • container — контейнер;

  • data model — модель данных;

  • data node — узел данных;

  • data tree — дерево данных;

  • derived type — производный тип;

  • extension — расширение;

  • leaf — лист;

  • leaf-list — лист-список;

  • list — список;

  • module — модуль;

  • Remote Procedure Call (RPC) input and output – ввод и вывод RPC.

Ниже перечислены термины, определённые в [XML-INFOSET].

  • attribute — атрибут;

  • document — документ;

  • element — элемент.

Ниже перечислены термины, определённые в [XML-NAMES].

  • local name — локальное имя;

  • namespace name — название пространства имён;

  • prefix — префикс;

  • qualified name — полное имя.

Ниже перечислены термины, определённые в [RFC7159].

  • array — массив;

  • member — элемент, член;

  • object — объект;

  • primitive type — тип примитива.

2.3. Пространства имён и префиксы

В приведённом далее тексте имена элементов XML и операторы расширения YANG всегда указываются с явными префиксами пространства имён, которое предполагается связанным со ссылкой URI, как показано в таблице 1.

Таблица 1. Префиксы пространств имён и URI.

Префикс

URI

elm

http://example.org/example-last-modified

md

urn:ietf:params:xml:ns:yang:ietf-yang-metadata

rng

http://relaxng.org/ns/structure/1.0

2.4. Определения новых терминов

annotation — аннотация

Один элемент метаданных, присоединяемых к экземплярам узлов данных YANG.

metadata — метаданные

Дополнительные сведения для дерева данных.

metadata object — объект метаданных

Объект в формате JSON, содержащий все аннотации, присоединённые к данному экземпляру узла данных.

3. Определение аннотаций в YANG

Аннотации метаданных задаются расширением YANG md:annotation, определенным в модуле ietf-yang-metadata (раздел 7).

Субоператоры md:annotation приведены в таблице 2. Они являются базовыми операторами YANG и числа во втором столбце указывают параграфы [RFC7950], где эти операторы определены.

Таблица 2. Субоператоры md:annotation.

Субоператор

Параграф в RFC 7950

Число элементов

description

7.21.3

0..1

if-feature

7.20.2

0..n

reference

7.21.4

0..1

status

7.21.2

0..1

type

7.6.3

1

units

7.3.3

0..1

Аннотация имеет единственное значение. Субоператор type, который должен присутствовать, принимает в качестве аргумента имя имеющегося встроенного или производного типа и значение аннотации должно соответствовать этому типу (см. параграф 7.4 в [RFC7950]).

Аннотацию можно сделать условной с помощью одного или нескольких операторов if-feature и такая аннотация будет поддерживаться лишь серверами, анонсирующими соответствующее свойство.

Семантику и правила использования аннотации следует полностью задавать операторами description, reference и units.

Аннотации недопустимо менять семантику дерева данных, определённую YANG. Например, не разрешается определять и применять аннотацию, позволяющую переопределять уникальность записей leaf-list.

Оператор status можно применять так же, как для узлов данных YANG.

Модули YANG с одним или несколькими операторами md:annotation не следует применять для определения узлов данных или группировок. Кроме того в таких модулях недопустимо определять производные типы и свойства (feature), если они не применяются определениями аннотаций в этом модуле.

3.1. Пример определения

Приведённый ниже модуль определяет аннотацию last-modified.

   module example-last-modified {
     namespace "http://example.org/example-last-modified";
     prefix "elm";
     import ietf-yang-types {
       prefix "yang";
     }
     import ietf-yang-metadata {
       prefix "md";
     }
     md:annotation last-modified {
       type yang:date-and-time;
       description
         "Эта аннотация содержит дату и время последнего 
          изменения (или создания) аннотируемого экземпляра.";
     }
   }

4. Использование аннотаций

Анонсируя модуль YANG с аннотацией метаданных, заданной оператором md:annotation, сервер указывает свою готовность обрабатывать эту аннотацию в соответствии с её определением. Таким образом, анонсированная сервером аннотация может быть присоединена к экземпляру узла данных, определённого в любом модуле YANG, реализованном этим сервером.

В зависимости от семантики аннотация может оказывать влияние лишь в определённых деревьях данных и/или экземплярах определённых типов узлов данных.

Клиенту недопустимо добавлять аннотацию к экземплярам узлов данных, если сервер не анонсировал это.

Нужно соблюдать осторожность при внесении аннотаций с системы управления сетью, чтобы избежать проблем совместимости и программных отказов, вызываемых клиентами, не понимающими семантики аннотаций. Как правило, сервер может без опаски использовать аннотации в указанных ниже случаях.

  • Аннотация является неотъемлемой частью встроенной или согласованной возможности протокола.

  • Аннотация содержит вспомогательные сведения, не критичные для работы протокола.

  • Клиент явно запросил у сервера включение аннотации в отклик (например, параметром запроса).

5. Представление аннотаций

Атрибуты XML являются естественным способом представления метаданных в документах экземпляров XML. Для JSON [RFC7159] нет общепринятого способа представления метаданных. Этот документ вводит специальный метод кодирования, соответствующий представлению JSON для экземпляров узлов данных YANG, заданного в [RFC7951].

5.1. XML

Аннотации метаданных добавляются в экземпляры узлов данных YANG с кодированием XML как атрибуты XML в соответствии с приведёнными ниже правилами.

  • В качестве локального имени атрибута нужно использовать имя аннотации, заданное в аргументе соответствующего оператора md:annotation.

  • Пространство имён атрибута нужно указывать идентификатором URI, заданным как аргумент оператора namespace в модуле YANG, где определяется аннотация. Рекомендуется использовать префикс, заданный в операторе prefix того же модуля, в полном имени атрибута.

  • Значение атрибута нужно представлять тем же способом, который применяется для значения экземпляра YANG leaf того же типа (см. раздел 9 в [RFC7950].

Например, аннотацию last-modified, заданную в параграфе 3.1, можно представить в показанной ниже форме.

   <foo xmlns:elm="http://example.org/example-last-modified"
        elm:last-modified="2015-09-16T10:27:35+02:00">
     ...
   </foo>

5.2. JSON

Определённое в этом параграфе кодирование метаданных JSON имеет указанные ниже свойства.

  1. Кодирование экземпляров узлов данных YANG, заданное в [RFC7951], не меняется.

  2. Пространство имён аннотации метаданных кодируется как пространство имён экземпляров узлов данных YANG [RFC7951].

5.2.1. Объект метаданных и аннотации

Все аннотации метаданных, назначенные экземпляру узла данных YANG, представляются как элементы (пары имя-значение) одного объекта JSON, называемого объектом метаданных. Размещение и имя объекта зависят от типа узла данных, как описано ниже.

Имя аннотации метаданных (как элемент объекта метаданных) использует синтаксис ABNF [RFC5234], где создание identifier определяет раздел 14 в [RFC7950]

   annotation-name = identifier ":" identifier

Левая часть идентификатора является именем модуля YANG, где определена аннотация, а правый элемент identifier является именем аннотации, заданным в аргументе соответствующего оператора md:annotation.

В отличие от имён элементов в экземплярах узлов данных YANG с представлением JSON (раздел 4 в [RFC7951]) для аннотаций всегда должен явно указываться идентификатор пространства имён (имя модуля).

Значение аннотации метаданных нужно представлять точно так же, как значение узла YANG leaf, имеющего общий тип с аннотацией (см. раздел 6 в [RFC7951]).

5.2.2. Добавление аннотации для anydata, container, list

Для экземпляра узла данных, представленного как объект JSON (т. е. контейнер, запись списка или узел anydata), объект метаданных добавляется как новый элемент этого объекта с именем @.

Примеры

  • cask — контейнер или узел anydata

   "cask": {
     "@": {
       "example-last-modified:last-modified":
         "2015-09-16T10:27:35+02:00"
     },
     ...
   }

  • seq — список, с ключом name, аннотация last-modified добавляется лишь к первому элементу

   "seq": [
     {
       "@": {
         "example-last-modified:last-modified":
             "2015-09-16T10:27:35+02:00"
       },
       "name": "one",
       ...
     },
     {
       "name": "two",
       ...
     }
   ]

5.2.3. Добавление аннотаций в экземпляры anyxml и leaf

Для экземпляра anyxml или leaf объект метаданных добавляется в виде пары имя-значение, где имя указывается символом @, объединенным (конкатенация) с именем аннотируемого элемента leaf или anyxml. Часть пространства имён (имя модуля) включается лишь в том случае, когда она входит в имя аннотируемого элемента.

Примеры

  • flag — узел leaf типа boolean, определённый в модуле foo; предполагается, что пространство имён представлено в кодировании JSON

   "foo:flag": true,
   "@foo:flag": {
     "example-last-modified:last-modified":
       "2015-09-16T10:27:35+02:00"
   }

  • stuff — узел anyxml

   "stuff": [1, null, "three"],
   "@stuff": {
     "example-last-modified:last-modified":
       "2015-09-16T10:27:35+02:00"
   }

5.2.4. Добавление аннотаций в записи leaf-list

Для записи leaf-list, представленной массивом JSON со значениями первичного (primitive) типа, аннотации могут быть назначены одной или нескольким записям путём добавления пар имя-массив, где именем является символ @, объединённый с именем аннотируемого leaf-list, а значением является массив JSON, i-м элементом которого является объект метаданных с аннотациями, назначенными i-й записи leaf-list, или null, если для записи нет аннотации. Нули в конце массива (т. е., следующие за последним непустым объектом метаданных) можно опускать.

Приведённый ниже пример экземпляра leaf-list имеет 4 записи и аннотации last-modified для второй и третьей записи.

   "bibliomod:folio": [6, 3, 7, 8],
   "@bibliomod:folio": [
     null,
     { "example-last-modified:last-modified":
         "2015-06-18T17:01:14+02:00"
     },
     { "example-last-modified:last-modified":
         "2015-09-16T10:27:35+02:00"
     }
   ]

6. Представление аннотаций в схемах DSDL

В [RFC6110] задано стандартное сопоставление моделей данных YANG с языками определения схемы документа (Document Schema Definition Languages или DSDL) [ISO.19757-1]. В этом параграфе задаётся сопоставление для оператора расширения md:annotation (раздел 7), которое позволяет проверять экземпляры документов XML с аннотациями метаданных.

Первый шаг процедуры сопоставления с DSDL (т. е. преобразования модели данных YANG в гибридную схему, см. раздел 6 в [RFC6110]) измене, как показано ниже.

  1. Если модель данных содержит хотя бы один оператор md:annotation, определение именованного шаблона RELAX NG [ISO.19757-2] должно добавляться как потомок корневого элемента <rng:grammar> в гибридной схеме. Для этого шаблона рекомендуется использовать имя __yang_metadata__.

  2. Ссылка на именованный объект, описанный в элементе 1, должна включаться как потомок каждого шаблона <rng:element>, соответствующего узлу данных anydata, container, leaf, leaf-list или list.

  3. Каждая аннотация метаданных, заданная в форме

       md:annotation ARGUMENT {
         ...
       }

сопоставляется с шаблоном RELAX NG [ISO.19757-2]

       <rng:optional>
         <rng:attribute name="PREFIX:ARGUMENT">
           ...
         </rng:attribute>
       </rng:optional>

где PREFIX — префикс, связанный с URI пространства имён модуля YANG с оператором md:annotation. Указанный выше шаблон нужно вставлять как потомка именованного шаблона, описанного в п. 1.

  1. Субоператоры md:annotation нужно сопоставлять с потомками шаблона rng:attribute в точном соответствии с разделом 10 в [RFC6110].

Например, именованный шаблон (п. 1) при создании лишь для аннотации last-modified будет иметь вид

   <rng:define name="__yang_metadata__">
     <rng:optional>
       <rng:attribute name="elm:last-modified">
         <rng:ref name="ietf-yang-types__date-and-time"/>
       </rng:attribute>
     </rng:optional>
   </rng:define>

Каждый шаблон rng:element, соответствующий узлу anydata, container, leaf, list или leaf-list, будет включать ссылку на приведённый выше шаблон. Например,

   <rng:element name="foo:bar">
     <rng:ref name="__yang_metadata__"/>
     ...
   </rng:element>

Отметим, что такая ссылка не требуется для шаблонов rng:element, соответствующих узлам anyxml, поскольку они уже разрешают присоединять к своим экземплярам атрибуты XML.

Второй этап процедуры сопоставления с DSDL (преобразование гибридной схемы в RELAX NG [ISO.19757-2], Schematron [ISO.19757-3] и Document Semantics Renaming Language (DSRL) [ISO.19757-8] не меняется при наличии md:annotation.

7. Модуль YANG Metadata

   <CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang"

   module ietf-yang-metadata {
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";

     prefix "md";

     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        WG Chair: Lou Berger
                  <mailto:lberger@labn.net> 

        WG Chair: Kent Watsen
                  <mailto:kwatsen@juniper.net> 

        Editor:   Ladislav Lhotka
                  <mailto:lhotka@nic.cz>"; 

     description
       "Этот модуль YANG определяет оператор extension, позволяющий
        определять аннотации метаданных.

        Авторские права (Copyright (c) 2016) принадлежат IETF Trust 
        и лицам, указанным как авторы кода. Все права защищены.

        Распространение и использование в исходной и двоичной форме
        с изменениями или без них разрешается в соответствии с условиями,
        указанными в упрощённой лицензии BSD, изложенной в разделе 4.c
        Правового положения IETF Trust применительно к документам IETF
        (http://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 7952
        (http://www.rfc-editor.org/info/rfc7952), где
        правовые аспекты выражены более полно.";

     revision 2016-08-05 {
       description
         "Исходный выпуск.";
       reference
         "RFC 7952: Defining and Using Metadata with YANG";
     }

     extension annotation {
       argument name;
       description
         "Это расширение позволяет определять аннотации метаданных в
          модулях YANG. Оператор md:annotation может применяться лишь на
          верхнем уровне модуля или субмодуля YANG, т. е. он становится
          новым вариантом в правиле создания ABNF для body-stmts 
          (раздел 14 в RFC 7950).

          Аргумент md:annotation задаёт имя аннотации. Синтаксически это
          идентификатор YANG, как указано в параграфе 6.2 RFC 7950.

          Аннотация, заданная этим оператором extension, наследует
          пространство имён и иной контекст из модуля YANG, где она 
          определена.

          Тип данных значения annotation задаётся так же, как для узлов
          leaf с использованием оператора type.

          Семантика аннотации и другие сведения могут быть указаны
          с помощью стандартных субоператоров YANG (необязательно)
          description, if-feature, reference, status, units.

          Сервер анонсирует поддержку определённой аннотации путём 
          включения модуля, где она определена, среди иных анонсируемых
          модулей YANG, например, в сообщении NETCONF <hello>
          или в библиотеке YANG (RFC 7950). После этого аннотацию можно
          связать с любым экземпляром узла данных, определённого в любом
          модулей YANG, анонсируемом сервером.

          Кодирование XML и JSON для аннотаций задано в RFC 7952.";
     }
   }

   <CODE ENDS>

8. Взаимодействие с IANA

Этот документ регистрирует URI в IETF XML Registry [RFC3688]. В соответствии с RFC 3688 это будет

   URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
   Registrant Contact: The NETMOD WG of the IETF.
   XML: N/A, the requested URI is an XML namespace.

Документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020].

   Name:         ietf-yang-metadata
   Namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-metadata
   Prefix:       md
   Reference:    RFC 7952

9. Вопросы безопасности

Этот документ представляет механизм для определения аннотаций в модулях YANG и их привязки к экземплярам узлов данных YANG. Сам механизм не создаёт угроз безопасности. Влияние заданных с его помощью аннотаций на безопасность должно рассматриваться в соответствующих определениях аннотаций.

Для аннотаций следует применять правила контроля доступа, не менее строгие, чем используются для аннотируемых узлов. Рекомендуется моделировать чувствительные в плане приватности или конфиденциальности данные как обычные узлы данных YANG, а не аннотации.

10. Литература

10.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.

[RFC6110] Lhotka, L., Ed., «Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content», RFC 6110, DOI 10.17487/RFC6110, February 2011, <http://www.rfc-editor.org/info/rfc6110>.

[RFC7159] Bray, T., Ed., «The JavaScript Object Notation (JSON) Data Interchange Format», RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.

[RFC7951] Lhotka, L., «JSON Encoding of Data Modeled with YANG», RFC 7951, DOI 10.17487/RFC7951, August 2016, <http://www.rfc-editor.org/info/rfc7951>.

[XML-INFOSET] Cowan, J. and R. Tobin, «XML Information Set (Second Edition)», World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

[XML-NAMES] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, «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>.

10.2. Дополнительная литература

[ISO.19757-1] International Organization for Standardization, «Information Technology — Document Schema Definition Languages (DSDL) — Part 1: Overview», ISO/IEC 19757-1, September 2008.

[ISO.19757-2] International Organization for Standardization, «Information technology — Document Schema Definition Language (DSDL) — Part 2: Regular-grammar-based validation — RELAX NG», ISO/IEC 19757-2:2008, December 2008.

[ISO.19757-3] International Organization for Standardization, «Information technology — Document Schema Definition Languages (DSDL) — Part 3: Rule-based validation – Schematron», ISO/IEC 19757-3:2016, January 2016.

[ISO.19757-8] International Organization for Standardization, «Information Technology — Document Schema Definition Languages (DSDL) — Part 8: Document Semantics Renaming Language — DSRL», ISO/IEC 19757-8:2008(E), December 2008.

[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», Work in Progress3, draft-ietf-netconf-restconf-16, August 2016.

[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, <http://www.rfc-editor.org/info/rfc6241>.

Благодарности

Автор признателен Andy Bierman, Martin Bjorklund, Benoit Claise, Juergen Schoenwaelder, Kent Watsen за полезные комментарии и предложения.

Адрес автора

Ladislav Lhotka
CZ.NIC
Email: lhotka@nic.cz


Перевод на русский язык


Николай Малых


nmalykh@protokols.ru 




1Internet Engineering Task Force — комиссия по решению инженерных задач Internet.






2Internet Engineering Steering Group — комиссия по инженерным разработкам Internet.






3Документ опубликован в RFC 8040. Прим. перев.



 											


		
						

							Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.													

					


					

					
			




	

		
Добавить комментарий