RE: Additional proposed update to Netconf Notification Draft

["Sharon Chisholm" <schishol@nortel.com>]

hi

This is a merge of the 5/25/06  text and the existing text. He had
discussion about expectations on the client side which people had
indicated was not something we could really talk about so that has not
been included. I also reworked things to be sentences instead of "foo:
stuff".

Remember it is expected that message can belong to more then one event
class. The event class is a predictor of content (and some behaviour).
There will always be overlap. Just like the real-world.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Thursday, June 15, 2006 3:26 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: Additional proposed update to Netconf Notification Draft


Sharon Chisholm wrote:

IMO, the text that Balazs proposed on 5/25/06 better.
Can you highlight the diffs; this doesn't look very changed.
It still contains all the same overlapping, vague classifications.


Andy


> hi
> 
> Here are some additional proposed edits in addition to those that I 
> sent a while back
> 	https://ops.ietf.org/lists/netconf/netconf.2006/msg00691.html
> 
> 
> 1. Replace the Event Class section with the following:
> "
> Events can be classified into one more event classes. Each event class

> identifies a set of event notifications which
>     - share similar content
>     - are generated from similar events
>    
> The initial set of event classes is configuration, fault, state, 
> audit, data, maintenance, metrics, security, information, heartbeat 
> and syslogTunnel. See the IANA Considerations section for information 
> on defining new event classes.
> 
> All events shall carry the following data: list of event class, 
> timestamp and sequence number of the notification. They may also carry

> additional data.
> 
> A configuration event, alternatively known as an inventory event, is 
> used to indicate that hardware, software, or a service has been added/

> changed/removed.  In keeping aligned with NETCONF protocol operations,

> configuration events may included copy configuration event, delete 
> configuration event, or the edit configuration event (create, delete, 
> merge, replace). As configuration notifications could potentially 
> carry huge amounts of data in order to properly support functions such

> as security audit logs, so it is expected that netconf clients will 
> engineer their subscriptions to meet their needs and to not overwhelm 
> their capacity to process and store event notifications. Examples 
> include hardware board removed, software module loaded or DNS server 
> reconfigured. Changes are reported to all subscribed clients, not just

> to those clients whose actions triggered the changes.
> 
> A fault event notification is generated when a fault condition (error 
> or
> warning) occurs.  A fault event may result in an alarm.  Examples of
> fault events could be a communications alarm, environmental alarm,
> equipment alarm, processing error alarm, quality of service alarm, or
a
> threshold crossing event.  See RFC3877 and RFC2819 for more
information.
> The fault notification should carry the following data: severity,
event
> source, probable cause, specific problem, additional information.
> 
> A state event indicates a change from one state to another, where a 
> state is a condition or stage in the existence of a managed entity. 
> State change events are seen in many specifications.  For Entity state

> changes, see [Entity-State-MIB] for more information. The  
> notification shall identify the object who's state changed and the new

> state. Internal states of a node are important for supervision 
> purposes and also effect how a node can be configured.
> 
>  Audit events provide event of very specific actions within a managed 
> device.  In isolation an audit events provides very limited data.  A 
> collection of audit information forms an audit trail.
> 
> A data dump event is an asynchronous event containing information 
> about a system, its configuration, state, etc.
> 
> A maintenance event signals the beginning, process or end of an action

> either generated by a manual or automated  maintenance action. If the 
> maintenance event is a direct result of a configuration management 
> operation on this Netconf session then an rpc-reply notification 
> should be used. This event class is intended instead for reporting on 
> scheduled maintenance activities. Expected data includes a description

> of the maintenance process, the stage the process has reached, the 
> manual action, automatic process that triggered the notification. 
> Examples include .automatic backup completed
> 
> A metrics event contains a metric or a collection of metrics.  This 
> includes performance metrics.
> 
> A heart beat event is sent periodically to enable testing that the 
> communications channel is still functional.  It behaves much like the 
> other event classes, with the exception that implementations may not 
> want to include an event log, if supported.  Although widely used 
> throughout the industry, no current corresponding work within the 
> IETF. However, other standards bodies such as the TeleManagement Forum

> have similar definitions.
> 
> syslogTunnel event is when syslog content is sent, unmodified, within 
> a Netconf event Notification. See appendix X.X for more information. "
> 
> 2. Add text clarifying that session-based subscriptions are stored 
> only in the running configuration.
> 
> 3.  To the callHome section, discuss target port and any implications 
> on transport and other things missing [I've asked Balazs if he could 
> help out with some text]
> 
> 4. Clarify that the filters will be applied against the content of the

> notifications (including the event class which is part of the header).
> 
> 5. Add clarification that if a subscription request will fail if 
> either the filter is syntactically invalid or the named profile does 
> not exist. Note that while you could also say it fails if the filter 
> points at garbage, but someone consider it just pointing at something 
> that does not yet exist yet and consider that a filter.
> 
> 
> Sharon Chisholm
> Nortel
> Ottawa, Ontario
> Canada
> 
> --
> 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/>