Hello
- FAULT event - OK, but could specify the details somewhat even if
they are optional e.g. eventsource, probable cause, severity,
specific problem
- CONFIGURATION - OK
- STATE - OK
- AUDIT event seems a bit overkill. I think event classes should
mainly speak about
why/on what occasion do we send that specific event class
what information does an event class carry
what handling is expected of the specific event class
Here we only have part of the third point. You could have an audit
trail of state changes or a trail of configuration changes etc. I
don't see this as a separate event class. It should be merged with
something or removed.
- DATA DUMP event should me merged with configuration event. The main
difference is that it can also carry state information. But thats
already included in State event, so kill data dump.
- Ericsson needs MAINTENANCE events. See Jurgens requirement page:
"notify about delayed results of long running RPCs [BL]". I am not
totally happy with the name of the event class, but I like the idea
behind it. If the draft misses this Ericsson will have to do some
dirty workaround.
- METRICS is certainly out of scope although I don't see any real
problem with it. We must note however that Netconf events are probably
unsuitable for HIGH volume performance data transfer.
- HEART BEAT - OK
- INFORMATION event is really an extension mechanism. OK.
- SYSLOG: We spoke a lot about transferring syslog via events, but
please could someone say who really has a requirement to do this! If
we really have the requirement Jurgen please add it to your page!
- SECURITY - mentioned in the initial list, but not described later.
As I see it security related notifications can be carried as fault or
state events, so I don't see a need for this event class.
Balazs
Andy Bierman wrote:
Hi,
This section is very under-specified.
IMO, it is impossible for independent developers
to select classifications in an interoperable manner.
It is really not at all clear why we need audit, data,
maintenance, metrics, information, and syslog classes at all.
Most of these are totally redundant.
Metrics is out of scope.
Syslog is not a proper member of this classification set.
In XML, we use namespaces to identify content format,
such as syslog/RAW, syslog/COOKED, acme/TOASTED, etc.
The notification <data> section will be just like
the <config> or <data> elements already defined in
the protocol.
Andy
--
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/>