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

[Andy Bierman <ietf@andybierman.com>]

Andy Bierman wrote:
> Netconf wrote:
> > #9: notification replay in the future
> > ----------------------------------------------+----------------------------- 
> >
> >   Reporter:  ietf@andybierman.com             |       
> > Owner:                           Type:  
> > defect                           |      Status:  new                  
> > Priority:  major                            |   
> > Milestone:                      Component:  
> > draft-ietf-netconf-notification  |     Version:                     
> > Resolution:                                   |    Keywords:  
> > notification replay
> > ----------------------------------------------+----------------------------- 
> >
> > Comment (by schishol@nortel.com):
> >
> >  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?

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

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