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

Re: Notification data model structure



Sharon Chisholm wrote:
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?


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.

Sharon

Andy





-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] 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.

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