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

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

Juergen: 

 

Thank you for your comments and questions.   I have answered the
point-by-point comments below. 

 

The goal of the exercise was to make one more attempt to resolve your
comments at the request of Alia Atlas and Benoit Claise.   You are a
brilliant person who has worked in NETCONF and NETMOD for several years.  I
hope to continue to resolve your concerns, but perhaps you are missing some
context from I2RS work.  

 

At this point, I find the following things in your response: 

1) Request for clarity on requirements (Ephemeral-REQ-05, Ephemeral-REQ-06) 

that were reviewed in 3 IETF meetings (IETF-93, IETF-94, and IETF-95) in
which you or other NETCONF/RESTCONF/YANG individuals did not comment. Also
there were no additional questions.  I welcome further discussion with you,
but I am copying the NETCONF chairs to determine if they can help you
understand these requirements or provide me suggestion on a resolution for
your comments. 

 

2) A disconnect from the charter that of I2RS.  The charter specifies
protocol-independent ephemeral state only document will be done in I2RS, and
protocol-dependent ephemeral state models (or augmentations) will be done in
other WGs.  This charter defines the ephemeral-only data models, and two
types of mixed data models (draft-ietf-bgp-model example given below). 

 

3) A disconnect from the process of I2RS requirements as a re-use protocol 

The re-use  methodology requires I2RS protocol to:  

a) require support for I2RS protocol version number identifier that 

identifies the support of a set of YANG, NETCONF, and RESTCONF features;

b) specifying the existing Yang, NETCONF, and RESTCONF features needed for
I2RS protocol version 1 (ephemeral state, protocol security, pub/sub, and
traceability) and its security environment; and 

c) specifying the additions to YANG, NETCONF, and RESTCONF needed for I2RS 

support of ephemeral state, protocol security, pub/sub and traceability). 

 

To try to clarify these points, I have uploaded a -07.txt with clarifying
comments. 

 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

 

 

Sue Hares 

 

 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, May 25, 2016 6:34 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [e-mail]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-06.txt --

 

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.

 

Let me try again: 

 

Ephemeral-REQ-05: The ability to augment an object with  appropriate 

Yang structures that have the property of being ephemeral.  An object is
defined as being one of the following:  yang module, schema tree, schema
node, 

Submodule, components of a submodule (derived types, groupings, 

data nod, RPCs, actions, and notifications).


 

The following are definitions in draft-ietf-netmod-rfc6020bis-09.txt 

1) Yang module (p. 12) - A Yang module defines a hierarchy of schema nodes. 

With its definitions and the definitions it imports or includes from
elsewhere,

A module is self-contained and "compilable". 

2) schema tree (p. 13) - The definition hierarchy specified within a module.


3) schema node (p. 12) - a node in the schema tree. 

4)  submodule (p. 13) - partial module definition that contributes derived
types, groupings, data modules, RPCs, actions, and notifications to a
module. 

 

The term "object" is defined to allow the data to augment each of these
structures.  Is this clearer? 

 

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

> Why does there have to be a YANG keyword?

 

Answer: There MUST be a way to writers of a data  model to define sections
of a data model that are ephemeral configuration and derived state.   No one
has suggested any other reasonable way to accomplish this in the last 2
years. 

 

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

Sue: I am glad we agree: 

 

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

 

Sue: The ability to utilize a non-secure transport requires:

a) support for non-secure transport in protocol, 

b) data-model definition that indicates a portion of the data model may be
passed over non-secure, and 

c) deployment context (via local node's policy on supporting this portion of
a data model).  

If you do not have a and b and c - then you should not send the data over
insecure channels. 

 

 

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

 

Sue: Do these capabilities allow for grouping of the NETCONF extensions
supported by a node to a specific set of extensions related to the I2RS
protocol set?   If not, this is the request. 

 

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

 

Let me give you an example:  

a) ephemeral only data model: draft-i2rs-rib-data-model-05 

b) mixed configuration model:  draft-bgp-model-01  (sections 6.1 - 6.4)
could be augmented to add ephemeral state to the configuration, 

c) mixed derived state: draft-bgp-model-01 section 6.5 defines operational
state, and this could be augmented to add ephemeral operational within this
data model. 

 

I suspect this reflects back to your misunderstanding Ephemeral-REQ-05. 

 

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

Sue: The requirement is to support NETCONF "roll-back-on-error" for
ephemeral state. 

 

>> 4) Support for the following  NETCONF [RFC6241] protocol specifications:

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

Sue:  The Ephemeral Requirements are defining a minimal set of 

NETCONF features to be absolutely required within the I2RS protocol
definition.   

To recreate I2RS as a re-use protocol, we are defining the features that
must be there to support the I2RS work.   

  

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

Sue: See above answer. 

 

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

 

Sue: No, please see draft-ietf-i2rs-architecture, section 6.3.1 with the
full description. 

 

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

 

Sue: The goal of the exercise was to try to resolve your comments on the
ietf-i2rs-ephemeral-state-06.txt.  I promised Alia Atlas and Benoit Claise
that I would give this discussion one more try.   See above for additional
comments on the "goal of the 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]> mailto:[e-mail]]
On Behalf Of Juergen 

> Schoenwaelder

> Sent: Tuesday, May 17, 2016 2:24 PM

> To: Jeffrey Haas

> Cc:  <mailto:[e-mail]> [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/>

>  <http://www.jacobs-university.de/> http://www.jacobs-university.de/>

> 

>  

> 

> _______________________________________________

> 

> i2rs mailing list

> 

>  < <mailto:[e-mail]> mailto:[e-mail]>  <mailto:[e-mail]>
[e-mail]

> 

>  < <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs>

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