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

[t.petch <[e-mail]>]

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" <[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