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

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

Juergen: 

You must be reading the wrong document.  draft-ietf-i2rs-ephemeral-09.txt
has 

   Ephemeral-REQ-05: Ephemeral state handling and notifications could
   increase need for CPU processing, data flow rates across a transport,
   or the rate of publication of data in a subscription or the logging
   for traceability.  The I2RS Agent SHOULD have the ability to
   constraints for OAM functions operating to limit CPU processing, data
   rate across a transport, the rate of publication of data in a
   subscription, and logging rates; and the I2RS Agent SHOULD have the
   ability to prioritize some of the management data flows between the
   I2RS Agent and I2RS Client.  In order to constrain resources needed,
   the I2RS Agent MAY also schedule data flows or split data flows unto
   multiple data flow streams.

Perhaps you meant to refer to: 
  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:
   o  Yang module(and the module's schema tree),
   o  submodule or components of a submodule (e.g. derived types,
      groupings, data node, RPCs, actions, and notifications), or
   o  a schema node (container, leaf, leaf-list, choice, case, rpc,
      input, output, notifications, and anyxml).

Please provide comments based on the current revision.  

Sue 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 31, 2016 2:39 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [e-mail]; 'Alia Atlas'
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
- Topic: Ephemeral State Requirements

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

Wrong text please use text above.


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

I have answered the life time in another response.  Lifetimes are a model
issue.  Each model may have different lifetime on operational state. 

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

Sue: WG Consensus on this point.   

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

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs