RFC 8640 Dynamic Subscription to YANG Events and Datastores over NETCONF

Internet Engineering Task Force (IETF)                           E. Voit
Request for Comments: 8640                                 Cisco Systems
Category: Standards Track                                       A. Clemm
ISSN: 2070-1721                                                Futurewei
                                                      A. Gonzalez Prieto
                                                               Microsoft
                                                       E. Nilsen-Nygaard
                                                             A. Tripathy
                                                           Cisco Systems
                                                          September 2019

Dynamic Subscription to YANG Events and Datastores over NETCONF

Динамическая подписка на события и хранилища данных YANG через NETCONF

PDF

Аннотация

Этот документ обеспечивает привязку протокола управления сетью (Network Configuration Protocol или NETCONF) к возможности динамической подписки на уведомления и YANG-Push.

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

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

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

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

Этот документ задаёт привязку потока событий, составляющих часть динамической подписки, к протоколу NETCONF [RFC6241]. Динамическая подписка определена в [RFC8639]. Поскольку [RFC8641] базируется на [RFC8639], этот документ позволяет клиенту NETCONF запрашивать через динамическую подписку и получать обновления из хранилища YANG на сервере NETCONF.

Документ предполагает знакомство читателя с терминологией и концепциями [RFC8639].

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

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

В [RFC8639] определены термины dynamic subscription (динамическая подписка), event stream (поток событий), notification message (сообщение с уведомлением), publisher (издатель), receiver (получатель), subscriber (подписчик), subscription (подписка). Данный документ не задаёт новых терминов.

3. Совместимость с <create-subscription> из RFC 5277

Издатель может одновременно поддерживать RPC динамической подписки, как указано в [RFC8639], и RPC <create-subscription> из [RFC5277]. Однако в одной транспортной сессии NETCONF недопустимо поддерживать сразу эту спецификацию и RPC <create-subscription> из [RFC5277]. Для защиты от попыток использования обоих вариантов в одно транспортной сессии NETCONF применяются указанные ниже меры.

• Решение должно возвращать элемент <rpc-error> [RFC6241] с error-tag operation-not-supported при получении RPC <create-subscription> в сессии NETCONF, где имеется подписка в соответствии с [RFC8639].

• Решение должно возвращать элемент <rpc-error> [RFC6241] с error-tag operation-not-supported при получении запроса establish-subscription в сессии NETCONF, где имеется подписка на основе RPC <create-subscription> из [RFC5277].

Если издатель поддерживает эту спецификацию, но не реализует подписку в соответствии с [RFC5277], ему недопустимо анонсировать urn:ietf:params:netconf:capability:notification:1.0.

4. Обязательная поддержка XML, потока событий и хранилища

Должно поддерживаться свойство encode-xml из [RFC8639], указывающее, что XML является пригодным кодированием для RPC, уведомлений о смене состояния и содержимого подписки.

Издатель NETCONF, поддерживающий подписку на поток событий в соответствии с [RFC8639], должен поддерживать поток событий NETCONF, заданный этим документом.

5. Связность NETCONF и динамическая подписка

Управление динамическими подписками выполняется через RPC, как указано в [RFC8641] и [RFC8639]. Для динамической подписки при прерывании сессии NETCONF, вовлеченной establish-subscription, подписка должна прерываться.

Для динамической подписки любые RPC modify-subscription, delete-subscription, resync-subscription должны передаваться в той же сессии NETCONF, где была организована соответствующая подписка.

6. Уведомления

Уведомления, транспортируемые через NETCONF, должны кодироваться в сообщения <notification>, как указано в разделе 4 [RFC5277]. В соответствии с определением объекта <eventTime> в [RFC5277], в <eventTime> помещается время, когда произошло событие.

Для динамической подписки все уведомляющие сообщений должны использовать транспортную сессию NETCONF, где был вызов RPC establish-subscription.

7. Динамическая подписка и отклики RPC Error

