RE: draft-shafer-netconf-syslog-00.txt

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

> >2) If I want to refer to a previous Netconf operation in syslog
> >I have to embed the Netconf sessionId, messageId and some
> >additional XML in syslog in a proprietary way. Not so nice.
> 
> We could do these as standard SD parameters.

STRUCTURED-DATA in syslog was intentionally choosen to be not XML. The
reason is that very low end receivers do not need to take care of XML
and existing applications can quickly be adopted. It is arguable if that
is the best choice (right now this topic is again brought up on the
syslog mailing list). HOWEVER, that does not mean that STRUCTURED-DATA
can not contain XML. It can, but as part of a value. So to embed NETCONF
session information, you could use something like this in structured
data:

[netconf rpc="<rpc-reply message-id=\"101\"
              xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\" />"]

I agree it looks somewhat ugly, but it is an absolutely "clean" solution
and in no way proprietary. You need to take into account message size
limitations in syslog, which may limit your ability to use large chunks
of XML inside the actual syslog message. If syslog is transported over
netconf, this obviously is a no-issue, so you do not need to place
restrictions here. All of this is in the spirit of the syslog I-Ds,
which provision of highly different capablities of senders and
receivers. syslog does this because these capability differences do
exist in practice and we can not ignore them.

> >I would rather support Sharon's idea to provide syslog as one option
> >for netconf notifications but definitely not the main method.
> 
> The three options are snmp, syslog, and roll-your-own.  Operators and
> vendors are fully invested in both snmp and syslog, so rolling your
> own really is not an acceptable option.  The volume of existing syslog
> data, as well as the extensibility, make this my choice.
> 
> Basically, my goal is to take the biggest available data set and move
> it onto the netconf.  That's what the draft attempts to do.  It's not
> an ideal solution, nor one that one would aim for on a green field
> world, but given the zillions of lines of syslog() calls and the
> current way that operators are using this data, it's the best path to
> the maximum content.

I support Phil's position. SYSLOG is a de-facto standard and very widely
deployed. It seems irrealistically that any time soon the POSIX logging
API *and* all applications using it will be upgrade to NETCONF
(notifications) or whatever. Not even the syslog WG expects this for
upcoming syslog changes. My personal position is that we will have
legacy syslog for at least another 10 years, if not longer. The
challenge is to mine syslog data while allowing to integrate it into a
more sophisticated system. NETCONF seems to have some potential as a
notification receiver (though I wouldn't have expected that from a
network *configuration* protocol in the first place). 

The most important thing obviously is a united event notification data
model (for syslog, SNMP, netconf, name-your-own). But, IMHO, we are very
far from that. Even if we had, we would need to use transforming
gateways for quite a while. So before we go for this glory united data
model, we should try to get all the data into a single location. That
can only be done via an evolutionary approach (look at RFC 3195 in the
syslog space and you'll see what happens if things are too different).
This is where I see Phil's draft. It is better to have something
not-so-perfect within a (relatively) short period of time than to wait
many years for the ultimate solution. You always can upgrade the
not-so-perfect one, but if you do it first, you can enjoy its benefits
while upgrading it.

Just my 2cts...

Rainer
> 
> Thanks,
>  Phil
> 
> --
> 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/>