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

Hi Tom, 
At least most of the YANG model authors that I work with are following
this discussion. However, I would guess that many are waiting for the
outcome and how it affects model structure as opposed to having a strong
opinion on the options.
Thanks,
Acee 

On 6/17/16, 11:15 AM, "netmod on behalf of t.petch"
<netmod-bounces@ietf.org on behalf of ietfc@btconnect.com> wrote:

>Lou
>
>By now, 17th June, I see solid support for one option but only see
>comments from a somewhat small number of participants
>
>The majority of the authors of the 172 YANG files I have in an
>archive are probably unaware of this discussion and yet some at least
>will be affected.  What concerns me is that history might be repeating
>itself.  In a sense, this discussion is about the original proposals for
>NETCONF and YANG not meeting current requirements which
>may be because there has mostly been a limited number of
>participants in netmod discussions.
>
>I was struck by Dale's recent, brilliant review of 6020bis because it
>came from a fresh angle and brought up nagging concerns that I had had
>but had not been able to articulate.  With a wider audience, similar
>comments might have been made much earlier to the advantage
>of YANG (perhaps even about RFC6020).
>
>In the same vein, there is NETCONF.  Juergen's I-D, which I see finding
>favour, could be said to cut the ground from under NETCONF (well, I
>would).  RFC6241 says
>" Configuration data is the set of writable data that is required to
>   transform a system from its initial default state into its current
>   state.  State data is the additional data on a system that is not
>   configuration data such as read-only status information and collected
>   statistics.  "
>
>The proposed 'intended' in the I-D is (ct, ro).  It is ct, configuration
>true, so it is configuration data.  It is ro, read only, so it is
>clearly not
>configuration data.  Without changing RFC6241, I cannot reconcile this.
>
>So I see RFC6241 being changed; can anyone reading the RFC understand it
>any more?  And yet the I-D makes no mention of this change to
>NETCONF nor have I seen any discussion on the netconf list.
>
>Stimulated by posts to the I2RS list, perhaps also a trigger for
>Juergen's I-D, I wrote up my own summary of the current state of
>datastores but I called it draft-tp-netconf-datastore because I see
>NETCONF
>currently telling us almost all that we know about datastores; YANG 1.0
>adds very little.  For me, NETCONF should be the starting point.
>
>Tom Petch
>
>----- Original Message -----
>From: "Lou Berger" <lberger@labn.net>
>To: "netmod WG" <netmod@ietf.org>
>Cc: <netmod-chairs@ietf.org>
>Sent: Tuesday, June 07, 2016 3:19 PM
>
>> 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