[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: standard notifications



HI,

I agree with you that the operations and the content can be
separated. However, there are "fields" of SNMP v2Trap &
inform that are encoded as part of the content. I believe that
this is confusing. Also, time and again people that have used
other notification systems wonder where are the missing
fields such as perceived severity, and when told that they
are not available, then wonder how to add them.

So, to me, the critical issues are:
 1) what fields should be part of the message and what should
    be optional subfields of the content
 2) how can additional fields be added to the message


On Wed, 21 Dec 2005, Andy Bierman wrote:

> Hi,
> 
> Although several WG members have expressed a wide spectrum
> of opinions on notification content, I  think we need to keep trying
> to find some consensus.
> 
> First, let's remember what we learned from SNMP.
> The Trap and Inform PDUs are totally separate
> (conceptually and in documentation) from the specific notification
> message content defined in MIB modules.
> 
> The document we are producing first is the message processing part.
> The data modeling requirements (e.g., XSD and RelaxNG templates)
> need to be documented here, but we need a separate document for
> standard notification content, such as "config-change", "capability-change".
> 
> We can work on both problems concurrently by starting a list
> (then a document) of standard notifications.  This is a coupling
> and cohesion issue -- I'm not trying to defer or avoid the
> standard notification content issue.
> 
> Andy
> 
Regards,
/david t. perkins


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