Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --

[Juergen Schoenwaelder <[e-mail]>]

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:[e-mail]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, May 17, 2016 2:24 PM
> To: Jeffrey Haas
> Cc: [e-mail]
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> 
> Fax:   [phone]         < <http://www.jacobs-university.de/>
> http://www.jacobs-university.de/>
> 
>  
> 
> _______________________________________________
> 
> i2rs mailing list
> 
>  <mailto:[e-mail]> [e-mail]
> 
>  <https://www.ietf.org/mailman/listinfo/i2rs>
> https://www.ietf.org/mailman/listinfo/i2rs
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>