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 <lber...@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.litkow...@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-boun...@ietf.org] On Behalf Of Lou Berger
>> Sent: Tuesday, June 07, 2016 16:20
>> To: netmod WG
>> Cc: netmod-cha...@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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
