Re: notification-08 comments

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> 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.

I think it is more useful to assume the more robust scenario than the most
fragile one.  Some agents may process RPCs during the notification replay,
and this document (right now) has no way for the manager to know that.
That means the manager cannot possibly know for sure if it should
wait for a reply or not.

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


This is an artifact of TCP.
The bytes will be there as long as the connection (and/or session)
has not been dropped.

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

This is very implementation-biased.
Why is this the best, especially since the spec allows an agent
to process RPCs if it wants.

> Balazs

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