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