[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netconf] #9: notification replay in the future
Sharon Chisholm wrote:
Hi
Actually, the document as currently written supports replay in the
future and requires no changes to continue to do so. (With the possible
exception of the fact the name is inappropriate). A change is required
to forbid start and stop times in the future.
I will have to look at -09 when it comes out, but -08
has details unspecified which raised interoperability concerns.
My big concern is that there seem to be a number of issues the working
group is changing its mind on and I'm running out of editing chocolate.
We have not even started the AD review, IESG review, and IETF Last Call yet.
Standards consensus is a fluid process. As more details are understood,
and and more clarifications needed, sometimes facts come to light which
made previously agreed-upon compromises unworkable, or previously
discarded compromises relevant again.
Sharon
Andy
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, August 01, 2007 11:33 AM
To: Balazs Lengyel
Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org
Subject: 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/>
--
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/>
--
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/>