On Wed, May 25, 2016 at 05:59:54PM -0400, Susan Hares wrote: > Juergen: > > > > Thank you for your comments on the ephemeral state. > > > > On Ephemeral-REQ-05, does this clarify the requirement: > > > > Ephemeral-REQ-05: The ability to add on an object (or a hierarchy of > objects) that have the property of being ephemeral. An object defined as > Yang module, > > schema tree, a schema node, submodule or components of a submodule (derived > types, groupings, data node, RPCs, actions, and notifications).
I have no clue what the above sentence is trying to say. Please try to use YANG terminology. > Any ephemeral object must be able to be identified by a yang key word. Why does there have to be a YANG keyword? > On Ephemeral-REQ-06, does this text restrict the definition to just > requirements: > > > > "Ephemeral-REQ-06: Yang MUST have a way to > > indicate in a data model that nodes have the following > > properties: ephemeral, writable/not-writable, status/configuration, > > and secure/non-secure transport. > > (If you desire examples, please see draft-hares-i2rs-protocol-strawman for > > potential yang syntax). " We do have config true/false this implies writable/not-writable. I find the idea strange that a data model defines secure/non-secure transport as a property of an data model definition since it usually depends on the deployment context whether it is acceptable to carry data over a non-secure transport. > On Ephemeral-REQ-07, NETCONF chairs asked for conceptual changes to NETCONF > and RESTCONF. Does change to Ephemeral-REQ-07 requirement set work for you? > If it does, I will create a similar reduction for Ephemeral-REQ-08: > > --------- > > Ephemeral-REQ-07: The bundle of conceptual changes to NETCONF to required to > support the I2RS protocol are the following: > > 1) protocol version support for I2RS protocol modifications - (e.g. I2RS > version 1); I do not understand what this is supposed to mean since NETCONF extensions usually are identified by a capability URN. So why is there a need for something else? > 2) support ephemeral model scope indication - which indicates whether a > module is ephemeral only, mixed config module (config with ephemeral), mixed > derived state (ephemeral and config), Not sure what this means. > 3) multiple message support - uses the I2RS "all or none" > (ietf-i2rs-architecture, section 7.9) which is the same as the NETCONF > "roll-back-on-error". So what is the requirement here? > 4) Support for the following NETCONF protocol specifications: > > NETCONF [RFC6241], > > yang pub-sub push [draft-ietf-netconf-yang-push], > > Yang module library [draft-ietf-netconf-yang-library], > > call-home support [draft-ietf-netconf-call-home], > > zero-touch support [draft-ietf-netconf-zero-touch], and > > server model [draft-ietf-netconf-server-module] with Why do you list this under changes to NETCONF? > 7) The ability to restrict insecure transports to specific portions of a > data model marked as valid to transfer via an insecure protocol, See above. > 8) ephemeral overwriting of ephemeral MUST be controlled by the following > two policy knobs (draft-ietf-i2rs-architecture, section 6.3, 6.3.1): > > * Policy Knob 1: ephemeral configuration overwrites local configuration > (normal value: true) > > *Policy Knob 2: update of local configuration value supersedes and > overwrites the ephemeral configuration value (normal value: false) And if I set both to true we run into a race? I am stopping here. I do not even understand why we need yet another list of requirements that just rephrase requirements already written down in other documents. What is the goal of this exercise? /js > 9) The ephemeral state overwriting a local configuration described in 8) > above is considered to be the composite of all ephemeral state values by > all clients. Some may consider this a single "pane of glass" for the > ephemeral values. You seem to assume a certain architectural model and it is unclear whether there is agreement on this model. There is ongoing discussion about this, see for example draft-schoenw-netmod-revised-datastores-00. > 10) The ephemeral state must support notification of write conflicts using > the priority requirements (see section 3.7 below, specifically requirements > Ephemeral-REQ-09 through Ephemeral-REQ-14). > > > > 11) Ephemeral data stores SHOULD not require support for interactions with > writeable-running, candidate data stores, confirmed commit, and a distinct > start-up capability. > > > > ========== > > > > On Ephemeral-09, this is covered in SEC-REQ-01. Section 3.7.1 was added as > explanation. It will be moved to the protocol-security-strawman. > > > > On Ephemeral-09 (second instance): is an extension of SEC-REQ-07 and > SEC-REQ-08. Will this change to Ephemeral-09 work for you? > > > > "Ephemeral-REQ-09: The data nodes MAY store I2RS client identity and not the > effective priority at the time the data node is stored. Per SEC-REQ-07 in > section 3.1 of [draft-ietf-i2rs-protocol-security-requirements], an > identifier must have just one priority. Therefore, the data nodes MAY store > I2RS client identity and not the effective priority at the time the data > node is stored. Priority MAY be dynamically changed by AAA protocols and > how the protocol handles the revision of a client's priority SHOULD be > defined by the protocol specification as long as the collisions are handled > as described by Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12." > > > > To your questions of repetition in Ephemeral-REQ-10, Ephemeral-REQ-11, > Ephemeral-REQ-12: Ephemeral write collisions utilize SEC-REQ-07 which > defines that an identifier MUST have only one priority. Ephemeral write > collisions are related to role-based data model security > (draft-ietf-i2rs-protocol-security-requirements, section 3.5), but only > SEC-REQ-19 underscores the use of "one identifier with one priority" in the > use of a I2RS client by multiple applications. You may be recalling input > from the I2RS-architecture document. > > > > On Ephemeral-REQ-13: This requirement has an explanation that I would like > to keep because the requirement has been misunderstood repeatedly in both > groups. Since this requirement represents to summation of the NETCONF/I2RS > sessions, I prefer to keep this requirement and ask the WG for input. > > > > > On the Pub-sub requirements: > > I will remove all pub-sub-requirements and add the following: > > > > 1) Pub-Sub-REQ-01: The Subscription Service MUST support subscriptions > against ephemeral data in operational data stores, configuration data stores > or both. > > 2) Pub-Sub-REQ-02: The Subscription Service MUST support filtering so > that subscribed updates under a target node might publish only ephemeral > data in operational data or configuration data, or publish both ephemeral > and operational data. > > > > > Sue > > > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, May 17, 2016 2:24 PM > To: Jeffrey Haas > Cc: [email protected] > Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt > > > > On Tue, May 17, 2016 at 12:26:35PM -0400, Jeffrey Haas wrote: > > > Jürgen, > > > > > > On Fri, May 06, 2016 at 09:34:45AM +0200, Juergen Schoenwaelder wrote: > > > > I have a hard time with this document. Section 3 is labelled > > > > requirements but it actually details solution and I disagree with a > > > > significant number of the solution elements. > > > > > > If you were to restrict your comments to the requirements labeled > variously: > > > Ephemeral-REQ-XX > > > PubSub-REQ-X > > > > > > do you consider the items sufficiently well described to be a > > > requirements document? > > > > Mostly: > > > > - I do not understand what Ephemeral-REQ-05 is trying to say. > > > > - I disagree with Ephemeral-REQ-06 and section 3.4.1 all sounds like > > solution attempts (to which I do not agree). > > > > > > - I disagree with Ephemeral-REQ-07 and all of section 3.5 and > > subsections; this is not a requirement but an attempt to describe a > > solution. > > - I disagree with Ephemeral-REQ-08 and all of section 3.5 and > > subsections; this is not a requirement but an attempt to describe a > > solution. > > > > - Has Ephemeral-REQ-09 (the first one) not been stated elsewhere > > already? > > > > - Ephemeral-REQ-xx with xx >= 09 and xx <= 13 seem repetitions from > > requirements already stated elsewhere? > > > > - I did not understand section 3.7.3 and I am unsure what > > Ephemeral-REQ-13 or more specifically whether it is different from > > what is already stated in the requirements. I have trouble parsing > > some of the sentences, e.g. > > > > [...] I2RS notes multiple operations in one or > > more messages handling can handle errors within the set of operations > > in many ways. > > > > - I do not understand PubSub-REQ-1; what is the difference between > > synchronous and asynchronous push? > > > > - I may disagree with PubSub-REQ-2 but then I do not know what 'real > > time for notifications' means. > > > > - I may disagree with PubSub-REQ-3. > > > > - I do not understand what PubSub-REQ-4 means; what is a 'critical > > node event'? How do I decide this requirement has been met? > > > > - PubSub-REQ-5 seems to mix up different issues. I do not know what a > > hierarchy of filters of XPATHs is. > > > > - PubSub-REQ-6 is likely underspecified. > > > > Overall, I do not understand why we need these additional requirements given > that we have draft-ietf-i2rs-pub-sub-requirements-08.txt. > > > As Sue mentioned, we can migrate solution-space discussion wholly into > > > the strawman document. > > > > In general, it would help me if you make an effort to reduce the number of > documents and if you make an effort to avoid document overlaps. Sometimes > less is more. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < <http://www.jacobs-university.de/> > http://www.jacobs-university.de/> > > > > _______________________________________________ > > i2rs mailing list > > <mailto:[email protected]> [email protected] > > <https://www.ietf.org/mailman/listinfo/i2rs> > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
