<inline>
Rainer
HT: Because nobody (that I know of) is interested/needs to carry
SNMP notifications inside NETCONF. Whether or not the Appendix B
proposal stays
in is up for discussion next week.
That's why I raised the point today.
> If you talk about filtering and also talk about syslog data,
> NETCONF IMHO actually tries to define a configuration
> mechanism for SYSLOG.
> The draft is not taking SYSLOG as *the* content format and
> just extending it with some syslog fields. The draft is
> defining a NETCONF notification format (which is perfectly
> fine and good to see) and then is mapping how SYSLOG should
> be mapped into it. The later IMHO should be done as a
> separate effort via a SYSLOG data model.
HT: The title of the section is "Leveraging Syslog Field Definitions"
and as the title I think suggests the purpose is to re-use existing
syslog definitions where it makes sense.
>
> > > Having syslog mappings in a basic netconf document forces the
> > > netconf document to be changed/obsoleted whenever there
> is change on
> > > the syslog side. I think this dependency should be avoided.
> > >
> > > There is some growing interest in the syslog community to define
> > > event data models. This effort could play nicely together
> with netconf.
> >
> > Does this mean you think it is a good idea for the NETCONF WG to
> > create a brand-new netconf-only notification system?
>
> I think it is eventually a good idea for the NETCONF WG to
> create a brand-new, EXTENSIBLE notification system that could
> also transport events traditionally being transported via
> SYSLOG, SNMP or vendor-specific event notification protocols.
> If I understood NETCONF correctly, it is a common base that
> it should be extensible.
> Extensions can be vendor-specific or via standard
> capabilities. Lots of discussion on this list are focussed
> about data models for configuration. If I follow that spirit,
> NETCONF notifications should provide a framework for
> notification delivery, but not necessarily (and exclusively)
> all data models that could be transported via it.
HT: That's the idea. Right now the doc only covers syslog & as I said in
a previous e-mail
SNMP is not something that has come up.
That's my problem: "right now the doc only covers syslog". If so, then
the doc is not talking about NETCONF but about SYSLOG ;) But if it is
about SYSLOG, then it is either beyond the charter of the NETCONF WG
or the NETCONF WG must endure that SYSLOG specifics be discussed here
(Andy, I think, rejected the later for good reasons).
I fear that if NETCONF notifications goes into too much detail on
SYSLOG, it will eventually distract interest in a solution for SYSLOG.
Think about it that way: any NETCONF agent that puts SYSLOG fields
into some NETCONF fields is not a pure NETCONF agent. It is actually a
SYSLOG/NETCONF gateway, as is shown in the netconf-syslog draft. The
SYSLOG side of that beast is actually ... a SYSLOG receiver.
Don't misunderstand me: I find it correct that NETCONF does
notifications, if NETCONF needs such. I also think it is valuable to
have an extensible notification mechanism. I just think that NETCONF
should standardize NETCONF and not whatever else seems handy. And,
yes, I agree SYSLOG messages are interesting to NETCONF agents. SNMP
events, IMHO, should also be interesting if you really intend to make
a single manager able to manage everything. In concept, I do not see
any big difference between the need to see SYSLOG vs. SNMP events if
you go after as many event data as possible. In practice, of course,
SNMP is mature and well-standardized while SYSLOG is a quick ad-hoc
solution. That doesn't mean that we should continue to look at it in a
quick ad-hoc way.
> > Or does it mean you think the SYSLOG WG should do this work
> instead of
> > the NETCONF WG?
>
> I think the syslog community should standardize a SYSLOG data model.
> As much as it probably could standardize a basic SYSLOG
> configuration data model (including syslog-specific filters
> and event actions). I do not think that the current SYSLOG WG
> (chartered in the SEC area) is the right one to do this. I
> think a new SYSLOG WG should be chartered in the OPS area to
> standardize syslog payload and thus also provide a data
> model. Ideally, it would lean on the good work NETCONF has done.
> Such a data model could be advertised as a capability.
HT: I think this is good. Not sure what SYSLOG data model entails but
I'll assume it could include event types/contents. If so, could this be
done (i.e. event types, contents) defined in a protocol independent
manner.
So far, I have just a personal view. I will try to write a short I-D
with a problem statement soon. In my (purely personal) point of view,
I think an XML based data stream for SYSLOG content would be
advisable. For obvious reasons, that would not need to be limited to
SYSLOG. I like the data model approach NETCONF is taking. I can easily
see how one and the same XML stream could be transmitted as part of a
SYSLOG STRUCTURED-DATA element or as part of a NETCONF <GET> operation
(or whatever is invented as part of netconf notifications). Thus I
consider it vital that NETCONF does not place any preconception on the
way SYSLOG events are encoded. For example, a very basic
(hypothetical) SYSLOG event XML stream could look like:
<event>
<syslog-message><144>HEADER,,, the raw message</message>
</event>
That obviously would be a solution for legacy senders, Other could do
things like
<event>
<origin>orgsender.example.com</origin>
<type>traffic-report</type>
<source>10.0.0.1</source>
<target>10.0.0.2</target>
<bytes-transferred>22222</bytes-transferred>
.
.
.
</event>
I think you'll get the idea. The last sample is my medium to long term
vision: some standard way of telling common events for firewalls
(traffic flow, access violations etc) and other common usage
scenarios,
OK, already written too much. I hope I have clarified.
Warp up: I think NETCONF should define what it needs for its
notifications, leave that as extensible (via capabilities) as the rest
of NETCONF and do not try to standardize things outside NETCONF
itself.
Rainer
>
> Rainer
>
> --
> 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/>