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

Re: replay as <get>

Phil Shafer wrote:

"David B Harrington" writes:

This way replay becomes a
data-model-specific thing, not an operation extension, and the
notification operation is vastly simplified.


Isn't making replay data-model specific worse, since this will lead
to <n> different ways of doing it?


I think Dave means the WG would have to create a specific data model
to represent the control knobs and the data logs.  This is arguably
less work than what the WG already did for the embedded replay feature
within the <create-subscription> operation.

The feature in the spotlight here is the ability for a manager
to start listening for live notifications 'now', but after it 'catches up'
with any notifications of interest that occurred before 'now',
instead of concurrently listening for new notifications and
retrieving the missed notifications with <get>.

IMO, this is not the same feature as a notification log, it's better
(for the manager).  But a notification log would be just as interoperable.




Thanks,
 Phil


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