RE: Comments on notifications-03

["Sharon Chisholm" <schishol@nortel.com>]

Hi

Thanks a lot for the review:

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

We can make this clearer. State that is a new capability building on
what was defined in the base protocol specification.

<Balazs>

Chapter 1.1) The definition of subscription contradicts the 9th
requirement in chapter 1.4

</Balazs>

That bullet says: 
"solution should not bind subscriptions to a connection"

Which does seem to contradict both the definition of a subscription and
what the working group agreed to. I believe that requirement means
something else, but I can't quite remember at the moment.


<Balazs>
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.
</Balazs>
Ok. Good bit of clarification.

<Balazs>
Chapter 1.4)
- requirement5: We will not provide agent initiated connections just now
so this should only be a future goal not a requirement.
</Balazs>
I'm not sure why this is still in the requirements list. I think we
agreed to remove it.

<Balazs>
- requirement10: I don't see this implemented in the draft, propose to
be removed.
</Balazs>

"channels for configuration change notifications should share fate
      with a session that includes a configuration channel"

Um. I think I left it in based on the notes from the Montreal meeting,
but I believe we indicated that they were independent.

<Balazs>

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

We had talked in Montreal about the fact that the current capability
didn't support 'mix-mode', but that we could define an optional
capability at some future date that did. This text is intending to not
preclude that definition, which may well include a definition of a
command such as cancel-subscription. Another event could be someone
supporting a CLI command to do this as well I suppose.

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

Agreed.

<Balazs>

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

No. That could be my mistake. Hector and I had talked about this and
decided having both was over-engineered so Hector provided a single one
to handle both. It seems we left some residue of the interim solution in
the draft. We'll fix that.

<Balazs>

I also believe it would be enough to use get-config in the examples and
omit the ones using get.
</Balazs>

Or the other way around I suppose ...

<Balazs>
Chapter 3.2.5.3)
Inside xs:annotation/xs:documentation it says: "Schema for event
streams". Is this correct?
</Balazs>
I believe so, but perhaps it could use a bit more description. This is
the schema that people are suppose to query to find out what streams are
supported by the system. As noted above, it does not match up with the
examples anymore.

<Balazs>

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

I notice we forgot to put the definition of stream in the XSD for the
create-subscription command. This of course would have definitively
shown the cardinality of streams per subscription. We do say in section
2.1.1 that you associate 'stream(s)' which is meant to indicate you can
associate more then one per subscription. We will fix up the schema to
properly handle streams.

<Balazs>

Chapter 5.2.1.2) Is there a strong need for the new construct? If not
remove it.

</Balazs>

This is related to the Beep transport mapping, which is something WE
NEED INPUT ON.

<Balazs>

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>

Agreed. We need to better specify this in the next release.

Thanks again,

Sharon

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