Re: notification-08 comments

[Andy Bierman <ietf@andybierman.com>]

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

You have exposed both sides of the issue:

1) What must/should/may an agent do with <rpc> input
   received while it is sending notifications?

[I agree with you that the agent must not discard this input.]

2) Should the corner-case where a stop time is given be handled
   by transitioning (silent or otherwise) from the 'sending replayed
   notifications' mode back to 'normal mode', or should it be
   handled the same way as when stop time is not provided
   (tail -f mode), by waiting for the manager to close the session?

[I share your concerns about this silent mode transition.
I would rather decide based on use cases rather than perceived
implementation complexity.  If we did as you suggest, then an
agent implementation is not forced to deal with any 'backed up' <rpc>
requests, but at some loss of functionality.  This mode
(get replays from time A to time B) could be viewed as just
another RPC operation like <get>.]


> Thanks,
>  Phil

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