Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

[Juergen Schoenwaelder <[e-mail]>]

> Discussion of I2RS Ephemeral State 
> 
> Questions: 
> 
> 1.  Do you think Ephemeral-REQ-05 covers the resource constraint
> issue discussed on the list and at IETF-95? 
>

I read:

   Ephemeral-REQ-05: The ability to augment an object with appropriate
   YANG structures 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 trouble to parse this since the 1st sentence does not seem to
make sense for each element that you consider an object. That said,
the real issue here are lifetimes. The lifetime of a config true
object is determined by config changes, the lifetime of config false
objects is determined by operational state changes. What happens to
an ephemeral augmentation of objects if their lifetime expires?

The revised datastore model I have described in
draft-schoenw-netmod-revised-datastores-00 links the ephemeral state
only to operational state, not at all to configuration. Does this
model not satisfy the I2RS requirements and make things much simpler?

 2.  Does Ephemeral-REQ-06 provide the Yang requirements in 
> a clear fashion?  Do you have any suggestions for alternative text? 

I think it is clear but broken. In particular the part about
indicating secure/non-secure transport.
 
> 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes 
>    are not necessary?   If so, what changes would you leave out?
>    Do the "policy-knobs" seem useful to you? 
>
> 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes 
>    are not necessary?  If so, what changes would you leave out? 
>    Do we need all the features (yang module library, call-home, 
>    server)? 

I think this needs to be trimmed down. I think it should be avoided to
create I2RS specific solutions for things that are already in place
(e.g., NETCONF has a mechanism for protocol capability discovery and
negotiation, NETCONF already supports multiple (secure) transports).

I think that having a clear architectural view is essential. I am not
sure the 'single pane of glass' model is the way to go. I think the
decision on the architectural model is key because it impacts many of
the other requirements and solutions.

You want both NC and RC to support XML and JSON and SSH and TLS and
(plaintext) TCP? Does this maximum of variability and flexibility
really help interoperability? Perhaps things should be reorganized
into things that are protocol agnostic (and should not be repeated)
and things that are protocol specific - if there is indeed a need to
work with multiple protocols.

I also think that it is not needed to write down requirements to
NETCONF for things that are already solved or being worked on.
 
> 5. Do you think the pub/sub requirements are sufficient? 
> 
>     (PUB-SUB-REQ-01, PUB-SUB-REQ-02)
 
I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers
everything that is needed. Again, this is linked to architectural
question. The text, for example, assumes that there is an 'operational
data stores'. As of today, this is not really the case. See
draft-schoenw-netmod-revised-datastores-00 for more details.
 
> 6. Do you have any concerns about Ephemeral-REQ-01 to 
> 
>    Ephemeral-REQ-04? 

I think this sentence in Ephemeral-REQ-04 should be taken out:

   The designer of ephemeral state modules are advised that such
   constraints may impact the speed of processing ephemeral state
   commits and should avoid them when speed is essential.

First, it may depend on the architectural model that will be used and
it likely also depends on implementation details whether something is
fast or not. Or is there in inherent reason why a reference to
non-ephemeral state has to be 'slow'?

/js

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