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

From: "Susan Hares" <[email-masked]>
Date: Mon, 30 May 2016 20:43:23 -0400

I2RS Meeting will try a new format to aid Participants in multiple Time zones.    The presentation for this interim has been recorded, and the presentation is online.   We expect participants to listen to the interim meeting presentation before the session.  During the 1 hour interim, we will discuss the questions below.   We will summarize the results of the interim, and start mail threads on these questions this week. 

Webex info: 

https://ietf.webex.com/ietf/j.php?MTID=m163079dec821ba49f3eec1f97b52006f

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

Topic: 

We will focus on the one topic: the discussion of the I2RS ephemeral state requirements.  You can review the ephemeral state requirements at:  

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

The presentation for this interim has been recorded, and the presentation is online.  The questions are listed below, and we will start mail threads on this questions this week.  

Agenda: 

The agenda is simply a discussion of I2RS Ephemeral State requirements.  

The presentation is online, and it is expected people will view the presentation

before the meeting. 

Description: Ephemeral State Update Review 

Streaming recording link:

https://ietf.webex.com/ietf/ldr.php?RCID=47311823b09d78f541a6276705b18795

Download recording link:

https://ietf.webex.com/ietf/lsr.php?RCID=d57e5e4c6ba68521d21dd33971d3b58d

presentation: 

https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-interim-2016-i2rs-9-0.pdf

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? 

2.  Does Ephemeral-REQ-06 provide the Yang requirements in 

a clear fashion?  Do you have any suggestions for alternative text? 

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

5. Do you think the pub/sub requirements are sufficient? 

    (PUB-SUB-REQ-01, PUB-SUB-REQ-02)

6. Do you have any concerns about Ephemeral-REQ-01 to 

   Ephemeral-REQ-04? 

From: I2RS Working Group [mailto:[email-masked]] 
Sent: Monday, May 30, 2016 8:18 PM
To: [email-masked]
Subject: (Forward to others) WebEx meeting invitation: Ephemeral State

You can forward this invitation to others. 

Hello, 

I2RS Working Group invites you to join this WebEx meeting. 

Ephemeral State 

Wednesday, June 1, 2016 

10:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 

Meeting number (access code): 647 996 643 

Meeting password: wisp.o.wind

 <https://ietf.webex.com/ietf/j.php?MTID=m6ac7c86e499ea78fac6793104961f873> Add to Calendar 

When it's time,  <https://ietf.webex.com/ietf/j.php?MTID=m163079dec821ba49f3eec1f97b52006f> join the meeting.

Join by phone

1-877-668-4493 Call-in toll free number (US/Canada)

1-650-479-3208 Call-in toll number (US/Canada)

 <https://www.webex.com/pdf/tollfree_restrictions.pdf> Toll-free calling restrictions

 <https://help.webex.com/docs/DOC-5412> Can't join the meeting? 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 08:38:42 +0200

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

> 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.
 
>    Do we need all the features (yang module library, call-home, 

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

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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 10:02:17 -0400

Juergen: 

Thank you for the second response.    The questions were on version 8 of the
draft.  Jeff wanted to review version 8 before posting - so I delayed
posting of version 8 until this morning.    I've answered your questions
based on version 08. 

I think you understood that the ephemeral datastores defined by i2RS are not
what you defined in draft-schoenw-netmod-revised-datastores-00: 

   o  The model foresees ephemeral datastores that are by definition not
      part of the persistent configuration of a device.  These ephemeral
      datastores are considered to interact with the rest of the system
      like any other control-plane mechanisms (e.g., routing protocols,
      discovery protocols).  [XXX Note that this is different from what
      is described in some of the I2RS documents.  XXX]

The difference is that I2RS defines ephemeral configuration and ephemeral
operational state.  You see this in all of the I2RS data modules.  I have
augmented your diagram with the proposed I2RS datastore. 

                    +------------+
                    | <intended> |  //  Subject to validation
                    | (ct, ro)   | //   e.g., missing resources or delays
                    +------------+   // Here I2RS ephemeral configuration
fits 
                          |         //  so missing resources/delays can be
handled
                          v
                    +------------+
                    | <applied>  |    - here I2RS defines ephemeral 
                    | (ct, ro)   |      configuration data store 
                    +------------+
                          |         // e.g., autodiscovery of values
                          v
          +--------------------------------+
          | <operational-state>            |<-- control plane and
          | (ct + cf, ro)                  |    ephemeral datastores

                      +--------------------------------------------------+

Your definitions ignored the WG requirements and the existing discussions.
Is there a reason why?  I2RS follows the break between operational state and
configuration data store. 

o  configuration datastore: When modeled with YANG, a configuration
      datastore is realized as an instantiated data tree with
      configuration data.
 
o  Operational state data is a set of data that has been obtained by
      the system at runtime and influences the system's behavior similar
      to configuration data.  In contrast to configuration data,
      operational state is transient and modified by interactions with
      internal components or other systems via specialized protocols.
 
This document is proposed on May 12, 2016 and we have been working on I2RS
for over 3 years.  You provided something that does not satisfy the
requirements of the existing I2RS data models (prepared for over 18 months).

Sue Hares 

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

>> 1.  Do you think Ephemeral-REQ-05 covers the resource constraint issue 

>> discussed on the list and at IETF-95?

> actions, and notifications".

Version -08 has the following for -05: 

   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.

I suspect you are working on Ephemeral-REQ-06: 

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

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

>I have trouble to parse this since the 1st sentence does not seem to make
sense for each element that you >consider an object. 

Do the three things make sense?  I used the work "object" because it had not
been used in yang 1.1.  

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

For config false objects,  the ephemeral augmentation of opstate objects
depends on the opstate objects.  

Let's examine the augmentation of bgp-global-config with node-type (see
interim presentation) used for operational state.  This operational state
exists as long as BGP exists in a node.   The data model has not defined a
life time.   The changes to operational state for node-type would occur when
BGP adds different peers.  There are three ways a implementation can keep
this state:  periodically (every n second update), or 

