RE: notification charter proposal

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

Comments in-line (HT)
Hector
 

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Eliot Lear
Sent: Thursday, November 24, 2005 12:59 AM
To: Andy Bierman
Cc: Glenn Waters; j.schoenwaelder@iu-bremen.de; Phil Shafer; Sharon
Chisholm; netconf@ops.ietf.org
Subject: Re: notification charter proposal

Andy,

I hope you're enjoying some decent Bird today in America and don't
actually read this till later ;-)  Please see below.

Andy Bierman wrote:

> I agree with Juergen on this one.

I agree in part.  I do not want the tail to wag the dog.  Just because
SSH or BEEP does or doesn't have a feature shouldn't dictate the
approach to notifications (events, whatever..).

> I would like to make sure the mandatory transport (SSH) can be used 
> for all the notification features defined.

First, if the notification feature is not mandatory, you're probably
adding extra unwanted hair.  But if we go this route, let's make proper
use of mapping mechanisms.  If SSH needs to add an ACK that's already
there for BEEP, don't make BEEP have a 2nd unnecessary ACK.

Now putting the horse before the cart, I think we have a few problems in
this space.  First of all, there is the SYSLOG working group that is
currently attempting to finalize a new specification that will include
some amount of structured data.  We must not simply duplicate their work
in an incompatible way, and so I agree with you there.

HT: Same here & Appendix D was put in as an attempt to address this
issue

However, SYSLOG isn't much more than PRI+Date+host+text.  There's a lot
of room to do better than that.  I think Sharon and crew should be
thinking about one of two directions:

 - what to do with the structured text component contemplated by
   SYSLOG wg (and now's the time to talk to them - and I mean right
   now)


 - creating a second approach that is richer than what SYSLOG has.
   The good here is that event systems have been out there for a
   while, and so perhaps the time is ripe.  The bad is that many
   have tried...

HT: We are trying to do a combination of the two above. There are some
good things about syslog which could/should be preserved but as I think
everyone agrees, syslog has limitations and there is no reason why a
second approach as you call it can't be pursued. More specifically to
your first point, the appendix in the doc does not discuss how to
maintain structured data definitions in sync but we have looked at this
issue. The latest syslog-protocol draft only has 2-3 definitions thus
far. 


So I don't know which approach is correct.

Finally, I reiterate that events and notifications appear to be
architecturally severable, and so I would like to understand why it is
necessary for the netconf protocol to be extended beyond perhaps a
capability referencing other work.



Eliot

--
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/>

--
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/>