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

["Sharon Chisholm" <schishol@nortel.com>]

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.

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.

Sharon 

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