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

Re: Review of draft-ietf-netconf-notification-06



"Kent Watsen" <kwatsen@juniper.net> wrote:
> 
> 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

Or maybe process it and reply with 'in-use'.

> 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

On the other hand, isn't this something the client can control?  If
it's a problem that it can't distinguish between multiple
subscriptions - don't create more than one.  If the client knows that
the notifications from two subscriptions are different (e.g. snmp
stream vs. syslog stream) it may make sense to have two
subscriptions.  See also below.

> Section 3.4
> 
> It is very unfortunate that <createSubscriptionType> only allows at most
> one stream at a time (i.e. its not maxOccurs=0)

Isn't this the same situation as above?

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

To be sent when the write buffer towards the client is full ;)  ?

I think this makes sense to keep as a statistics counter in the "agent
mib".  


/martin

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