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

["David B Harrington" <dbharrington@comcast.net>]

Hi,

If the reason this is being discussed is 
> >>  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.

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
dbharrington@comcast.net
ietfdbh@comcast.net

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Monday, July 30, 2007 6:02 PM
> To: David B Harrington
> Cc: trac@tools.ietf.org; netconf@ops.ietf.org
> Subject: Re: [Netconf] #9: notification replay in the future
> 
> David B Harrington wrote:
> > Hi,
> > 
> > MAY NOT or MUST NOT?
> 
> MAY NOT (IMO).
> That's why it's an open issue ;-)
> 
> Andy
> 
> > 
> > David Harrington
> > dbharrington@comcast.net
> > ietfdbh@comcast.net
> >  
> > 
> >> -----Original Message-----
> >> From: owner-netconf@ops.ietf.org 
> >> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Netconf
> >> Sent: Saturday, July 28, 2007 4:19 AM
> >> Cc: netconf@ops.ietf.org
> >> Subject: [Netconf] #9: notification replay in the future
> >>
> >> #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
> > Grouprzuzz?????rz))z?w&rz??w
> > 
> > 
> > 
> > --
> > 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/>