Subject: NETCONF Notifications

From: Andy Bierman <[email-masked]>
Date: Sat, 28 May 2005 09:34:29 -0700

Hi,

Let's start a thread to see if we agree on the problem we're trying to 
solve.
First, let's remember where we left off.

Here's what I remember:

  - we wanted to simply adopt RFC 3195 for notifications but decided
    that this was a problem because it was BEEP-only
  - our solutions for mapping multiple channels to SSH and SOAP mappings
    was not approved by the WG and dropped. Notifications over SOAP/HTTP
    were particularly clumsy (IMO).
  - the lack of any notification filtering (i.e., default is get-all)
    was a concern, but so was simply providing a proprietary hook instead
    of a standard solution for notification filtering.

What did I forget (or remember wrong)?

IMO, it's important that the NM application not have to use
notifications differently (via capabilities) depending on
the NETCONF application mapping in use for a particular session.
I could live with a BEEP-only notification solution too, to solve
this problem in minutes instead of weeks.

I want to know what the WG thinks...

Andy

--
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: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 29 May 2005 02:12:00 +0200

On Sat, May 28, 2005 at 09:34:29AM -0700, Andy Bierman wrote:
 
> solve. First, let's remember where we left off.

I think it is important to not ignore what is going on in the syslog
WG. In particular, <draft-ietf-syslog-protocol-11.txt> seems to be
relevant.

The only strong reason I see for a netconf notification transport
would be the reuse of security associations. Perhaps a syslog mapping 
over ssh would kind of solve the problem.

Bottom line: I am not really sure yet a notification channel within
netconf is essential. Even if it is, we should not be blind and ignore 
that syslog is out there and that there is active work to build from
the original BSD design and which is not bound to BEEP.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 May 2005 10:40:35 +0200

Juergen,

SYSLOG is out there.  Anyone can use it.  However, for reliable and 
secure SYSLOG you have to do something different.  Particularly, for 
reliable.  That's what 3195 was meant to cover.  If you want messages 
signed individually then that's a different kettle of fish, but to 
simply not have the messages go over the clear one can use the existing 
BEEP profile just fine.

Realistically from a BEEP perspective I'm not even sure we need to make 
a change to NETCONF to enable 3195 support.  We simply need to indicate 
that during a <greeting> the profile is available.  But this doesn't 
work for the other protocols (ssh, http).

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 May 2005 11:28:36 +0200

> simply not have the messages go over the clear one can use the existing 

<draft-ietf-syslog-protocol-11.txt> quite clearly states the following:

:                                 This protocol utilizes a layered
:   architecture, which allows the use of any number of transport
:   protocols for transmission of syslog messages.

So I believe syslog is moving to support other transports and not only
BEEP for reliable delivery.

/js

---

From: Eliot Lear <[email-masked]>
Date: Mon, 30 May 2005 21:22:07 +0200

> BEEP for reliable delivery.

We'll have 3 or 4 of those as well.  Great for interoperability.

Eliot

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 30 May 2005 12:27:47 -0700 (PDT)

Hi,

> BEEP for reliable delivery.

That statement is there to allow for udp and the future possibilities of
better transports.

http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-04.txt
"Transmission of syslog messages over UDP"  allows (more-r-less) backwards
compatibility with everything that currently does syslog/udp.  The WG (or
successors) could also allow other protocols in the future but RFC 3195 is
currently on the standards track for the syslog WG.  We made the decision
a very long time ago to separate the protcol from the transports for just
this reason.

Thanks,
Chris