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

Re: Comments on notification-09

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

Li Yan wrote:

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