From nobody Fri Jul 1 09:39:37 2016 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD212B069 for ; Fri, 1 Jul 2016 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viAaU0Gu4T7Q for ; Fri, 1 Jul 2016 09:39:34 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 2416312D766 for ; Fri, 1 Jul 2016 09:39:34 -0700 (PDT) Received: (qmail 23071 invoked by uid 0); 1 Jul 2016 16:39:31 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 1 Jul 2016 16:39:31 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id DUfS1t00n2SSUrH01UfV8M; Fri, 01 Jul 2016 10:39:29 -0600 X-Authority-Analysis: v=2.1 cv=OPe0g0qB c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=cAmyUtKerLwA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=2e0-p80xrcNJJP8vqxkA:9 a=rsa8LudIkhsgxw8_:21 a=aGguCUFjmwur6afT:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:To:References:Subject; bh=3cIp16H7OPUQkEyGL06Cx9Y2srr0Tl5UFFb3kLarFLY=; b=DU6hneJoQaw/sIM14LpnoM26d7 23QQWWWGMiM3iGF8LpP2881G+zXt7mvAB9xRRb7PDuo6m7fUefUfrUmE/wG0eqkRapxG5VccHEDfO SJTOkRYE8131Hl+AdgHLCqklG; Received: from box313.bluehost.com ([69.89.31.113]:42547 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bJ1TT-0005Pb-VF for rtg-yang-coord@ietf.org; Fri, 01 Jul 2016 10:39:28 -0600 References: To: Routing YANG Coordination From: Lou Berger X-Forwarded-Message-Id: Message-ID: <6c99eaaf-f4e1-051e-d226-9688acfcead4@labn.net> Date: Fri, 1 Jul 2016 12:39:21 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1bJ1TT-0005Pb-VF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:42547 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [Rtg-yang-coord] Fwd: [netmod] Closing on an OpState Solution Direction (was: Opstate solutions discussions: update and request for WG input) X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 16:39:36 -0000 FYI - comments should be directed to -------- Forwarded Message -------- Subject: [netmod] Closing on an OpState Solution Direction (was: Opstate solutions discussions: update and request for WG input) Date: Fri, 1 Jul 2016 12:36:11 -0400 From: Lou Berger To: netmod WG CC: netmod-chairs@ietf.org All, It's time to make a consensus call on this topic, so that we can all move on to defining a solution and aligning modules under development. Based on the feedback received and the overall discussions on the topic, we see that there is consensus to follow a datastore based approach to supporting operational state, i.e., direction 'B'. We will be asking the authors of [4] and [5] to review their proposals (individual drafts) in Berlin, as well as to highlight differences and suggest ways that their work could be consolidated. Of course, others may also choose to submit their own proposals. Given the importance of this work, we will be looking to have active discussion on the topic both in Berlin and on the list, with an objective of having a draft ready for considerations as a WG document by the November IETF. We have reviewed this decision with our AD and the NetConf chairs and have agreed to begin this work in NetMod. We certainly expect to coordinate the work with the NetConf WG and re-home work as/if needed. Finally, we'd also like to thank all those who have contributed to this discussion to date, from problem identification to proposed solutions, and we look forward to your continued efforts to publish a standard solution. Lou (and Kent) On 6/7/2016 10:19 AM, Lou Berger wrote: > 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jul 6 11:20:18 2016 Return-Path: X-Original-To: rtg-yang-coord@ietfa.amsl.com Delivered-To: rtg-yang-coord@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18C12B035 for ; Wed, 6 Jul 2016 11:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJn9xkSfLnTh for ; Wed, 6 Jul 2016 11:20:14 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA3412B04F for ; Wed, 6 Jul 2016 11:20:14 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f89so120648110qtd.2 for ; Wed, 06 Jul 2016 11:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rqyPfZ4W/AdisVv6rizxHlQyNB/Xp3YMO+TtEqKJzAA=; b=L1gLetBMD7YyYE9C/4B2j7f2k3yxQ6fXApXjwcRgNYAgQSISLkZzQvCvKjTRlC02za bu4MLCHXDYF1GNMRN6knEDvdJPdQbi6/Gz/TpRPbMer2nw9s9sJdxv9B4coo1OKlzmsf c2tXoxGVffcXiy3EdVi2/swNHhqXFcO+cuiYvUNsO4YE6CQHh4p0DbgtjYrIncCY47G8 MwCSuSRZQiT5Hac3OOP8Pw1s3RnbH95cR214jzRPWvbPVu0u48of4DVj9cOTnm3S6DkP CFnlMOmIt6VqebnLQ6dmQ2/N3+Ekk7XUFAUnMwZdFZAIrNhIn2F5WZmWrC+9+xUo5MhD /07Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rqyPfZ4W/AdisVv6rizxHlQyNB/Xp3YMO+TtEqKJzAA=; b=ZMCXjYJxZkv7JjmflaD9Vr8OfZGz/6pwLlxGwlzM57Ter5Zw7nxmQnR/D9GICtaev7 pd8ZPYvkCkOL2HTXw+UhlXMoMdkNGEKxIOMvQ45F1XHTaf4iJ+mE6mmjX9WhMtoH/F8k aY8RZCb74Cv4zjAkdXM20UlPJskbUi0/SlYIFNoBcyUWpEjkxzHIQxTQzQC8Rrr+DQcO 7ZbXHwGY0Nqa5wmCerulR1mZ01pQX75GoJgw4bXkBDzP+WBboyqBYCPdeJN+wfR2+J80 fiHrgVjHS0jz43PJxG11sX7tEYp1n56RBZBIuFn+Zy8sj+5NWDXnHYHssmslM3elYJxq ykqw== X-Gm-Message-State: ALyK8tI7Klv4CqyLrJFVq3MlfKPWk0/pwhl0YW25HBu5QMS8w1VBSsDs5c4BdcG5rrlyj0F8+BtW3HPEb8n7iA== X-Received: by 10.237.34.44 with SMTP id n41mr38639879qtc.25.1467829213213; Wed, 06 Jul 2016 11:20:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Wed, 6 Jul 2016 11:20:12 -0700 (PDT) In-Reply-To: References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> From: Alia Atlas Date: Wed, 6 Jul 2016 14:20:12 -0400 Message-ID: To: "Rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=001a1135761ad849310536fb9e52 Archived-At: Subject: [Rtg-yang-coord] Fwd: [netmod] Closing on an OpState Solution Direction X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "\"List to discuss coordination between the Routing related YANG models\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 18:20:17 -0000 --001a1135761ad849310536fb9e52 Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: Benoit Claise Date: Wed, Jul 6, 2016 at 5:31 AM Subject: Re: [netmod] Closing on an OpState Solution Direction To: Lou Berger , netmod WG Cc: "netmod-chairs@ietf.org" Thanks Lou and Kent. As mentioned in YANG Data Models in the Industry: Current State of Affairs : "Once those two issues are resolved, this will for sure open the gate to publish all these much-needed models." While the operation status is not yet solved, the key message is that the YANG modules don't need to be modified. So, now is THE time to publish those YANG models. Regards, Benoit All, It's time to make a consensus call on this topic, so that we can all move on to defining a solution and aligning modules under development. Based on the feedback received and the overall discussions on the topic, we see that there is consensus to follow a datastore based approach to supporting operational state, i.e., direction 'B'. We will be asking the authors of [4] and [5] to review their proposals (individual drafts) in Berlin, as well as to highlight differences and suggest ways that their work could be consolidated. Of course, others may also choose to submit their own proposals. Given the importance of this work, we will be looking to have active discussion on the topic both in Berlin and on the list, with an objective of having a draft ready for considerations as a WG document by the November IETF. We have reviewed this decision with our AD and the NetConf chairs and have agreed to begin this work in NetMod. We certainly expect to coordinate the work with the NetConf WG and re-home work as/if needed. Finally, we'd also like to thank all those who have contributed to this discussion to date, from problem identification to proposed solutions, and we look forward to your continued efforts to publish a standard solution. Lou (and Kent) On 6/7/2016 10:19 AM, Lou Berger wrote: 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod . _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --001a1135761ad849310536fb9e52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

---------- Forwarded messag= e ----------
From: Benoit Claise <bclaise@cisco.com= >
Date: Wed, Jul 6, 2016 at 5:31 AM
Subject: Re: [netmod] C= losing on an OpState Solution Direction
To: Lou Berger <lberger@labn.net>, netmod WG <netmod@ietf.org>
Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>


=20 =20 =20
Thanks Lou and Kent.

As mentioned in YANG Data Models in the Industry: Current State of Affairs: "On= ce those two issues are resolved, this will for sure open the gate to publish all these much-needed models."
While the operation status is not yet solved, the key message is that the YANG modules don't need to be modified.
So, now is THE time to publish those YANG models.

Regards, Benoit
All,

It's time to make a consensus call on this topic, so that we can all mo=
ve on to defining a solution and aligning modules under development. Based =
on the feedback received and the overall discussions on the topic, we see t=
hat there is consensus to follow a datastore based approach to supporting o=
perational state, i.e., direction 'B'.=20

We will be asking the authors of [4] and [5] to review their proposals (ind=
ividual drafts) in Berlin, as well as to highlight differences and suggest =
ways that their work could be consolidated. Of course, others may also choo=
se to submit their own proposals. Given the importance of this work, we wil=
l be looking to have active discussion on the topic both in Berlin and on t=
he list, with an objective of having a draft ready for considerations as a =
WG document by the November IETF.=20

We have reviewed this decision with our AD and the NetConf chairs and have =
agreed to begin this work in NetMod. We certainly expect to coordinate the =
work with the NetConf WG and re-home work as/if needed.=20

Finally, we'd also like to thank all those who have contributed to this=
 discussion to date, from problem identification to proposed solutions, and=
 we look forward to your continued efforts to publish a standard solution.=
=20

Lou (and Kent)


On 6/7/2016 10:19 AM, Lou Berger wrote:

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-o=
pstate-01
[2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate=
-02
[3] https://tools.ietf.org/html/draft-wilton-netmod-opst=
ate-yang-02
[4] https://tools.ietf.org/html/draft-schoenw-net=
mod-revised-datastores-00
[5] https://tools.ietf.org/html/draft-wilton-netmo=
d-refined-datastores-00
* - Chris H. and Acee L.


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


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


--001a1135761ad849310536fb9e52--