Subject: Notification Schema Bug

From: Andy Bierman <[email-masked]>
Date: Fri, 04 May 2007 17:19:08 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 May 2007 11:54:49 -0400

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.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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.

The replayCompleteNotification can be defined in another XSD and
namespace:

Of course, a notification with parameters would not have an empty
<extension> like this one.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 May 2007 09:57:28 -0700

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

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 May 2007 13:36:16 -0400

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.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
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:
> 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.

Andy

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Andy Bierman

> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.
> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 May 2007 10:56:02 -0700

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

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 May 2007 14:06:21 -0400

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:[email-masked]] 
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:
> - A configuration change entity which sends to snippet of 
> configuration that has changed (this case is a bit different)
> 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.
> 

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.

Andy

> element definitions (for <get> and <notification>) are trivial to 
> write, and the actual semantics are only defined once.
> 
> 
>> Sharon
> 
> Andy
> 
>> decision
>> the
>> the

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 May 2007 11:55:48 -0700

> used for both, preferably without defining a complex type that gets used

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.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 9 May 2007 15:30:43 -0400

Hi

I could not get this to validate. The XML Schema definition of the
replay complete didn't validate and neither did a random instance of a
notification that I tried. In the spirit of what Andy is suggesting, I
propose the same definition of notification, but the following
definition of the replay complete notification

    <xs:element name="replayComplete" minOccurs="0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay 
                portion of a subscription.
            </xs:documentation>  
        </xs:annotation>
        <xs:complexType>
          <xs:complexContent>
              <xs:extension
base="netconf:NotificationType"></xs:extension>              
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

Instead of  

<xs:element name="replayComplete" minOccurs="0">
        <xs:annotation>
            <xs:documentation>
                This notification is sent to signal the end of a replay 
                portion of a subscription.
            </xs:documentation>  
        </xs:annotation>
    </xs:element> 

I can also define things like

    <xs:element name="fooNotification" >
        <xs:complexType>
          <xs:complexContent>
              <xs:extension base="NotificationType">
                  <xs:sequence>
                      <xs:element name="eventClass"/>
                  </xs:sequence>
              </xs:extension>  
          </xs:complexContent>
        </xs:complexType>
    </xs:element>

My validator lets me do a <get> on this, but I'm not sure how smart it
is.

Sharon
-----Original Message-----

Hi,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 May 2007 08:47:00 -0700

> definition of the replay complete notification

The problem is that the default namespace is used incorrectly.

It is a good idea to set the default namespace (xmlns="foo")
to the target namespace (targetNamespace="foo") so definitions
within the module that reference other definitions from that
module are the only ones without a prefix.

The
It is important that the replayCompleteNotification be defined
as a complexType, to allow proper extensions for those vendors that
might ever want to do that (maybe even the WG).

Why can't you take the 'replayComplete' element and make it a ReplayComplete
complexType instead, so the element 'replayComplete' is a separate definition?

Can you see if the following fix works:

------------------------
--> Set the default namespace to the target namespace

--> In a different XSD:
   --> set the default namespace to the target namespace
   --> set the 'notif' prefix to the target namespace from the previous module

     <xs:complexType name="ReplayCompleteNotificationType">
       <xs:complexContent>
         <xs:extension base="notif:NotificationContentType"/>
       </xs:complexContent>
     </xs:complexType>

     <xs:element name="replayComplete"
                 type="ReplayCompleteNotificationType"
                 substitutionGroup="notif:notificationContent"/>

-------------------------------------------------------------

[Note changes in 'base' and 'substitutionGroup' QNames]

Andy