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

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Aug 2007 07:57:37 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 01 Aug 2007 17:03:53 +0200

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

Andy Bierman wrote:
>> I submitted the same comment as Dave in trac, but it seems that there 
>> is no email about updates to trac issues.
>>
>> Balazs
>>
> 
> Andy

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Aug 2007 08:09:32 -0700

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.

oops.
I agree that startTime in the future MUST be an error.

> And yes interleaving is complicated.

wrong ticket number... grrrr

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 01 Aug 2007 08:32:37 -0700

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

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 1 Aug 2007 12:14:14 -0400

Hi,

(Andy, do you plan to put interleaving into trac?)

For what it's worth, ISMS supports interleaving over its SSH
connections; the tunnel is a tunnel, and traffic is traffic. 

If an operator prefers to NOT interleave the ISMS traffic, for example
to ensure notifications aren't held up by large response messages,
they can configure their notifications to go over a different SSH
session by specifying a different port in the TARGET-MIB. 

ISMS doesn't have subscriptions and replay and other niceties as an
extension of the protocol; in SNMP such things would be handled
through data model manipulations rather than protocol extensions.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Wednesday, August 01, 2007 10:58 AM
> To: Balazs Lengyel
> Cc: David B Harrington; [email-masked]; [email-masked]
> Subject: Re: [Netconf] #9: notification replay in the future
> 
> Balazs Lengyel wrote:
> > Hello,

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 01 Aug 2007 23:16:58 +0200 (CEST)

> the document to support a 'cron' like feature, added at the

I don't know about WG consensus, but I think it's a good idea to
forbid a startTime in the future, to make things simpler.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 02 Aug 2007 15:50:29 +0200

Hello,
I proposed the simple rules:

startTime in future -> error
stopTime in future -> error
stopTime =< StartTime -> error
stopTime present and startTime absent -> error

The startTime must be in the past or must be absent.
The stopTime must be in the past, or just Now, or absent.

I think Andy's special value NOW for stopTime is a good idea.

Balazs

---

From: Phil Shafer <[email-masked]>
Date: Thu, 02 Aug 2007 13:59:16 -0400

>I think Andy's special value NOW for stopTime is a good idea.

IMHO it's generally better to make a new element than to
overload an existing one.  In JUNOS, we use the <recorded/>
element to indicate that we match on only recorded messages,
ending the RPC as soon as we see the end of recorded messages.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 02 Aug 2007 11:10:32 -0700

> ending the RPC as soon as we see the end of recorded messages.

But our data model doesn't work that way (yet).
This doesn't affect the startTime.  Wouldn't
the <recorded/> flag match everything in the notification log?

What if the <create-subscription> RPC used a 'choice'
instead of a 'union' for this parameter?
A choice of <now/> or <stopTime> can be used.
If the <now/> choice is used, the agent will generate
the <stopTime> from the current system time.

We ruled that the <recorded/> element was part of the
notification data model, just like <eventClass>.

Andy

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 31 Jul 2007 08:56:18 -0500

Hi all,

Regarding configuration of Trac, I can set it up so that all issue
changes is sent to the list without you needing to add the list to
the Cc: field.

There is however an issue at the IETF mail-server end also, which
have to be resolved -- at least 2 of the mails from Trac has
resulted in a delivery failure.  I'm going to try to find out exactly
why, and fix.

Assuming that's sorted out, should I configure the tracker to send
notification for all issue changes to the list?

Regards,

	Henrik

