[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on notifications-03
Hello,
General:
I think the draft is going in the good direction, nice work but still needs clarifications.
The document should state very clearly whether this is new capability (or two) or a
mandatory addition to netconf.
I believe the draft defines 2 new capabilities, however for the base-notification this is
not clearly stated. Even the capability identifier is defined only in the example in
chapter 3.1
Chapter 1.1) The definition of subscription contradicts the 9th requirement in chapter 1.4
Chapter 1.2 last paragraph) The agent is not required to process RPC requests ON THE SAME
NETCONF SESSION. I believe it is required for the agent to be able to open another Netconf
session and handle RPCs there.
Chapter 1.4)
- requirement5: We will not provide agent initiated connections just now so this should
only be a future goal not a requirement.
- requirement10: I don't see this implemented in the draft, propose to be removed.
Chapter 2.1.1 Description) What kind of event are you thinking about ?
Chapter 2.3) I would mention closing the transport session. What other actions are you
thinking about?
Chapter 3.2.5.1)
I believe we should consider defining the exact namespace and path of the stream
information instead of providing a namespace called example.com
I wonder if the distinction between sessionEventStreams and systemEventStreams is really
needed. Why don't we just say: There is a set of eventStreams and every one will see the
set of streams according to his/her access rights.
I also believe it would be enough to use get-config in the examples and omit the ones
using get.
Chapter 3.2.5.3)
Inside xs:annotation/xs:documentation it says: "Schema for event streams". Is this correct?
Chapter 3.2.6.2)
Is it allowed to subscribe to multiple eventStreams in one subscription/session ? I would
like to believe so. If I am right further channels are not needed to receive multiple
streams.
Until now we avoided using multiple channels on one Netconf session. Why do we introduce
it here?
Chapter 5.2.1.2) Is there a strong need for the new construct? If not remove it.
Chapter 7.1 paragraph 3) The warning message should be defined somehow. E.g. an extra
element in the first notification indicating the real start time.
Balazs
--
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/>