query bgp-neighbor, or every time an bgp-neighbor changes - queue the
change.   The data model should define the type of lifetime the operational
state has.   If a periodic method is used, then the data model should
indicate the last time opstate was updated.   

presentation

https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-inter
im-2016-i2rs-9-0.pdf

If we have opstate that disappears when the lifetime expires, then the
ephemeral state would disappear and a notification would be sent to the I2RS
client.   For example, let us say that dynamic LSP has a lifetime and after
the lifetime expires - it disappears.   The I2RS client augments the LSP
with additional ephemeral operational state.   If the dynamic LSP lifetime
expires, and the opstate for the LSPs disappears - then the I2RS ephemeral
state would disappear as well.  A notification would be sent to the I2RS
client monitoring such state. 

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?

No, it is does not satisfy the I2RS requirements for configuration and
operational state.   I2RS wants to be able to query applied configuration
(ephemeral and local configuration) as well as the operational state.   I2RS
state may have routes with next-hop that are intended - that is the next-hop
is not resolved. 

>I think it is clear but broken. In particular the part about indicating
secure/non-secure transport.

>From version 8: 

   Ephemeral-REQ-07: Yang MUST have a way to indicate in a data model

   that nodes have the following properties: ephemeral, writable/not-

   writable, and status/configuration.  Yang must also have a way to

   specify on a module or submodule level whether the data MAY optionally

   flow across an non-secure transport.

Do you feel this is better or still broken? 

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

Please see version 8 of the document.  If you feel that I2RS requirements
suggest an existing solution, please indicate the solution.  Per your
request, these are requirements, not solutions. 

NETCONF & RESTCONF changes 

1)      I2rs protocol-version 

2)      Support module scope (ephemeral only, mixed (config & ephemeral),
mixed (opstate & ephemeral),

3)      Ability to restrict non-secure transport to specific models or
submodules (see above) 

4)      Ephemeral overwriting of local configuration state controlled by 2
knobs 

5)      Ephemeral overwriting of local configuration state is considered as
composite of all I2RS clients 

6)      Write conflicts handled as error using priority (ephemeral-REQ-10 to
ephemeral-REQ-13).  Support for write-conflict notification 

Existing features:  XML/JSON encoding,  features (pub-sub, yang module
library, call-home, server-module). 

NETCONF only: 

1)      multiple message support - "I2RS all-or-nothng" aka NETCONF
"roll-back-on-error"

2)      transports:  SSH, TLS, TCP with non-secure 

3)      No support of writable-running, candidate data store, confirmed
commit, or distinct start-up.   

RESTCONF only: 

1)      http over TLS,  http used in non-secure fashion 

2)      support for development of pub/sub in RESTCONF 

3)      Expansion of RESTCONF write-config support to include I2RS config
support (rather than replacement). 

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

No, see above.  Per your comments, version 08 clarifies.  I have provided
this above.   The current format was chosen based on request from
NETMOD/NETCONF for protocol specific.  I will be glad to switch the format
to common, NETCONF only, RESTCONF only. 

>I also think that it is not needed to write down requirements to NETCONF
for things that are already solved

> or being worked on.

Thank you for your comments.  However, some people have requested us to
indicate which NETCONF/RESTCONF features are required.   This allows
implementers to know what NETCONF/RESTCONF features must be implemented. 

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

The draft proposal does not align with the I2RS architecture design of
ephemeral having (config + operational state).   It does not allow the I2RS
client to query both ephemeral config and ephemeral operational state
separately.   See above. 

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

I agree that architecture + implementation defines the final speed of a
implementation.  Today's experience with NETCONF implementations
(architecture + speed) leads to this comment.   Since, this particular
sentence was requested by several people - we will need to poll the WG to
determine if this sentence gets removed.  I will add it to the questions for
the WG. 

/js

-- 

Fax:   +49 421 200 3103         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

_______________________________________________

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 16:25:40 +0200

> augmented your diagram with the proposed I2RS datastore. 

