Re: notification-08 comments

[Andy Bierman <ietf@andybierman.com>]

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

<co-Chair-hat-on>
We need to decide this issue based on perceived features and risks
to the operation of the network.  The implementation argument is a wash.
One implementer says it would be hard not to accept the new <rpc>.
Another says the opposite.  A third says it's the same amount
of new code either way.

The manager needs a better way to tell what the agent will do
in this case than to send an <rpc> request and wait some
unspecified time for an <rpc-reply>.

There is no technical reason that interleaving of <rpc-reply> and <notification>
elements to the manager should be forbidden, and at the same time, the
WG does not want to require the agent to support this 'interleave mode'.

However, this 'special mode' design is messy, not well documented,
and some WG members don't like it much:

   1) normal mode (<rpc> and <rpc-reply> only)
   2) normal notification mode (live <notification> only)
   3) replay notification mode (replayed notifications only, then
        transition to 'normal mode' after <replayComplete> is sent)
   4) tail-f mode (replay-then-live notifications only)
   5) interleave notification mode (any of modes (2) - (4), except
      the agent will respond if the manager sends an <rpc> request)

The deterministic and inter-operable resolution to this issue
must be part of the document.  It is OK if specific behavior
is optional, as long as the manager can easily know what to expect.
</co-Chair-hat-on>

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


What exact edits are you proposing?


> Balazs

Andy

> 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


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