При возникновении ошибки RPC, как указано в параграфе 2.4.6 [RFC8639] и Приложении A [RFC8641], отклик NETCONF RPC должен включать элемент <rpc-error> [RFC6241] с указанными ниже сведениями об ошибке.

• error-type application.

• Узел error-tag, значением которого является строка, соответствующая связанному с ошибкой идентификатору. Для заданных в этом документе механизмов error-tag будет соответствовать идентификаторам из (1) параграфа 2.4.6 в [RFC8639], показанным ниже (базовые ошибки подписки)

 

Идентификатор ошибки	error-tag
dscp-unavailable	invalid-value
encoding-unsupported	invalid-value
filter-unsupported	invalid-value
insufficient-resources	resource-denied
no-such-subscription	invalid-value
replay-unsupported	operation-not-supported

 

или (2) приложения A.1 к [RFC8641] для ошибок, связанных с конкретным хранилищем YANG

 

Идентификатор ошибки	error-tag
cant-exclude	operation-not-supported
datastore-not-subscribable	invalid-value
no-such-subscription-resync	invalid-value
on-change-unsupported	operation-not-supported
on-change-sync-unsupported	operation-not-supported
period-unsupported	invalid-value
update-too-big	too-big
sync-too-big	too-big
unchanging-selection	operation-failed

 

• Может включаться error-severity или error.

• Узел error-app-tag, значением которого является строка, соответствующая связанному с ошибкой идентификатору, как указано в параграфе 2.4.6 [RFC8639] для ошибок общего типа и в приложении A.1 к [RFC8641] для подписок на хранилища данных. Используемый идентификатор зависит от вызова RPC, для которого возникла ошибка. Каждый идентификатор ошибки вставляется как error-app-tag в формате <modulename>:<identityname>. Примером корректного кодирования служит ietf-subscribed-notifications:no-such-subscription. Допустимые значения ошибок для разных RPC указаны ниже.

 

RPC	Базовый идентификатор
establish-subscription	establish-subscription-error
modify-subscription	modify-subscription-error
delete-subscription	delete-subscription-error
kill-subscription	delete-subscription-error
resync-subscription	resync-subscription-error

 

• В случаях ошибок при запросе establish-subscription или modify-subscription можно включать узел error-info, который может содержать в кодировке XML советы по установке параметров для повторения запроса RPC в будущем. Могут возвращаться структуры yang-data из [RFC8639] и [RFC8641], показанные ниже.

 

establish-subscription	Советы в yang-data structure
target: event stream	establish-subscription-stream-error-info
target: datastore	establish-subscription-datastore-error-info

 

modify-subscription	Советы в yang-data structure
target: event stream	modify-subscription-stream-error-info
target: datastore	modify-subscription-datastore-error-info

В структуру yang-data, помещенную в error-info, не следует включать необязательный лист reason, поскольку он будет избыточным с учётом сведений в error-app-tag.

В случае ошибок RPC delete-subscription, kill-subscription, resync-subscription не требуется включать error-info, поскольку subscription-id является единственным входным параметром RPC и советов о смена параметра не может быть.

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

Этот документ не создаёт новых проблем безопасности для динамических подписок в дополнение к рассмотренным в [RFC8639]. Но есть одно соображение, которое следует уточнить с учётом ориентированной на соединения природы NETCONF. В частности, если включающий ошибки или скомпрометированный подписчик NETCONF передаёт ряд запросов establish-subscription, эти подписки аккумулируются и могут потреблять излишние ресурсы системы. В таких случаях подписки можно прервать, закрывая соответствующую сессию NETCONF. Издатель может также приостановить часть активных подписок в сессии NETCONF для восстановления ресурсов и обеспечения нормальной работы других подписчиков.

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

Документ не требует действий IANA.

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, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5277] Chisholm, S. and H. Trevino, “NETCONF Event Notifications”, RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

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

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

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

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

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

[RFC8347] Liu, X., Ed., Kyparlis, A., Parikh, R., Lindem, A., and M. Zhang, “A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)”, RFC 8347, DOI 10.17487/RFC8347, March 2018, <https://www.rfc-editor.org/info/rfc8347>.