There needs to be _one_ architectural model. I may be ignorant but we
have to look at how things fit together. What you are drawing is
ignoring for instance the fact that <intended> is the subject of
configuration validation while I2RS explicitly states that ephemeral
is not part of configuration validation. So your model is not a
workable solution either.
  
> requirements of the existing I2RS data models (prepared for over 18 months).

Which I2RS requirements? Please be specific.

There needs to be _one_ architectural model for all the datastores
people to introduce in various places and it does not help to
complain. Please get down to the I2RS requirements that the above
proposal does not address. Make a better proposal. Iterate. There have
been quite a few calls related to the intended and applied datastore
discussions that are not taking place in I2RS land and as I said above
we need to come up with a common architectural model.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 11:12:13 -0400

Juergen: 

Thank you for your quick response.  See my comments below.   I believe as
you said " I may be ignorant but we have to look at how things fit together"
- so I have provided more information.  I believe the I2RS model is
workable, and I look forward to your informed review of this information. 

Version -09 of Ephemeral-state is released to make it clear ephemeral state
has ephemeral configuration and ephemeral operational state.   Click below
for the draft:

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 31, 2016 10:26 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Benoit Claise'; 'Alia Atlas'
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am

On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote:
>> I think you understood that the ephemeral datastores defined by i2RS 
>> are not what you defined in draft-schoenw-netmod-revised-datastores-00:
>> 
>> The difference is that I2RS defines ephemeral configuration and 
>> ephemeral operational state.  You see this in all of the I2RS data 
>> modules.  I have augmented your diagram with the proposed I2RS datastore.
>> 
>> 
>>                     +------------+
fits 
>>                           |         //  so missing resources/delays can
be handled

>> Is there a reason why?  I2RS follows the break between operational 
>> state and configuration data store.
>

>There needs to be _one_ architectural model. 
> I may be ignorant but we have to look at how things fit together. 
>What you are drawing is ignoring for instance the fact that <intended> is
the subject of configuration 
> validation while I2RS explicitly states that ephemeral is not part of
configuration validation. 
>So your model is not a workable solution either.

Not really, the ephemeral configuration is a part of the configuration
validation.  The ephemeral validates as either a stand-alone modules
(I2RS-RIB), or as a validation of an augmentation (see examples in the
interim presentation).  It is validated at the intended stage of
configuration.   Therefore, the proposal discussed by I2RS is workable. Your
opinion goes against years of NETCONF people suggesting to I2RS that
ephemeral configuration and ephemeral operational state is possible. 
  
>> This document is proposed on May 12, 2016 and we have been working on 
>> I2RS for over 3 years.  You provided something that does not satisfy 
>> the requirements of the existing I2RS data models (prepared for over 18
months).

> Which I2RS requirements? Please be specific. 
==================
Ephemeral-REQ-01 to Ephemeral-REQ-04 cover both configuration and
operational state.  If that's not clear, then I guess we need to add them.
Here's the Ephemeral-REQ-01 for version -09 of the text. 

    Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
   not persist across reboots.  If state must be restored, it should be
   done solely by replay actions from the I2RS client via the I2RS
   agent.  Ephemeral state may consist of ephemeral configuration 
  or ephemeral operational state, or both.  
========
> There needs to be _one_ architectural model for all the datastores people
to introduce in various places 
> and it does not help to complain. 

One model for data stores people is reasonable.  However, your model does
not work for I2RS.  You have not explained why technically the i2RS model
does not work for you.  

>Please get down to the I2RS requirements that the above proposal does not
address. 
See Above.  

> Make a better proposal. Iterate. There have been quite a few calls related
to the intended and applied 
> data store discussions that are not taking place in I2RS land and as I
said above we need to come up with a 
> common architectural model.

Been iterating for a while in I2RS.   Love to hear technical reasons why the
ephemeral datastore architecture does not work for you.    

If mention a few NETCONF calls/ your individuals draft, you must compare it
against the i2RS WG 3 years plus  3 WG drafts to IESG (pub/sub,
traceability, protocol-security), and  2 in final review (protocol-security
environment, ephemeral state).  May I suggest suggesting your draft has
precedence or personal behaviors is not a fruitful discussion.  Let's keep
on the technical discussion. 

