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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 10:25:36 +0200

On Tue, May 31, 2016 at 03:29:55PM -0400, Susan Hares wrote:
> 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.
> 
> 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 
>

Unless you define what the terms mean and what ::== means I have no
clue what you are trying to convey here.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 10:39:22 +0200

On Tue, May 31, 2016 at 11:09:10PM +0000, Linda Dunbar wrote:

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

Having a framework how different datastores conceptually fit together
is essential for getting implementations that behave in a predictable
manner. I am not talking about an implementation framework. As long as
people use key terms with different meanings, I have little hope that
this leads to interoperable behavior.
 
> 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.

I think a client needs to know what it means to modify a certain
datastore. A client needs to know what validation means. If people
code against <running>, <indented>, <applied>, <ephemeral> (and there
are more suggested) and it is undefined how things conceptually relate
to each other and interact with each other, then I have my doubts this
will lead to interoperability since systems likely expose rather
different behavior.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 11:10:10 +0200

On Tue, May 31, 2016 at 03:36:40PM -0400, Jeffrey Haas wrote:
> [Note that I'm answering messages in thread order to the originator of a
> point rather than necessarily to responses.  This is intentional.]
> 
> On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote:
> > 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?
> 
> 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?

It is difficult since I am not sure what the original intention
was. There is augmentation at the schema tree level and then there is
augmentation at the data tree level. My understanding (which may be
wrong) is that I2RS primarily looks at data tree level augmentations
of operational state data and not so much at configuration datastore
data. Part of the openconfig inspired discussion is to do away with
the /foo and /foo-state division and that has an impact how the schema
trees are constructed.

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

I doubt ephemeral feeds into the <running> datastore since running can be
expected to be persistent. draft-schoenw-netmod-revised-datastores-00.txt
actually suggests ephemeral interacts with <operational-state>. The
alternative view I mentioned is that a magic merge (+) takes <applied>
and <ephermeral> as input that feeds into <operational-state>. This is
likely closer to the 'pane of glass' model. The revised datastore model
kind of puts the magic merge function (+) into the operational datastore
itself, essentially treating I2RS ephemeral datastores like any other
control plane interface. (This still allowes a 'paned' implementation
within the <operational-state> but it does not require this.)

Note that draft-schoenw-netmod-revised-datastores-00 came out of a
meeting I had with Martin in Stockholm and there have been a couple of
calls where people where trying to figure out ways to deal with the
openconfig ideas. There is no WG agreement on any of this, its all
just input to discussion.

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

One of the driving forces were attempts to overcome the /foo and
/foo-state distinction we started to make in data models. This might
actually make ephemeral data model extensions easier.

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

The choice of transports and in particular the question whether a
non-secure transport is acceptable is for me primarily a deployment
question and not a data modeling question.

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

It is actually difficult for me to imagine objects that are in all
usage contexts never security sensitive.

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

Whether an interface is used or not can be sensitive information. In a
certain deployment, it may still be OK to use an unsecure transport
because the path between the IPFIX exporter and collector is believed
to be reasonably protected. But that is a deployment question, not a
data modeling question.

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

So lets leave it there and lets not repeat it.

> 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.
> 
> > I also think that it is not needed to write down requirements to
> > 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.

Yes!

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jun 2016 11:19:53 +0200

On Tue, May 31, 2016 at 04:27:51PM -0400, Susan Hares wrote:
> 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?

At the schema level, you will augment the schema tree. If the current
separation of /foo and /foo-state would go away, this will likely get
simpler (but this is orthogonal to the question how an <ephemeral>
datastore conceptually interacts with the other datastores).

At the data tree level, there is a magic merging (+) function involved
that takes configuration data from a configuration datastore and data
from an ephemeral data store and produces the resulting operational
state. The idea was to not further detail how this is achieved and
instead treat an ephemeral datastore pretty much like any other
control plane interface interacting with <operational state>.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 07:09:02 -0400

Joel: 

I am surprised you asked this question as you have followed the I2RS data
modules.  Is this question rhetorical? 
Ephemeral operational state have three types: 

1) results of rpc operations stored to respond to rpc actions 

