[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] #9: notification replay in the future

Balazs Lengyel wrote:

Hello Andy,
My mail was about replay in the future not interleaving. There I vote for "the client MUST NOT" support replay in the future. 
And yes interleaving is complicated.


IMO, there is WG consensus that startTime in the future MUST be
an error.  The alternative is to rewrite major portions of
the document to support a 'cron' like feature, added at the
last minute.

The current replay feature needs to be as simple as possible
so it will be more inter-operable.  There needs to be complete and precise
definitions of as much behavior as we can anticipate.


Balazs


Andy



Andy Bierman wrote:

Balazs Lengyel wrote:

Hello,
I vote for MUST NOT. Why complicate things. Will it bring us anything?



Things are complicated either way.
First, what are the choices?

  1) require interleaving MUST be supported by the agent
  2) allow interleaving to be supported by the agent,
     but just warn that the manager SHOULD NOT interleave
     and the agent MAY NOT accept interleaved requests.
  3) allow interleaving to be supported by the agent,
     based on the '#interleave' capability,
     and also warn that the manager SHOULD NOT interleave
     and the agent MAY NOT accept interleaved requests.
  4) require interleaving MUST NOT be supported by the agent
     - what happens when the manager sends an <rpc> anyway?
       a) close session
       b) ignore request
       c) send operation-failed response

What are the benefits?

There obvious benefit from allowing interleaving,
if you believe sessions are expensive -- it saves an extra session
on both the manager and the agent.

The real benefit is that <close-session> is a the cleanest way
to terminate sessions, and it should be used in all modes.
The <kill-session> and drop connection methods are both bad ideas.

It would also be a HUGE CLR to forbid interleaving completely.
In the future, some new feature will come up that will make it
clear the agent should never be in a mode it MUST stop listening
to all input from the client.  It will be clear then (if not now)
that this is a really bad idea.

So what are the benefits of forbidding interleaving completely,
and what happens if the manager sends an <rpc> anyway?
I submitted the same comment as Dave in trac, but it seems that there is no email about updates to trac issues. 

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