[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 19:13:04 +0200

> ephemeral configuration and ephemeral operational state is possible.

I understand YANG validation rules and I understand YANG's notion of
configuration datastores. I do not think this matches your ephemeral
configuration validation.

> > Which I2RS requirements? Please be specific. 

So how is this broken? This is the only time 'ephemeral operational
state' shows up in -09. So please elaborate whether this is by
intention in order to express that 'ephemeral operational state' is
something different than a subset of 'operational state' or even
better please explain how you think 'ephemeral operational state'
relates to 'operational state'.

In fact, it would help if terminology would be clearly defined. How do

- ephemeral operational state
- ephemeral state
- ephemeral config
- derived state (ephemeral)
- derived state (opstate)
- ephemeral configuration
- mixed ephemeral config (ephemeral + config)

relate to each other? Let me check draft-ietf-i2rs-architecture-15.txt:

- ephemeral state
- ephemeral configuration
- ephemeral data - is data which does not persist across a reboot
      (software or hardware) or a power on/off condition. Ephemeral
      data can be configured data or data recorded from operations of
      the router.
- ephemeral static state (?)

So is my interpretation right that 'ephemeral data' is the union of
'ephemeral configuration' and 'ephemeral state'?  (If my
interpretation of these terms is correct the probably not all usages
of the terms are correct in draft-ietf-i2rs-architecture-15.txt; so
more likely my interpretation is incorrect.)

Given the operational state is by its nature ephemeral, is there a
distinction between 'operational state' and ephemeral state? Or is
'ephemeral state' just a subset of 'operational state' that has been
influenced by 'ephemeral configuration'?

> ephemeral datastore architecture does not work for you.

There are many datastores being proposed and at the end they all need
to work together. Implementations can't support N different datastore
models that are not aligned. I understand that this concern is not
your prime problem since your focus is I2RS but please understand that
other people are proposing other datastores and I do believe
NETMOD/NETCONF needs to find agreement on a bigger architectural
picture that addresses the various requirements and enables
implementations that work in a predictable manner.

> on the technical discussion.

I just tried to make you aware that some people think we need a common
and consistent architectural model within NETMOD and NETCONF. I
pointed to one proposal. There can be others. But at the end, there
needs to be a single unifying architectural model if we want
implementations being able to address requirements coming from
different communities and still behave in a predictable manner.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 14:27:12 -0400

If I understood you correctly Juergen, you are suggesting using your 
document:
https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
as a basis for addressing the I2RS requirements.

I am having trouble understanding how the approach in your document 
would work for ephemeral configured information.
1) The document says that such information is treated like other control 
protocols.
1a) How would one use NetConf or RestConf to write this?
1b) How would the controllable relationship with conventional 
configuration be realized
1c) How would the descriptions of this information be provided? 
(Arguably, this last is not a requirements question, but it would help 
in understanding your proposal.
2) Similarly, since operations have been segregated by datastore, how 
would an I2RS client read the configured information to tell what was 
being applied?
3) How would the I2RS requirement for priority of operation be applied?
4) How would the requirement for reversion to configured values upon 
removal of an I2RS modification be done?

It is very hard as a reader to tell if your approach is acceptable, 
better than, or worse than, the one we have on the table.

As far as I can tell, in terms of a consistent architecture for data 
stores, both approaches consist of creating extra data stores when needed.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 May 2016 11:41:59 -0700

Hi,

I agree with your concerns.  The opstate design team should not be ignoring
ephemeral state
and the I2RS WG should not be ignoring the opstate work.  I prefer to see 1
RFC on datastores
that defines a coherent and cost-effective framework that works for years
to come.
New implementations should opt-in to using new datastores.  Old
implementations must
continue to work even if the new datastores are ignored.

Isn't all operational state ephemeral by definition?
Doesn't proper management of a system with ephemeral data require
just 1 view of operational data which reflects current system behavior?

At some point the WG needs to agree on normative text instead of iterating
on requirements forever.  Some of them will fall out as important vs.
irrelevant
if there is an actual protocol spec to review.  E.g. secondary ID cannot
be "may keep" and "SHOULD report".  Either the standard protocol has an
official use for secondary client ID or it doesn't.

Andy

On Tue, May 31, 2016 at 10:13 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > >> Thank you for the second response.    The questions were on version 8
> of
> > the
> > >> are not what you defined in
> draft-schoenw-netmod-revised-datastores-00:
> > >>
> people

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 20:48:44 +0200

> as a basis for addressing the I2RS requirements.

No. All I am saying is that there are discussions underway basically
triggered by openconfig ideas and that we need to find a common
architectural model for the various datastores different groups like
to have. The I-D cited above is input to this discussion. The
discussion goes beyond I2RS concerns but still I2RS concerns should be
considered by this discussion.
 
> I am having trouble understanding how the approach in your document would
> work for ephemeral configured information.

Via an ephemeral datastore. The difference is that this ephemeral
datastore primarily interacts with operational state. This actually
seems consistent since I2RS tends to favor to relate to state more
than to config.

> 1b) How would the controllable relationship with conventional configuration
> be realized

The ephemeral datastore overwrite, right? So an implementation pulls
from the <applied> config datastore and the ephemeral datastore and
the (+) function gives content from the ephemeral datastore
preference.

> 1c) How would the descriptions of this information be provided? (Arguably,
> this last is not a requirements question, but it would help in understanding
> your proposal.

A YANG module. Perhaps I do not understand the question.

> 2) Similarly, since operations have been segregated by datastore, how would
> an I2RS client read the configured information to tell what was being
> applied?

Be careful with 'applied' since there now is an 'applied' datastore
with very specific meaning. But in general, a client that wants to
read one of the configuration datastores simply reads that datastore.

> 3) How would the I2RS requirement for priority of operation be applied?