On 2007-07-31 04:34 David B Harrington said the following:
> Hi,
> 
> It appears to me that [email-masked] could be put into the CC: field
> when creating a new ticket, and then changes will be sent to the
> netconf list.
> 
> I will add an item so we can experiment with it to see if this works.
> 
> dbh
> 
>> From: David B Harrington [mailto:[email-masked]] 
>> Sent: Tuesday, July 31, 2007 5:20 AM
>> To: 'Balazs Lengyel'; 'Andy Bierman'
>> Cc: [email-masked]'; [email-masked]'
>> Subject: Netconf Issue Tracker - features
>>
>> Hi,
>>
>> Just so people on this list understand about trac...
>>
>> I had assumed that my email comments would be recorded in 
>> trac, since trac was included in the To: list of my email; 
>> apparently that does not happen.
>>
>> If I understand Balacz's comment, entering comments directly 
>> into the trac page records the comment in trac, but does not 
>> send an email to the WG showing the comment was made.
>>
>> I am getting a number of trac emails that have no content, 
>> just the title of the issue. I notice that Balacz responded 
>> to a previous message from Hideki, but I never saw a 
>> non-empty email from Hideki and his comment does not seem to 
>> be logged within trac.
>>
>> Maybe trac has some settings that can be modified to make 
>> sure comments are sent to the list, or the trac@ address logs 
>> comments. 
>>
>> Until we can learn about how to configure the tool better, to 
>> make sure the chairs have a clear record of comments, I 
>> recommend that everybody explicitly send their comments to 
>> the mailing list, and not count on trac to send the email for 
>> you. If you want your comment tracked in trac, then you 
>> should **also** go to the trac page and enter your comment 
>> using the web input tool.
>>
>> that's my suggestion.
>>
>> David Harrington
>> [email-masked]
>> [email-masked]
>>
>>
>>> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
>>> Sent: Tuesday, July 31, 2007 3:45 AM
>>> To: Andy Bierman
>>> I submitted the same comment as Dave in trac, but it seems 
>>> that there is no email about updates 
>>> to trac issues.
>>>
>>> Balazs
>>>
>>>
>>> Andy Bierman wrote:
>>>> David B Harrington wrote:
>>>>> Hi,
>>>>>
>>>>> MAY NOT or MUST NOT?
>>>> MAY NOT (IMO).
>>>> That's why it's an open issue ;-)
>>>>
>>>> Andy
>>>>
>>>>> David Harrington
>>>>> [email-masked]
>>>>> [email-masked]
>>>>>  
>>>>>
>>> [mailto:[email-masked]] 
>>>>>> On Behalf Of Netconf
>>>>>> Sent: Saturday, July 28, 2007 4:19 AM
>>>>>> Cc: [email-masked]
>>>>>> Subject: [Netconf] #9: notification replay in the future
>>>>>>
>>>>>> #9: notification replay in the future
>>>>>> ---------------------------------------------+----------------
>>>>>> --------------
>>>>>>  Reporter:  [email-masked]             |       
>>> Owner:          
>>>>>> Type:  defect                           |      Status:  new
>>>>>>  Priority:  major                            |   Milestone:
> 
>>>>>> Component:  draft-ietf-netconf-notification  |     Version:
> 
>>>>>>  Keywords:  notification replay              |  
>>>>>> ---------------------------------------------+----------------
>>>>>> --------------
>>>>>>  The startTime and/or stopTime parameters to the 
>>> create-subscription
>>>>>>  operation can be in the future.  This is unintended 
>> behavior that
>>>>>>  is not part of the original use cases for this feature.
>>>>>>
>>>>>>  Requiring the agent to replay notifications that have not
>>>>>>  happened yet is non-intuitive, and there is some ambiguity
>>>>>>  with the meaning of the <replayComplete> notification,
>>>>>>  and when it should be sent.
>>>>>>
>>>>>>  The text should be clear that the agent MAY NOT support
>>>>>>  startTime and/or stopTime values in the future.
>>>>>>
>>>>>> -- 
>>>>>> Ticket URL: <http://tools.ietf.org/wg/netconf/trac/ticket/9>
>>>>>> Netconf <http://tools.ietf.org/wg/netconf/trac/>
>>>>>> Issue tracker for the NETCONF Working
>>>>> Grouprzuzz?????rz))z?w&rz??w
>>>>>
>>>>>
>>>>>
>>>>> --

---

From: "Netconf" <[email-masked]>
Date: Mon, 06 Aug 2007 23:37:57 -0000

#9: notification replay in the future
----------------------------------------------+-----------------------------
  Reporter:  [email-masked]             |       Owner:                     
      Type:  defect                           |      Status:  new                
  Priority:  major                            |   Milestone:                     
 Component:  draft-ietf-netconf-notification  |     Version:                     
Resolution:                                   |    Keywords:  notification replay
----------------------------------------------+-----------------------------
Comment (by [email-masked]):

 The working group previously discussed and decided that replay in the
 future was a useful feature. This usefulness was confirmed in offline
 discussions in Chicago. The only issues was that the name no longer fit.
 Where does this come from?

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netconf/trac/ticket/9#comment:2>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Grouph�{.n�+���zwZ��,j��w�r�߭�z�h�Ȟ��+����^ݺ{.n�+�����"�	^�)�j�azg�����mn�rj�!�������l��_��?�+-��޵�'

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Aug 2007 17:52:09 -0700

> #9: notification replay in the future

The issue was not really understood before the latest WG meeting.
  - There is concern that this is a different feature than
    getting notifications from the internal notification log,
    and turning into something more like the 'cron' or 'at' command.
  - There is a concern that this forces the agent to treat notifications
    in the future as if they were replayed.
  - There is confusion about when to send the <replayComplete> notification.
    Is is sent after the last buffered notification (at the time the
    <create-subscription> is received) or is it sent after the last live
   (replayed) notification that occurs around the <stopTime>?
  - There is concern that asking for replay notifications that have not
    happened yet is confusing.
  - There is concern that this document is already a year late and
    the extra time it would take to get this new feature correctly
    documented is not worth the effort.
  - There is concern that the 'replay in the future' feature is
    just a by-product of the data model design, and not a real feature at all.
    There does not seem to be a real use case for this feature.
    Why wouldn't the manager just wait an hour to send the
    <create-subscription>, rather than say "send me the replay notifications,
    but wait an hour before starting".  Why would the manager tie up
    a session (which cannot do anything for an hour)?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 07 Aug 2007 05:34:20 -0700

Andy Bierman wrote:
>> Owner:                           Type:  
>> defect                           |      Status:  new                  
>> Priority:  major                            |   
>> Milestone:                      Component:  
>> draft-ietf-netconf-notification  |     Version:                     
>> Resolution:                                   |    Keywords:  
>> notification replay

I think the issue is what the agent actually does when it gets
startTime and/or stopTime in the future.

If the agent simply uses these timestamps to determine which
notifications CURRENTLY IN ITS REPLAY BUFFER apply to the request.
If the manager asks for notifications from time A to time B,
(at time C) then the only thing that matters are the notifications
in the internal buffer at time C.

So asking for replays from the future would immediately return
the <replyComplete> since there are none in the log at time C
that match the search criteria.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 13 Aug 2007 15:38:26 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Wednesday, August 01, 2007 11:33 AM
To: Balazs Lengyel
Cc: David B Harrington; [email-masked]; [email-masked]
Subject: Re: [Netconf] #9: notification 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.

Andy

>> 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.
>> 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 [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Aug 2007 13:00:43 -0700

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

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

Andy