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 <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