It is the magic (+) function that merges <applied> config with
<ephemeral> config leading to operational state.

> 4) How would the requirement for reversion to configured values upon removal
> of an I2RS modification be done?

The magic (+) function would have to take care of it.

> It is very hard as a reader to tell if your approach is acceptable, better
> than, or worse than, the one we have on the table.

I understand. The alternative model is to have <ephemeral> somewhere
between <applied> and <operational state>. But then it seems people
want <ephemeral> really behave more like other control plane protocols
that also typically interact directly with <operational state>.

> As far as I can tell, in terms of a consistent architecture for data stores,
> both approaches consist of creating extra data stores when needed.

Yes. But details matter. For example, <intended> and YANG
configuration datastore validation are one thing, I tend to believe
that I2RS validation really means something different. Hence I am
pointing out that we need the I2RS requirements but then we
(NETMOD/NETCONF people) also need to come up with an architectural
model that considers things that are beyond I2RS' scope.

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 15:07:03 -0400

Would a fair paraphrase of the point you are making here be
that the <ephemeral> data store could sit next to the <applied> data 
stored rather than either below or combined with it?

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 21:27:29 +0200

On Tue, May 31, 2016 at 03:07:03PM -0400, Joel M. Halpern wrote:
> that the <ephemeral> data store could sit next to the <applied> data stored
> rather than either below or combined with it?
>

Yes.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 15:29:55 -0400

>I understand YANG validation rules and I understand YANG's notion of
configuration datastores. I do not >think this matches your ephemeral
configuration validation.

This does not provide a technical discussion of: 
a) what you understand the ephemeral configuration validation rules to be, 
b) why you do not the model matches the configuration validation rules. 

1 Data Model is a great idea for NETCONF/NETMOD.  However, it should
encompass 

Ephemeral data:== ephemeral state ::== Ephemeral configuration + Ephemeral
operational state 

Cheers, 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2016 1:13 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Benoit Claise'; 'Alia Atlas'
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am

[snip] 
of
> >> I think you understood that the ephemeral datastores defined by 
> >> i2RS are not what you defined in

>[Juergen]: I understand YANG validation rules and I understand YANG's
notion of configuration datastores. I do not think this matches your
ephemeral configuration validation.

[sue:] This is not a technical response.  Please provide: 
a) what is the understand you have of the I2RS ephemeral validation rules, 
b) Why you think it does not match Yang validation rules or Yang's notion of
configuration datastores. 

> >> This document is proposed on May 12, 2016 and we have been working 
> >> on I2RS for over 3 years.  You provided something that does not 
> >> satisfy the requirements of the existing I2RS data models (prepared 
> >> for over 18
> months).
> > 
> 

Juergen: 
>So how is this broken? This is the only time 'ephemeral operational state'
shows up in -09. 

Sue:  The inclusion of operational state has been in the I2RS RIB data model
for over 18 months.  The I2RS WG had assumed that the I2RS Data models would
be examined when creating ephemeral datastore models. 
So, the inclusion in -09.txt is for your benefit and for others who do not
read the I2RS ephemeral-only data models.  

Juergen: 
>So please elaborate whether this is by intention in order to express that
'ephemeral operational state' is >something different than a subset of
'operational state' or even better please explain how you think >'ephemeral
operational state'
>relates to 'operational state'.

Ephemeral comes in two varieties:  configuration and operational state.  The
examples in my interim presentation provide you with an example of
configuration state.  The operational state can also be see by BGP using the
node-type as an operational state variable.   

>- mixed ephemeral config (ephemeral + config)

The problems with the definitions come to the fact the netmod WG has not
settle on a definition of operational state.  
-  ephemeral operational state - ephemeral state which is operational
(Node-type as operational state in the examples in my presentation) 
>- ephemeral state - the combination of I2RS ephemeral configuration and
I2RS ephemeral operational state
>- ephemeral config - configurations which are ephemeral (see the
requirements).  Ephemeral configuration only - would be I2RS RIB.  
>- derived state (ephemeral) - derived state = operational state that exists
which is defined by ephemeral object in an I2RS data model.  Derived state
is a NETMOD's term. 
>- derived state (opstate) - derived state = operational state that is not
ephemeral  
>- mixed ephemeral config (ephemeral + config) - see the BGP examples in my
interim slide 

Juergen: 
> ephemeral static state (?)

>So is my interpretation right that 'ephemeral data' is the union of
'ephemeral configuration' and 'ephemeral >state'?  (If my interpretation of
these terms is correct the probably not all usages of the terms are correct
in >draft-ietf-i2rs-architecture-15.txt; so more likely my interpretation is
incorrect.)

Ephemeral data = ephemeral state = ephemeral = ephemeral configuration +
ephemeral operational state 

>Given the operational state is by its nature ephemeral, is there a
distinction between 'operational state' and >ephemeral state? Or is
'ephemeral state' just a subset of 'operational state' that has been
influenced by >'ephemeral configuration'?
See above.  To answer your question, no it is not. 

