Subject: Clarification on future stopTime

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 12 Sep 2007 12:24:56 -0400

Hi

Attached is the proposed update so far to allow stopTime in the future
again and to add the interleave capability.

A question I had was what we wanted to say about whether or not the
server could return an error if the future time was further ahead then
the server wanted to deal with.
	1 Explicitly say that all values should be valid   (April 1,
3023)
      2 Error with the following error message: <something>
      3 Nothing. Let's not specify any particular behaviour beyond what
is in the draft already.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 12 Sep 2007 19:12:53 +0200 (CEST)

Hi,

> again and to add the interleave capability.

Great!

>       3 Nothing. Let's not specify any particular behaviour beyond what

I think it makes sense to let the server reject a request if the
stopTime is too big.  If we do this, I think we should mention which
error to use.  I'm not sure which error msg is most appropriate
though.  operation-not-supported?  or does that error refer only to
the operation itself, not individual parameters?  bad-element?  Maybe
use a standard one and an <error-app-tag> stop-time-too-big.

Some other comments:

> 6.  Interleave Capability
> 
> 6.1.  Description
> 
>    The Interleave capability indicates that the NETCONF peer supports
>    the ability to interleave other NETCONF operations within a
>    Notification subscription.  This means the NETCONF server is able to
>    receive, process and respond to NETCONF requests on a session with an
>    active notification subscription.
> 
> 6.2.  Dependencies
> 
>    This capability is dependant on the notification capability being
>    supported.
> 
> 6.3.  Capability Identifier
> 
>    The :interleave capability is identified by the following capability
>    string:
> 
>    urn:ietf:params:netconf:capability:interleave:1.0
> 
> 6.4.  New Operations
> 
>    None.
> 
> 6.5.  Modifications to Existing Operations
> 
>    None.

I think we must mention that if you do a <create-subscription> in
interleave mode, the server MUST return an error.  (again, which
error?  I think it was discussed on the list)

> 8.  IANA Considerations
> 
>    This document registers three URIs for the NETCONF XML namespace in
>    the IETF XML registry [RFC3688].
> 
>    Following the format in RFC 3688, IANA has made the following
>    registration.
> 
>    URI: urn:ietf:params:netconf:capability:notification:1.0
> 
>    URI: urn:ietf:params:xml:ns:netmod:notification
> 
>    URI: urn:ietf:params:xml:ns:netconf:notification

This URI is never used in the draft.  Was it supposed to be the
targetNamespace of the schema which defines the new rpc?

/martin

--
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: "Sharon Chisholm" <[email-masked]>
Date: Thu, 13 Sep 2007 12:14:30 -0400

Hi

Part of me doesn't want to prevent people from calling a second
subscription on the subscription, but I guess in order to support the
second subscription, we need to bring back the subscription ID. 

So, for stopTime too far in the future,  the candidate errors seem to be
       bad-element
       invalid-value

It sort of begs for a variable to query for the latest supported
stopTime so you don't have to use trial and error though.

Sharon

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 1:13 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: Clarification on future stopTime

Hi,

Great!

I think it makes sense to let the server reject a request if the
stopTime is too big.  If we do this, I think we should mention which
error to use.  I'm not sure which error msg is most appropriate though.
operation-not-supported?  or does that error refer only to the operation
itself, not individual parameters?  bad-element?  Maybe use a standard
one and an <error-app-tag> stop-time-too-big.

I think we must mention that if you do a <create-subscription> in
interleave mode, the server MUST return an error.  (again, which error?
I think it was discussed on the list)

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Sep 2007 12:57:38 +0200 (CEST)

> second subscription, we need to bring back the subscription ID. 

An alternative is to allow the second create-subscription, and let the
manager deal with notifications from multiple streams.  I.e. keep the
current text as it is.  If the manager excplitly asks for multiple
streams, it can probably handle it.  (And I never understood the
problems with multiple streams anyway...)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Sep 2007 07:00:33 -0700

> problems with multiple streams anyway...)

Here's one problem.
The 2nd create-subscription ALSO asks for replay, but different parameters
than the first, WHILE the first replay stream is being delivered.
When the agent sends replayComplete, which subscription is it for?

> /martin

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 17 Sep 2007 10:37:55 -0400

>problems with multiple streams anyway...)

The problem is that it takes a simple service (give me events) that
can be _easily_ handled over a single channel with useful and
endearing properties (real-time, low overhead, simple model, easily
implemented) and turns it on its head to cover a rare and uninteresting
corner case.

If you want two sets of events, open two channels.  If you want to
perform RPCs while getting events, open another channel.  The
interleaving and multi-use channel aspects of the current draft are
the annoying details where the devils live.

But I'm definitely in the KISS camp, if my face paint and shoes
didn't clue you in already.  Keep the simple cases simple; keep
the complex cases from interfering with the simple cases; keep
the corner cases few and obvious.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 17 Sep 2007 18:12:24 +0200 (CEST)

> the corner cases few and obvious.

Of course.  Simple is always good.  But simple for who?  For the agent
implementation?  Simplicity of the spec?  For the manager?  One
implementor stated that the non-interleaving mode was much more
difficult for him to implement, and he would never support it.
Several others (myself included) stated that it is not more difficult
to implement interleaving than non-interleaving.  I think the
specification would be simpler with as few special corner cases as
possible.  As for the non-interleaving mode, it was pointed out that
it would be simpler for the manager to send a <close-session> (and
thus the agent would have to handle it) than opening a new channel and
send <kill-session>.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 18 Sep 2007 17:34:07 +0200

I also put my vote in the KISS camp. If we keep it simple, we might get it done before Dan 
kills us personally one-by-one :-)
Balazs