Subject: NETCONF Notifications: Consensus Points

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Nov 2005 10:32:03 -0800

Hi,

I'd like to try to gauge WG consensus on some recent
mailing list issues.  Please object if you think I've
totally got it wrong:

Terminology:

  The term Notification is preferred over Event Message.

Max Message Size: 

  A NETCONF peer should advertise its max message.
  The standard should not set a max-size although it is
  understood that implementations can use a max message size.
  There seems to be some consensus for mandating a minimum
  value for this parameter, although it's not clear what the exact
  should be (something between 1500 and 65535 bytes).

Application-Level ACKs

  It is not clear what a sender would do differently even
  if it knew the receiver did not understand the message.
  Without specific features in the protocol which would
  need app-level ACKs (such as data model version negotiation),
  the cost and complexity of this feature cannot be justified.

Transport-Level ACKs

  There is WG consensus that this feature is required.

Feature Consistency at the Protocol Layer

  There is WG consensus that the protocol-level notification
  features must be consistent across the supported transports.
  However, there is not yet WG consensus that NETCONF over SOAP
  must be supported.  The discussions have focused on SSH and BEEP.
  Each time it is mentioned that SOAP/HTTP cannot support this
  feature, the issue is ignored.

Notification Info Model/Payload

  There is WG consensus to reuse syslog classification, although
  the ability to transfer additional user data (similar to the OBJECTS
  clause in an SNMP notification) is also required.  The option
  of asking the SYSLOG WG for enhancements to RFC 3195 is also
  possible, and some WG members prefer this approach if syslog
  is going to be enhanced in any meaningful way.

Events Draft as Starting Point

  There is WG consensus to use draft-chisholm-netconf-event-01.txt as
  the starting point for this work, even though there are strong
  objections to specific details in the draft.  It is understood
  that the WG is addressing the feature list in the WG charter,
  not in this draft, if the two are in conflict.

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

---

From: Ted Goddard <[email-masked]>
Date: Fri, 25 Nov 2005 14:55:09 -0700

>  feature, the issue is ignored.

Notifications for NETCONF over SOAP/HTTP could be implemented
using:

     1. Separate HTTP connections for NETCONF management and
        NETCONF notifications channels
     2. HTTP response to a notification request delayed until
        notifications are available

Ted.

---

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Nov 2005 08:42:08 -0800

>        NETCONF notifications channels

You mean one session in each direction?
Both NC peers have to implement HTTP Server and Client SW
to have notifications in this case.

>        notifications are available

Not sure what you mean here.
I think you mean the NMS continuously polls for notifications,
but the agent holds each response until there is a notification
to send (in order to minimize the polling overhead).

Won't this cause the connection to time out in the client,
and perhaps HTTP caches in between the manager and agent?
(I guess this can be avoided by using a different port number than 80.)

> Ted.

Andy

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 28 Nov 2005 12:41:47 +0100

Notification as a term I queried for two reasons, one being that I was unclear
whether or not you were using it in the SNMPv3 sense, and I still don't know the
answer.  I see it used in security (PKI, EAP), CCAMP (probably borrowing from
ITU-T), congestion (FECN) etc but only defined in SNMPv3.

So I would like some clarification as to what you mean by it, as opposed to
event message.  You prefer the former but why, what distinction are you drawing?

(My second reason is editorial, that event it used in so many places in the
draft that I anticipate a lot of editing if notification is preferred to event)

Tom Petch

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Nov 2005 06:36:41 -0800

>ITU-T), congestion (FECN) etc but only defined in SNMPv3.

I'm using the term as it was defined first in the English dictionary:

http://www.m-w.com/dictionary/notification

    Function: noun
    1 : the act or an instance of notifying
    2 : a written or printed matter that gives notice

>draft that I anticipate a lot of editing if notification is preferred to event)

This is not a WG draft.
There will be many edits made if this becomes a WG draft.

Andy

---

From: Ted Goddard <[email-masked]>
Date: Mon, 28 Nov 2005 09:26:06 -0700

> to have notifications in this case.

The agent on the managed device would still be the
HTTP server, but two normal HTTP connections would
be opened to it from the NMS.  Two connections
are necessary because pipelining a notification
request and a management request on the same connection
could cause the management request to be blocked
behind the notification.

> to send (in order to minimize the polling overhead).

Exactly; the agent does not respond to the request
for notifications until notifications are available.
Then if the NMS wants more, it asks again.  It's
not very elegant, but it does work within the confines
of HTTP.

> (I guess this can be avoided by using a different port number than  

If there are caches or other factors causing timeouts,
then I would suggest that the NMS should keep polling
until the agent returns an error.  But HTTP on the
NMS could be configured to have a very long timeout,
so the problem shouldn't really arise.

Ted.