Snip to next technical discussion 

Juergen: 
>There are many datastores being proposed and at the end they all need to
work together. Implementations >can't support N different datastore models
that are not aligned. I understand that this concern is not your >prime
problem since your focus is I2RS but please understand that other people are
proposing other >datastores and I do believe NETMOD/NETCONF needs to find
agreement on a bigger architectural picture >that addresses the various
requirements and enables implementations that work in a predictable manner.

The fact that the NETCONF/NETMOD people are proposing one model is great.
The I2RS work has been existing for 2 years and I2RS should be considered as
one of the key requirements for NETCONF datastore definitions.   

> If mention a few NETCONF calls/ your individuals draft, you must 
> compare it against the i2RS WG 3 years plus  3 WG drafts to IESG 
> (pub/sub, traceability, protocol-security), and  2 in final review 
> (protocol-security environment, ephemeral state).  May I suggest 
> suggesting your draft has precedence or personal behaviors is not a 
> fruitful discussion.  Let's keep on the technical discussion.

>I just tried to make you aware that some people think we need a common and
consistent architectural model >within NETMOD and NETCONF. I pointed to one
proposal. There can be others. But at the end, there needs to >be a single
unifying architectural model if we want implementations being able to
address requirements >coming from different communities and still behave in
a predictable manner.

Excellent technical point on 1 model.  The problem is your model does not
support:
Ephemeral data == ephemeral state == ephemeral configuration + ephemeral
operational-state

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 May 2016 15:36:40 -0400

[Note that I'm answering messages in thread order to the originator of a
point rather than necessarily to responses.  This is intentional.]

> an ephemeral augmentation of objects if their lifetime expires?

I agree that your observation covers the general intent.  The requirements
language above is attempting to be a bit too specific for a given
implementation detail, namely instantiation of ephemeral behaviors in a data
tree.

Could you please supply alternative text?

> model not satisfy the I2RS requirements and make things much simpler?

I've been unable to follow netmod/netconf recently, so thanks for pointing
out this document.  It does seem to do a nice job in attempting to summarize
a number of discussions on the various datastore concepts we've been seeing
the last year.

There are a few things I find slightly problematic in your hierarchy with
respect to what I2RS likely needs for ephemeral configuration state, but I
think it might be solvable.  Here are some observations:

If ephemeral configuration state were to be treated as a datastore that
feeds into running, would you expect that the resulting running state should
be writable?  (I.e. running = candidate, startup + ephemeral?)

It would be helpful to see how an ephemeral datastore is intended to
interact in this diagram.  A detail that would need to be clarified is what
happens when there is overlaps in portions of the schemas.

> indicating secure/non-secure transport.

The text relating to transport is applied to generally and needs clarifying.
Let's provide a specific goal:

For Yang notifications, there may be some desire for the information to be
sent across alternative transports, potentially with specific encodings.
draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be
sent via alternative transports.  Should we have some sort of markup in the
Yang language to identify what transports might be utilized?  What about
security requirements?

Obviously we can spell out transport security considerations as part of the
description clause within a notification.  However, since a significant
amount of feedback has been given from individuals with a security
background that many objects we're likely to use in I2RS may be security
sensitive - but not all! - some way to indicate the sensitivity may be
required.

The motivation for this is that for insecure and high speed transports and
ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g.
interface statistics) but the same may not be true for other data and a
secured transport may be required.

> work with multiple protocols.

I agree we're being overly specific here, although as noted above we need
some discussion about what to do about insecure transports for some
operations, such as subscriptions.  (I think that's covered by the 
yang-push doc in particular.)

Item 6 about precedence of local configuration vs. ephemeral configuration
requires discussion, including in the revised-datastore document if it
chooses to address ephemeral configuration.

> NETCONF for things that are already solved or being worked on.

I think we're happy to subtract these, or at the least call out the existing
work in progress.  As noted in some earlier drafts, the goal of the I2RS
drafts should be to not have drafts in I2RS, but solution space documents in
netconf and netmod.

> draft-schoenw-netmod-revised-datastores-00 for more details.

I think converging on the concept of an conceptional operational datastore
would address many of these considerations.  (Note that I believe you'll
want either additional filtering capabilities to select whether the
configuration state in the operational store originates in local
configuration or ephemeral configuration.  This was in an earlier version of
the ephemeral state requirements draft.)

I believe the remainder of the configuration state considerations are
covered by the yang-push draft in the on-change behavior.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 May 2016 15:45:04 -0400

> configuration validation.

Prior working group discussion had suggested that bypassing validation (e.g.
constraints) may be required for sufficiently fast operations.  Obviously
this point has remained contentious.

The functional desire is sufficient speed out of configuration operations in
the ephemeral elements of the datastore.  If that can be done without
compromising on validation - or imposing certain considerations on the
structure of i2rs/ephemeral modules - I suspect that would satisfy the
working group.

> relates to 'operational state'.

