Re: notification-08 comments

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

See below!
Andy Bierman wrote:
> Balazs Lengyel wrote:
> > Hello
> >
> > Andy Bierman wrote:
> > > 3.3.2, para 3:
> > >
> > >    A replayComplete notification is sent to indicate that all of the
> > >    replay notifications have been sent.
> > >
> > > Use 'replayComplete' or <replayComplete>.
> > >
> > >    becomes a normal NETCONF session again.
> > >
> > > Indicate that the agent will now accept <rpc> operations.
> > > Any requests which have been received but not processed by
> > > the agent will now be processed in the order they were received.
> > [BALAZS]: Buffering earlier received <rpc> operations for a 
> > potentially long time seems bad. I would prefere discarding all <rpc> 
> > operations before <replayComplete> and accepting only new <rpc> 
> > operations.
>
> How does the agent know the next <rpc> just arrived or has been
> in queue for an hour.  Isn't this implementation-dependent?
> Wording it the other way (flush the queue) is also 
> implementation-dependent.
>
> But the other way, the manager would get no indication the <rpc> 
> elements were
> dropped.  It would wait for replies, and the agent would
> wait for a new <rpc> -- and the session would hang.
>
> > Balazs
>
> Andy
[BALAZS]: I think the manager should assume that anything it sent before receiving 
replayComplete will be discarded. It should not even send anything before that in the first 
place. 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.

On the other hand if the agent may store requests that arrived before the replayComplete was 
sent you end up with a lot of other questions:
- how long must an agent store rpc requests? 1 year?
- how many requests must it store?
- if the agent is not able to store all requests, it drops some. How will the manager know how 
many have been dropped?

As I see it discarding all requests is the best defined behavior we can prescribe.

Balazs

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