I2RS-RIB-Data 
Rpcs: 
      +---x rib-add
      |  +---w input
      |  |  +---w rib-name        string
      |  |  +---w rib-family      rib-family-def
      |  |  +---w ip-rpf-check?   boolean
      |  +--ro output
      |     +--ro result uint32
      |     +--ro reason? string

2) notification data stored 

I2RS-RIB-Data
   notifications:
      +---n nexthop-resolution-status-change
      |  +--ro nexthop
..... 
      +---n route-change
         +--ro rib-name                 string
         +--ro rib-family               rib-family-def
         +--ro route-index              uint64

3) read-only status information 

See my presentation where the bgp-global-config - can be used by config or
state.  It is ephemeral state augmenting these features.   Or see the L2
topology module below. 

augment /nw:networks/nw:network/nw:node/nt:termination-point:
   +--rw l2-termination-point-attributes
      +--rw description?          string
      +--rw maximum-frame-size?   uint32
      +--rw (l2-termination-point-type)?
      |  +--:(ethernet)
      |  |  +--rw mac-address?          yang:mac-address
      |  |  +--rw eth-encapsulation?    identityref
      |  |  +--rw port-vlan-id?         vlan {VLAN}?
      |  |  +--rw vlan-id-name* [vlan-id] {VLAN}?
      |  |     +--rw vlan-id      vlan
      |  |     +--rw vlan-name?   string
      |  +--:(legacy)
      |     +--rw encapsulation?        identityref
      +--ro tp-state?             Enumeration

Sue Hares 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2016 4:10 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
- Topic: Ephemeral State Requirements

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

On 5/31/16 3:29 PM, Susan Hares wrote:
> Ephemeral data:== ephemeral state ::== Ephemeral configuration + 
> Ephemeral operational state
>
> Cheers,
>
> Sue

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 07:32:45 -0400

Juergen: 

A misconception you have below is that I2RS data models have mostly state.
There are the types of data models: 

1) ephemeral only - configuration and operational data 
2) mixed configuration - ephemeral augmentations to configuration
(bgp-global-config example used for config)
3) mixed operational state - ephemeral augmentations to operational state
(bgp-global-config  example used for state) 
4) some combination of 2 and 3 

Sue 

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

On Tue, May 31, 2016 at 02:27:12PM -0400, Joel M. Halpern wrote:

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

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.
>> 1) The document says that such information is treated like other 
>> control protocols.
>> 1a) How would one use NetConf or RestConf to write this?

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

Sue: Not true.  See often repeated statements. 

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

Why are you assuming the applied data store.  It could also be done at the
intended data store before the data is resolved.   Example usage is:
ephemeral route overwrites a normal RIB Route and then needs to resolve
next-hop.   (See I2RS Ephemeral RIB and overwriting local configuration). 

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

I2RS RIB Data Model is a Yang model.

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

This does not answer Joel's question.  How does the I2RS client read an
applied I2RS RIB Data Model? 

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

Sue: Again, at what stage does this 

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

Sue: It would be good to see some definition of a "magical +" function in
order to review your specification. 

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

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

Sue:  Why is this the only place.  Why not a merge at the intended
configuration>?   "It seems people" - seems to indicate some source of
input.  Can you share this input to your design? 

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

Sue: Does this mean you feel you can ignore the I2RS requirements if you
feel it does not meet your architectural model? 

/js

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 07:54:10 -0400

Andy: 

The I2RS topology (based, l3, L2) models do not interact with local configuration.  The current implementation in ODL uses RESTCONF to send/receive.  Other implementations of ephemeral only seem to be working.  

The next step is the mixed ephemeral/normal config. 

I have pointed out several problems with draft-schoenw-netmod-revised-datastores-00  architecture. 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, May 31, 2016 10:05 PM
To: Linda Dunbar
Cc: [email-masked]; Juergen Schoenwaelder; Alia Atlas; Benoit Claise; Jeffrey Haas; Susan Hares
Subject: Re: [i2rs] Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

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. 

 <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> http://www.urbanblisslife.com/wp-content/uploads/2012/10/Done-is-Better-Than-Perfect.jpg

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,

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

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

Andy,

On Tue, May 31, 2016 at 11:41:59AM -0700, Andy Bierman wrote:
> At some point the WG needs to agree on normative text instead of iterating
> 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: Andy Bierman <[email-masked]>
Date: Wed, 1 Jun 2016 05:08:16 -0700

