From: Susan Hares, June 30, 2016 3:13 PM Eric:
Thank you for your comments: See comments below. Sue From: i2rs [mailto:[email protected]] On Behalf Of Eric Voit (evoit) Sent: Thursday, June 30, 2016 2:52 PM To: Susan Hares Cc: [email protected]<mailto:[email protected]> Subject: Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11 >Comment #2 >Isn’t all data in Operational data stores ephemeral? I see the mailing list >discussions on this terminology topic for the requirements earlier in the >document. This is where you said: “Ephemeral state is defined as "ephemeral >configuration state" and operational state.” But the >terminology fix doesn’t >seem to have made it down here. Sue: We thought this was more specific. I can change it to “Ephemeral state”. Eric: consistency with higher requirements makes sense. Pub-Sub-REQ-02: Comment #3: >Building off Comment #2, is there such a thing as Ephemeral data in >Operational data? Or are you talking filtering so that only changes in >Operational data are sent. I believe you are intending the second. In that >case there might need to be special types of filters >needed. Filters such as >a count of the number of objects under a tree (e.g., number of routes), or >range based filters for an operational value. Sue: We have ephemeral data models with operational state. Technically, the data is both ephemeral (under an ephemeral model) and operational state. The difficulty is that this conflicts with some data models. Eric: I understand now. As an aside comment, the types of filtering needed will be varied and complex. They will need to be specified later, and should directly correspond with the filters which we need to support via in draft-ietf-netconf-yang-push. Section 2, Bullets 5 & 9 and Section 7: >Priority Collision. Could you explicitly say when the priority of one write >will prevent a lower priority write from occurring? Is it the completion of >and response to some POST? I don’t know what time-of-use means. > In RESTCONF, the updating process will check the priority of the existing write. This check will occur at least the completion of the POST for an over-write of an existing post. Since the RESTCONF posts are not simultaneous (but rather 1 at a time), the check will occur a single write. In NETCONF, this will be at edit-config stage. Both of these stages were defined as “time of use” – because it was when the update was to occur. Eric: I think it is possible that RESTCONF and NETCONF posts can come in concurrently from alternative sources. I think detecting this is one of the purposes of ETag in draft-ietf-netconf-restconf-13 section 3.4.1.2. It might be worth have the requirement state that priority must be considered for both completed ephemeral posts, as well as posts in progress. /Eric Do you have an alternate suggestion? Eric
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
