Subject: NETCONF Notifications Issues List

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Nov 2006 09:39:36 -0800

Hi,

I started an issues list for the discussion at the IETF meeting.
Many sections are blank, which means there are either no problems
or no comments made recently on that topic.  I really hope everyone
in the WG takes the time to read this draft and send comments to
the WG mailing list.  We need to get this document ready for WG Last Call.

1) Design

2) RPC Methods
   - create-subscription
     - why isn't there a stop-time in the replay capability?  [BL]
     - why stop notifications after replay (e.g. no tail -f mode) [BL]

3) Filters

4) Capabilities

5) <notification> Element

6) Data Models
   - Why do we need to query the notification subscriptions? [BL]
   http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html

7) Syntax (General XSD issues)
   - Why do we need 3 namespaces? [BL]
   - The XML Schema should start with a top level element (e.g. <top>)
     and specify the containing elements all the way down. [BL]
   http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html

8) Documentation (Organization, clarity, references, bugs)
   - assorted comments and corrections (10/24/06 email) [BL]
     http://ops.ietf.org/lists/netconf/netconf.2006/msg01227.html

   - assorted comments and corrections (10/24/06 email) [MB]
     http://ops.ietf.org/lists/netconf/netconf.2006/msg01228.html

   - notification-03 review [BW]
     http://ops.ietf.org/lists/netconf/netconf.2006/msg01165.html

9) Security Considerations

   - Need paragraph stating that security threats are handled during
     NETCONF session establishment, and the notification mechanism
     does not introduce any new threats, since any data available
     through <notification> can also be made available to the <get> RPC. 
[DR]

10) Transport Mappings

   - Which transports must be supported in version 1.0?

   - Document packaging
     Include in Notifications RFC or create 2 separate RFCs? 4 separate 
RFCs?

   - SOAP needs a lot of specification work; not going to hold up the entire
     work item waiting for this document. [AB]

   - SOAP could use Ajax Push design [TG]
     http://ops.ietf.org/lists/netconf/netconf.2006/msg01216.html

--
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: Fri, 3 Nov 2006 12:56:59 -0500

Hi

>     - why stop notifications after replay (e.g. no tail -f mode) [BL]

The first issue was in the discussion list before the -04 update. I
tried to generate some discussion on the topic, but wasn't successful so
I kept it open. I'll try again. In the use cases I've seen, an implicit
stop time of when the command was sent works, so adding stop time
doesn't seem necessary. Thoughts?

For the second one, in the use cases I've seen, people don't want to
have to wait until the replay has completed before getting current
alarms. They therefore do not want replay and real-time on the same
subscription.

>   http://ops.ietf.org/lists/netconf/netconf.2006/msg01226.html

If a working group in any other IETF area developed a protocol with no
way to manage it, we would think they hadn't design a proper solution.
Somehow in Netconf, we seem to be holding ourselves to a lower standard.
I think we need monitoring schema to report on the state of the system.

Sharon

---

From: Andy Bierman <[email-masked]>
Date: Fri, 03 Nov 2006 10:44:19 -0800

> alarms. They therefore do not want replay and real-time on the same

IMO, in both cases these are parameters that the NMS might want.
Whatever the parameter set, there should only be one version of it.
(I.e., no capabilities per parameter like with edit-config, that
was a mistake).

I don't really care what the parameters are, as much as there is
one standard way to do notification replay.  The way an agent
avoids this feature is by storing zero seconds worth of replay data,
so the rpc-reply "I have no replay data that meets these parameters"
is always returned.

> I think we need monitoring schema to report on the state of the system.

I tend to agree with you here, but this data isn't that useful.
Maybe it will be useful during deployment debugging, who knows.
Perhaps a comprehensive data model for monitoring all aspects
of the active sessions is more appropriate.  (What does the WG think?)

> Sharon

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 3 Nov 2006 15:49:41 -0500

hi

Two more comments:

1. New issue: I was apparently validating things against an older
version of the Netconf base protocol definition and now that I have the
proper version, my event instances are not validating correctly. You
can't put content in the data field.  This is a result of the base
protocol changing to
  <xs:complexType name="dataInlineType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType"/>
    </xs:complexContent>
  </xs:complexType>
 
from
 
     <xs:complexType name="configInlineType">
       <xs:complexContent>
         <xs:extension base="xs:anyType"/>
       </xs:complexContent>
     </xs:complexType> 

I have a product tripping over this at the moment so I should have
solutions shortly.

2. All of Bert's comments you reference below were addressed in the -04
release except for those highlighted in the discussion email. All
comments received to that point are in that boat.
	http://ops.ietf.org/lists/netconf/netconf.2006/msg01171.html

Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Thursday, November 02, 2006 12:40 PM
To: Netconf (E-mail)
Subject: NETCONF Notifications Issues List

Hi,

I started an issues list for the discussion at the IETF meeting.
Many sections are blank, which means there are either no problems or no
comments made recently on that topic.  I really hope everyone in the WG
takes the time to read this draft and send comments to the WG mailing
list.  We need to get this document ready for WG Last Call.

1) Design

2) RPC Methods
   - create-subscription

3) Filters

4) Capabilities

6) Data Models

[DR]

10) Transport Mappings

   - Document packaging

   - SOAP needs a lot of specification work; not going to hold up the
entire
     work item waiting for this document. [AB]

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