> the /foo and /foo-state division and that has an impact how the schema
This REQ-05 doesn't give any reason why data nodes need to be tagged as
ephemeral
in the schema tree, or what it means to be tagged as ephemeral.

My intention for suggesting an "i2rs:ephemeral" YANG extension was to
identify
the I2RS conformance requirements for a server claiming to implement I2RS
for a specific YANG module.

A node tagged as ephemeral MUST be accessible in the ephemeral datastore
using I2RS if the module (or feature) is supported. An untagged node MAY be
accessible.

An I2RS data model could define read-only nodes.  These nodes could
be considered ephemeral operational state.  Should these nodes live in
this datastore or an "operational" datastore?  I don't know.
That's why we probably need your draft.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Jun 2016 08:35:50 -0400

> will lead to interoperability since systems likely expose rather

+1

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Jun 2016 08:41:11 -0400

> using I2RS if the module (or feature) is supported. An untagged node MAY be

This covers the intent properly.

Your suggestion of a mechanism in yang is probably reasonable, but as Jürgen
would say, this is all about the requirements.  So, could you suggest text
covering the requirement?

> That's why we probably need your draft.

If the implementation detail for ephemeral state is that it is part of a
datastore, then having the operational state in the ephemeral datastore
seems to make sense.  However, I find it more likely that we'll need a
mechanism to get the "union view after precedence" (i.e. panes of glass
model) for a conceptional datastore that covers state from local and
ephemeral.

But again, that's a protocol detail which we're trying to avoid in the
requirements.

If you think it belongs in the strawman or another document, we'd love text.

-- Jeff

---

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jun 2016 05:40:13 -0700

On Wed, Jun 1, 2016 at 5:41 AM, Jeffrey Haas <[email-masked]> wrote:

> > > > implementation detail, namely instantiation of ephemeral behaviors
> in a
> > > data
> > > > tree.
> > > >
I thought I just did.

Andy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 1 Jun 2016 08:49:55 -0400

> > covering the requirement?

It had been suggested the text covering Ephemeral-REQ-05/06 (in draft -09)
wasn't proper.  The text at the top of the quote covers at least one useful
property.

It's getting the full set of text covering those two sections correct that
we probably need.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 09:20:26 -0400

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

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

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

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

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

Sue: WG Consensus on this point.   

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

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 1 Jun 2016 09:30:21 -0400

Jeff and others: 

To make progress, can we please comment based on the
draft-ietf-i2rs-ephemeral-09.txt.   We will be using this text for
discussion. 

The following changes have been made in that document: 

1) Ephemeral-REQ-01 has new text 
2) Ephemeral-REQ-05 was added, and sequences renumbered 
3) ephemeral-REQ-06 (old Ephemeral-REQ-05) has  new text. 
4) Ephemeral-REQ-07 and Ephemeral-REQ-08 have new text [NETCONF/RESTCONF] to
clarify based on Juergen's comments. 

On Jeff's comments, 

1) why do you think the insecure transport was covered by the yang push
document? 
2) on draft-schoenw-netmod-revised-datastores-00 
>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.)

Why do you think the data model as it states covers the resolution of
nexthops that I2RS RIB Data model requires?  Why does the ephemeral not have
the simple case:  Ephemeral config / Ephemeral opstate? 

Sue 

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

On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote:
> objects is determined by operational state changes. What happens to an 
> ephemeral augmentation of objects if their lifetime expires?

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

> 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

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: Joel Halpern Direct <[email-masked]>
Date: Wed, 1 Jun 2016 09:31:24 -0400

My question was not about whether I2RS operations and configuration can 
produce operational state.

Rther, the quesiton is whether this operational state is in any way 
different from all other operational state?
Operational state, by its nature, is never persisted in config.
Operational state, by its nature, comes and goes depending upon other 
aspects (you frequently can not get statistics on an interface that is 
not enabled.)

So I don't see anything special on the operational side that I2RS requires.

Yours,
Joel

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 1 Jun 2016 16:34:44 +0000

Andy,

Agree with your suggested approach.

Linda

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, May 31, 2016 9:05 PM
To: Linda Dunbar
Cc: Jeffrey Haas; Benoit Claise; [email-masked]; Juergen Schoenwaelder; Susan Hares; Alia Atlas
Subject: Re: Can I2RS focus on the "Over the Wire" data structure , not on how end point handle the "DataStore"?