I would suggest that we avoid talking about "ephemeral operational state".
While it's possible to discuss the context of such a thing existing as a
result of schema rules that config false nodes may be under nodes that are
both config true and ephemeral true (using our example keyword
modifications), I don't think calling it ephemeral operational state brings
too much to the conversation.

The one case for possible concern is that in the event the ephemeral
datastore is off-line is that such config false nodes may not be present.
However, this may be covered by other existing netconf mechanisms depending
on how the ephemeral datastore and related modules are instantiated in the
protocol.

> implementations that work in a predictable manner.

Some of the frustration comes from the discussion for ephemeral state having
been ongoing while the current operational state discussions have been
somewhat new.  

We agree that we need to have a unified datastore architecture.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 May 2016 15:51:23 -0400

Andy,

On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> on requirements forever.

IMO, it would be in I2RS's best interests if netconf/netmod provided drafts
in appropriately normative language covering I2RS requirements.  However,
we've been in a pathological cycle of:
"We don't understand, please give us requirements"
"We don't understand your requirements"
"You provided examples with your requirements that appear to be attempts to
change our protocol - don't do that."

The most recent revised-datastore draft would be a good place to document
where netmod(/netconf) believes ephemeral datastores (if that's the
instantiation) could live, and also how ephemeral configuration state could
interact with candidate, startup and running configuration.

yang-push covers much of our desired pub-sub behavior. (Yay!)

Discussion is required for how to tag security considerations impacting
transport into the yang model, in particular for notification.

Proposals for secondary identity and priority are also needed.

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 16:06:15 -0400

Thanks.  That makes sense to me.
Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 16:10:05 -0400

Can you clarify something for me?
What is ephemeral operational state?

The only thing I can think of is operational state like statistics 
related to ephemeral leaves or constructs?
Is that what you mean by "ephemeral operational state"?
The reason i ask is that such state does not seem to need any special 
handling or labeling.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 16:17:50 -0400

The more I read the text about marking secure or insecure transports, 
the I wonder whether it is an I2RS requirement at all.
that is, I2RS requires the ability to send notifications via an insecure 
channel.
I don't think I2RS cares what granularity this is marked at.
There are security reasons for wanting to restrict the usage.  Equally, 
one needs any definition of some usage to be done by the entity which 
actually knows what is needed.
I2RS as a system does not know or care how to resolve that tension.
So lets not state a requirement on it?

Jeff, you allude to using a protocol like IPFIX.  Given that IPFix won't 
be reading these YANG models at all, it seems that the requirement as 
stated (marking in the YANG which nodes are allowed to be transferred 
insecurely) won't help solve the problem.

I also wonder if the very notion of an I2RS protocol is getting in the 
way.  If the insecure transfer we envision is some protocol other than 
NetConf / RestConf, then we seem to be stating the requirement in the 
wrong place.

Yours,
Joel

On 5/31/16 3:36 PM, Jeffrey Haas wrote:
> ...
...
> secured transport may be required.
...

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 31 May 2016 16:27:51 -0400

Juergen: 

How does ephemeral sitting next to the <applied> data store provide the
ability to augment configuration with ephemeral configuration or operational
state with ephemeral operational state? 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 31, 2016 3:27 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Tue, May 31, 2016 at 03:07:03PM -0400, Joel M. Halpern wrote:
> Would a fair paraphrase of the point you are making here be that the 
> <ephemeral> data store could sit next to the <applied> data stored 

Yes.

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 31 May 2016 17:06:00 -0400

Joel,

On Tue, May 31, 2016 at 04:17:50PM -0400, Joel M. Halpern wrote:
> The more I read the text about marking secure or insecure
> transports, the I wonder whether it is an I2RS requirement at all.
> that is, I2RS requires the ability to send notifications via an
> insecure channel.

The requirements have been getting written in a very proscriptive manner for
the cases when security *is* required.  

We have had numerous discussions about other transports, which *might not*
be secured.

If your argument is that because we MUST support the secured cases that we
don't need to cover the insecure cases, I strongly disagree.

> I don't think I2RS cares what granularity this is marked at.

I2RS doesn't give a darn.  Models and security folk reviewing the models do.

> So lets not state a requirement on it?

Let's not try to brush it off.

> Jeff, you allude to using a protocol like IPFIX.  Given that IPFix
> won't be reading these YANG models at all, it seems that the
> requirement as stated (marking in the YANG which nodes are allowed
> to be transferred insecurely) won't help solve the problem.

Please try to have paid attention to the discussion the last two years about
pub-sub mechanisms for telemtry data.  We have more than one vendor which
has implemented some form of telemetry state coverable by yang modeling with
alternate presentation or transport layers.  The most common example
regularly cited has been GRPC with protobufs encoding. Discussion has
happened in-hallway, on-list and between vendors about the potential
programmatic mapping layers between things like protobufs, thrift and even
IPFIX and yang although to my knowledge only protobufs and thrift had gotten
more than a smattering of attention.

> I also wonder if the very notion of an I2RS protocol is getting in
> the way.  If the insecure transfer we envision is some protocol
> other than NetConf / RestConf, then we seem to be stating the
> requirement in the wrong place.

