Subject: notification-07 issue list

From: Andy Bierman <[email-masked]>
Date: Sun, 03 Jun 2007 13:48:33 -0700

Hi,

We need to finish up this document by the end of the Chicago IETF.
This is a first draft issue list, based on mailing list comments
so far.  It is getting increasingly difficult to get people to
review successive versions of the draft.  It seems that each time,
not all approved changes are made, and one or two new things show
up that were never even discussed by the WG.  This has the combined
effect of discouraging people from reviewing new versions,
and keeps generating new issues to resolve.

Therefore, we need to focus on creating a final edit list and
making sure that it is applied exactly as approved by the WG,
so we can finally forward the draft to the IESG.

The issue list below highlights the recent comments made on notification-07:

http://ops.ietf.org/lists/netconf/netconf.2007/msg00136.html

http://ops.ietf.org/lists/netconf/netconf.2007/msg00137.html

http://ops.ietf.org/lists/netconf/netconf.2007/msg00148.html

http://ops.ietf.org/lists/netconf/netconf.2007/msg00153.html

http://ops.ietf.org/lists/netconf/netconf.2007/msg00196.html

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

1) named profiles

  a) <stream> element in named profile is not used for anything

  b) need <key> (==<name>) to properly support edit-config operation

  c) edit-config not applicable to contents of <filter> because
     its base type is 'any'

  d) filter element is optional. Not clear what use case a named
     profile without a filter supports.

2) <eventStreams> data model element

 a) definition is not extensible, such that XSD cannot be properly used
    to specify extensions and restrictions

 b) new element named 'replayLogStartTime' has been added to the XSD.
    This is not mentioned anywhere in the draft.  The WG never discussed
    adding this element.

3) XSD and Xpath corrections

   [see message list for details]

4) XSD template for <notification> wrapper

   a) current definition is not what the WG agreed to, and does not
      even support the replayComplete notification correctly

   b) definition is not extensible, such that XSD cannot be properly used
      to specify extensions and restrictions

5) XML representation of the <replayComplete> notification

   a) new element named <eventClass> has been added to the XSD.
      The WG never discussed adding this element.

           <xs:element name="eventClass"/>

      There is no text in the document about this element, including
      its actual XML type definition, purpose, or value for the 
<replayComplete>
      notification.

6) SSH Transport Support Text

   a) need separate document to support top-level <notification> element
      explicitly by NETCONF over SSH

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

Please try to use a separate email for each existing topic or new topic,
instead of responding to this thread, if you want to comment on
any of the open issues.

We would like to finish up as much as possible on the mailing list,
and not defer these decisions until the meeting in Chicago.

thanks,
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: Balazs Lengyel <[email-masked]>
Date: Tue, 12 Jun 2007 17:38:51 +0200

Hello,
Chapter 3.3.2) indicates that replayComplete is sent even if a stopTime was not specified.

Chapter 3.3.3) states that replayComplete is sent only if stopTime was specified.

Which is true?

Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 12 Jun 2007 17:50:27 +0200

Hello,
I believe defining _any_ XML as configuration data in a datastore is saying: "Vendor specific, 
unspecified". I don't like that. A workaround could be to restrict the _any_ using plain 
english. However specifying XML in plain english sounds bad.

I would rather delay named profiles then have _any_ as part of a standard data model.

As an alternative we could refer to named profiles without actually defining them like we do 
with eventStreams. This would be a cleaner way to say: vendor specific.

Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jun 2007 09:35:53 -0700

Balazs Lengyel wrote:
> Hello,
> I believe defining _any_ XML as configuration data in a datastore is 
> saying: "Vendor specific, unspecified". I don't like that. A workaround 
> could be to restrict the _any_ using plain english. However specifying 
> XML in plain english sounds bad.

This sounds like even more special-case (hack) code to deal
with NETCONF's version of XML, instead of "real XML".

> I would rather delay named profiles then have _any_ as part of a 

I agree, if it means (and it does) backing into an important
data modeling decision without thinking it through or specifying any of
the details.

> 
> As an alternative we could refer to named profiles without actually 
> defining them like we do with eventStreams. This would be a cleaner way 
> to say: vendor specific.

I disagree.

1) The eventStreams are defined well enough to be used within
the notification system.  How they get there in the first place
is outside the standard.  Without specifying the contents of
the named profile, there are missing pieces (like the filter).
The way subtree filtering is defined, the only data type that
works is 'any'.  Well-formed junk is just no-match, nothing more.

2) It is not vendor-specific.
The 'any' node (filter) has a conceptual definition
and there are standard algorithms for determining
the filter output.

