Review of draft-ietf-netconf-notification-06

["Kent Watsen" <kwatsen@juniper.net>]

This proposal is good except for the following:
 

Section 1.2 

The spec says that a capability can be used to announce that the netconf
server can process rpcs while sending notifications.  I think that it
very important that the device NOT process any new <create-subscription>
requests while sending notifications as there is no per-notification
subscription-identifier - thus it is not impossible for the client to
differentiate which subscription its receiving a notification for

 

Section 2.1.1 

The "negative response" section should clearly indicate what happens
when either the start-time is set but the stream doesn't support replay
or when the stop-time is set without having the start-time set - both of
these conditions are marked as illegal by the spec without any clear
statement about what will happen (i.e. what rpc-error will be returned)

 

Section 3.3 

It doesn't make sense for the namedProfile to include the "lastModified"
element - as it is not usable without any API to discover which
subscriptions are active and when they began...

 

Section 3.4

It is very unfortunate that <createSubscriptionType> only allows at most
one stream at a time (i.e. its not maxOccurs=0) - as the only
alternative is for the client to open a separate netconf session for
each stream, but this is both awkward and not efficient for either the
client or the server.   I fear that, unless this is fixed,
implementations will only support the required "netconf" stream and use
subscription filters to select what to receive, effectively rendering
the "stream" concept useless

 

Section 5.2 

The spec does not indicate if XPATH filters must be supported - this
would be surprising to me as the base netconf protocol lets XPATH be an
optional capability.  Maybe :notifications can use XPATH filters if and
only if the :xpath capability is advertised?

 

Section 6.3 

In addition to the special replayCompleteNotification notification, it
would be nice for there to also be a special eventsDroppedNotification
(or something) that can be used whenever a device drops an event (i.e.
buffer full, etc.)


Sincerely,
Kent


--
Kent Watsen
Chief Software Architect
NSM, Juniper Networks



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