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

From: "Netconf" <[email-masked]>
Date: Sat, 28 Jul 2007 08:18:45 -0000

#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 Group-��칻�&ޱ��jg�����޵�'~����-��"z��"�a{
+v�칻�&ފv��x%zX�y�-�鞲Ơzױ��ɪ܆+ކ�i��)�'�~���X����z�(��

---

From: "Netconf" <[email-masked]>
Date: Mon, 30 Jul 2007 16:08:24 -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]):

 We should use MUST NOT instead of MAY NOT. We never want a replay of the
 future.

-- 
Ticket URL: <http://tools.ietf.org/wg/netconf/trac/ticket/9#comment:1>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Group������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w�

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 30 Jul 2007 17:45:33 -0400

Hi,

MAY NOT or MUST NOT?

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

> -----Original Message-----
> From: [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
> 
> Issue tracker for the NETCONF Working
Grouprzuzz?????rz))z?w&rz??w

--
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, 30 Jul 2007 15:01:32 -0700

> MAY NOT or MUST NOT?

MAY NOT (IMO).
That's why it's an open issue ;-)

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 30 Jul 2007 18:20:15 -0400

Hi,

If the reason this is being discussed is 
> >>  and when it should be sent.

Then won't the same problem exist if some implementation supports
this?
Won't it be potentially more ambiguous if different implementations do
it differently? 

I think the WG should clarify how it is done, or make it an error to
specify a StartTime in the future. 

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

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Monday, July 30, 2007 6:02 PM
> To: David B Harrington
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Netconf] #9: notification replay in the future
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 30 Jul 2007 16:09:44 -0700

> specify a StartTime in the future. 

What? You don't want to let me punt on third down? ;-)

Of those very legitimate choices, I think it must be an error
if startTime is in the future, according to the agent's notion of time.

Andy

---

From: OKITA Hideki <[email-masked]>
Date: Tue, 31 Jul 2007 15:27:36 +0900 (JST)

Hi,

For the clarification of the replay feature,
I send my understanding of expected behavior for
each available set of startTime/stopTime.

   #| startTime | stopTime | expected behavior of devices
   -+-----------+----------+---------------------------------
   1| future    | future   | Reserve replay.
   2| future    | none     | Reserve continuous replay.
   3| past      | future   | Start at once, stop at future.
   4| past      | none     | Start continuous replay at once.
   5| past      | past     | Start replay.
   6| none      | *        | Not valid. Ignored.

If we remove "reservation" from the replay feature,
a startTime:future subscription should be error.

Regards,

Hideki Okita

From: "Netconf" <[email-masked]>
Subject: [Netconf] #9: notification replay in the future
Date: Sat, 28 Jul 2007 08:18:45 -0000

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 Group
������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w�

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 31 Jul 2007 09:41:08 +0200

Hello,
I thought we are designing a replay function not a scheduled notification delivery function. I 
do not see the usecase for scheduling notification sending and putting the burden of the 
scheduling on the agent.

I would rather go for a simple solution.
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.

Balazs

OKITA Hideki wrote:
> ������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)��b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w�

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

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 31 Jul 2007 09:45:12 +0200

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

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:
>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of Netconf

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 Jul 2007 05:19:34 -0400

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
> Cc: David B Harrington; [email-masked]; [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 31 Jul 2007 05:34:17 -0400

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,
> 
> 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]
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 Jul 2007 09:23:55 -0700

Henrik Levkowetz wrote:
> 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?
> 

I think people misinterpreted my original comment about
using the tracker as intended.  I meant that instead of
reviewing a draft by submitting a long email to the WG mailing list,
enter the issues one at a time into the tracker.

IMO, the WG should discuss the issues on the mailing list
and then the ticket updated by a WG member or the
administrator as needed.

> 	Henrik

Andy

> 
> 
> On 2007-07-31 04:34 David B Harrington said the following:
>> Hi,
>>