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

I agree that option B is the best way forward. The sooner we reach the
consensus the sooner we can discuss how this can simply models that are
waiting for the IETF OpsState direction.
Thanks,
Acee 

On 6/8/16, 11:20 AM, "netmod on behalf of chopps@chopps.org"
<netmod-bounces@ietf.org on behalf of chopps@chopps.org> wrote:

>
>Martin Bjorklund <mbj@tail-f.com> writes:
>
>> Andy Bierman <andy@yumaworks.com> wrote:
>>> Hi,
>>>
>>> I prefer (B).
>>
>> For the record, I also prefer B.
>
>I also prefer B.
>
>In addition to the points below, it also "Just Works" for all
>existing and future models including ones designed outside of the
>purview of the IETF.
>
>Thanks,
>Chris.
>
>>
>> B is a more robust solution, since it can handle not only intended and
>> applied, but also other existing (e.g. startup) and future
>> (e.g. ephemeral) datastores.
>>
>>
>> /martin
>>
>>
>>> 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 <lberger@labn.net> 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
>>> > [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
>>> >
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>