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

[Martin Bjorklund <mbj@tail-f.com>]

"Kent Watsen" <kwatsen@juniper.net> wrote:
> > > 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?
> 
> Not at all - the difference being that the above regards dynamic
> subscriptions while this is still a single static subscription
> 
> I envision a "stream" for each logical module in a device (i.e. auth,
> config, firewall, vpn, ids, etc.), which would cause a management
> application wanting to receive notifications for all modules to have to
> create a netconf session/subscription for each...

I agree with you.  I also think it would have been better to keep
subscription for multiple streams.  Maybe we'll see implementations
hack around this by making it possible to request the
"auth-vpn-syslog" stream ;)

> Using SSH, the required mapping, each netconf session results in a
> forked process on the device - enabling multiple streams in a
> subscription would eliminate this overhead

You mean "using OpenSSH".  In our implementation we do not fork a new
UNIX process for each new session.  And if the new netconf session is
opened as a new ssh channel, the socket and encryption state overhead
is minimized.


> > > 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".
> 
> Yes, it is ironic, I know...and it may not even be possible, but my
> point is that an app should be able to find out where its missing
> information - a single counter isn't quite enough...  
> 
> Using the stream-per-module approach from above, a reasonable solution
> to this would be for each module to mark each event with a sequence-id -
> what do you think?

With the no-header approach we have, this is by design up to each
application/implementation to solve for itself.


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