Hi,

Andy

On Tue, May 31, 2016 at 4:09 PM, Linda Dunbar <[email-masked]<mailto:[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.

[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]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Tuesday, May 31, 2016 4:09 PM
To: Jeffrey Haas
Cc: Benoit Claise; [email-masked]<mailto:[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: Jeffrey Haas <[email-masked]>
Date: Thu, 2 Jun 2016 10:27:33 -0400

Juergen,

> control plane interface interacting with <operational state>.

While such a solution-space seems mostly right, I had been under the
impression that the interactions necessary for validation meant that
ephemeral needed to move up closer to the top of your diagram.

Note that I'm not saying I2RS requires validation, however the lack of
validation has been a contentious point in prior discussions.

To confirm my understanding, ephemeral configuration state in the model
you're proposing above is treated as operational state (the output of the
netconf <get> operation for config true elements)?

-- Jeff

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 2 Jun 2016 14:32:18 +0000

> Jeffrey Haas, Tuesday, May 31, 2016 3:51 PM
> 

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

We have been working two mechanisms being worked in the pub-sub drafts:

(1) For dynamically established subscriptions, the security credentials used for establishing the transport connection will also be used to determine either (a) access to an Event stream, or (b) access to nodes in a YANG datastore.  For (b) if the subscription has no read access to the target node then the subscription is rejected; if subtree nodes have no read access, then they are filtered out of the response.

(2) For subscriptions statically configured on a device, minimum security expectations and transport requirements will be included as part of the subscription.  Once the transport connectivity is established, the process in (1) above would be followed.

Are these addressing the security concerns you have about the subscription mechanisms?   Is something else needed?

> Proposals for secondary identity and priority are also needed.

Per my other email, mechanisms for priority might be adoptable from the Subscription drafts.

Eric

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 19:44:13 +0200

> netconf <get> operation for config true elements)?

For configuration datastores, we have a reasonably precise definition
what validation means. And this comes for a price, e.g., config true
nodes are not allowed to refer to config false nodes. The reason is
that validate should work on the configuration data and it should not
depend on the operational state a device is in.

My understanding is that I2RS wants to inject data that modifies state
that might be purely operational state, e.g., state in a routing table
obtained from a routing protocol. If this is correct, then the
ephemeral state datastore is closer to the ephemeral state and pretty
detached from configuration datastores and likely it needs its own
validation rules (if they are needed at all).

Again, for configuration datastores, I can obtain the config and
validate it pretty much anywhere, on the device or offline at a
controller. My understanding is that this would not be true for I2RS'
ephemeral stat datastores; I would need some amount of additional data
to do something close to YANG's configuration datastore validation.

/js

PS: I think 'ephemeral state datastore' is actually a misnomer. The
    fact that the datastore I2RS is looking for is ephemeral is a
    property of this datastore but there are likely more important
    characteristics that should determine its name. But I have no good
    suggestion and this is perhaps a discussion to have at some later
    point in time.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 14:16:38 -0400

Juergen: 

I2RS Ephemeral Configuration - is configuration which needs validation, but
does not survive a reboot. 

I2RS data models which are "ephemeral at top node" and have operational
state.  In these models, the operational state is like all other operational
state.  

I suggest we focus on the I2RS ephemeral Configuration.  On this topic you
stated below: 
 
"Again, for configuration datastores, I can obtain the config and validate
it pretty much anywhere, on the device or offline at a controller. My
understanding is that this would not be true for I2RS'
ephemeral stat datastores; I would need some amount of additional data to do
something close to YANG's configuration datastore validation." 

Why is this not true for ephemeral datastore?  I am missing any reason why
you think this is true. 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 06, 2016 1:44 PM
To: Jeffrey Haas
Cc: Susan Hares; 'Joel M. Halpern'; [email-masked]
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Thu, Jun 02, 2016 at 10:27:33AM -0400, Jeffrey Haas wrote:
> > >>  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?
> > >
> > At the schema level, you will augment the schema tree. If the 
> > > current separation of /foo and /foo-state would go away, this will 
> > > likely get simpler (but this is orthogonal to the question how an 
> > > <ephemeral> datastore conceptually interacts with the other
datastores).
> > >
> > >At the data tree level, there is a magic merging (+) function 
> > >involved that takes configuration data from a configuration 
> > >datastore and data from an ephemeral data store and produces the 
> > >resulting operational state. The idea was to not further detail how 
> > >this is achieved and instead treat an ephemeral datastore pretty 
> >> much like any other control plane interface interacting with
<operational state>.
> >To confirm my understanding, ephemeral configuration state in the 
> >model you're proposing above is treated as operational state (the 
> >output of the netconf <get> operation for config true elements)?