The real problem is that <edit-config> itself is not fully
specified for all possible data-model related corner-cases.
IMO, the NETMOD specification should fill in those gaps,
not the protocol spec.

I am definitely in favor of creating standard data models
whenever possible, but a data model containing a template
for every conceivable data model is problematic, and perhaps
not that important in our notification delivery system.
Passing the <filter> as an RPC parameter places
it immediately into the 'internal format', not available
to <edit-config>.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 24 Jun 2007 20:41:27 -0400

<Andy>

   b) definition is not extensible, such that XSD cannot be properly
used
      to specify extensions and restrictions

</Andy>

Actually, after Andy suggested some XSD to achieve being able to define
notifications as proper extensions of the notification 
https://ops.ietf.org/lists/netconf/netconf.2007/msg00123.html 
I responded
https://ops.ietf.org/lists/netconf/netconf.2007/msg00131.html
suggesting that the XSD did not work as advertised in my tools, so I
proposed something in the spirit of what Andy's stuff was trying to
achieve but that validated in my tools.  If there are other things it
should be able to do, please clarify since it does what it needs to do
from what I can see.

<Andy>

</Andy>

This is residue. It was suppose to have been removed. It will be removed
in the update.
 
Sharon

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2007 07:27:16 -0700

> should be able to do, please clarify since it does what it needs to do

The current XSD definition is for a <notification> wrapper
that cannot have any XML attributes defined, and must contain
an element called <data>.

      <xs:complexType name="dataInlineType">
        <xs:complexContent>
          <xs:extension base="xs:anyType"/>
        </xs:complexContent>
      </xs:complexType>

      <!-- <Notification> operation -->
      <xs:complexType name="NotificationType">
         <xs:sequence>
           <xs:element name="data" type="netconf:dataInlineType" />
         </xs:sequence>
      </xs:complexType>

      <xs:element name="notification" type="NotificationType"/>

The <replayComplete> notification does not have an element called <data>.
This may not be the only notification ever defined that does
not have any additional data to include.

I think other people in the WG need to comment on this issue.
Should this 'data' element be defined in the <notification> base type?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2007 17:06:48 +0200 (CEST)

> not have any additional data to include.

I think the idea is that a notification looks like this:

  <notification xmlns="urn:ietf:params:netconf:capability:notification:1.0">
    <data>
      <my-notif xmlns="http://example.com/ns/foo">
         ...
      </my-notif>
    </data>
  </notification>

There are no examples of what a <notification> looks like though.

The <data> element does seem to be superflous though.

I think this approach works, although an alternative is to use a
subsitution group like the rpc, which you pointed out earlier.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Jun 2007 08:31:03 -0700

>   <notification xmlns="urn:ietf:params:netconf:capability:notification:1.0">

URN is wrong! Use the Namespace format, not the Capability format.

>       <my-notif xmlns="http://example.com/ns/foo">

Can you find some examples on the mailing list where this sort
of structure is used?

I think we have been assuming the following format, as we agreed to
for the <replayComplete> notification:

   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification">
     <replayComplete xmlns="urn:ietf:params:xml:ns:netmod:replayComplete"/>
   </notification>

> subsitution group like the rpc, which you pointed out earlier.

I don't see why the extra XML layer helps.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2007 17:40:30 +0200 (CEST)

> URN is wrong! Use the Namespace format, not the Capability format.

Actually, I just copied from the targetNamespace in the XSD in -07.

>      <replayComplete xmlns="urn:ietf:params:xml:ns:netmod:replayComplete"/>

I agree.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2007 00:03:38 +0200 (CEST)

"Sharon Chisholm" <[email-masked]> wrote:
> achieve but that validated in my tools.

Missing from both these posts are the XML that you actually got
validated.  I can't get your suggestion to validate...

I think Andy's definition works fine (with some prefix/namespace
fixes) -- although the replayComplete can be made simpler like this:

  <xs:element name="replayComplete"
              substitutionGroup="ncEvent:notificationContent"/>

Using this, I can validate:

  <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <replayComplete xmlns="urn:ietf:params:xml:ns:netmod:notification"/>
  </notification>

You can also define:

  <xs:complexType name="FooType">
    <xs:complexContent>
      <xs:extension base="ncEvent:NotificationContentType">
	<xs:sequence>
	  <xs:element name="target" type="xs:string"/>
	</xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <xs:element name="fooNotif"
	      type="FooType"
	      substitutionGroup="ncEvent:notificationContent"/>

And validate:

  <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <fooNotif xmlns="http://example.com/ns/notifs">
      <target>foo</target>
    </fooNotif>
  </notification>

As Andy pointed out, this is consistent with how rpcs are done in the
base protocol.

/martin