[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Notification Schema Bug
hi
I just want to make sure we are not setting a precedent with how
notifications are defined that would preclude the same information being
used for both, preferably without defining a complex type that gets used
in two places.
Sharon
-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Monday, May 07, 2007 1:56 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Netconf (E-mail)
Subject: Re: Notification Schema Bug
Sharon Chisholm wrote:
> 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.
>
XSD works great for this use case.
1) Define the content (syntax and semantics) with a named type.
2) Define accessible elements as needed, in notification content,
RPC parameter content, or data model content.
There is no reason to say anything in the protocol document about how
notification content can also be retrieved with a <get> operation.
It is up to the vendor to add yet another stored notification retrieval
mechanism. It is up to the vendor to decide what data is retrievable
with a <get> operation.
> Sharon
Andy
>
> -----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/>
>
>
--
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/>