IMO, calling it an "I2RS protocol" was mistaken.  The minute we decided we
were going to attempt to leverage existing mechanisms such as netconf and
restconf, the framing should have simply been "extensions to support i2rs
cases".

If netconf proved intransigent against the changes in question, it was
likely at some point that the vendor set implementing i2rs mechanisms would
eventually chosen to have forked netconf protocol behaviors to support their
code and use cases for ephemeral state.  Thus far, it appears that each has
chosen to stay with their own internal forms of ephemeral configuration and
avoid exposing netconf mappings until these issues have resolved.

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 31 May 2016 17:07:10 -0400

All I was saying was that we as I2RS should focus on our requirement 
that it be possible to ship some data in a non-secure transport.  While 
I am tempted to argue against the requirement, it is the WG consensus, 
so it stands.

But when it comes to declaring requirements on marking which pieces of 
data may be shipped insecurely, and specifically marking that in AYNG, I 
think we are overstating the requirement.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 May 2016 14:08:34 -0700

Hi,

I am not convinced the IETF can be forced to function as if it were
a dev-group in some corporation.  This is a volunteer organization so
usually solution proposals come from people who have created a solution
and they want the WG to standardize it.

Andy

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 31 May 2016 23:09:10 +0000

IETF has been successful for past 20 years  in focusing on “Over the Wire” data structure.  It would be so much cleaner and straight forward if the YANG modules developed by I2RS  focusing on the “Over the Wire” data structure (and with NETMOD to focus on other aspects).
The “I2RS ephemeral State” has the needed description for the desired behavior  of the data received over I2RS interface. If we follow the IETF practice,  it is good enough.
Internal implementation framework is always controversial, hard to converge, usually ending up with a document (if completed) that is too big and difficult to read.

Providing some source code to show the internal implementation would be much more useful as a reference implementation.

The draft-schoenw-netmod-revised-datastores-00 is on the architectural framework for datastores as they are used by network management protocols. IMHO, how data stores are used are internal to the end points.

[http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg]<http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw&url=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F&psig=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w&ust=1464822503865777>

Linda Dunbar

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, May 31, 2016 4:09 PM
To: Jeffrey Haas
Cc: Benoit Claise; [email-masked]; Juergen Schoenwaelder; Susan Hares; Alia Atlas
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

Hi,

Andy

On Tue, May 31, 2016 at 12:51 PM, Jeffrey Haas <[email-masked]<mailto:[email-masked]>> wrote:
Andy,

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 May 2016 19:04:47 -0700

Hi,

If your graphic advice means "the requirements are good enough, move on"
then I agree.

The datastore framework would be nice to have, but it is very close
to the implementation details.  It is also attempting to be a superset of
all
"accepted" implementation choices.

By "on the wire" we usually mean a protocol specification.
IMO, all that is needed (for editing) is a set of RESTCONF extensions.
Some people want to describe the I2RS desired behavior wrt/ how it
interacts with the local config. (and many more features...)

Perhaps a good first step would be ephemeral data models that do not
interact with the local config at all.  I2RS is the only protocol of
concern and the
highest priority client.  I2RS just needs to support read/write/notify of
ephemeral data.
If this is not acceptable then be prepared to wait until all the framework
stuff is settled
and standardized.

Andy

On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <[email-masked]>
wrote:

> IETF has been successful for past 20 years  in focusing on “Over the Wire”
> data structure.  It would be so much cleaner and straight forward if the
> YANG modules developed by I2RS  focusing on the “Over the Wire” data
> structure (and with NETMOD to focus on other aspects).
>
> The “I2RS ephemeral State” has the needed description for the desired
> behavior  of the data received over I2RS interface. If we follow the IETF
> practice,  it is good enough.
>
> Internal implementation framework is always controversial, hard to
> converge, usually ending up with a document (if completed) that is too big
> and difficult to read.
>
>
>
> Providing some source code to show the internal implementation would be
> much more useful as a reference implementation.
>
>
>
> The draft-schoenw-netmod-revised-datastores-00 is on the architectural
> framework for datastores as they are used by network management protocols.
> IMHO, how data stores are used are internal to the end points.
>
>
>
> [image:
> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg]
> <http://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwj50KWat4XNAhULxGMKHRhqDPQQjRwIBw&url=http%3A%2F%2Fwww.urbanblissmedia.com%2Fentrepreneur-rules-done-is-better-than-perfect%2F&psig=AFQjCNGKEiPB2iHSqyBiF5609pd72H0L7w&ust=1464822503865777>
>
>
>
> Linda Dunbar
>
>
>
> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Tuesday, May 31, 2016 4:09 PM
> *To:* Jeffrey Haas
> *Cc:* Benoit Claise; [email-masked]; Juergen Schoenwaelder; Susan Hares;
> Alia Atlas
> *Subject:* Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am -
> 11:00am - Topic: Ephemeral State Requirements
>
>
>
> Hi,
>
>
>