[XPATH] Clark, J. and S. DeRose, “XML Path Language (XPath) Version 1.0”, November 1999, <https://www.w3.org/TR/1999/REC-xpath-19991116>.

Приложение A. Примеры

Это приложение не является нормативным. Используемые идентификаторы подписок 22, 23, 39, 99 служат лишь примерами. В реальной среде значения id могут быть достаточно большими целыми числами.

A.1. Обнаружение потока событий

Как указано в [RFC8639], поток событий представляет продолжающийся набор событий, доступных для подписки. Клиент NETCONF может получить список доступных потоков событий от издателя NETCONF с помощью операции <get> для контейнера streams верхнего уровня, заданного в параграфе 3.9 [RFC8639]. Приведённый ниже пример XML [W3C.REC-xml-20081126] иллюстрирует получения списка доступных потоков событий.

<rpc message-id="101"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <streams
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"/>
    </filter>
  </get>
</rpc>

Рисунок 1. Запрос <get> для извлечения потоков событий.

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

A.2. Динамические подписки

A.2.1. Организация динамической подписки

На рисунке 2 показаны два успешных вызова RPC establish-subscription, как описано в [RFC8639]. Первый вызов имеет идентификатор подписки 22, второй – 23.

+------------+                 +-----------+
| Подписчик  |                 | Издатель  |
+------------+                 +-----------+
      |                              |
      |    Обмен возможностями       |
      |<---------------------------->|
      |                              |
      |    establish-subscription    |
      |----------------------------->|  (a)
      | RPC Reply: OK, id = 22       |
      |<-----------------------------|  (b)
      |                              |
      |     уведомление (для 22)     |
      |<-----------------------------|
      |                              |
      |    establish-subscription    |
      |----------------------------->|
      |     уведомление (для 22)     |
      |<-----------------------------|
      | RPC Reply: OK, id = 23       |
      |<-----------------------------|
      |                              |
      |     уведомление (для 22)     |
      |<-----------------------------|
      |     уведомление (для 23)     |
      |<-----------------------------|
      |                              |

Рисунок 2. Несколько подписок в сессии NETCONF.

В качестве примера передаваемых сведений ниже представлены сообщения для взаимодействий (a) и (b) на рисунке 2 (рисунки 3 и 4).

<rpc message-id="102" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <establish-subscription
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
    <stream-xpath-filter xmlns:ex="https://example.com/events">
      /ex:foo/
    </stream-xpath-filter>
    <stream>NETCONF</stream>
    <dscp>10</dscp>
  </establish-subscription>
</rpc>

Рисунок 3. Запрос establish-subscription (a).

Поскольку издатель NETCONF мог полностью выполнить запрос (a), он передаёт идентификатор воспринятой подписки в отклике (b)

  <rpc-reply message-id="102"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <id
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      22
    </id>
  </rpc-reply>

Рисунок 4. Запрос establish-subscription (b).

Если издатель NETCONF не модет полностью выполнить запрос или у подписчика нет прав на организацию подписки, издатель возвращает сообщение об ошибке RPC. Например, если заданное подписчиком значение dscp 10 (Рисунок 3) неприемлемо, издатель может вернуть показанное ниже сообщение.

   <rpc-reply message-id="102"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <rpc-error>
      <error-type>application</error-type>
      <error-tag>invalid-value</error-tag>
      <error-severity>error</error-severity>
      <error-app-tag>
        ietf-subscribed-notifications:dscp-unavailable
      </error-app-tag>
     </rpc-error>
   </rpc-reply>

Рисунок 5. Неудачный вызов establish-subscription.

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

A.2.2. Изменение динамической подписки

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

+------------+                 +-----------+
| Подписчик  |                 | Издатель  |
+------------+                 +-----------+
      |                              |
      |     уведомление (для 23)     |
      |<-----------------------------|
      |                              |
      | modify-subscription (id = 23)|
      |----------------------------->|  (c)
      | RPC error (с советом)        |
      |<-----------------------------|  (d)
      |                              |
      | modify-subscription (id = 23)|
      |----------------------------->|
      | RPC Reply: OK                |
      |<-----------------------------|
      |                              |
      |     уведомление (для 23)     |
      |<-----------------------------|
      |                              |

