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

[Mahesh Jethanandani <[e-mail]>]

+1 (a.k.a. support option B)

> On Jun 7, 2016, at 9:23 AM, Andy Bierman <[e-mail]> wrote:
> 
> Hi,
> 
> I prefer (B).
> I do not think it is realistic that vendors will rewrite their IETF
> modules and vendor modules and all the associated client/server instrumentation.
> This is expensive at many levels. Stability is important for an API.
> 
> So if we do (A), there will be some modules following the convention
> and the rest using proprietary RPC-based solutions.
> But if we do (B), vendors can integrate the standard RPC-based solution
> into their existing running code with zero disturbance.
> 
> 
> Andy
> 
> 
> 
> On Tue, Jun 7, 2016 at 7:19 AM, Lou Berger <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01>
> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02 <https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02>
> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02 <https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02>
> [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00 <https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00>
> [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00 <https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00>
> * - Chris H. and Acee L.
> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[e-mail]