Subject: Notification data model structure

From: Andy Bierman <[email-masked]>
Date: Wed, 02 May 2007 09:46:14 -0700

Hi,

I want to propose a minor change to the 'state' data models
in the Notifications draft, and some XSD improvements.

Currently, the 'eventStreams', 'namedProfile', and 'namedProfiles'
elements are all top-level elements in the MIB.
(I call the conceptual data under the <config> node the NETCONF MIB.)

I think this is a really bad idea.
We will probably be adding lots of elements over time, and some thought
needs to go into the data organization.

I am proposing that a top-level element called 'netconf' be added.
The 'eventStreams' and 'namedProfiles' elements will be child nodes
of 'netconf'. The 'namedProfile' element will be a child node of 'namedProfiles',
as intended.

Over time, the ability to retrieve all the data
related to the NETCONF protocol itself with the simple filter "<netconf/>"
will become obvious, if it isn't already.  The namespace ID
could be 'netmod'.  I don't know the XSD details involved,
but an element called 'netconf' of type 'any' seems possible.

The XSD should be redone so that the table 'row' structs are
defines as <complexTypes> instead of unnamed types within an <element>.
I think the following version of the XSD is easier to understand,
and reflects the intended data structures more correctly.

Andy

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

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
     xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:event:1.0"
     targetNamespace="urn:ietf:params:xml:ns:netmod:event:1.0"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
     <xs:annotation>
         <xs:documentation xml:lang="en">
             A schema that can be used to learn about current
             event streams and to manage named profiles.
         </xs:documentation>
     </xs:annotation>

   <xs:import namespace="http://www.w3.org/XML/1998/namespace"
         schemaLocation="http://www.w3.org/2001/xml.xsd"/>
   <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
         schemaLocation="urn:ietf:params:xml:ns:netconf:base:1.0"/>
   <xs:import
         namespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
         schemaLocation=
         "urn:ietf:params:xml:ns:netconf:notification:1.0"/>

  <xs:complexType name="EventStream">
    <xs:annotation>
      <xs:documentation>
        Stream name and description
       </xs:documentation>
    </xs:annotation>
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="description" type="xs:string"/>
      <xs:element name="replaySupport" type="xs:boolean"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="EventStreams">
    <xs:annotation>
      <xs:documentation>
        The list of event streams supported by the system.
        When a query is issued, the returned set of streams is
        determined based on user privileges
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name="stream" type="EventStream" minOccurs="0"
          maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="NamedProfile">
    <xs:annotation>
      <xs:documentation>
        A named profile, which is a saved set of parameters
        associated that may be associated with zero or more
        active subscriptions.

        This object can be created, read, deleted and its
        individual components can be modified.
      </xs:documentation>
    </xs:annotation>
    <xs:sequence>
       <xs:element name="name">
         <xs:annotation>
           <xs:documentation>
              The name associated with the profile.

              This object is readable and modifiable.
           </xs:documentation>
          </xs:annotation>
       </xs:element>

       <xs:element name="stream"  minOccurs="0">
         <xs:annotation>
           <xs:documentation xml:lang="en">
               The event stream associated with this named
               profile.

               This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="filter"
          type="netconf:filterInlineType"  minOccurs="0">
         <xs:annotation>
           <xs:documentation xml:lang="en">
              The filters associated with this named profile.
              This object is readable and modifiable.
           </xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="lastModified" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>
              The timestamp of the last modification to this
              named Profile. Note that modification of the
              profile does not cause an immediate update
              to all applicable subscription. Therefore,
              this time should be compared with the last
              modified time associated with the
              subscription. If this time is earlier, then
              the subscription is using the exact set of
              parameters associated with this named profile.
              If this time is later, then the subscription
              is using an earlier version of this named
              profile and the exact parameters may not
              match.

              This object is read-only.
            </xs:documentation>
          </xs:annotation>
        </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="NamedProfiles">
     <xs:annotation>
       <xs:documentation>
         The list of named profiles configured on the system.
       </xs:documentation>
     </xs:annotation>
     <xs:sequence>
       <xs:element name="namedProfile" type="NamedProfile"
           minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <xs:element name="eventStreams" type="EventStreams"/>

   <xs:element name="namedProfiles" type="NamedProfiles"/>

</xs:schema>

--
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: Wed, 2 May 2007 15:02:44 -0400

Hi

I was getting ready to press send on the update ...

I can easily enough add a <netconf> wrapper to the content schema in
this draft. I guess then in theory we would then define the monitoring
information in
http://www.ietf.org/internet-drafts/draft-chisholm-netconf-monitoring-00
.txt to extend that object. 

I'm not sure what the procedure is for making these sort of changes post
working group last call.

For the second issue, this seems more subjective. Do we expect people
will use these complex types?

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Wednesday, May 02, 2007 12:46 PM
To: Netconf (E-mail)
Subject: Notification data model structure

Hi,

I want to propose a minor change to the 'state' data models in the
Notifications draft, and some XSD improvements.

I am proposing that a top-level element called 'netconf' be added.
The 'eventStreams' and 'namedProfiles' elements will be child nodes of
'netconf'. The 'namedProfile' element will be a child node of
'namedProfiles', as intended.

Over time, the ability to retrieve all the data related to the NETCONF
protocol itself with the simple filter "<netconf/>"
will become obvious, if it isn't already.  The namespace ID could be
'netmod'.  I don't know the XSD details involved, but an element called
'netconf' of type 'any' seems possible.

The XSD should be redone so that the table 'row' structs are defines as
<complexTypes> instead of unnamed types within an <element>.
I think the following version of the XSD is easier to understand, and
reflects the intended data structures more correctly.

Andy

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

</xs:schema>

--
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: Andy Bierman <[email-masked]>
Date: Wed, 02 May 2007 12:13:04 -0700

> will use these complex types?

IMO, it makes the XSD easier to read, but more importantly,
it allows vendors (or even the IETF) to define proper extensions
or restrictions in their schemas.

Andy

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 2 May 2007 23:39:43 +0300

In line. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Wednesday, May 02, 2007 10:03 PM
> To: Netconf (E-mail)
> Subject: RE: Notification data model structure
> 
> Hi
> 
> I can easily enough add a <netconf> wrapper to the content 
> schema in this draft. I guess then in theory we would then 
> define the monitoring information in 
> I'm not sure what the procedure is for making these sort of 
> changes post working group last call.

The document is still in the WG hands, so you are allowed to do any
change you want. The chairs should establish the process to make sure
the changes enjoy the consensus of the WG (another LC, fast track LC,
question the list, etc.)

> 
> For the second issue, this seems more subjective. Do we 
> expect people will use these complex types?

I would say yes (contributor opinion)

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 3 May 2007 08:12:33 -0700

Hi,

As Andy just said, named complex types can have clean
vendor extensions - unnamed types require hacking the
schema - in IEEE-ISTO PWG standards we ONLY used named
types for every element, for that very reason.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, May 02, 2007 3:40 PM
To: Sharon Chisholm; Netconf (E-mail)
Subject: RE: Notification data model structure

In line. 

Dan

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.6.2/785 - Release Date: 5/2/2007 2:16 PM