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

[Andy Bierman <[e-mail]>]

On Wed, May 25, 2016 at 3:33 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> 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?
>
>

This could be an extension and not a keyword, depending on how it is done.
The extension vs. keyword debate will not be rehashed here, but there is
an issue wrt/ how the data definition is interpreted by tools/protocols
that do not understand the extension and just ignore it.

Shared:

   list foo {
      i2rs:ephemeral true;
      ....
    }

I2RS-only:

   i2rs:ephemeral {
      list foo {  ... }
   }



> > 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.
>
>

This is a very expensive feature wrt/ standards resources.
First the WG has to agree that all the subtree data is OK to send in the
clear
under all circumstances. (Including augmenting nodes?)  Then this needs to
be
carefully reviewed by the SECDIR and IESG.  Both steps will require lots of
IETF time.

I agree that operators need to have the final say.
This extension is the opposite of the nacm:default-deny-all extension.
But it is designed to allow operators to configure access through NACM.
How does an operator override the extension?
And if the operator can override, why is an extension even needed?
If not, then what criteria is used to decide the data is universally
non-secure?


Andy




> > 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/>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>