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

[Lou Berger <[e-mail]>]

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