Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11

["Eric Voit (evoit)" <[e-mail]>]

Works for  me

Eric:

For version -13, the following  changes will be made:

   Pub-Sub-REQ-01: The Subscription Service MUST support
   subscriptions against ephemeral state in operational data stores, configuration data stores or both.

   Pub-Sub-REQ-02: The Subscription Service MUST support filtering
   so that subscribed updates under a target node might publish only
   ephemeral state in operational data or configuration data, or publish both
   ephemeral and operational data.


Ephemeral-REQ-12:
Will have the following text after it

   Note:RESTCONF and NETCONF posts can come in concurrently from alternative sources
   (see  ETag in <xref target="draft-ietf-netconf-restconf"></xref> section 3.4.1.2 usage).
   Therefore the collision detection and comparison of priority needs to occur both
   for both type of updates (POST or edit-config) at the point of comparison.

Does this resolve your comments?

Sue

From: i2rs [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, June 30, 2016 3:38 PM
To: Susan Hares
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [i2rs] Review of draft-ietf-i2rs-ephemeral-state-11

From: Susan Hares, June 30, 2016 3:13 PM
Eric:

Thank you for your comments:  See comments below.

Sue

From: i2rs [mailto:[e-mail]] On Behalf Of Eric Voit (evoit)
Sent: Thursday, June 30, 2016 2:52 PM
To: Susan Hares
Cc: [e-mail]<mailto:[e-mail]>
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