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

["Susan Hares" <[e-mail]>]

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

Any ephemeral object must be able to be identified by a yang key word. 

 

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

 

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);

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), 

 

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

   

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 

     server module must be augmented to support mutual authentication

     (see details in [draft-ietf-i2rs-protocol-security-requirements]
section 3.1 

      in requirements: SEC-REQ-01 to SEC-REQ-08)), 

 

5) Support the following encodings   XML and JSON; 

6) support the following transports : "TCP", "SSH", TLS", and non-secure.  

(See ietf-i2rs-protocol-security-requirements in section 3.2 in requirements
SEC-REQ-09 and SEC-REQ-11 for details).  NETCONF should be able to 

Expand for I2RS transport support is requirement as future I2RS protocol
versions will support other transports. 

 

7) The ability to restrict insecure transports to specific portions of a
data model marked as valid to transfer via an insecure protocol,  

 

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) 

 

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.

 

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