> For configuration datastores, we have a reasonably precise definition what
validation means. And this comes for a price, e.g., config true nodes are
not allowed to refer to config false nodes. The reason is that validate
should work on the configuration data and it should not depend on the
operational state a device is in.

My understanding is that I2RS wants to inject data that modifies state that
might be purely operational state, e.g., state in a routing table obtained
from a routing protocol. If this is correct, then the ephemeral state
datastore is closer to the ephemeral state and pretty detached from
configuration datastores and likely it needs its own validation rules (if
they are needed at all).

Again, for configuration datastores, I can obtain the config and validate it
pretty much anywhere, on the device or offline at a controller. My
understanding is that this would not be true for I2RS'
ephemeral stat datastores; I would need some amount of additional data to do
something close to YANG's configuration datastore validation.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 20:31:22 +0200

> does not survive a reboot.

Sue, 'validation' is not enough; there needs to be a clearer
definition what 'validation' means.
 
> state.  In these models, the operational state is like all other operational

The phrase 'ephemeral at top node' just confuses me.

> Why is this not true for ephemeral datastore?  I am missing any reason why

Configuration datastore validation works because data is
self-consistent without references to any (external) state. Are you
saying that the same is true for I2RS' ephemeral datastores?

/js

---

From: "Fedyk, Don" <[email-masked]>
Date: Mon, 6 Jun 2016 18:51:46 +0000

Does this imply for a minor tweak of some operational datastore (temporary link metric change or something similar) , I2RS ephemeral has to have its own complete datastore?  

Don 

> Sent: Monday, June 06, 2016 2:31 PM
> To: Susan Hares <[email-masked]>
> Cc: 'Jeffrey Haas' <[email-masked]>; [email-masked]; 'Joel M. Halpern'
> <[email-masked]>
> > I2RS Ephemeral Configuration - is configuration which needs
> > validation, but does not survive a reboot.
> 
> Sue, 'validation' is not enough; there needs to be a clearer definition what
> 'validation' means.
> 
> > I2RS data models which are "ephemeral at top node" and have
> > operational state.  In these models, the operational state is like all
> > other operational state.
> 
> > I suggest we focus on the I2RS ephemeral Configuration.  On this topic
> > you stated below:
> >
> > "Again, for configuration datastores, I can obtain the config and
> > to do something close to YANG's configuration datastore validation."
> >
> > Why is this not true for ephemeral datastore?  I am missing any reason
> > why you think this is true.
> 
> Configuration datastore validation works because data is self-consistent
> without references to any (external) state. Are you saying that the same is
> true for I2RS' ephemeral datastores?
> 
> /js
> 
> --

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 14:57:40 -0400

Don: 

In my understanding, no.   

I2RS should be able to augment the normal configuration with ephemeral
configuration (see the example in my presentation of Node-Type augmenting
bgp-global-config/config). 

I2RS should be able to augment the operational data store  (see the example
of my presentation of Node-Type augmenting bgp-global-config/state).  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Fedyk, Don
Sent: Monday, June 06, 2016 2:52 PM
To: Juergen Schoenwaelder; Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

Does this imply for a minor tweak of some operational datastore (temporary
link metric change or something similar) , I2RS ephemeral has to have its
own complete datastore?  

Don 

> > operational state.  In these models, the operational state is like 
> > all other operational state.
> 
> > I suggest we focus on the I2RS ephemeral Configuration.  On this 
> > topic you stated below:
> >
> > ephemeral stat datastores; I would need some amount of additional 
> > data to do something close to YANG's configuration datastore
validation."
> >
> > Why is this not true for ephemeral datastore?  I am missing any 
> > reason why you think this is true.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 21:03:25 +0200

On Mon, Jun 06, 2016 at 06:51:46PM +0000, Fedyk, Don wrote:

> Does this imply for a minor tweak of some operational datastore
> (temporary link metric change or something similar) , I2RS ephemeral
> has to have its own complete datastore?

Yes. Because this is where the information that something got
overwritten is stored. And in this case, the datastore would
essentially consist of a single key/value pair. The phrase 'complete
datastore' may indicate something complex while it can actually be
lightweight. In any case, somewhere information must be kept that
something was overwritten - we call this something a datastore.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 15:07:13 -0400

Juergen: 

Please start by defining validation for NETCONF configuration.  Then, we can
provide the additions for ephemeral configuration state that are not in
ephemeral requirements.  See the rest of the comments below. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, June 06, 2016 2:31 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

> Sue, 'validation' is not enough; there needs to be a clearer definition
what 'validation' means.

>The phrase 'ephemeral at top node' just confuses me.

  module: ietf-i2rs-rib
      +--rw routing-instance  (what do NETCONF people call this node?) 

>Configuration datastore validation works because data is self-consistent
without references to any (external) state. 
>Are you saying that the same is true for I2RS' ephemeral datastores?

Please define what NETCONF/RESTCONF/NETMOD means by external state?  
See Ephemeral-REQ-01 to Ephemeral-REQ-04 which specify the external state
references.  
    
/js

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 15:12:23 -0400

Juergen: 

I agree you if you overwrite data, the original config data and the I2RS
values must be kept some-place.  However, this is an implementation matter
in my mind.  Why do you tag it to a different data store. 

Also, is the augmentation of any variable considered a separate data store?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, June 06, 2016 3:03 PM
To: Fedyk, Don
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'; Susan Hares
Subject: Re: [i2rs] Ephemeral State Requirements discussion

> has to have its own complete datastore?

Yes. Because this is where the information that something got overwritten is
stored. And in this case, the datastore would essentially consist of a
single key/value pair. The phrase 'complete datastore' may indicate
something complex while it can actually be lightweight. In any case,
somewhere information must be kept that something was overwritten - we call
this something a datastore.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 22:00:04 +0200

> Also, is the augmentation of any variable considered a separate data store?

See the I-D I posted.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jun 2016 22:03:53 +0200

> ephemeral requirements.  See the rest of the comments below. 

The validation of NETCONF configurations modelled in YANG 1.0 is
defined in RFC 6020 and for configurations modelled in YANG 1.1 it is
defined in draft-ietf-netmod-rfc6020bis-12.

/js

PS: Our communication is not effective, I drop out for now.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 19:05:15 -0400

Juergen: 

Thank you for the pointer,  I am assuming you are referring to section 8.3
on constraint enforcement (from RFC6020bis), and as a part of constraint
enforcement, the validation.  

I2RS ephemeral requirements 1-4 are: 
   Ephemeral-REQ-01: I2RS requires ephemeral configuration 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-REQ-02: Non-ephemeral state MUST NOT refer to  ephemeral state
for constraint purposes; 
   it SHALL be considered a validation error if it does.
   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. 
   Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state 
   for purposes of implementing constraints.

I2RS uses the definition you do of constraint and validation.  For
discussion purposes, let us consider  "ephemeral state" in these
requirements as "ephemeral configuration state".   

What needs to be expanded for Ephemeral Configuration State is the second
paragraph of section 8.3.3 to include ephemeral state.  In the end, the
ephemeral configuration parsing of rpc payloads, <edit-config>, and
validation MUST obey all validation constraints.  What we are discussing is
"when" and "how" the I2RS constraint enforcement occurs, and "when" and
"how" validation occurs.   

Sue 

================
For reference of I2RS list

8.3.  NETCONF Constraint Enforcement Model

   For configuration data, there are three windows when constraints MUST
   be enforced:
   o  during parsing of RPC payloads - 
   o  during processing of the <edit-config> operation
   o  during validation
   Each of these scenarios is considered in the following sections.

8.3.3.  Validation

   When datastore processing is complete, the final contents MUST obey
   all validation constraints.  This validation processing is performed
   at differing times according to the datastore.  

  If the datastore is "running" or "startup", these constraints MUST be
enforced at the end
   of the <edit-config> or <copy-config> operation.  If the datastore is
   "candidate", the constraint enforcement is delayed until a <commit>
   or <validate> operation.

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, June 06, 2016 4:04 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Mon, Jun 06, 2016 at 03:07:13PM -0400, Susan Hares wrote:
> Juergen: 
> 
> Please start by defining validation for NETCONF configuration.  Then, 
> we can provide the additions for ephemeral configuration state that 
> are not in ephemeral requirements.  See the rest of the comments below.
>

The validation of NETCONF configurations modelled in YANG 1.0 is defined in
RFC 6020 and for configurations modelled in YANG 1.1 it is defined in
draft-ietf-netmod-rfc6020bis-12.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Jun 2016 16:22:05 +0200

Sue,

Ephemeral-REQ-03 seems to be in conflict with what YANG validation
rules expects. If I2RS validation depends on 'temporary operational
state', then the validation result is only meaningful at a specific
point in time; YANG validation specially avoids this in order to have
the property that a configuration that is valid remains valid (and
does not become invalid if 'temporary operational state' changes.

Hence: I2RS ephemeral validation != YANG config true validation

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Jun 2016 11:29:43 -0400

Juergen: 

You are correct that I2RS ephemeral validation !:== YANG config true
validation (where !:== - means is not defined as).  This is why we defined
Ephemeral-REQ-03.  Otherwise, we would not have added it to the list of
requirements.

There is a range of state (static ----> virtual (configured/not existent)
---> LSPs).  You may want to look at OSPF Yang to consider the
virtual-links.  IMHO, NETCONF is being provided with requirements to that
suggest  changes to constraint checking for Ephemeral Configuration State.
In many messages, you asked for requirement and not design. 

In your discussions, I have not heard any suggestions regarding new text for
the ephemeral state document.  Did you have any specific suggestions?  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, June 07, 2016 10:22 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

Sue,

Ephemeral-REQ-03 seems to be in conflict with what YANG validation rules
expects. If I2RS validation depends on 'temporary operational state', then
the validation result is only meaningful at a specific point in time; YANG
validation specially avoids this in order to have the property that a
configuration that is valid remains valid (and does not become invalid if
'temporary operational state' changes.

/js

On Mon, Jun 06, 2016 at 07:05:15PM -0400, Susan Hares wrote:
> Juergen: 
> 
> Thank you for the pointer,  I am assuming you are referring to section 
> 8.3 on constraint enforcement (from RFC6020bis), and as a part of 
> constraint enforcement, the validation.
> 
>    Ephemeral-REQ-01: I2RS requires ephemeral configuration state; i.e. 
> state that does not persist
>    Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to  ephemeral 
> state for constraint purposes;
>    Ephemeral-REQ-03: Ephemeral state must be able to utilized 
> temporary operational state
> What needs to be expanded for Ephemeral Configuration State is the 
> second paragraph of section 8.3.3 to include ephemeral state.  In the 
> end, the ephemeral configuration parsing of rpc payloads, 
> <edit-config>, and validation MUST obey all validation constraints.  
> What we are discussing is "when" and "how" the I2RS constraint enforcement
occurs, and "when" and
>   If the datastore is "running" or "startup", these constraints MUST 
> be enforced at the end
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > Please start by defining validation for NETCONF configuration.  
> > Then, we can provide the additions for ephemeral configuration state 
> > that are not in ephemeral requirements.  See the rest of the comments
below.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Jun 2016 17:56:38 +0200

> the ephemeral state document.  Did you have any specific suggestions?  

No, I think I am giving up.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 7 Jun 2016 12:46:24 -0400

Juergen: 

<author hat on> 

Just to clarify your statement, you are giving up on your review regarding
the ephemeral state document, and you do not have any additional input.
Your past comments can be summarized as;  

.         Please define ephemeral state, ephemeral configuration state, and
ephemeral operational state. 

.         Please state as requirements only things which are changes to
Yang, NETCONF, or RESTCONF. 

I do not believe I had any other actionable suggestions for this document.
If there are more, please let me know. 

Thank you for your questions and active participation. 

Sue 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, June 07, 2016 11:57 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email-masked]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Tue, Jun 07, 2016 at 11:29:43AM -0400, Susan Hares wrote:

> In your discussions, I have not heard any suggestions regarding new 

> text for the ephemeral state document.  Did you have any specific
suggestions?

/js

-- 

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