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