Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:What if the stopTime in the future happens before the agent is done sending the replay notifications?Nothing special, since the stopTime just means that the agent is supposed to send all notifications that were generated before that time. When that's done (whenever that happens) it reverts to normal mode.
This seems like more trouble to implement than it is worth. I think I am not the only one that does not see a need to expand the replay feature into something that requires the agent to treat each corner case differently. The simple case -- the start to stop interval represents log entries -- seems to be getting WG consensus. I have not heard much support for applying stopTime-in-the-future as an additional mechanism to transition to live notifications but stop after some of them. I think WG consensus is converging on the idea that the replay feature applies only to logged entries that exist when the <create-subscription> is received. I also think WG consensus is converging towards allowing interleaving. I do not know yet if there is consensus that an agent MUST support <close-session> in notification mode, even if no other operations are supported. I think only one person wants to make sure the agent MUST NOT accept any interleaved RPCs. There seems to be consensus that this option is not what the WG wants. I think the "manager SHOULD NOT send, and the agent MAY NOT process" language is not inter-operable and does not allow for <close-session>. This is very important text, so we have to keep working on it until it is right.
/martin
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/>