Рисунок 6. Модель взаимодействия при успешном изменении подписки.

Если изменяемая на рисунке 6 подписка является подпиской на хранилище данных в соответствии с [RFC8641], запрос на изменение (c) может выглядеть как на рисунке 7. Вносимые изменения включают применение фильтра XPath, а также установку интервала передачи.

<rpc message-id="303"
  xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <modify-subscription
       xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
       xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <id>23</id>
    <yp:datastore-xpath-filter xmlns:ex="https://example.com/datastore">
        /ex:foo/ex:bar
    </yp:datastore-xpath-filter>
    <yp:periodic>
      <yp:period>500</yp:period>
    </yp:periodic>
  </modify-subscription>
</rpc>

Рисунок 7. Запрос изменения подписки на хранилище данных.

Если издатель NETCONF может выполнить оба запроса, он передаст положительный отклик для RPC. Если какое-либо из предложенных изменений издатель NETCONF не может выполнить, он передаёт отклик об ошибке RPC (d). Рисунок 8 показывает пример отклика об ошибке RPC для (d) с включением совета, указывающего другой интервал, который позволит внести изменение.

   <rpc-reply message-id="303"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <rpc-error>
       <error-type>application</error-type>
       <error-tag>invalid-value</error-tag>
       <error-severity>error</error-severity>
       <error-app-tag>
           ietf-yang-push:period-unsupported
       </error-app-tag>
       <error-info>
         <modify-subscription-datastore-error-info
             xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
           <period-hint>
               3000
           </period-hint>
         </modify-subscription-datastore-error-info>
       </error-info>
     </rpc-error>
   </rpc-reply>

Рисунок 8. Отказ modify-subscription с советом (d)

A.2.3. Удаление динамической подписки

Figure 9 demonstrates the deletion of a subscription. This subscription may have been to either a stream or a datastore.

  <rpc message-id="103"
    xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <delete-subscription
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <id>22</id>
    </delete-subscription>
  </rpc>

Рисунок 9. delete-subscription.

Если издатель NETCONF может выполнить запрос, он возвращает отклик, указывающий успех.

Если издатель NETCONF не может выполнить запрос, он передаёт элемент <rpc-error>, указывающий, что изменение не прошло. На рисунке 10 показан корректный отклик для имеющегося идентификатора подписки, организованной в другой транспортной сессии NETCONF.

   <rpc-reply message-id="103"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <rpc-error>
       <error-type>application</error-type>
       <error-tag>invalid-value</error-tag>
       <error-severity>error</error-severity>
       <error-app-tag>
           ietf-subscribed-notifications:no-such-subscription
       </error-app-tag>
     </rpc-error>
   </rpc-reply>

Рисунок 10. Неудачный вызов delete-subscription.

A.3. Уведомления о состоянии подписки

Издатель будет передавать уведомления о состоянии динамической подписки в соответствии с [RFC8639].

A.3.1. subscription-modified

В соответствии с параграфом 2.7.2 в [RFC8639] может передаваться уведомление subscription-modified через NETCONF, если меняется настроенный фильтр. Уведомление о смене состояния подписки кодируется в XML, как показано ниже.

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2007-09-01T10:00:00Z</eventTime>
  <subscription-modified
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
    <id>39</id>
    <stream-xpath-filter xmlns:ex="https://example.com/events">
      /ex:foo
    </stream-xpath-filter>
    <stream>NETCONF</stream>
  </subscription-modified>
</notification>

Рисунок 11. Уведомление о состоянии подписки subscription-modified.

A.3.2. subscription-resumed и replay-complete

