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

[Lou Berger <[e-mail]>]

Tom,

    Thanks for the perspective.  I'm a little unsure if you're expecting
a response or just making a statement, so if you're looking for
something specific and don't see it below -- please let me know.

On 6/17/2016 11:15 AM, t.petch wrote:
> Lou
>
> By now, 17th June, I see solid support for one option but only see
> comments from a somewhat small number of participants
This is true, and I've heard privately that some more may/should be
forthcoming.

> 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.

So two points on this:
- Today is different in that there are a great number of players
using/looking to YANG at the moment --- so I think we have more lurkers
out there than you'd expect.

- The fact that 172 documents (and that's just in the IETF) would be
impacted by option (A) is exactly why we think it's the wrong way to go.
Think about if we came up with a solution that requires each modeler to
build their definitions a fixed way how this would be
socialized/enforced.  Now think about doing that in other SDOs.

> 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.
It's just a ro version/view of the config data.  I'm not sure why this
is problematic.  Perhaps I'm just missing something.

> 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.
The first question is deciding on an approach (A vs B), the second
question is on the details of the selected option.  If we move forward
with B, I think which WG does the data store work is a fine topic to
consider.  But we (netmod)  first need to close on A vs B -- which will
be easy if there are no new comments in short order.

Lou
> Tom Petch
>
> ----- Original Message -----
> From: "Lou Berger" <[e-mail]>
> To: "netmod WG" <[e-mail]>
> Cc: <[e-mail]>
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>