Balazs Lengyel wrote:
I don't see the connection between scaling and notification classes. Also if we manage to filter notifications that just improves scalability.
They are not. I don't think this solution is suitable for replacing any existing non-session based notification system. Therefore (IMO) the only use it has is to copy and deliver netconf specific notifications (over a session) while a manager is connected for operations. Even if one really wanted notifications over sessions, why not just run syslog over ssh somehow? It is not at all clear to me why reinvented-syslog over netconf over ssh is important.
We need a notification template I agree but even if we just say - we have event class filters- xpath or subtree filters are applied to the data in the notification starting from a standard base point e.g. <data>and leave the data model below this base point up to each implementation we still have produced something useful. Based on this you could build a model agnostic tool where filters can be configured on a GUI.Still I feel the notification content should be defined in more detail. The notification draft does contain a very basic XSD for notifications (mainly page 23). Would you like a more detailed more specific XSD separately for each notification class or how would you start defining the event classes. I am willing to put in some work on this, but after understanding that you feel that the current version is insufficient I would like to understand what you would like to see in the draft.
Look at an IANA classification system like interface type (ifType). Without specific documentation to determine which classification to choose, there is no point to standardizing the classification system. I already pointed out that this document does not actually need to define the classification system. At the protocol level, the <event-class> could be a Name string. But if it does include a classification system, it must be complete, meet IETF documentation standards, and show WG consensus for each enumerated choice.
regards Balazs
Andy
Andy Bierman wrote:Balazs Lengyel wrote:Hello,If we provided the following set of data for each notification(why event?) class would that be enough ?I like the term notification classification better.- Definition - Events that trigger the notification - Expected data, might contain optional parts - expected handling/usage Or do we need more ? What ?We don't have any notification definition template for XSD, RelaxNG or whatever. If one were to define such a template, there would be a field for the event-class. We need a classification set that is complete and also easy to decide which classification to choose. Otherwise, standard filters based on event-type will be mostly worthless because no 2 agents classify notifications the same way. Since this entire solution scales so poorly, without useful filtering for session-based manager ease-of-use, it is totally pointless.BalazsAndyAndy Bierman wrote:Balazs Lengyel wrote: IMO, the only thing that matters here is that the classifications are clearly defined so that any 2 independent implementors will pick the same classification for the same new notification message. There is no way that can happen given the current text. The descriptions of some of them are too vague, and there is too much overlap. AndyHello- 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 aboutwhy/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 classHere 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/>
-- 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/>