Thanks Andy. I had missed that line in Linda's email.
I agree with Andy. As I understand the WG agreements, ephemeral state has nothing to do with the presence or absence of a connection to the I2RS client which provided the state. The ephemeral aspect is strictly about whether the state survives reboot of the device with the I2RS Agent (there is some ambiguity / flexibility about the case where the I2RS Agent reboots without the device itself rebooting, which we should be clear about.)
While the document title may be narrower than its scope (often the case with IETF documents) it is important that we get protocol mechanisms which deal with the priority as well as the ephemeral aspects. I see no benefit in having two separate documents to discuss them.
Yours, Joel On 7/18/15 10:55 PM, Andy Bierman wrote:
Hi, very interesting comments... I agree these are requirements that could apply to more than I2RS. The first-one-wins (via client priority) details could apply to configuration as well as ephemeral state, and I wonder if NETCONF should be changed to support it. I don't agree that a lost connection caused all the state for that client to disappear. In NETCONF, it is generally only the edits in progress that are tossed. Since I2RS will not use a candidate config, these multi-PDU edits should not be possible in I2RS. I agree that the "access" procedures for ephemeral state can be separated from "multi-head" procedures, but they are somewhat coupled. I think the arch. doc mentioned parameters sent with an edit to ask for a notification if the edit is rejected because higher priority data already exists (notify me when my edit might work). It seems multi-head control is mandatory to support. Andy On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar <[email protected] <mailto:[email protected]>> wrote: __ __ Sue and Jeff, ____ __ __ There have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wasting your time. ____ ____ __ __ I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about the “multi-headed control of a I2RS agent”.____ __ __ IMHO, the “I2RS-ephemeral-state” should be addressed separately from “multi-headed control”, because for networks that only use single controller, they don’t have to deal with the complicated scheme of multiple controllers, but they do need to conform to the “ephemeral-state” via I2RS interface. ____ __ __ “I2RS-ephemeral-state” should be simply:____ - all commands from I2RS interface are ephemeral, i.e. they do not sustain restart, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost. ____ __ __ __ __ The Multi-headed control scheme described in the draft can also be applied to persistent configuration. ____ __ __ __ __ draft-ietf-i2rs-ephemeral-state-00 introduced a new “ephemeral-config” to NETCONF, does it mean that if I2RS client uses regular “config” instead of “ephemeral-config”, the configuration becomes persistent? It shouldn’t, in my opinion. ____ __ __ __ __ Linda Dunbar____ __ __ _______________________________________________ i2rs mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
