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

From: "Kent Watsen" <[email-masked]>
Date: Fri, 16 Mar 2007 18:18:26 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 18 Mar 2007 12:57:08 +0100 (CET)

"Kent Watsen" <[email-masked]> wrote:
> 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

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.

> one stream at a time (i.e. its not maxOccurs=0)

Isn't this the same situation as above?

> - as the only

> (or something) that can be used whenever a device drops an event (i.e.

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

---

From: "Kent Watsen" <[email-masked]>
Date: Mon, 19 Mar 2007 10:53:25 -0700

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

That would work

> 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

> 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

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 20 Mar 2007 10:52:11 +0100 (CET)

"Kent Watsen" <[email-masked]> 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)
> > 
> 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 this would be for each module to mark each event with a sequence-id -

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Mar 2007 03:55:03 -0700

> "auth-vpn-syslog" stream ;)

I don't think this approach scales well at all.
Also, stream configuration is is out of scope for the first version of 
NETCONF Notifications,
but that does not mean you cannot provide a data model for this purpose 
in your products.
When you get it right, propose it as new work, and get other vendors to 
agree that
is how they want to configure their streams also.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 20 Mar 2007 15:20:43 +0100

Hello,
I am upset that the detailed error messages got stripped out of Sharon's draft.

In my experience it is nearly always good practice to provide as much error information as 
possible. Just saying that the error is Bad-Value is too generic for me. It reminds me of the 
limited set of SNMP error messages that should have covered everything, but in reality were far 
from enough.

I hope at least the error-info and the error-message parts will stay in the notifications 
draft.  I see no reason to remove them.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Mar 2007 09:40:52 -0700

Balazs Lengyel wrote:
> In my experience it is nearly always good practice to provide as much 
> error information as possible. Just saying that the error is Bad-Value 
> is too generic for me. It reminds me of the limited set of SNMP error 
> messages that should have covered everything, but in reality were far 
> from enough.
>
> I hope at least the error-info and the error-message parts will stay 
> in the notifications draft.  I see no reason to remove them.

The WG decided that producing a new version of the NETCONF protocol
to add a special error code for a start time after a stop time was not 
justified.
I disagree with your conclusions 100%.  I do not want to write special
code to deal with (or generate) special error-tags for every possible 
combination
of corner-case errors that can occur.  This is simply an invalid-value 
error.

There is going to be an error-message string that contains the "stop 
before start time"
indication.

Andy