Возобновление подписки (subscription-resumedимеет вид

  <notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2007-09-01T10:00:00Z</eventTime>
    <subscription-resumed
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <id>39</id>
    </subscription-resumed>
  </notification>

Рисунок 12. Уведомление subscription-resumed.

Уведомление replay-complete очень похоже, но вместо subscription-resumed применяется replay-complete.

A.3.3. subscription-terminated и subscription-suspended

Уведомление subscription-terminated имеет вид

  <notification
    xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2007-09-01T10:00:00Z</eventTime>
    <subscription-terminated
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
      <id>39</id>
      <reason>
         suspension-timeout
      </reason>
    </subscription-terminated>
  </notification>

Рисунок 13. Уведомление о состоянии подписки subscription-terminated.

Уведомление subscription-suspended отличается лишь заменой subscription-terminated на subscription-suspended.

A.4. Примеры фильтров

В этом приложении даны примеры применения методов XPath и subtree для фильтрации содержимого записей о событиях. Примеры основаны на уведомлении YANG vrrp-protocol-error-event из модели данных YANG ietf-vrrp в [RFC8347]. Записи о событиях, создаваемые издателем на основе этой спецификации, могут иметь вид

  <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2018-09-14T08:22:33.44Z</eventTime>
    <vrrp-protocol-error-event
         xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
       <protocol-error-reason>checksum-error</protocol-error-reason>
    </vrrp-protocol-error-event>
  </notification>

Рисунок 14. Пример уведомления VRRP в соответствии с RFC 8347.

Предположим, что подписчик хочет организовать подписку, в которой предоставляются лишь записи о событиях, где checksum-error является частью события протокола резервирования виртуального маршрутизатора (Virtual Router Redundancy Protocol или VRRP). Предположим также, что издатель помещает такие записи в поток NETCONF. Для получения продолжающейся серии соответствующих записей о событиях подписчик может запросить применение фильтра XPath к потоку NETCONF. RPC establish-subscription для решения этой задачи может иметь вид

 <rpc message-id="601" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <establish-subscription
     xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
     <stream>NETCONF</stream>
     <stream-xpath-filter xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp">
       /vrrp-protocol-error-event[
          vrrp:protocol-error-reason="vrrp:checksum-error"]
     </stream-xpath-filter>
   </establish-subscription>
 </rpc>

Рисунок 15. Причина ошибки при организации подписки (XPath).

Дополнительные примеры фильтров XPath приведены в [XPATH].

Предположим, что вызов establish-subscription с рисунка 15 был воспринят, а позднее подписчик решил расширить подписку включением всех событий протокола VRRP (а не только с checksum-error). Подписчик может попытаться изменить подписку путём замены фильтра XPath на фильтр subtree, который будет передавать все события протокола VRRP. Такой вызов RPC modify-subscription может иметь вид

 <rpc message-id="602" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
   <modify-subscription
      xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
     <id>99</id>
     <stream-subtree-filter>
      <vrrp-protocol-error-event
             xmlns="urn:ietf:params:xml:ns:yang:ietf-vrrp"/>
     </stream-subtree-filter>
   </modify-subscription>
 </rpc>

Рисунок 16. Пример RPC modify-subscription.

Дополнительные примеры фильтров subtree приведены в параграфе 6.4 [RFC6241].

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

Авторы признательны Andy Bierman, Yan Gang, Sharon Chisholm, Hector Trevino, Peipei Guo, Susan Hares, Tim Jenkins, Balazs Lengyel, Martin Bjorklund, Mahesh Jethanandani, Kent Watsen, Qin Wu, Guangying Zheng за полезный вклад, комментарии и предложения .

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

Eric Voit

Cisco Systems

Email: evoit@cisco.com

 

Alexander Clemm

Futurewei

Email: ludwig@clemm.org

 

Alberto Gonzalez Prieto

Microsoft

Email: alberto.gonzalez@microsoft.com

 

Einar Nilsen-Nygaard

Cisco Systems

Email: einarnn@cisco.com

 

Ambika Prasad Tripathy

Cisco Systems

Email: ambtripa@cisco.com

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

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

nmalykh@protokols.ru