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

	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 <lberger@labn.net> 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 <stephane.litkowski@orange.com> 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:netmod-bounces@ietf.org] On Behalf Of Lou Berger
>> Sent: Tuesday, June 07, 2016 16:20
>> To: netmod WG
>> Cc: netmod-chairs@ietf.org
>> 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
>> netmod@ietf.org
>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod