RE: stopping notifications

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

Hi

On this topic, the draft currently says:

"A NETCONF server is not required to process RPC requests on the
   session associated with the subscription until the notification
   subscription is done and may silently discard these requests.  A
   capability may be advertised to announce that a server is able to
   process RPCs while a notification stream is active on a session.  The
   behaviour of such a capability is outside the scope of this
document."

Note that in Montreal it was agreed that processing messages just to
produce error messages just did not make sense. 

In some offline discussions, we have proposed the following improvement
to the paragraph

"A NETCONF server is will not read RPC requests, by default, on the
   session associated with the subscription until the notification
   subscription is done.  A capability may be advertised to announce 
   that a server is able to process RPCs while a notification stream 
   is active on a session.  The behaviour of such a capability is 
   outside the scope of this document." 

Sharon

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, July 05, 2007 10:40 PM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: Re: stopping notifications

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> The agent has to send something if a manager sends an RPC request 
>> during notification mode, even if it is a quick 'operation-failed'
reply.
> 
> There's nothing in the draft that specifies this behaviour.
> 
>> Just letting the manager hang until it times out seems wrong.
> 
> Well it's wrong to try to send anything in notification mode...

The agent cannot assume the manager will always send the correct PDU.
The agent must always respond appropriately to an <rpc> request.
RFC 4741 says so.

The immediate issue is whether or not the draft needs to say anything
about this situation.

I think it is better to just say the agent MAY allow RPC requests to be
processed after <create-subscription>, but if not, the agent MUST
respond with an appropriate <rpc-error>.
(Define an error-app-tag like 'notification-exclusive-mode' for an
operation-failed error-tag).

> 
>> IMO, there is already code to close down the session in case it is 
>> dropped, and this is not nearly as hard to support as allowing any 
>> RPC method.
> 
> This is obviously implementation dependent.  In my implementation, I 
> would have to add code to detect this case and send an 
> 'operation-failed' error instead of handling the request.

This argument washes out.
You would need special code to know you are in notification mode so you
should ignore the subsequent <rpc> requests.

I think my solution above allows the 'normal' code path to be utilized,
allows an implementer to easily reject requests in notification mode,
and allows a manager to easily tell if interlaced RPCs are supported
(without needing yet another capability).

> 
> 
> /martin

Andy



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

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