[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

real problem? was Re: no interim meeting -- read the rules



----- Original Message -----
From: "Balazs Lengyel" <balazs.lengyel@ericsson.com>
To: "Andy Bierman" <ietf@andybierman.com>
Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
Sent: Wednesday, March 29, 2006 9:57 AM
Subject: Re: no interim meeting -- read the rules

> Hi,
> For us notifications are needed mostly not as a logging mechanism but as:
> - a way to notify about configuration changes
> - a way to notify the management system about delayed results of an RPC (e.g.
when an RPC
> initiated action takes 10 minutes to complete we send an immediate reply
<started> and a
> late reply <finished>)
> - to notify the network management system (NMS) about things that might need
operator
> action. (While alarm handling is mostly SNMP there is a need for some other
events to be
> handled by the NMS.)
>
> For these reasons we do need a notification mechanism. We could use
> - SNMP: but if we have an XML based hierarchical data model with meaningful
names using
> SNMP is not my choice.
> - Syslog: but the message size limit of less then 480 octets seems a problem.
Also I like
> subscription. Adding XML to syslog needs some work. We have to care about a
second
> transport/security mechanism TLS (I don't know if this is a real problem).

Yes, I suspect it is.  In a secure, distributed system, particularly one with a
large number of unattended boxes, I believe that the distribution and
maintenance of security credentials is a real problem, much complexity and
expense.

So (netconf over) ssh for configuration with the necessary notifications coming
back (over syslog) over tls.  I don't know anyone doing security that way so I
imagine it is significantly  more complex than just ssh or tls (or ipsec or
....).  Anyone know otherwise?

Agreeing with the reasons above why notifications are needed, I see this as the
reasonwhy they should be part of netconf.
If security is not needed, then no problem - lots of choice.

Tom Petch

<snip>


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