Hi Lou, I would say 2 steps ahead. Step 1 seems to be to reconfirm the meeting room consensus from Yokohama (model-based vs. protocol-based)
Step 2 is usually picking a starting point for a solution draft. Step 3 is when people can start detailed solution reviews. IMO [4] is a good starting point but there are many open issues that need to be resolved, possibly addressed in the other drafts. Andy On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger <[email protected]> wrote: > Sue, > > I think you're looking a step beyond the scope of decision we're > considering now. This is a fine thing, and certainly the right thing to > be thinking about from the I2RS (or any other WG working on YANG models > that is considering operational state for that matter) perspective. > > The decision at hand is to choose between directions A and B. I think > you are saying you that you like direction B but that the details aren't > sufficient for your (WG's) needs. Is this correct? > > If so, then I think you're point is that [4] and [5] need work. We > agree with this statement and we believe consistent with the statement in > B: > > -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > So, once the WG closes on direction B (before Berlin), the WG can then > start discussing details of the WG's version of [4] and [5] -- and > issues on ephemeral support makes sense to discuss then if they still > haven't been addressed. Of course discussion on the individual drafts > don't need to wait for the decision on basic direction. > > Make sense? > > Lou > > On 6/8/2016 12:10 PM, Susan Hares wrote: > > Lou: > > > > Thank you for your work on the two options. I'd like to comment on the > > following statement in your message statement, and reference a few > things in > > [4] and [5] regarding ephemeral state: > > > > You state: > > " 2) Model OpState using a revised logical datastore definition > > as introduced in [4] and also covered in [5]. There is > > also a variant of this that we believe doesn't significantly > > impact this choice. > > With this approach, model definitions need no explicit > > changes to support applied configuration." > > > > In [4], the author states: > > > > "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]" > > > > In [5], the author states: > > > > "5.5. Ephemeral Configuration Datastore (Optional) > > This document does not intend to formally define an Ephemeral > > Configuration Datastore. In particular, it must be noted that the > > ephemeral configuration datastore described here does not match that > > described in version -09 of draft-ietf-i2rs-ephemeral-state > > [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually > > how such a datastore (restricted to configuration only) might fit > > into a conceptual refined datastore model." > > > > Therefore, the result of I2RS WG spending 2 years writing requirements > for > > the ephemeral data store that both option 2 documents "do not match" the > > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > > state. [5] provides an ephemeral architecture closer to I2RS ephemeral > > requirements, but does not understand that > draft-ietf-i2rs-ephemeral-state > > is a requirements document. Your statement " With this approach, model > > definitions need no explicit changes to support applied configuration" > > cannot be true if you consider the I2RS data models (RIB, topology). > > > > How is option (2) a reasonable design for ephemeral state? I have spent > the > > last week answering questions to Juergen [4] on the I2RS ephemeral state. > > After our discussion, he did not have any specific suggestions to change > > these requirements > > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). > > > > Can I have an option 2b that considers ephemeral state based on the > > requirements listed by I2RS? > > > > Sue Hares > > I2RS WG-chair > > > > -----Original Message----- > > From: Rtg-yang-coord [mailto:[email protected]] On Behalf > Of > > Lou Berger > > Sent: Wednesday, June 08, 2016 9:06 AM > > To: [email protected] > > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: > > update and request for WG input > > > > FYI this decision is likely to have some impact on models under > development, > > including in the routing area. Comments on the message itself should go > to > > netmod. > > > > Lou > > > > > > --- Forwarded message --- > > From: Lou Berger <[email protected]> > > Date: June 7, 2016 10:20:23 AM > > Subject: [netmod] Opstate solutions discussions: update and request for > WG > > input > > To: netmod WG <[email protected]> > > CC: [email protected] > > > > All, > > > > We want to provide an update based on the off line discussions related to > > OpState Solutions that we have been having and solicit input from the WG. > > > > All authors of current solution drafts [1,2,3] together with those who > > helped conduct the solutions analysis* were invited to the these > discussions > > -- with the objective of coming up with a single consolidated proposal to > > bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and > > are involved with the technical details.) > > > > The discussions have yielded some results but, unfortunately, not a > single > > consolidated proposal as hoped, but rather two alternate directions -- > and > > clearly we need to choose one: > > > > 1) Adopt the conventions for representing state/config > > based on Section 6 of [1]. > > > > From a model definition perspective, these conventions > > impact every model and every model writer. > > > > 2) Model OpState using a revised logical datastore definition > > as introduced in [4] and also covered in [5]. There is > > also a variant of this that we believe doesn't significantly > > impact this choice. > > > > With this approach, model definitions need no explicit > > changes to support applied configuration. > > > > >From a technology/WG standpoint, we believe an approach > > that doesn't impact every model written (i.e., #2) is superior. > > The counterpoint to this is that the conventions based approach (i.e., > #1) > > is available today and being followed in OpenConfig defined models. > > > > We would like to hear opinions on this from the WG before declaring one > of > > the following as the WG direction: > > > > A) models that wish to support applied configuration MUST > > follow conventions based on [1] -- and the WG needs to > > formalize these conventions. > > or > > B) no explicit support is required for models to support > > applied configuration -- and that the WG needs to > > formalize an opstate solution based on the approach > > discussed in [4] and [5]. > > > > We intend to close on this choice before Berlin. > > > > Thank you, > > Lou (and co-chairs) > > > > [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01 > > [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 > > [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 > > [4] > https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 > > [5] > https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 > > * - Chris H. and Acee L. > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtg-yang-coord >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
