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

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

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:

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" <trac@tools.ietf.org>
Subject: [Netconf] #9: notification replay in the future
Date: Sat, 28 Jul 2007 08:18:45 -0000


#9: notification replay in the future
---------------------------------------------+------------------------------
Reporter: ietf@andybierman.com | 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
������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: Balazs.Lengyel@ericsson.com

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