Re: notification-08 comments

[Phil Shafer <phil@juniper.net>]

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.

>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?
- how will the client know what was discarded?

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?

Thanks,
 Phil

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