[netmod] Corollary to [OpsState Direction Impact on Recommended IETF YANG Model Structure]

[Robert Wilton <[e-mail]>]

[Re-titled thread for a separate applied config observation, and to 
avoid derailing the intend of the original thread]

If the conclusion below reaches consensus, and all models have both 
"feature" and "feature-state" trees (as required), then I wonder whether 
it wouldn't also make sense to represent applied configuration on the 
path "feature-applied" as a direct duplication of the schema for the 
config nodes that live under "feature".  I.e. I specifically *don't* 
mean writing this into the schema by hand, but just have systems 
(clients and servers) that support applied configuration instantiate a 
copy of all of the config schema nodes on to the "feature-applied" path.

This would arguably be more in keeping with separate "feature" and 
"feature-state" trees, and also wouldn't require clients to manage 
separate trees for each datastore.  It also means that the 
intended/applied/and derived state all have independent, but 
mechanically relate-able, paths.

Rob


On 21/07/2016 18:39, Robert Wilton wrote:
> Hi,
>
> So after the various meetings and discussions this week, I think that 
> the most important thing for IETF to do is to publish reviewed YANG 
> models quickly, with the understanding that it is better to publish 
> imperfect models than to end up not publishing any models at all.  
> This is with the understanding that these models could be fixed by 
> subsequent RFCs if required.
>
> So, I effectively support Acee's solution (2).  But to state this more 
> precisely, I would suggest that the specific guidance should be:
> 1) IETF Models MUST NOT have a split for applied configuration 
> leaves.  All IETF models that have not been turned into RFCs must be 
> modified to remove any applied configuration nodes.  Any models that 
> have this convention in RFCs should be revised to follow a consistent 
> intended/applied convention for IETF models.  [The justification here 
> is that IETF standard models have to be able to assume that the 
> applied configuration will be available via a separate applied 
> configuration (or operational state) datastore or equivalent mechanism.]
> 2) All IETF Models MUST put "derived state and statistics" into a 
> separate namespace from the configuration (i.e. top level "feature" 
> and "feature-state").  The two trees must be as structurally similar 
> as possible, sharing the same paths, node names (except the top level 
> node), using the same lists keys where appropriate, etc.*
> 3) Both of these rules should be written into rfc6087bis.  We should 
> then get this guidelines document finished as quickly as possible at 
> the highest priority, and use that as the definitive guideline for the 
> modules that the working groups are working on.
>
> * Note, I chose this option not because I think that it is elegant 
> (because I don't) but because it seems to me that it is the only 
> pragmatically option that we have available.  The alternatives appear 
> to be: (i) we wait another year before publishing any models (if 
> ever), or (ii) we publish models that no-one can use today without 
> violating the existing RFCs, or (iii) we end up with a hybrid mess 
> without any consistency.
>
> Thanks,
> Rob
>
>
> On 11/07/2016 18:36, 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"
>> <[e-mail] on behalf of [e-mail]> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod