RFC 9144 Comparison of Network Management Datastore Architecture (NMDA) Datastores

Internet Engineering Task Force (IETF)                          A. Clemm
Request for Comments: 9144                                         Y. Qu
Category: Standards Track                                      Futurewei
ISSN: 2070-1721                                              J. Tantsura
                                                               Microsoft
                                                              A. Bierman
                                                               YumaWorks
                                                           December 2021

Comparison of Network Management Datastore Architecture (NMDA) Datastores

Сравнение хранилищ данных управления сетью (NMDA)

PDF

Аннотация

Этот документ определяет операцию удалённого вызова процедуры (Remote Procedure Call или RPC) для сравнения архитектуры хранилища данных управления сетью (Network Management Datastore Architecture или NMDA).

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

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

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

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

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

Авторские права (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, без каких-либо гарантий (как указано в Revised BSD License).

1. Введение

При пересмотре архитектуры NMDA [RFC8342] добавлены новые хранилища данных, поддерживающие формат YANG [RFC7950] и предоставляющие различные «точки зрения» (viewpoint) на поддерживаемые сервером данные. Новые хранилища YANG включают раздел <intended>, содержащий проверенные данные конфигурации, которые клиентское приложение планирует ввести в действие, и раздел <operational>, содержащий данные рабочего состояния (такие как статистика), а также реально применяемые данные конфигурации.

В NMDA введена концепция жизненного цикла (lifecycle) данных управления, отличающая данные конфигурации, предоставленные пользователем, данные, которые были фактически применены как часть рабочего состояния, и общие данные рабочего состояния, включающие параметры конфигурации, а также состояние и статистику.

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

Данные могут передаваться между хранилищами и возможно различие данных в разных хранилищах. Отчасти это ожидаемо, поскольку может возникать временной интервал между передачей конфигурации устройству с её отражением в хранилище <intended> и фактическим применением с отражением в <operational>. Однако в некоторых случаях элемент конфигурации, который должен быть применён, может не вступить в силу или на это потребуется длительное время. Это может быть обусловлено несоблюдением тех или иных условий, отказом от применения отдельных частей конфигурации, сочтённых неактивными, несоблюдением зависимостей от ресурсов или ошибками реализации при задании условий.

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

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

В этом документе вводится модель данных YANG, определяющая RPC, предназначенные для использования с протоколами NETCONF [RFC6241] и RESTCONF [RFC8040]. Эти RPC позволяют клиенту запросить у сервера сравнение двух хранилищ NMDA и отчёт о различиях между ними.

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

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

3. Обзор модели данных

Основой решения является новая операция управления <compare>, сравнивающая содержимое дерева данных в двух хранилищах. Эта операция отыскивает различия в значениях или узлах данных обоих хранилищ и возвращает найденные расхождения. Вывод имеет формат YANG Patch [RFC8072].

Модель данных YANG определяет операцию <compare> как новую процедуру RPC. Входные параметры операции указаны ниже.

source – источник

Указывает хранилище, служащее основой (эталоном) для сравнения, например, <intended>.

target – назначение

Указывает хранилище, сравниваемое с эталонным (source), например, <operational>.

filter-spec – спецификация фильтра

Фильтр, задающий извлекаемые части хранилища. Он служит селектором, указывающим узлы данных для сравнения и узлы, исключаемые из сравнения. Это позволяет искать различия лишь в интересующей части хранилища, например, в определённом субдереве. Отметим, что в фильтре нельзя использовать выражения для сопоставления со значениями узлов данных, поскольку это может вызвать трудности при реализации и обычно не требуется.

all – все

Указывает, что нужно включать все различия, в том числе относящиеся к узлам схемы, имеющимся лишь в одном из хранилищ. При отсутствии этого параметра автоматически выполняется предварительная фильтрация для исключения данных, которые не представлены в обоих хранилищах. Если какой-либо узел присутствует лишь в одном из хранилищ, все экземпляры этого узла схемы и их потомки исключаются из сравнения. Это позволяет клиентским приложениям сосредоточиться на различиях, определяющих фактическое несоответствие экземпляров данных без указания более сложных фильтров.

report-origin – источник отчёта

Указывает, что метаданные об источнике следует включать в вывод RPC. При отсутствии параметра метаданные источника в сравнении, включающем <operational>, опускаются. Отметим, что метаданные источника применимы лишь к хранилищу <operational> и не указываются в сравнении, не включающем <operational>, независимо от наличия этого параметра.

Операция представляет на выходе один параметр, описанный ниже.

differences – различия

Этот параметр содержит список различий, представляемых в соответствии с моделью данных YANG Patch [RFC8072]. Когда узел хранилища данных в эталонном источнике отсутствует в целевом хранилище, это может быть указано как delete или remove в файле различий (patch), поскольку сравнение здесь невозможно. Модель данных YANG Patch была дополнена для указания узлов эталонного хранилища (в дополнение к самому исправлению), которые нужно применить к источнику для создания целевого объекта. Когда целевым является хранилище <operational> и установлен входной параметр report-origin, метаданные источника включаются как часть исправления (patch). Это может помочь в объяснении причин различия в некоторых случаях, например, когда узел данных является частью <intended>, но источник того же узла в <operational> указан как system.

Модель данных определена в модуле YANG ietf-nmda-compare, структура которого показана ниже, в соответствии с обозначениями из [RFC8340].

   module: ietf-nmda-compare
     rpcs:
       +---x compare
          +---w input
          |  +---w source            identityref
          |  +---w target            identityref
          |  +---w all?              empty
          |  +---w report-origin?    empty
          |  +---w (filter-spec)?
          |     +--:(subtree-filter)
          |     |  +---w subtree-filter?
          |     +--:(xpath-filter)
          |        +---w xpath-filter?     yang:xpath1.0 {nc:xpath}?
          +--ro output
             +--ro (compare-response)?
                +--:(no-matches)
                |  +--ro no-matches?    empty
                +--:(differences)
                   +--ro differences
                      +--ro yang-patch
                         +--ro patch-id    string
                         +--ro comment?    string
                         +--ro edit* [edit-id]
                            +--ro edit-id         string
                            +--ro operation       enumeration
                            +--ro target          target-resource-offset
                            +--ro point?          target-resource-offset
                            +--ro where?          enumeration
                            +--ro value?
                            +--ro source-value?

Рисунок . Структура ietf-nmda-compare.

4. Модель данных YANG

Этот модуль YANG включает ссылки на [RFC6991], [RFC8342], [RFC8072], [RFC6241].

   <CODE BEGINS> file "ietf-nmda-compare@2021-12-10.yang"
   module ietf-nmda-compare {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-nmda-compare";
     prefix cmp;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore
          Architecture (NMDA)";
     }
     import ietf-yang-patch {
       prefix ypatch;
       reference
         "RFC 8072: YANG Patch Media Type";
     }
     import ietf-netconf {
       prefix nc;
       reference
         "RFC 6241: Network Configuration Protocol (NETCONF)";
     }

     organization
       "IETF NETMOD (Network Modeling) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netmod/> 
        WG List:  <mailto:netmod@ietf.org> 

        Author: Alexander Clemm
                <mailto:ludwig@clemm.org> 

        Author: Yingzhen Qu
                <mailto:yqu@futurewei.com> 

        Author: Jeff Tantsura
                <mailto:jefftant.ietf@gmail.com> 

        Author: Andy Bierman
                <mailto:andy@yumaworks.com>"; 
     description
       "Модель данных YANG определяет новую операцию <compare>, которая
        может применяться для сравнения хранилищ NMDA.

        Авторские права (Copyright (c) 2021) принадлежат IETF Trust и
        лицам, указанным как авторы кода. Все права защищены.
        Распространение и применение модуля в исходной или двоичной 
        форме с изменениями или без таковых разрешено в соответствии с
        лицензией Revised BSD License, изложенной в параграфе 4.c
        IETF Trust's Legal Provisions, применительно к документам IETF
        (https://trustee.ietf.org/license-info). 

        Эта версия модуля YANG является частью RFC 9144, где правовые
        аспекты приведены более полно.";

     revision 2021-12-10 {
       description
         "Исходный выпуск.";
       reference
         "RFC 9144: Comparison of Network Management Datastore
          Architecture (NMDA) Datastores";
     }

     /* RPC */
     rpc compare {
       description
         "Операция сравнения хранилищ данных NMDA.";
       input {
         leaf source {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Хранилище-образец для сравнения.";
         }
         leaf target {
           type identityref {
             base ds:datastore;
           }
           mandatory true;
           description
             "Сравниваемое с образцом хранилище.";
         }
         leaf all {
           type empty;
           description
             "При наличии этого листа сравниваются все узлы данных
              независимо от их присутствия в 1 или обоих хранилищах.
              При отсутствии листа автоматически применяется 
              предопределённый фильтр для исключения узлов данных,
              имеющихся лишь в одном из хранилищ. В частности, если
              одно из хранилищ (source или target) содержит лишь данные
              конфигурации, а другим служит <operational>, узлы данных с 
              config false исключаются из сравнения.";
         }
         leaf report-origin {
           type empty;
           description
             "При наличии этого листа метаданные источника включаются в
              вывод RPC. При отсутствии листа метаданные источника в
              сравнении с участием <operational> опускаются.";
         }
         choice filter-spec {
           description
             "Указывает сравниваемые части хранилища данных.";
           anydata subtree-filter {
             description
               "Указывает искомые части целевого хранилища данных.";
             reference
               "RFC 6241, Section 6.";
           }
           leaf xpath-filter {
             if-feature "nc:xpath";
             type yang:xpath1.0;
             description
               "Выражение XPath, указывающее искомые части целевого
                хранилища.";
             reference
               "RFC 6991: Common YANG Data Types";
           }
         }
       }
       output {
         choice compare-response {
           description
             "Результаты сравнения.";
           leaf no-matches {
             type empty;
             description
               "Указывает, что фильтру не соответствует ничего
                и сравнение не выполняется.";
           }
           container differences {
             description
               "Список различий в формате RFC 8072 с дополнением для
                включения исходных значений, когда это применимо. При
                отсутствии узла хранилища source в хранилище target
                это может быть указано как delete или remove, поскольку
                различий нет из-за отсутствия сравнения.";
             uses ypatch:yang-patch {
               augment "yang-patch/edit" {
                 description
                   "Указывает источник исправления (patch) относительно
                    источника при сравнении в дополнение к значению
                    target, когда это применимо.";
                 anydata source-value {
                   when "../operation = 'delete'"
                      + "or ../operation = 'merge'"
                      + "or ../operation = 'move'"
                      + "or ../operation = 'replace'"
                      + "or ../operation = 'remove'";
                   description
                     "Значение anydata применяется лишь для операций 
                      delete, move, merge, replace, remove.";
                 }
                 reference
                   "RFC 8072: YANG Patch Media Type";
               }
             }
           }
         }
       }
     }
   }
   <CODE ENDS>

5. Пример

Ниже приведён пример сравнения субдерева interfaces в хранилищах <operational> и <intended>. Это субдерево содержит подмножество объектов, заданных в модели данных YANG для управления интерфейсами [RFC8343]. Для понимания приведённого примера ниже приведён фрагмент модели данных, создающий экземпляр, служащий для сравнения.

   container interfaces {
     description
       "Параметры интерфейса.";
     list interface {
       key "name";
       leaf name {
         type string;
         description
           "Имя интерфейса.";
       }
       leaf description {
         type string;
         description
           "Текстовое описание интерфейса.";
       }
       leaf enabled {
         type boolean;
         default "true";
         description
           "Заданное конфигурацией желаемое состояние интерфейса.";
       }
     }
   }

Ниже показано содержимое хранилищ <intended> и <operational> в формате XML [W3C.REC-xml-20081126].

   <!--INTENDED-->
   <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
     <interface>
       <name>eth0</name>
       <enabled>false</enabled>
       <description>ip interface</description>
     </interface>
   </interfaces>

   <!--OPERATIONAL-->
   <interfaces
       xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"
       xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
     <interface or:origin="or:learned">
       <name>eth0</name>
       <enabled>true</enabled>
     </interface>
   </interfaces>

Хранилище <operational> не включает экземпляр листа description, имеющийся в <intended>, а лист enabled имеет в хранилищах разное значение (true в <operational> и false в <intended>). Лист name в обоих хранилищах совпадает. Источником экземпляров листьев в <operational> указано изучение (learned), что может помочь в понимании причины различия.

RPC запрашивает сравнение <operational> (образец) с <intended> (цель сравнения).

   <rpc message-id="101"
       xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <compare xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
         xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
       <source>ds:operational</source>
       <target>ds:intended</target>
       <report-origin/>
       <xpath-filter
           xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
         /if:interfaces
       </xpath-filter>
     </compare>
   </rpc>

Отклик RPC с найденными различиями представлен ниже.

   <rpc-reply
        xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
        message-id="101">
     <differences
        xmlns="urn:ietf:params:xml:ns:yang:ietf-nmda-compare"
        xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
       <yang-patch>
         <patch-id>interface status</patch-id>3
         <comment>
           diff between operational (source) and intended (target)4
         </comment>
         <edit>
           <edit-id>1</edit-id>
           <operation>replace</operation>5
           <target>/ietf-interfaces:interface=eth0/enabled</target>
           <value>
             <if:enabled>false</if:enabled>
           </value>
           <source-value>
              <if:enabled or:origin="or:learned">true</if:enabled>
           </source-value>
         </edit>
         <edit>
           <edit-id>2</edit-id>
           <operation>create</operation>6
           <target>/ietf-interfaces:interface=eth0/description</target>
           <value>
             <if:description>ip interface</if:description>
           </value>
         </edit>
       </yang-patch>
     </differences>
   </rpc-reply>

Такой же запрос в RESTCONF (с использованием формата JSON [RFC7951]) показан ниже.

   POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
   Host: example.com
   Content-Type: application/yang-data+json
   Accept: application/yang-data+json

   { "ietf-nmda-compare:input" : {
      "source" : "ietf-datastores:operational",
      "target" : "ietf-datastores:intended",
      "report-origin" : null,
      "xpath-filter" : "/ietf-interfaces:interfaces"
      }
   }

Запрос RESTCONF (в формате JSON) даст показанный ниже результат.

   HTTP/1.1 200 OK
   Date: Thu, 24 Jan 2019 20:56:30 GMT
   Server: example-server
   Content-Type: application/yang-data+json

   { "ietf-nmda-compare:output" : {
       "differences" : {
         "ietf-yang-patch:yang-patch" : {
           "patch-id" : "interface status",
           "comment" : "diff between intended (source) and operational",
           "edit" : [
             {
               "edit-id" : "1",
               "operation" : "replace",7
               "target" : "/ietf-interfaces:interface=eth0/enabled",
               "value" : {
                  "ietf-interfaces:interface/enabled" : "false"
               },
               "source-value" : {
                  "ietf-interfaces:interface/enabled" : "true",
                  "@ietf-interfaces:interface/enabled" : {
                    "ietf-origin:origin" : "ietf-origin:learned"
                  }
                }
             },
             {
               "edit-id" : "2",
               "operation" : "create",8
               "target" : "/ietf-interfaces:interface=eth0/description",
               "value" : {
                 "ietf-interface:interface/description" : "ip interface"
               }
             }
           ]
         }
       }
     }
   }

6. Вопросы производительности

Операция <compare> может потребовать значительных расчётов. Хотя предполагается, что ответственные клиентские приложения будут применять эту операцию с пониманием и лишь при наличии гарантий, реализациям следует учитывать, что чрезмерное использование этой операции будет истощать ресурсы системы, и принимать меры по предотвращению снижения производительности. Одной из возможностей реализации по снижению угроз может быть ограничение числа запросов, принимаемых от клиента или любого числа клиентов в течение интервала времени, путём отклонения слишком частых запросов (больше, чем реализация может разумно поддерживать).

Хотя такие инструменты, как модели данных YANG, полезны для отслеживания ресурсов серверов, производительности систем и статистики RPC, их рассмотрение выходит за рамки документа. Таким моделям данных следует быть общими по своей природе и не ограничиваться операцией RPC, описанной в этом документе.

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

7.1. Обновление реестра IETF XML

Агентство IANA обновило URI в реестре IETF XML [RFC3688], как показано ниже.

   URI:  urn:ietf:params:xml:ns:yang:ietf-nmda-compare
   Registrant Contact:  The IESG.
   XML:  N/A; запрошенный URI является пространством имён XML.

7.2. Обновление реестра YANG Module Names

Агентство IANA зарегистрировало новый модуль YANG в реестре YANG Module Names [RFC6020].

   name:  ietf-nmda-compare
   namespace:  urn:ietf:params:xml:ns:yang:ietf-nmda-compare
   prefix:  cmp
   reference:  RFC 9144

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

Заданный в этом документе модуль YANG определяет схему данных, которая предназначена для доступа по протоколу управления сетью, такому как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижележащим уровнем для NETCONF является защищённый транспортный уровень с обязательной реализацией протокола Secure Shell (SSH) [RFC6242], а для RESTCONF – протокол HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].

Модель доступа к конфигурации сети (Network Configuration Access Control Model или NACM) [RFC8341] обеспечивает возможность предоставлять доступ лишь отдельным пользователям NETCONF или RESTCONF к заданному подмножеству операций NETCONF или RESTCONF и содержимого. NACM определяет доступ к серверу в целом, а также правила доступа ко всем его хранилищам. Все субдеревья, к которым запрашивающему не предоставлен доступ, пропускаются и не учитываются в сравнении.

Определённая в этом модуле YANG операция RPC <compare> может быть чувствительной или уязвимой в некоторых сетевых средах, поэтому важно контролировать доступ к этой операции. Чувствительные и уязвимые аспекты операции RPC <compare> указаны ниже.

Сравнение хранилищ на предмет различий требует использования вычислительных ресурсов сервера. Злоумышленник может попытаться атаковать сервер, передавая ему запросы с большим объёмом сравнения. Реализации серверов могут защитить себя несколькими способами. Во-первых, можно реализовать модель NACM для проверки полномочий при запросах. Во-вторых, можно ограничивать число запросов, принимаемых от клиента в интервале времени, отвергая запросы, которые реализация не способна разумно поддерживать.

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>.

[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>.

[RFC6991] Schoenwaelder, J., Ed., “Common YANG Data Types”, RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[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>.

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

[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>.

[RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, “YANG Patch Media Type”, RFC 8072, DOI 10.17487/RFC8072, February 2017, <https://www.rfc-editor.org/info/rfc8072>.

[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>.

[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>.

[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>.

[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, “Extensible Markup Language (XML) 1.0 (Fifth Edition)”, World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/2008/REC-xml-20081126>.

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

[RFC8343] Bjorklund, M., “A YANG Data Model for Interface Management”, RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

Приложение A. Возможные в будущем расширения

В будущем возможно расширение операции <compare> разными дополнительными функциями. В частности, можно задать расширение с дополнительной функцией демпфирования, позволяющее клиентам задать минимальный интервал времени, в течение которого различия должны существовать, чтобы их следовало включать в результат. Это даст клиентам возможность отличить мимолётные различия от невнесенных изменений, которые могут привести к реальным проблемам в работе и несогласованности устройства. Для этого можно добавить входной параметр, указывающий интервал демпфирования, чтобы включать лишь долгоживущие изменения. Значение 0 или отсутствие параметра будут отключать демпфирование. Отчёты о различиях можно отложить на время демпфирования с момента получения запроса. Для реализации такой возможности сервер может запускать сравнение при вызове RPC и сохранять временный результат. Затем, по истечении периода демпфирования проверяется наличие найденных различий и сохранившиеся различия включаются в отчёт.

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

Спасибо Rob Wilton, Martin Bjorklund, Mahesh Jethanandani, Lou Berger, Kent Watsen, Phil Shafer, Ladislav Lhotka, Tim Carey, Reshad Rahman за их отклики и предложения.

Адреса авторов

Alexander Clemm
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: ludwig@clemm.org
 
Yingzhen Qu
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: yqu@futurewei.com
 
Jeff Tantsura
Microsoft
Email: jefftant.ietf@gmail.com
 
Andy Bierman
YumaWorks
Email: andy@yumaworks.com

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

nmalykh@protokols.ru


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

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

3Состояние интерфейса.

4Отличие рабочего состояния от предполагаемого (intended).

5Операция смены состояния интерфейса (disabled на enabled).

6Создание описания в хранилище <intended>.

7Смена состояния интерфейса.

8Создание описания интерфейса.

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

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