Re: notification-08 comments

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello,
I still feel that just letting data sent by the manager to sit in the TCP buffers is a bad 
thing to do. These buffers will fill up and this might block the manager SW. At that point the 
agent actually does not accept anything from the manager. According to the Postel principle you 
should be liberal what you accept. Accepting nothing is not liberal.

So in my view the client/agent should read the data from the connection buffers and do 
something with it. If not discard it then what?

I agree with you on one point: we need a precise definition about when Netconf connection 
enters and leaves notification mode. This should be described both for the agent and the manager.
Balazs

Phil Shafer wrote:
> Balazs Lengyel writes:
> > [BALAZS]: I think the manager should assume that anything it sent before receiving 
> > replayComplete will be discarded.
>
> You can't make specs out of assumptions and living dangerously.  You
> need "MUST"s and "MUST NOT"s.  Otherwise, code that works against one
> conforming implementation will fail against another and no one will
> be clearly at fault.
>
> > You can still have a situation when the rpc request and replayComplete are sent at the 
> > same time, but if you like to live dangerously better have a timeout on the request.
>
> A timeout won't close the timing window that you've opened, it will just
> introduce another, possibly worse, one, since you have no idea how long
> any RPC will take.
[BALAZS]: Timeout was brought up by Andy as I remember.
> > As I see it discarding all requests is the best defined behavior we can prescribe.
>
> Discarding leaves you with simlar questions:
> - how will the server know when to stop discarding?
[BALAZS]: start discarding after the create-subscription was replied with OK. Stop discarding 
after the replayComplete was sent.
> - how will the client know what was discarded?
[BALAZS]: It should not send anything after create-subscription until the replayComplete or 
create-subscription-error is received. If it still does send something we are in the gray area. 
The client must be prepared for lost rpc-requests.
> So the facts seem to be:
> (a) the client can put the connection into "notification" mode
> (b) the server can put the connection into "rpc" mode 
>
> There's no way the server can discard content from the client, since
> it has no idea whether the content pre-dates the switch back into
> "rpc" mode.
>
> So is it worth _not_ allowing the server to put the connection
> back into "rpc" mode?
[BALAZS]: I can live with something like a tear_down of the connection, although an unusable 
connection left dangling is something I would not like.
> Thanks,
>  Phil

--
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: Balazs.Lengyel@ericsson.com

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