[as a contributor] I’m for ‘B’ as well, in case it wasn’t obvious from [2] (Lou’s ref below).
Kent From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <kkous...@cisco.com> Date: Friday, June 17, 2016 at 2:36 PM To: Lou Berger <lber...@labn.net> Cc: "netmod-cha...@ietf.org" <netmod-cha...@ietf.org>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput Resent-From: <alias-boun...@ietf.org> Resent-To: <j.schoenwael...@jacobs-university.de>, <lber...@labn.net>, Kent Watsen <kwat...@juniper.net>, <mishra.ash...@outlook.com> Resent-Date: Friday, June 17, 2016 at 2:36 PM Hi All I’d like to support Option B below. >> 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]. Thanks Kiran >> 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<mailto:netmod@ietf.org> >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
