Hi Martin,
After reflecting on this for a bit, I am ok with your argument that if the system is quickly generating notification-messages, then the replay buffer might be continuously emptying. And therefore a hint for replay start time might not be accurate for very long. As a result, it is better to start the replay immediately with the oldest buffered event.
I have updated the establish-subscription RPC as follows. Does this cover your concern (per this sub-thread)?
rpc establish-subscription {
input { }
output {
leaf identifier { }
leaf replay-start-time {
if-feature "replay";
type yang:date-and-time;
description
"If a replay has been requested, this represents the
earliest time covered by the event buffer for the requested
stream. The value of this object is the
'replay-log-aged-time' if it exists. Otherwise it is the
'replay-log-creation-time'. All buffered event records
after this time will be replayed to a receiver. Note that
this object will only be sent if the 'replay-start-time' is
later than the time requested by the subscriber.";
}
}
}
If you are ok, I will spread the change through the rest of the document.
Eric
> "Eric Voit (evoit)" <evoit@xxxxxxxxx> wrote:
> > > From: Martin Bjorklund, March 23, 2018 7:37 AM
> > >
> > > Hi,
> > >
> > >
> > > "Eric Voit (evoit)" <evoit@xxxxxxxxx> wrote:
> > > > Hi Martin,
> > > >
> > > > > From: Martin Bjorklund, March 16, 2018 4:19 AM
> > > > >
> > > > > Hi,
> > > > >
> > > > > Andy Bierman <andy@xxxxxxxxxxxxx> wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > 2.4.2.1. Replay Subscription
> > > > > >
> > > > > > If the "replay-start-
> > > > > > time" contains a value that is earlier than content stored within
> > > > > > the
> > > > > > publisher's replay buffer, then the subscription MUST be
> rejected,
> > > > > > and the leaf "replay-start-time-hint" MUST be set in the reply.
> > > > > >
> > > > > > >> this is a significant and bad change from RFC 5277 behavior
> > > > > > >> the start-time says "send all events that you have stored
> > > > > > since this time" The server sends its oldest event and does
> > > > > > not reject the request. This draft incorrectly interprets
> > > > > > the request as "the server MUST have an event stored at least
> > > > > > this old"
> > > > >
> > > > > I agree, and I have pointed this out in earlier reviews.
> > > >
> > > > In our past discussions, it looked like you were ok after reading
> > > > Yves requirement here:
> > > >
> > > > https://www.ietf.org/mail-
> archive/web/netconf/current/msg12154.htm
> > > > l
> > > >
> > > > Beyond this functional requirement, the design pattern used is
> > > > that an establish-subscription RPC must send the exact parameters
> > > > accepted by the publisher.
> > > >
> > > >
> > > > > If a client sends a too early time, and the server doesn't send
> > > > > the optional hint, the client will have to guess the time. Not
> > > > > very robust.
> > > > >
> > > > > If the motivation is that the client should be informed that he
> > > > > might have missed some notifs b/c the replay-start-time is too
> > > > > early, this information can be passed in the rpc-reply from
> > > > > establish-subscription instead.
> > > >
> > > > Yes this could be done. But this doesn't follow the design
> > > > pattern of making the client explicitly ask for what they want.
> > > > Consistent design patterns do matter.
> > >
> > > Well, "what they want" depends on the semantics of this leaf! If we
> > > keep the old semantics, then if the client passes this parameter
> > > with some start time, it "explicitly asked for what it wanted".
> > >
> > > Anyway, if the objective is to ensure that no notifs are sent unless
> > > the replay-start-time exactly matches the event-time of a
> > > notification in the buffer, then we can add a parameter to ensure
> > > that.
> >
> > The current definition of replay-start-time is:
> >
> > "Used to trigger the replay feature and indicate that the replay
> > should start at the time specified..."
> >
> > To me, that means the replay-start-time has to be covered by the scope
> > of the replay buffer. It does not mean that it is required that the
> > requested replay-start-time needs to exactly match the time of a
> > buffered event.
>
> The text is quite unclear:
>
> Used to trigger the replay feature and indicate that the
> replay should start at the time specified.
>
> and:
>
> If the "replay-start- time" contains a value that is earlier than
> content stored within the publisher's replay buffer, then the
> subscription MUST be rejected
>
> In lack of a clear definition, I assume that "content stored [in] replay buffer"
> refers to event records, since I assume that nothing else can be stored in
> the replay buffer?
>
> Next question is what it means that a time value is earlier than "content"?
> Again, my assumption is that it means "earlier than the 'eventTime' of the
> event records". Is this not what is intended?
>
> From what you write here though, I think that what you propose is
> that:
>
> If "replay-start-time" is less than the latest of
> "replay-log-aged-time" and "replay-log-creation-time", then the
> request is rejected.
>
> This must be clarified. Also, ensure that the required behavior is clearly
> defined in the YANG module, and not just in the text in the document.
>
> But I still think that there should be some way for the client to get all
> buffered event records, just like what was supported in RFC 5277, without
> extra round trips. Note that if the system is quickly generating notifs, the
> client might need many round trips before it manages to replay anything.
>
>
> > > In all cases, if the client receives a notif with a time later than
> > > what it asked for, it knows that it might have lost some notifs.
> >
> > Why would this mean it might have lost some notifs? In the current
> > embodiment, the replay will not start unless the subscriber asked for
> > a time that is within the scope covered by the buffer. I.e., a time
> > later than both "replay-log-creation-time" and "replay-log-aged-time".
>
> See above. But the reason for rejection is that the client might have lost
> some notifs.
>
> > > leaf replay-exact-start-time {
> > > if-feature "replay";
> > > when "../replay-start-time";
> > > type empty;
> > > description
> > > "If this parameter is present, and the server does not have any
> > > stored event record with 'eventTime' equal to the requested
> > > 'replay-start-time', then the server MUST reject the request.";
> > > }
>
> If we add something like this, the leaf name and description text needs to
> be tweaked for the clarified semantics of replay-start-time.
>
> > Something like this parameter *might* be applicable if we choose to
> > respond to a dynamic replay request with events later than those
> > requested. (i.e., in the establish-subscription success response.) As
> > noted in other threads, this is a legitimate way to approach the
> > issue. However if the WG chooses this way, this will result in an
> > exception to the design pattern of requiring the subscriber to ask for
> > what they are going to receive.
>
> I disagree. The client explicitly asks the server to send all buffered event
> records.
>
> > In addition, we might end up sending a stream of information to the
> > subscriber which is not sufficient, and therefore not verifiably
> > relevant.
>
> It is up to the client to define what is relevant. Maybe I just want to view
> the replay buffer for trouble shooting purposes.
>
>
>
> /martin
