Hi
Notification logging isn't the use case I was referring to. Here are
some that have come up.
- An interface has changed notification where the same information is
sent via a <get> you get via a notification
- A configuration change entity which sends to snippet of configuration
that has changed (this case is a bit different)
- An list of alarms which can be queried to retrieve active ones, but
each individual alarm definition is actually what is sent over the wire.
These sort of cases were part of the reason the notification definitions
were not too tied to just notifications. Notification is an operation on
the data, so you don't want to limit the definition to just be able to
be sent via notifications.
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Monday, May 07, 2007 12:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Netconf (E-mail)
Subject: Re: Notification Schema Bug
Sharon Chisholm wrote:
Hi
If we go this way, we should also add a little note somewhere that
content defined as notifications can also be retrieved via the <get>
operation. This allows a single definition of content instead of
forcing everything to be defined twice like SNMP did. It becomes a
little less obvious when it is an extension of the notification.
I disagree.
This is outside the scope of this document, and part of a Notification
Logging MIB instead. However, such a MIB would be rather redundant,
given the replay feature within the notification draft.
If named complexTypes are used for the content, then the 'redundant'
element definitions (for <get> and <notification>) are trivial to write,
and the actual semantics are only defined once.
Sharon
Andy
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]
On Behalf Of Andy Bierman
Sent: Friday, May 04, 2007 8:19 PM
To: Netconf (E-mail)
Subject: Notification Schema Bug
Hi,
The notification element definition is obsolete, based on the decision
to remove the parameters from the ReplayCompleteNotification.
There is no <data> element in the notification, like <rpc-reply>.
The <notification> element is a wrapper, just like the <rpc> element.
This allows proper extension by any organization. The XSD for the
<notification> element must be done the same way as the <rpc> element.
Current text: notification-06: page 21:
<xs:complexType name="NotificationType">
<xs:sequence>
<xs:element name="data" type="netconf:dataInlineType" />
</xs:sequence>
</xs:complexType>
<xs:element name="notification" type="NotificationType"/>
Proposed replacement text for page 21:
<xs:complexType name="NotificationContentType"/>
<xs:element name="notificationContent"
type="NotificationContentType" abstract="true"/>
<xs:complexType name="NotificationType">
<xs:sequence>
<xs:element ref="notificationContent"/>
</xs:sequence>
</xs:complexType>
<xs:element name="notification" type="NotificationType"/>
The replayCompleteNotification can be defined in another XSD and
namespace:
<xs:complexType name="ReplayCompleteNotificationType">
<xs:complexContent>
<xs:extension base="NotificationContentType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="replayCompleteNotification"
type="ReplayCompleteNotificationType"
substitutionGroup="notificationContent"/>
Of course, a notification with parameters would not have an empty
<extension> like this one.
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/>