RE: Clarification on future stopTime

["Sharon Chisholm" <schishol@nortel.com>]

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:mbj@tail-f.com] 
Sent: Wednesday, September 12, 2007 1:13 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: netconf@ops.ietf.org
Subject: Re: Clarification on future stopTime

Hi,


"Sharon Chisholm" <schishol@nortel.com> wrote:

> Attached is the proposed update so far to allow stopTime in the future

> again and to add the interleave capability.

Great!

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

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