Subject: Comments on notification-08

From: Li Yan <[email-masked]>
Date: Wed, 11 Jul 2007 05:44:07 +0800

Hi,
Here are my comments. I commented the snapshot of draft-ietf-netconf-notifications yesterday. Some comments in it are still valid.
o  sec 4
   <xs:element name="stream"
       type="streamNameType" minOccurs="0">
   Does it imply that a single <create-subscription> operation can not subscribe multiple streams?

o  sec 5.1 says: an <events> element at the top level that contains one or more child elements <eventEntry> ...
   But the Figure 10 contains <event> instead of <eventEntry> element.

o  sec 5.1
   The label 'Figure 12' is missing. 

o  sec 5.1 and sec 5.2
   There is <reportingEntity> element in the Figure 10.
   <reportingEntity>
     <card>Ethernet0</card>
   </reportingEntity>
   But in the Figure 12 (its label is missing) and the Figure 14, <reportingEntity> is changed to <reportingElement>.

o  sec 5.2
   The Figure 14 is still wrong:
   1. The filtering criteria evaluation is not consistent with the XPATH expression in the <filter> element.
   2. Two '(' are missing.
   3. It is hard to read due to different sequence of conditions.
   The XPath filter should be:
   <netconf:rpc message-id="101"
           xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
     <create-subscription
        xmlns="urn:ietf:params:netconf:capability:notification:1.0">
          <filter netconf:type="xpath"
                  xmlns:ex="http://example.com/event/1.0"
             select="/ex:event[
                (ex:eventClass='state' or ex:eventClass='config') and
                ((ex:eventClass='fault' and ex:severity='critical') or
                 (ex:eventClass='fault' and ex:severity='major') or
                 (ex:eventClass='fault' and ex:severity='minor') or
                 (ex:eventClass='fault' and
                         ex:reportingEntity/ex:card='Ethernet0'))]"/>
    </create-subscription>
  </netconf:rpc>

Yan

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jul 2007 09:41:44 -0700

Li Yan wrote:

Thanks for your comments.
I also noticed that the examples do not reflect the
schema, since the top-level element <netconf> is missing.
(This was pointed out at least twice already).

Andy

> Hi,
> Here are my comments. I commented the snapshot of 
> draft-ietf-netconf-notifications yesterday. Some comments in it are 
> still valid.
> o  sec 4
>    But in the Figure 12 (its label is missing) and the Figure 14, 
> <reportingEntity> is changed to <reportingElement>.
>  
> o  sec 5.2

--
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: Thu, 12 Jul 2007 20:32:06 +0200

Major comments:
---------------
Chapter 3.2 para 3) Filters are mentioned in plural, should be singular

Chapter 3.3.2 and 3.3.3) The two sections contradict each other!!!
In 3.3.3 the draft says: after the replayComplete is received (sent?) the subscription is
terminated (by the Netconf agent???). In 3.3.2 the draft indicates that notifications might be
sent even after replayComplete.

Chapter 3.6) Multiple filters are mentioned. It should be just one. The second paragraph should
be removed as there is only one filter.

Chapter 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.

Minor issues:
------------
General) Labeling text examples as figures is strange for me, I would rather label them
"Example"  (still I am not a native English speaker).

Chapter 1.3 2nd para) The netconf server will read RPC requests (otherwise the TCP buffer will
fill up :-). The text in the 07-draft was better.

Chapter 3.2 para 2) The text refers to figure 2 but it should refer to figure 4

General) I would still prefer just one XSD but OK, I can live with this. Also the name netmod
in the URN is strange for me, but OK I accept.

Chapter 3.2.5.2.1) I would include the following sentence: "Both subtree and XPATH filtering
can be used.

Chapter 4) Why do we need a streamNameType? It is just a string.

Balazs

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 12 Jul 2007 15:19:21 -0400

-----Original Message-----
<clip>

Minor issues:
------------
General) Labeling text examples as figures is strange for me, I would
rather label them "Example"  (still I am not a native English speaker).

