Acee,
I personally was assuming we'd follow 3, but I'd like to understand
the implication of 2 as I'm not sure I really understand what you're
thinking here. Can you elaborate what you're thinking here?
Thanks,
Lou
On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
> While there are details to be worked out between the two data stores
> models (as indicated below), we now have implicit modeling of applied
> configuration. Existing models (both standard and draft) do not take this
> into consideration and, consequently, much of the state that is modeled
> explicitly represents the application configuration. For the RFC models,
> it probably doesn’t make much sense to redo them (unless they are being
> reworked for other reasons). This still leaves the existing WG draft
> models for which we have basically 3 options:
>
> 1. Do nothing - allow them proceed as they are with multiple ways of
> representing the applied configuration. This would provide visibility to
> the data independent of whether or not the device supported the revised
> data-stores supporting implicit retrieval of the applied configuration.
> 2. Prune out the redundant data nodes except those required as list
> keys, etc, since they can be obtained from the applied state data store.
> 3. #2 plus collapse the config (read-write) and system-state
> (read-only) into common containers. No more branching of
> <model-name>-config and <model-name>-state at the top level of the model.
>
> At I high-level, I feel these are the options. I’m not married to any one
> of these and the worse thing we could do is hold up progression of the
> existing YANG model drafts for another couple years while we debate the
> best course. Having said that, #3 is compelling since it will yield the
> most concise models and colocates the schema data nodes for any managed
> object.
>
> Thanks,
> Acee
>
> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
> <netmod-boun...@ietf.org on behalf of lber...@labn.net> wrote:
>
>> All,
>>
>> It's time to make a consensus call on this topic, so that we can all move
>> on to defining a solution and aligning modules under development. Based
>> on the feedback received and the overall discussions on the topic, we see
>> that there is consensus to follow a datastore based approach to
>> supporting operational state, i.e., direction 'B'.
>>
>> We will be asking the authors of [4] and [5] to review their proposals
>> (individual drafts) in Berlin, as well as to highlight differences and
>> suggest ways that their work could be consolidated. Of course, others may
>> also choose to submit their own proposals. Given the importance of this
>> work, we will be looking to have active discussion on the topic both in
>> Berlin and on the list, with an objective of having a draft ready for
>> considerations as a WG document by the November IETF.
>>
>> We have reviewed this decision with our AD and the NetConf chairs and
>> have agreed to begin this work in NetMod. We certainly expect to
>> coordinate the work with the NetConf WG and re-home work as/if needed.
>>
>> Finally, we'd also like to thank all those who have contributed to this
>> discussion to date, from problem identification to proposed solutions,
>> and we look forward to your continued efforts to publish a standard
>> solution.
>>
>> Lou (and Kent)
>>
>>
>> On 6/7/2016 10:19 AM, Lou Berger 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
> _______________________________________________
> 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
