NETCONF notifications proposal

["Rob Enns" <rpe@juniper.net>]

The original NETCONF drafts included a notification capability that
had good agreement from the authors of the draft. We ended up taking
it out in order to finish the draft in finite time, but now that we're
considering updating the charter, I'd like to summarize (and slightly
extend) that proposal.

The principles of this approach are:

o Nail down a simple transport
o Pick a widely deployed notification model (syslog)
  for the initial release

This is how we should approach notifications if we're going to add
them back to the protocol. I do not want the WG to end up arguing about 
what event classes make sense, etc. The operators use syslog and SNMP
traps, and we're not going to get them to switch by inventing
something new for NETCONF.


Notification Capability:
-----------------------

urn:ietf:params:netconf:capability:notifications:1.0


Requesting Notifications:
------------------------

The notification capability adds the <open-notifications> and
<close-notifications> operations.  Notification format is specified on
<open-notifications> element.

<rpc>
  <open-notifications>
    <!-- request RFC 3195 COOKED Syslog Format -->
    <format>http://xml.resource.org/profiles/syslog/COOKED</format> 
  </open-notifications>
</rpc>


Notification Formats:
--------------------

In the interest of reusing existing standards and catering to the most
widely deployed eventing mechanism used by operators, the formats
supported for 1.0 are the RFC 3195 RAW and COOKED syslog formats.

   http://xml.resource.org/profiles/syslog/RAW
   http://xml.resource.org/profiles/syslog/COOKED

See also the structured data approach from
draft-ietf-syslog-protocol-15.txt.

   
Filtering Notifications:
-----------------------

Notification filters can be specified on the <open-notifications>
operation:

<rpc>
  <open-notifications>
    <format>http://xml.resource.org/profiles/syslog/COOKED</format> 
    <filter type="xpath"> <!-- same filter mechanism as NETCONF -->
      event[starts-with(@tag, "RSVP")]
    </filter>
  </open-notifications>
</rpc>

<rpc>
  <open-notifications>
    <format>http://xml.resource.org/profiles/syslog/RAW</format> 
    <filter type="regex"> <!-- supports 'regex' filter as well -->
      RSVP*
    </filter>
  </open-notifications>
</rpc>

<rpc>
  <close-notifications/> <!-- stop sending me notifications -->
</rpc>


Notification Transport:
----------------------

Notifications either occupy their own channel or must be in-between
successive <rpc-reply> elements (in other words, notifications don't
interrupt an <rpc-reply>).


Notification Examples:
---------------------

RFC 3195 RAW:
------------
<notification>
  Oct 18 16:01:37 dent rsvpd[2958]: RSVP neighbor 10.5.14.2 up on
interface fe-1/3/0.0
</notification>



RFC 3195 RAW (with structured data from draft-ietf-syslog-protocol-15):
----------------------------------------------------------------------
<notification>
  1 8 6 00 2005-10-18T16:01:37Z dent rsvpd 2958 RSVP_NBRUP
  [exampleSDID@0 neighbor="10.5.14.2" interface="fe-1/3/0.0"]
  RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0
</notification>



RFC 3195 COOKED:
---------------
<notification>
  <entry facility="8" severity="6" timestamp="Oct 18 16:01:37"
    hostname="dent" tag="RSVP_NBRUP">
    RSVP neighbor 10.5.14.2 up on interface fe-1/3/0.0
  </entry>
</notification>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>