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

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

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

That would work


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

Firstly, in my original text, s/impossible/possible/

Yes, the client can use multiple netconf sessions for subscriptions -
I'm not pushing for a subscription-id, I'm just pointing out why it
should not be allowed


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


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

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?




Thanks,
Kent



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