Re: Clarification on future stopTime

[Martin Bjorklund <mbj@tail-f.com>]

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