1. Introduction

本文档定义了如何向 NETCONF 协议提供异步消息 notification 传输。
这是 NETCONF 基本定义之上的可选能力。
本文档定义了实行此服务所必要的 capability 和 operation。

名词定义：

• Element ：一个 XML Element。
• Subscription：通过 NETCONF session 接收 event notification 的一份 agreement 和 method。与此相关的概念还有 destination 和 selection of notification。它们与此 session 的绑定时间是整个 lifetime。
• Event：一些发生的你可能感兴趣的东西，如 configuration change，fault，change in status，某临界值被突破，系统中来自外部的输入等等。
• Replay：当收到 send/re-send 之前记录的 notification 的请求时，能将其发出的能力。
• Stream：event stream 即满足一些转发标准，能被 NETCONF client 订阅的一个 event notification 集合。
• Filter：表明在所有的 event 中，订阅者对哪些 event 感兴趣。

一些规则：

• notification 应可以与 configuration operation 使用同一个 model。
• notification 中的信息应该足以分析发生的事件。也就是说，读者可以完全不关心此 notification 是如何实现的，用了什么协议与什么传输机制。
• 注意，一个 subscription 被创建之后就无法被修改，直到 session 终止，或者 subscription 因某种原因终止。

2. Notification-Related Operations

Subscribing
“订阅”由 NETCONF client 发起，由 NETCONF server 回复。
订阅在其整个生命期间，只与一个 stream 绑定。

<create-subscription>
此 operation 初始化了一个订阅。
其参数有：

• Stream (optional，指定订阅哪个 stream。若未指定，则订阅 default stream)。
• Filter (optional，指定哪些 event 被订阅。此参数的格式与 NETCONF protocol operation 中的 filter 一样。 若未指定，则订阅所有未被其他参数排除的 event)。
• Start Time (optional, 表明支持 Replay 机制，以及从何时开始的 logged notification 可以被 re-send。 此参数指定的时间不应晚于当前时间。此参数的格式为 dateTime(RFC3339)。实现中应支持 time zones)。
• Stop Time (optional, 必须与start time 配合使用，表示订阅机制持续到何时。其指定的时间必须晚于 start time。 若未设置，则订阅将会一直持续到被终止。)

成功的回复：
server 返回一个 <ok> element。
失败的回复：
在 <rpc-reply> 中包含一个 <rpc-error>。

Memo中提供了订阅的例子，见 2.1.1.1。

Sending notifications
<notification>
当订阅的事件发生时，向订阅的 client 发送通知。
其参数有：

• eventTime 事件发生的时间。格式为 dateTime。

除了 eventTime 之外，notification 中包含什么内容不在本文档的范围中。

此消息无需回复。

Terminating subscription
取消 subscription 可以用 <close-session> ，或者通过另一个 session 使用 <kill-session> 终止 NETCONF session 或终止下层的传输session。
若订阅创建时设置了 stop time，则到了 stop time 指定的时间时 subscription 便会终止。 此时， NETCONF session 仍会是个 active session。

3. Supporting Concepts

Capabilities Exchange
在 NETCONF client 和 server 进行 capability exchange 的时候，event notification 相关的处理、发送的能力会被 advertised。
此能力的标识为 "urn:ietf:params:netconf:capability:notification:1.0"
以下为例子：

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capabilities>
        <capability>
            urn:ietf:params:xml:ns:netconf:base:1.0
        </capability>
        <capability>
            urn:ietf:params:netconf:capability:startup:1.0
        </capability>
        <capability>
            urn:ietf:params:netconf:capability:notification:1.0
        </capability>
     </capabilities>
     <session-id>4</session-id>
   </hello>

Event Streams
一个 event stream 即一组满足特定转发条件的 event notification 的集合。

在实际工作中，各种 system component 会产生各种 event notification，它们被统一发送到 central component 以进行分类和分发。 Central component 会根据 event notification 是否满足 event stream 的定义来判断此 event notification 是否属于某一 event stream。 一个 event notification 可以同时属于多个 event stream。
当 NETCONF server 收到来自 stream 的 event 后，会将其转换为对应的 XML 编码，组成 <notification>，将其发送到订阅此 stream 的所有 NETCONF session 的对端（此流程中 NETCONF server 还得考虑 filter）。
notification 日志记录服务也许应该提供，以满足可选的 replay 机制。

Event stream 是由被操控的设备预先定义的。对 event stream 的配置不在本文考虑范围内。
在目前的设想中，event stream 是由设备厂商预定义，并可由用户配置。设备厂商也许能支持通过 NETCONF protocol 配置 event stream (通过 <edit-config> 操作)。

支持 notification 能力的 NETCONF server 必须支持 “NETCONF” notification event stream。
This stream contains all NETCONF XML event notifications supported by the NETCONF server.
The exact string "NETCONF" is used during the advertisement of stream support during the <get> operation on <streams> and during the <create-subscription> operation.

NETCONF client 可通过对 <streams> subtree 的 <get> 操作从 NETCONF server 处取得支持的 event stream 列表。
结果的 event stream 信息通过 <name> 和 <description> 传递。 <name> 是必需的，且其 value 在整个 NETCONF server 中应是唯一的。
更多有关 stream 的信息还有 repaly 是否支持。 以及如果支持的话，可 replay 的最早 notification 的时间戳等。

以下是取得可用 event stream 列表的例子

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

返回的例子详见 3.2.5.1。

NETCONF client 进行 <create-subscription> 操作时应指定订阅的 event stream。 若没有指定，则将订阅 default NETCONF event stream。

Replay
Replay 是在一个订阅中，将已发送过的 notification 重新发送的能力，或在某些情况下将 notification 首次发到特定 NETCONF client。

在支持 replay 的 notification stream 中，我们并不期望支持对 notification 无限制的记录。 NETCONF client 可以通过查询 <replayLogCreationTime> 和 <replayLogAgedTime> 获得可被 replay 的 notification 的相关信息。

记录的 notification 的具体数目由 NETCONF server 的实现自行确定。 对这方面的控制参数也不在本文考虑范围内。