<clip>

Since I can't figure out xml2rfc, the choice was either figure numbering
that was non-contiguous or labelling everything. Perhaps I should have
left it as non-contiguous and just added a note to the RFC editor?

Sharon

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 12 Jul 2007 21:23:56 +0200

That's fine, thanks
Balazs

Sharon Chisholm wrote:
> Hi
> 
> On filters versus filter elements. You are right about section 3.2 para
> 3). That was somehow missed. But section 3.6 should only be talking
> about filter elements, which is ok.
> 
> Sharon 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Balazs Lengyel
> Sent: Thursday, July 12, 2007 2:32 PM
> To: [email-masked]
> Subject: Comments on notification-08 from Balazs
> 
> Major comments:
> ---------------
> In 3.3.3 the draft says: after the replayComplete is received (sent?)
> the subscription is terminated (by the Netconf agent???). In 3.3.2 the
> draft indicates that notifications might be sent even after
> replayComplete.
> 
> Chapter 3.6) Multiple filters are mentioned. It should be just one. The
> second paragraph should be removed as there is only one filter.
> 
> Chapter 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.
> 
> 
> Minor issues:
> ------------
> Chapter 1.3 2nd para) The netconf server will read RPC requests
> (otherwise the TCP buffer will fill up :-). The text in the 07-draft was
> better.
> 
> General) I would still prefer just one XSD but OK, I can live with this.
> Also the name netmod in the URN is strange for me, but OK I accept.
> 
> Chapter 3.2.5.2.1) I would include the following sentence: "Both subtree
> and XPATH filtering can be used.
> 
> to unsubscribe send a message to [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 12 Jul 2007 15:17:36 -0400

Hi

Sharon 

-----Original Message-----

Major comments:
---------------

Minor issues:
------------

Chapter 3.2 para 2) The text refers to figure 2 but it should refer to
figure 4

Balazs

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 12 Jul 2007 17:25:12 -0400

Hi Sharon,

I tried to send you some suggestions last week, especially one about
asking Elwyn, who is quite proficient at xml2rfc. Your address keeps
getting filtered out by filtops@nortel. I think you are missing
mailings from [email-masked]. Your filtops dept advises people who
get their notice of email having been filtered to send them email to
alert them if you believe the email should not be filtered, but they
filter out the responses to themselves as well. Sigh.

I think in the latest xml2rfc you can specify a counter name attribute
for numbered sequences, like figures. I believe this is undocumented.
So I recommend trying <figure counter="fignum"> for each of your
figures (using the same variable for all figures). That might solve
the numbering problem. I have not tested this.

There is an xml2rfc mailing list
([email-masked]), which is the best place to
get questions answered.

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sharon Chisholm
> Sent: Thursday, July 12, 2007 3:19 PM
> To: [email-masked]
> Subject: RE: Comments on notification-08 from Balazs
> 
>  
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jul 2007 11:00:57 +0200 (CEST)

Li Yan <[email-masked]> wrote:
>    1. The filtering criteria evaluation is not consistent with the
>    XPATH expression in the <filter> element.

You're right.  But I think the filtering criteria evaluation is wrong,
and the XPath correct.  The filtering criteria says:

   (( state | config ) & ( fault & (...)))

This can never evaluate to true, since is says that the eventClass
must be 'state' or 'config' AND eventClass must be 'fault'.

It should be

   ( state | config | ( fault & (...)))

>    3. It is hard to read due to different sequence of conditions.

Agreed.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jul 2007 11:25:39 +0200 (CEST)

Balazs Lengyel <[email-masked]> wrote:

> (otherwise the TCP buffer will fill up :-).

But that's the point!

> The text in the 07-draft
> was better.

The problem with the old text ("the server is not required to process RPC
requests") is that people interpreted it differently.  See
http://ops.ietf.org/lists/netconf/netconf.2007/msg00314.html.

/martin