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

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



Balazs Lengyel writes:
>1) If I want to refer to data in my configuration store how do I do
>that in the syslog solution?

There's no current mechanism, but we should be able to use
the <error-path> from <rpc-error> (with a different tag name).

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

>3) Do we need call-home for syslog?

They are complementary, but not prerequisites.

>While this solution is good for nodes that already use syslog,
>for those that do not, this is an additional protocol layer that
>you have to wrap your information in. Additional work.

Considering the overwhelming volume of syslog data and the minimal
size of the wrapping, this seems like an easy call.

>Also I see a risk that we might delay standardizing a number of
>important features like: 
>how to refer to the data model and other netconf operations in
>netconf notifications 

I don't really follow you here.  How does this draft increase the risk
of delay for standardizing other features?

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

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