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

[Kent Watsen <[e-mail]>]

[as a contributor]

I’m for ‘B’ as well, in case it wasn’t obvious from [2]  (Lou’s ref below).

Kent


From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[e-mail]>
Date: Friday, June 17, 2016 at 2:36 PM
To: Lou Berger <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, Kent Watsen <[e-mail]>, <[e-mail]>
Resent-Date: Friday, June 17, 2016 at 2:36 PM

Hi All
I’d like to support Option B below.
>>     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].

Thanks
Kiran


>> 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
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netmod
>


_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod