Re: [netmod] Opstate solutions discussions: update and request for WG input

For applied configuration, I'd also prefer [B], especially [4], which clarifies datastores in a better way. [4] also paves a way for better modeling of derived state.  Once the approach for applied configuration is formalized, the derived state, as a part of OpState modeling, will need to be formalized. At that time, the modeling ideas from [1] could be applied, to re-consider the top-level branch for config-false tree. In this regard, 1) and 2) can be combined.

Thanks,

- Xufeng

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Tuesday, June 7, 2016 10:20 AM
> To: netmod WG <netmod@ietf.org>
> Cc: netmod-chairs@ietf.org
> Subject: [netmod] Opstate solutions discussions: update and request for WG
> input
> 
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod