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

Re: Notification Schema Bug

Sharon Chisholm wrote:

 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.


I don't understand.
Named types are available to provide the precise feature that we need here,
all within the domain of the data model designer, as intended.
What XSD mechanism are you proposing instead?

There is no reason the Notifications document should require that any
particular data be available in any particular namespace or location
within the agent's conceptual data model, in order to be
sent in a <notification> message.

There are a couple ways to tell your XSD tools that <foo> in a notification
is the same as the /acme/router-config/blah/foo element in the
agent's data model, but this document is not the right place to
make any requirements on such a mapping.




Sharon



Andy



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





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