Re: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

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

Juergen: 

Answers are listed below.  After you confirm Ephemeral-REQ-03,
Ephemeral-REQ-06, and Ephemeral-REQ-08, I will release a version-11. 

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, June 23, 2016 8:03 AM
To: [e-mail]
Subject: [i2rs] comments on draft-ietf-i2rs-ephemeral-state-10

>Hi,
>
>here are few comments on the latest version.
>
> Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
> operational state (e.g.  MPLS LSP-ID or a BGP IN-RIB) as a
> constraints.

> I am not sure what 'must be able to utilized temporary operational state
as constraints' means. The text in the parenthesis does not help me
understand this better. Did you want to say something like:
> 'Ephemeral configuration state may have constraints that refer to
operational state'? I am using 'ephemeral configuration state' since this is
used in other places (although sometimes worded slightly different).
>

Sue:  Ephemeral state is defined as "ephemeral configuration state" and
operational state.  Would this text be acceptable: 

Ephemeral State Requirements
In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state 
is defined as potentially including both ephemeral configured state and
operational state.	

Ephemeral-REQ-03: Ephemeral state must be able to utilize operational state 
(e.g. MPLS LSP-ID or BGP In-RIB) as a constraint.      

>   Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state
> for purposes of implementing constraints.

> Hm, now I wonder whether this is just a special case of
> Ephemeral-REQ-03 and if so it is not clear why we need this as a separate
requirement. If this is not the case but something different, then likely my
interpretation of Ephemeral-REQ-03 is wrong.

Juergen: Ephemeral state was defined by the I2RS group as both ephemeral
configuration state and operational state in ephemeral portions of
datastore. 

>s/2RS/I2RS in Ephemeral-REQ-05. I would actually rewrite the beginning of
Ephemeral-REQ-05 as follows:

Sue: I will change /2RS/I2RS. 

>   Ephemeral-REQ-05: I2RS interactions may
>  lead to undesirable or unsustainable resource consumption on a system
> implementing an I2RS Agent.  It is RECOMMENDED that mechanisms be
>  made available to permit prioritization of I2RS interactions, when
>  appropriate, to permit implementations to shed work load when
> operating under constrained resources.  An example of such a work
 > shedding mechanism is rate-limiting.

Sue: The text that specifies  
"I2RS pub-sub, logging, RPC or other mechanisms may lead to undesirable 
   or unsustainable resource consumption on a system implementing an I2RS
Agent.:" 

provides useful information to the I2RS implementers.  Unless this really
causes problems, 
it would be useful to leave it.  I believe it says the same thing. 

>I would remove the Note: since I believe the key observation here are the
potentially high volume of I2RS interactions and not the fact that there is
a datastore involved that is ephemeral.

Sue: I can remove the note. 

>I am still struggling with Ephemeral-REQ-06:
>
> Ephemeral-REQ-06: The ability to augment an object with appropriate
> YANG structures that have the property of being ephemeral.  An object
> defined as any one of the following: yang module, submodule or
> components of submodule, or schema node.

> Perhaps this is what you wanted to say?

   > Ephemeral-REQ-06: The ability to augment YANG schema nodes with
   > additional YANG schema nodes that have the property of being
   > ephemeral.

Sue:  If this text allows: 
1) yang modules that are all ephemeral, 
2) yang submodules that are all ephemeral, 
3) portions of submodules that are ephemeral,  and 
4) schema nodes that are ephemeral

Then I'll change it.  Please confirm. 

>I wonder why there are some ephemeral state requirements in sections
labeled with "I2RS Protocol version 1" while others seem to be protocol
version agnostic. What is the definition of I2RS protocol versions?  Perhaps
this notion of protocol version should simply be >removed; I am not sure it
helps with the requirements.

Sue: I will remove it.  However, the I2RS knows that it will add additional
features in a second revision.  However, that is probably self-evident if we
come up with a "bis" document. 

>   Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
>  that nodes have the following properties: ephemeral, writable/not-
>  writable, and status/configuration.

>This is confusing because it says 'nodes' while in YANG we distinguish data
nodes and schema nodes. For example, in YANG a schema node has a property
config true|false. This schema node property defines whether corresponding
data nodes are writable/non->writable. In other words, some of this
requirement seems to be covered by YANG already; so what remains is the
'ephemeral' property - does the requirement expect this to be a property of
a schema node?

We will change nodes to a "schema node". 

Editorial: s/prevent was the oscillation/prevent oscillation/
- changed 

/js

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