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

[Lou Berger <[e-mail]>]

Agreed and already forwarded to the routing area yang coordination
list.  would you suggest any other lists?

Lou


On 6/15/2016 1:57 PM, Nadeau Thomas wrote:
> 	Lou,
>
> 	Given the wide-ranging impact of this sort of decision across not just the IETF, let me suggest that it might be a good idea to get data points from a sample that is a bit larger than 4 or 5.  Forwarding this query to some other relevant WGs might be in order given the lack luster responses to-date.
>
> 	—Tom
>
>
>> On Jun 15, 2016:6:37 AM, at 6:37 AM, Lou Berger <[e-mail]> wrote:
>>
>> Stephane,
>>
>> Response has been a bit light, albeit all for (B).  I'm hoping we'd here from some additional WG participants - so we need a little bit more time.  I'm still expecting for this discussion to be closed before Berlin.
>>
>> Also, can we infer from you message that you are also in favor of (B)?
>>
>> Thanks,
>> Lou
>>
>>
>> On June 15, 2016 4:22:27 AM <[e-mail]> wrote:
>>
>>> Hi Lou, chairs,
>>>
>>> Based on the feedback on the list, could we conclude that we go to B) or do you want to wait more ?
>>> We would like to close work on multiple YANG models, and today ops state are blocking ... would be good to close it asap.
>>>
>>> Best Regards,
>>>
>>> Stephane
>>>
>>> -----Original Message-----
>>> From: netmod [mailto:[e-mail]] On Behalf Of Lou Berger
>>> Sent: Tuesday, June 07, 2016 16:20
>>> To: netmod WG
>>> Cc: [e-mail]
>>> Subject: [netmod] Opstate solutions discussions: update and request for WG input
>>>
>>> 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
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>>>
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>