Subject: I-D ACTION:draft-ietf-netconf-notification-09.txt

From: [email-masked]
Date: Tue, 11 Sep 2007 11:15:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title		: NETCONF Event Notifications
	Author(s)	: H. Trevino, S. Chisholm
	Filename	: draft-ietf-netconf-notification-09.txt
	Pages		: 45
	Date		: 2007-9-11
	
This document defines mechanisms that provide an asynchronous message
   notification delivery service for the NETCONF protocol.  This is an
   optional capability built on top of the base NETCONF definition.
   This document defines the capabilities and operations necessary to
   support this service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-netconf-notification-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-netconf-notification-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Li Yan <[email-masked]>
Date: Thu, 13 Sep 2007 13:27:21 +0800

Hi,
I have found some mistakes in this revision of the draft.
o Sec 1, Figure 1, the vertical lines have not been aligned. The labels
("Layer", "Example") are not in the middle of the box. The three boxes
marked with "Configuration data", "<get-config>,..." and "BEEP,..."
respectively should have the same width.
o Sec 1.1, p5, "Event:" item, there is an otiose hyphen at the end of the
first line of this paragraph.
o Sec 1.3, paragraph 2, line 1, "close-session" should be "<close-session>".
o Sec 2.1.1, p8, "Stop Time:" item, "A stop times that is later than the
current time", where "times" should be singular.
o Sec 2.3, this section should mention using the <close-session> operation
to terminate the NETCONF session.
o Sec 3.2.1, the last line, "edit-config" should be "<edit-config>".
o Sec 3.2.2, Sec 3.2.3, capitalize the "must".
o Sec 3.2.5.1, "An empty reply is returned if there are no available event
streams." This sentence confuses me. Sec 3.2.2 states that the notification
capability must support the "NETCONF" notification event stream, why this
case could happen?
o Sec 3.7, Figure 4, I suggest that "<startTime> and <stopTime>" should be
added at the right of <create-subscription> so that the reader can easily
tell the difference between Figure 3 and Figure 4.
As follows:
          |  <create-subscription>    |   (with <startTime> only)
          |-------------------------->|
          ...
                Figure 3

          |  <create-subscription>    |   (with <startTime> and <stopTime>)
          |-------------------------->|
          ...
                Figure 4
o Sec 5.1, the first example, the filtering criteria evaluation should be
  ((fault & severity=critical) | (fault & severity=major) | (fault &
severity=minor))
o Sec 5.1, the second example, the following XML segment should be deleted,
because there is no this filtering criteria in the foregoing evaluation
expression.
          <event xmlns="http://example.com/event/1.0">
            <eventClass>fault</eventClass>
          </event>
  <reportingElement> should be <reportingEntity>
o Sec 5.2, the second example, the filtering criteria evaluation is wrong,
it should be
( state | config | ( fault & card=Ethernet0 ))
Therefore, the <filter> parameter should be
   <filter netconf:type="xpath"
           xmlns:ex="http://example.com/event/1.0"
      select="/ex:event[
         ex:eventClass='state' or ex:eventClass='config' or
        (ex:eventClass='fault' and
ex:reportingEntity/ex:card='Ethernet0')]"/>

Yan

--
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: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Sep 2007 09:03:45 +0200 (CEST)

>   ((fault & severity=critical) | (fault & severity=major) | (fault &

I agree.  There are two examples in 5.1 and two in 5.2.  I guess that
they are supposed to be equal, i.e.  the first in 5.1 and the first in
5.2 are supposed to be the same test, expressed as a subtree filter
and xpath filter respectively.  Thus I suggest that the evaluation
criteria used in those sections are exactly the same.

For the first example in 5.1. and 5.2, I suggest you use

  (fault & ((severity=critical) | (severity=major) | (severity=minor)))

For the second example, I suggest you use

   (state | config | (fault & (card=Ethernet0)))

Maybe even align the text describing those examples...

>             <eventClass>fault</eventClass>

I agree.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 14 Sep 2007 18:18:42 +0200

Hello,

2.1.1) I think the following negative responses should also be mentioned:
- stopTime < StartTime 	Is this "bad-element" ?
- startTime > currentTime. Earlier it is stated this is not valid.	Is this "bad-element" ?

3.4) In the XSD schema it is still written that the list of streams is based on user privileges.

6 one but last paragraph)
"If a user does not have permission to view content via other NETCONF operations, it does not 
   have permission to access that content via Notifications."
Is this a requirement? then it should use the word MUST instead of "does". On the other hand 
SNMP does not work like this, so why do we want to define access control here?

6) I would not worry much about the security of the transport for non-netconf streams;
SSH is secure enough. I think the real risk is that Netconf has a different receiving
application then syslog, SNMP. The Netconf manager application might be less secure then e.g. a
syslog server.

Balazs