From nobody Wed Jun 8 06:06:12 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 E0AF212D0F5 for ; Wed, 8 Jun 2016 06:06:11 -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 cP810N_0VLJj for ; Wed, 8 Jun 2016 06:06:10 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 1F21A12D0FB for ; Wed, 8 Jun 2016 06:06:06 -0700 (PDT) Received: (qmail 8035 invoked by uid 0); 8 Jun 2016 13:06:05 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 8 Jun 2016 13:06:05 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 4D611t01N2SSUrH01D64Qk; Wed, 08 Jun 2016 07:06:05 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=bjOTHDNsHRUA:10 a=pD_ry4oyNxEA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=UpDgKoEnUKNL7nFQn14A:9 a=ePRFXQdX5Jlhjh0d:21 a=-HK9cRhjIXiZLujl:21 a=CjuIK1q_8ugA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From; bh=XSM4a2+kAy3g2EaMhDGDcpeODi25Jf9fw1rEQzK8mCo=; b=gRSXlod0Vf2bwFXOR1OCyz1lpy 8/34VFaVINuv0g5HMrX8UyofNTssrjo2f9G8iqVKAnTEFrwsyhsMNeqwHtxdbnjPteX/smlDX7QPQ 9QXMNklqAapyO2L27BNrUZZDO; Received: from [172.58.184.72] (port=46238 helo=[192.0.0.4]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1bAdBJ-0000Lc-9T for Rtg-yang-coord@ietf.org; Wed, 08 Jun 2016 07:06:01 -0600 From: Lou Berger To: Date: Wed, 08 Jun 2016 09:05:56 -0400 Message-ID: <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> User-Agent: AquaMail/1.6.2.3 (build: 27000203) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 172.58.184.72 authed with lberger@labn.net} Archived-At: Subject: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 13:06:12 -0000 FYI this decision is likely to have some impact on models under development, including in the routing area. Comments on the message itself should go to netmod. Lou --- Forwarded message --- From: Lou Berger Date: June 7, 2016 10:20:23 AM Subject: [netmod] Opstate solutions discussions: update and request for WG input To: netmod WG CC: netmod-chairs@ietf.org 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 From nobody Wed Jun 8 09:10:54 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 8070512DA34; Wed, 8 Jun 2016 09:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no 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 p0Y37d0eoMFa; Wed, 8 Jun 2016 09:10:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 BA59812DA1F; Wed, 8 Jun 2016 09:10:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Lou Berger'" , References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Wed, 8 Jun 2016 12:10:09 -0400 Message-ID: <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6IwJELg8in36m9tA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Benoit Claise' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 16:10:37 -0000 Lou: Thank you for your work on the two options. I'd like to comment on the following statement in your message statement, and reference a few things in [4] and [5] regarding ephemeral state: You state: " 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." In [4], the author states: "o The model foresees ephemeral datastores that are by definition not part of the persistent configuration of a device. These ephemeral datastores are considered to interact with the rest of the system like any other control-plane mechanisms (e.g., routing protocols, discovery protocols). [XXX Note that this is different from what is described in some of the I2RS documents. XXX]" In [5], the author states: "5.5. Ephemeral Configuration Datastore (Optional) This document does not intend to formally define an Ephemeral Configuration Datastore. In particular, it must be noted that the ephemeral configuration datastore described here does not match that described in version -09 of draft-ietf-i2rs-ephemeral-state [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually how such a datastore (restricted to configuration only) might fit into a conceptual refined datastore model." Therefore, the result of I2RS WG spending 2 years writing requirements for the ephemeral data store that both option 2 documents "do not match" the I2RS ephemeral requirements set. [4] lumps ephemeral with operational state. [5] provides an ephemeral architecture closer to I2RS ephemeral requirements, but does not understand that draft-ietf-i2rs-ephemeral-state is a requirements document. Your statement " With this approach, model definitions need no explicit changes to support applied configuration" cannot be true if you consider the I2RS data models (RIB, topology). How is option (2) a reasonable design for ephemeral state? I have spent the last week answering questions to Juergen [4] on the I2RS ephemeral state. After our discussion, he did not have any specific suggestions to change these requirements (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). Can I have an option 2b that considers ephemeral state based on the requirements listed by I2RS? Sue Hares I2RS WG-chair -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, June 08, 2016 9:06 AM To: Rtg-yang-coord@ietf.org Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input FYI this decision is likely to have some impact on models under development, including in the routing area. Comments on the message itself should go to netmod. Lou --- Forwarded message --- From: Lou Berger Date: June 7, 2016 10:20:23 AM Subject: [netmod] Opstate solutions discussions: update and request for WG input To: netmod WG CC: netmod-chairs@ietf.org 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 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Jun 8 09:23:38 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 51EB112D093 for ; Wed, 8 Jun 2016 09:23:37 -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 pmFm6_wdPkEd for ; Wed, 8 Jun 2016 09:23:35 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 5441F12D1D2 for ; Wed, 8 Jun 2016 09:23:35 -0700 (PDT) Received: (qmail 3999 invoked by uid 0); 8 Jun 2016 16:23:35 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Jun 2016 16:23:35 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 4GPV1t01N2SSUrH01GPYr1; Wed, 08 Jun 2016 10:23:34 -0600 X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=_YrKmtLnOJmTjYVyYW4A:9 a=6XKu0j9-T9O7taiO:21 a=7DWPM4YPNewJAEty:21 a=pILNOxqGKmIA:10 a=aHrNv8WqsBEA:10 a=972hS-PGyNsA: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:Cc:References:To:Subject; bh=Yxbqurd2owgDW4dAn0/av2uqoXMqqoezr8AEqNAFWOw=; b=CE/Ww/9JFI8GLCQ7W74dwbiDUv z4LT8R2S7ueXeATjl7QGSghfnMgw6m0vPMyxqpLh1uFcHwgdkHOb9OO69TUm6ZgJEX2r7FF7xDG5K O5yJ5+YPlIjx3g3R/i/zKbtis; Received: from box313.bluehost.com ([69.89.31.113]:48005 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bAgGP-0006Cx-Ev; Wed, 08 Jun 2016 10:23:29 -0600 To: Susan Hares , Rtg-yang-coord@ietf.org References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> From: Lou Berger Message-ID: <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> Date: Wed, 8 Jun 2016 12:23:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> 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} Archived-At: Cc: 'Benoit Claise' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 16:23:37 -0000 Sue, I think you're looking a step beyond the scope of decision we're considering now. This is a fine thing, and certainly the right thing to be thinking about from the I2RS (or any other WG working on YANG models that is considering operational state for that matter) perspective. The decision at hand is to choose between directions A and B. I think you are saying you that you like direction B but that the details aren't sufficient for your (WG's) needs. Is this correct? If so, then I think you're point is that [4] and [5] need work. We agree with this statement and we believe consistent with the statement in B: -- and that the WG needs to formalize an opstate solution based on the approach discussed in [4] and [5]. So, once the WG closes on direction B (before Berlin), the WG can then start discussing details of the WG's version of [4] and [5] -- and issues on ephemeral support makes sense to discuss then if they still haven't been addressed. Of course discussion on the individual drafts don't need to wait for the decision on basic direction. Make sense? Lou On 6/8/2016 12:10 PM, Susan Hares wrote: > Lou: > > Thank you for your work on the two options. I'd like to comment on the > following statement in your message statement, and reference a few things in > [4] and [5] regarding ephemeral state: > > You state: > " 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." > > In [4], the author states: > > "o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX]" > > In [5], the author states: > > "5.5. Ephemeral Configuration Datastore (Optional) > This document does not intend to formally define an Ephemeral > Configuration Datastore. In particular, it must be noted that the > ephemeral configuration datastore described here does not match that > described in version -09 of draft-ietf-i2rs-ephemeral-state > [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually > how such a datastore (restricted to configuration only) might fit > into a conceptual refined datastore model." > > Therefore, the result of I2RS WG spending 2 years writing requirements for > the ephemeral data store that both option 2 documents "do not match" the > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > state. [5] provides an ephemeral architecture closer to I2RS ephemeral > requirements, but does not understand that draft-ietf-i2rs-ephemeral-state > is a requirements document. Your statement " With this approach, model > definitions need no explicit changes to support applied configuration" > cannot be true if you consider the I2RS data models (RIB, topology). > > How is option (2) a reasonable design for ephemeral state? I have spent the > last week answering questions to Juergen [4] on the I2RS ephemeral state. > After our discussion, he did not have any specific suggestions to change > these requirements > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). > > Can I have an option 2b that considers ephemeral state based on the > requirements listed by I2RS? > > Sue Hares > I2RS WG-chair > > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of > Lou Berger > Sent: Wednesday, June 08, 2016 9:06 AM > To: Rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: > update and request for WG input > > FYI this decision is likely to have some impact on models under development, > including in the routing area. Comments on the message itself should go to > netmod. > > Lou > > > --- Forwarded message --- > From: Lou Berger > Date: June 7, 2016 10:20:23 AM > Subject: [netmod] Opstate solutions discussions: update and request for WG > input > To: netmod WG > CC: netmod-chairs@ietf.org > > 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 > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Wed Jun 8 09:52:34 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 5B2E512D5F9; Wed, 8 Jun 2016 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no 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 HKsFtqjDsYeh; Wed, 8 Jun 2016 09:52:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 9C40112D576; Wed, 8 Jun 2016 09:52:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Lou Berger'" , References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> In-Reply-To: <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> Date: Wed, 8 Jun 2016 12:52:33 -0400 Message-ID: <00fc01d1c1a6$274832f0$75d898d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6IwJELg8iAeYo0GEDLoLykJ9WDx1Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Benoit Claise' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 16:52:31 -0000 Lou: My email message was to express my concerns as I2RS co-chair. [A] does not even consider ephemeral. [B] at least considers it, but does not match I2RS requirements. As I2RS WG Chair, both [A] and [B] have problems. Either [A] or [B] work as long as ephemeral state gets handed. On B, at least [4] and [5] at least give some ideas on handling ephemeral state. I will work with authors [1][2][3][4][5] to suggest ephemeral improvements. Will getting support [A] or [B] to work as individual contributor. Sue Hares ========= . [A] does not even consider ephemeral. [B] at least considers it, but does not match it. As I2RS WG Chair, [A] and [B] both has problems. [A] - will not cause me to re-write data models. All data models (BGP, I2RS) have split between operational data and configuration data. [B] As individual contributor, I appreciate that [4] and [5] at trying to work through the details of ephemeral. [5] has a really good diagram in section 4 that would work for I2RS Ephemeral Configuration State. [5] uses the term "ephemeral configuration datastore" and correctly understands what a get of the ephemeral datastore should result in. It also allows multiple layers. However, [5] has not considered the multi-headed issues in the I2RS ephemeral requirements. -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, June 08, 2016 12:23 PM To: Susan Hares; Rtg-yang-coord@ietf.org Cc: 'Benoit Claise'; i2rs@ietf.org; 'Alia Atlas' Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input Sue, I think you're looking a step beyond the scope of decision we're considering now. This is a fine thing, and certainly the right thing to be thinking about from the I2RS (or any other WG working on YANG models that is considering operational state for that matter) perspective. The decision at hand is to choose between directions A and B. I think you are saying you that you like direction B but that the details aren't sufficient for your (WG's) needs. Is this correct? If so, then I think you're point is that [4] and [5] need work. We agree with this statement and we believe consistent with the statement in B: -- and that the WG needs to formalize an opstate solution based on the approach discussed in [4] and [5]. So, once the WG closes on direction B (before Berlin), the WG can then start discussing details of the WG's version of [4] and [5] -- and issues on ephemeral support makes sense to discuss then if they still haven't been addressed. Of course discussion on the individual drafts don't need to wait for the decision on basic direction. Make sense? Lou On 6/8/2016 12:10 PM, Susan Hares wrote: > Lou: > > Thank you for your work on the two options. I'd like to comment on > the following statement in your message statement, and reference a few > things in [4] and [5] regarding ephemeral state: > > You state: > " 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." > > In [4], the author states: > > "o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX]" > > In [5], the author states: > > "5.5. Ephemeral Configuration Datastore (Optional) > This document does not intend to formally define an Ephemeral > Configuration Datastore. In particular, it must be noted that the > ephemeral configuration datastore described here does not match that > described in version -09 of draft-ietf-i2rs-ephemeral-state > [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually > how such a datastore (restricted to configuration only) might fit > into a conceptual refined datastore model." > > Therefore, the result of I2RS WG spending 2 years writing requirements > for the ephemeral data store that both option 2 documents "do not > match" the I2RS ephemeral requirements set. [4] lumps ephemeral with > operational state. [5] provides an ephemeral architecture closer to > I2RS ephemeral requirements, but does not understand that draft-ietf-i2rs-ephemeral-state > is a requirements document. Your statement " With this approach, model > definitions need no explicit changes to support applied configuration" > cannot be true if you consider the I2RS data models (RIB, topology). > > How is option (2) a reasonable design for ephemeral state? I have > spent the last week answering questions to Juergen [4] on the I2RS ephemeral state. > After our discussion, he did not have any specific suggestions to > change these requirements > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). > > Can I have an option 2b that considers ephemeral state based on the > requirements listed by I2RS? > > Sue Hares > I2RS WG-chair > > -----Original Message----- > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On > Behalf Of Lou Berger > Sent: Wednesday, June 08, 2016 9:06 AM > To: Rtg-yang-coord@ietf.org > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: > update and request for WG input > > FYI this decision is likely to have some impact on models under > development, including in the routing area. Comments on the message > itself should go to netmod. > > Lou > > > --- Forwarded message --- > From: Lou Berger > Date: June 7, 2016 10:20:23 AM > Subject: [netmod] Opstate solutions discussions: update and request > for WG input > To: netmod WG > CC: netmod-chairs@ietf.org > > 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 > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Jun 8 10:39:16 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 D788112D7B6 for ; Wed, 8 Jun 2016 10:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 DQS8MPclIv9X for ; Wed, 8 Jun 2016 10:39:10 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 46F1412D7B8 for ; Wed, 8 Jun 2016 10:39:10 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id c72so14372023ywb.1 for ; Wed, 08 Jun 2016 10:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Q8W4/XuhBcsClMt1mqneZ8VUsrTLTbAG1TVaeBAWJI4=; b=h1q7h3WhmnOOkCcgtzWHYR5NxB6D91NUupY/JnWIW/VtAdyTG2JQYsxeMclljIRtaY 6KfzLq51TWCpJFhuc86cCXONyn1dWfT7r69e4R5bWEs/gRnO+usi2T/bkjxT7OdP2THI NJtWFRJh9kcNgOD9dR765PunnC4rQQquiFm9fJJ71WXR7CUNFTQusXx2qiX1GqurluFg dw3Gdsl9TmblQPchgerRY9UrbZfndmKolKQwdpHU20FpOsHK1boqUUT7stvByLy2jWvk mgUu9OhNeLhbhqWzj+LUnjnUAvdxZ0ASlTjVZK45SD3ZkAKJEdO9V+gbQo4aSp6Trpij iFCA== 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:date :message-id:subject:from:to:cc; bh=Q8W4/XuhBcsClMt1mqneZ8VUsrTLTbAG1TVaeBAWJI4=; b=cSDxucKHoHbeNQWeZBGhPdszoYlvDD6trInKdYKu0XGvWuTWnTNCJZ+7+bAWs9N8Av d537UVEyXSFOTUI6qgkGwe/KaIdleQ/M1QQs+14dup7Wfj7TOwKOPHNI9v0Vd3H7m4x2 Za/Dp/uxh7K5ZEpZtHgicpYPvm96e9GxIhRwF9IZnD20QINKwT/NdRlOskhG0Q1Tlppk FX3ekbCdVjV7WTF9P+0fvjzzbJ2abispoDg7j1fTHRV7siUJsXhofRI9RE/ZyGRyDaLF 1HQAVa+JFhLN/i6d2APlZ6D8rcQsBrvWQhMEWfDcSWYRAs2xkHNUWya5ATKNmc8TX4t8 4jUw== X-Gm-Message-State: ALyK8tJvrciIFemLZlR2eLsLAsmyqay4ycTN2/rJgV+C0FQESYtMojR5TnUKvdynmC2c94WJQUGJ9tN4ESFuZQ== MIME-Version: 1.0 X-Received: by 10.37.10.4 with SMTP id 4mr3405837ybk.160.1465407549316; Wed, 08 Jun 2016 10:39:09 -0700 (PDT) Received: by 10.37.42.77 with HTTP; Wed, 8 Jun 2016 10:39:09 -0700 (PDT) In-Reply-To: <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> Date: Wed, 8 Jun 2016 10:39:09 -0700 Message-ID: From: Andy Bierman To: Lou Berger Content-Type: multipart/alternative; boundary=001a113dde166dd84a0534c7c88d Archived-At: Cc: "rtg-yang-coord@ietf.org" , Benoit Claise , Alia Atlas , Susan Hares , "i2rs@ietf.org" Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 17:39:14 -0000 --001a113dde166dd84a0534c7c88d Content-Type: text/plain; charset=UTF-8 Hi Lou, I would say 2 steps ahead. Step 1 seems to be to reconfirm the meeting room consensus from Yokohama (model-based vs. protocol-based) Step 2 is usually picking a starting point for a solution draft. Step 3 is when people can start detailed solution reviews. IMO [4] is a good starting point but there are many open issues that need to be resolved, possibly addressed in the other drafts. Andy On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger wrote: > Sue, > > I think you're looking a step beyond the scope of decision we're > considering now. This is a fine thing, and certainly the right thing to > be thinking about from the I2RS (or any other WG working on YANG models > that is considering operational state for that matter) perspective. > > The decision at hand is to choose between directions A and B. I think > you are saying you that you like direction B but that the details aren't > sufficient for your (WG's) needs. Is this correct? > > If so, then I think you're point is that [4] and [5] need work. We > agree with this statement and we believe consistent with the statement in > B: > > -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > So, once the WG closes on direction B (before Berlin), the WG can then > start discussing details of the WG's version of [4] and [5] -- and > issues on ephemeral support makes sense to discuss then if they still > haven't been addressed. Of course discussion on the individual drafts > don't need to wait for the decision on basic direction. > > Make sense? > > Lou > > On 6/8/2016 12:10 PM, Susan Hares wrote: > > Lou: > > > > Thank you for your work on the two options. I'd like to comment on the > > following statement in your message statement, and reference a few > things in > > [4] and [5] regarding ephemeral state: > > > > You state: > > " 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." > > > > In [4], the author states: > > > > "o The model foresees ephemeral datastores that are by definition not > > part of the persistent configuration of a device. These ephemeral > > datastores are considered to interact with the rest of the system > > like any other control-plane mechanisms (e.g., routing protocols, > > discovery protocols). [XXX Note that this is different from what > > is described in some of the I2RS documents. XXX]" > > > > In [5], the author states: > > > > "5.5. Ephemeral Configuration Datastore (Optional) > > This document does not intend to formally define an Ephemeral > > Configuration Datastore. In particular, it must be noted that the > > ephemeral configuration datastore described here does not match that > > described in version -09 of draft-ietf-i2rs-ephemeral-state > > [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes conceptually > > how such a datastore (restricted to configuration only) might fit > > into a conceptual refined datastore model." > > > > Therefore, the result of I2RS WG spending 2 years writing requirements > for > > the ephemeral data store that both option 2 documents "do not match" the > > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > > state. [5] provides an ephemeral architecture closer to I2RS ephemeral > > requirements, but does not understand that > draft-ietf-i2rs-ephemeral-state > > is a requirements document. Your statement " With this approach, model > > definitions need no explicit changes to support applied configuration" > > cannot be true if you consider the I2RS data models (RIB, topology). > > > > How is option (2) a reasonable design for ephemeral state? I have spent > the > > last week answering questions to Juergen [4] on the I2RS ephemeral state. > > After our discussion, he did not have any specific suggestions to change > > these requirements > > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). > > > > Can I have an option 2b that considers ephemeral state based on the > > requirements listed by I2RS? > > > > Sue Hares > > I2RS WG-chair > > > > -----Original Message----- > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf > Of > > Lou Berger > > Sent: Wednesday, June 08, 2016 9:06 AM > > To: Rtg-yang-coord@ietf.org > > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: > > update and request for WG input > > > > FYI this decision is likely to have some impact on models under > development, > > including in the routing area. Comments on the message itself should go > to > > netmod. > > > > Lou > > > > > > --- Forwarded message --- > > From: Lou Berger > > Date: June 7, 2016 10:20:23 AM > > Subject: [netmod] Opstate solutions discussions: update and request for > WG > > input > > To: netmod WG > > CC: netmod-chairs@ietf.org > > > > 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 > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > --001a113dde166dd84a0534c7c88d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Lou,

I would say 2 steps ahead.
Step 1 seems to be to reconfirm the meeting room consensus from=C2=A0= Yokohama
(model-based vs. protocol-based)

Step 2 is usually picking a starting point for a solution draft.

Step 3 is when people can start detailed solution reviews.=

IMO [4] is a good starting point but there are ma= ny open issues that need to be resolved,
possibly addressed in th= e other drafts.


Andy

=

On Wed, Jun= 8, 2016 at 9:23 AM, Lou Berger <lberger@labn.net> wrote:
=
Sue,

I think you're looking a step beyond the scope of decision we're considering now. This is a fine thing, and certainly the right thing to
be thinking about from the I2RS (or any other WG working on YANG models
that is considering operational state for that matter) perspective.

The decision at hand is to choose between directions A and B.=C2=A0 I think=
you are saying you that you like direction B but that the details aren'= t
sufficient for your (WG's) needs.=C2=A0 Is this correct?

If so, then I think you're point is that [4] and [5] need work.=C2=A0 W= e
agree with this statement and we believe consistent with the statement in B= :

=C2=A0 =C2=A0 -- and that the WG needs to
=C2=A0 =C2=A0 =C2=A0 =C2=A0formalize an opstate solution based on the appro= ach
=C2=A0 =C2=A0 =C2=A0 =C2=A0discussed in [4] and [5].

So, once the WG closes on direction B (before Berlin), the WG can then
start discussing details of the WG's version of [4] and [5] -- and
issues on ephemeral support makes sense to discuss then if they still
haven't been addressed.=C2=A0 =C2=A0Of course discussion on the individ= ual drafts
don't need to wait for the decision on basic direction.

Make sense?

Lou

On 6/8/2016 12:10 PM, Susan Hares wrote:
> Lou:
>
> Thank you for your work on the two options.=C2=A0 I'd like to comm= ent on the
> following statement in your message statement, and reference a few thi= ngs in
> [4] and [5] regarding ephemeral state:
>
> You state:
> "=C2=A0 2) Model OpState using a revised logical datastore defini= tion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as introduced in [4] and also covered in [5= ]. There is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 also a variant of this that we believe does= n't significantly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact this choice.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 With this approach, model definitions need = no explicit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 changes to support applied configuration.&q= uot;
>
> In [4], the author states:
>
>=C2=A0 =C2=A0 "o=C2=A0 The model foresees ephemeral datastores tha= t are by definition not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0part of the persistent configuration of a de= vice.=C2=A0 These ephemeral
>=C2=A0 =C2=A0 =C2=A0 =C2=A0datastores are considered to interact with t= he rest of the system
>=C2=A0 =C2=A0 =C2=A0 =C2=A0like any other control-plane mechanisms (e.g= ., routing protocols,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0discovery protocols).=C2=A0 [XXX Note that t= his is different from what
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is described in some of the I2RS documents.= =C2=A0 XXX]"
>
> In [5], the author states:
>
> "5.5.=C2=A0 Ephemeral Configuration Datastore (Optional)
>=C2=A0 =C2=A0 This document does not intend to formally define an Ephem= eral
>=C2=A0 =C2=A0 Configuration Datastore.=C2=A0 In particular, it must be = noted that the
>=C2=A0 =C2=A0 ephemeral configuration datastore described here does not= match that
>=C2=A0 =C2=A0 described in version -09 of draft-ietf-i2rs-ephemeral-sta= te
>=C2=A0 =C2=A0 [I-D.ietf-i2rs-ephemeral-state].=C2=A0 Instead, it descri= bes conceptually
>=C2=A0 =C2=A0 how such a datastore (restricted to configuration only) m= ight fit
>=C2=A0 =C2=A0 into a conceptual refined datastore model."
>
> Therefore, the result of I2RS WG spending 2 years writing requirements= for
> the ephemeral data store that both option 2 documents "do not=C2= =A0 match" the
> I2RS ephemeral requirements set.=C2=A0 [4] lumps ephemeral with operat= ional
> state.=C2=A0 [5] provides an ephemeral architecture closer to I2RS eph= emeral
> requirements, but does not understand that draft-ietf-i2rs-ephemeral-s= tate
> is a requirements document.=C2=A0 =C2=A0 Your statement " With th= is approach, model
> definitions need no explicit changes to support applied configuration&= quot;
> cannot be true if you consider the I2RS data models (RIB, topology). >
> How is option (2) a reasonable design for ephemeral state?=C2=A0 I hav= e spent the
> last week answering questions to Juergen [4] on the I2RS ephemeral sta= te.
> After our discussion, he did not have any specific suggestions to chan= ge
> these requirements
> (https://www.ietf.org/mail-arch= ive/web/i2rs/current/msg03688.html).
>
> Can I have an option 2b that considers ephemeral state based on the > requirements listed by I2RS?
>
>=C2=A0 Sue Hares
>=C2=A0 I2RS WG-chair
>
> -----Original Message-----
> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of
> Lou Berger
> Sent: Wednesday, June 08, 2016 9:06 AM
> To: Rtg-yang-coord@ietf.org=
> Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:=
> update and request for WG input
>
> FYI this decision is likely to have some impact on models under develo= pment,
> including in the routing area. Comments on the message itself should g= o to
> netmod.
>
> Lou
>
>
> --- Forwarded message ---
> From: Lou Berger <lberger@labn.= net>
> Date: June 7, 2016 10:20:23 AM
> Subject: [netmod] Opstate solutions discussions: update and request fo= r WG
> input
> To: netmod WG <netmod@ietf.org>
> CC: netmod-chairs@ietf.org
>
> 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 discu= ssions
> -- 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 si= ngle
> consolidated proposal as hoped, but rather two alternate directions --= and
> clearly we need to choose one:
>
>=C2=A0 =C2=A0 =C2=A01) Adopt the conventions for representing state/con= fig
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 based on Section 6 of [1].
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 From a model definition perspective, these = conventions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact every model and every model writer.<= br> >
>=C2=A0 =C2=A0 =C2=A02) Model OpState using a revised logical datastore = definition
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as introduced in [4] and also covered in [5= ]. There is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 also a variant of this that we believe does= n't significantly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 impact this choice.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 With this approach, model definitions need = no explicit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 on= e of
> the following as the WG direction:
>
>=C2=A0 =C2=A0 =C2=A0A) models that wish to support applied configuratio= n MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 follow conventions based on [1] -- and the = WG needs to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 formalize these conventions.
> or
>=C2=A0 =C2=A0 =C2=A0B) no explicit support is required for models to su= pport
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 applied configuration -- and that the WG ne= eds to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 formalize an opstate solution based on the = approach
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 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/d= raft-openconfig-netmod-opstate-01
> [2] https://tools.ietf.org/html/draf= t-kwatsen-netmod-opstate-02
> [3] https://tools.ietf.org/html/= draft-wilton-netmod-opstate-yang-02
> [4] https://tools.ietf.or= g/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 >
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtg= -yang-coord
>
>


_______________________________________________
Rtg-yang-coord mailing list
Rtg-yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-yang-c= oord

--001a113dde166dd84a0534c7c88d-- From nobody Wed Jun 8 10:40:33 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 A334712D7B8; Wed, 8 Jun 2016 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 B9Xa9_ZP6LZE; Wed, 8 Jun 2016 10:40:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3812D7B6; Wed, 8 Jun 2016 10:40:30 -0700 (PDT) Received: from localhost (h-46-190.a165.priv.bahnhof.se [46.59.46.190]) by mail.tail-f.com (Postfix) with ESMTPSA id CB0721AE0389; Wed, 8 Jun 2016 19:40:28 +0200 (CEST) Date: Wed, 08 Jun 2016 19:40:28 +0200 (CEST) Message-Id: <20160608.194028.358336333232277992.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: Rtg-yang-coord@ietf.org, bclaise@cisco.com, lberger@labn.net, akatlas@gmail.com, i2rs@ietf.org Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 17:40:31 -0000 Hi Sue, "Susan Hares" wrote: > In [4], the author states: > > "o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX]" [...] > Therefore, the result of I2RS WG spending 2 years writing requirements for > the ephemeral data store that both option 2 documents "do not match" the > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > state. I don't think this last sentence is correct. Admittedly, the details about ephemeral in [4] are not worked out (by design). But the idea was not to "lump ephemeral and operational state". The idea was rather that the content of ephemeral datastore(s) would interact with the applied config to produce the resulting operational state. If the WG agrees that B is the right way to go, we'll need to work out all the details about how the ephemeral datastore(s) work. The main point is that [4] (and [5]) provides an architecture into which ephemeral datastores can fit. /martin From nobody Wed Jun 8 12:27:33 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 770EB12B00B for ; Wed, 8 Jun 2016 12:27:31 -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=unavailable 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 EjCKs7XewKkQ for ; Wed, 8 Jun 2016 12:27:28 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 8CCFA12D548 for ; Wed, 8 Jun 2016 12:27:28 -0700 (PDT) Received: (qmail 23171 invoked by uid 0); 8 Jun 2016 19:27:24 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 8 Jun 2016 19:27:24 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 4KTB1t01F2SSUrH01KTEoP; Wed, 08 Jun 2016 13:27:22 -0600 X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=h1CNhEJjTAOSSbiXWbYA:9 a=XKglFbNVR357Agop:21 a=yK49gFaQljK2HJlX:21 a=QEXdDO2ut3YA:10 a=aHrNv8WqsBEA:10 a=972hS-PGyNsA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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:Cc:References:To:Subject; bh=yXEcu2gseVYk/UjI5LpVKOE36p2AovIPkN6M/JtcIME=; b=jd4Ci1s/VbSx/dJ8eHGCxWwFb8 gpas7Xgif/lZt394YAW2t5e0JLR/9fTW9zaCYrwsMNAMDeloYrip5QnNNbDZ/EFip3xLPNETbd6Yv +WQJR+N9JV3R7rwzsc6g+1IPn; Received: from box313.bluehost.com ([69.89.31.113]:48454 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bAj8D-00009Y-7q; Wed, 08 Jun 2016 13:27:13 -0600 To: Andy Bierman References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> From: Lou Berger Message-ID: <834c9a77-76e4-23b9-87e6-d28439e52bd2@labn.net> Date: Wed, 8 Jun 2016 15:27:07 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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} Archived-At: Cc: "rtg-yang-coord@ietf.org" , Benoit Claise , Alia Atlas , Susan Hares , "i2rs@ietf.org" Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Wed, 08 Jun 2016 19:27:31 -0000 Andy, (Sue) Valid point -- either way the WG will get to Ephemeral *after* the direction question is settled. Lou On 6/8/2016 1:39 PM, Andy Bierman wrote: > Hi Lou, > > I would say 2 steps ahead. > Step 1 seems to be to reconfirm the meeting room consensus from Yokohama > (model-based vs. protocol-based) > > Step 2 is usually picking a starting point for a solution draft. > > Step 3 is when people can start detailed solution reviews. > > IMO [4] is a good starting point but there are many open issues that > need to be resolved, > possibly addressed in the other drafts. > > > Andy > > > On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger > wrote: > > Sue, > > I think you're looking a step beyond the scope of decision we're > considering now. This is a fine thing, and certainly the right > thing to > be thinking about from the I2RS (or any other WG working on YANG > models > that is considering operational state for that matter) perspective. > > The decision at hand is to choose between directions A and B. I think > you are saying you that you like direction B but that the details > aren't > sufficient for your (WG's) needs. Is this correct? > > If so, then I think you're point is that [4] and [5] need work. We > agree with this statement and we believe consistent with the > statement in B: > > -- and that the WG needs to > formalize an opstate solution based on the approach > discussed in [4] and [5]. > > So, once the WG closes on direction B (before Berlin), the WG can then > start discussing details of the WG's version of [4] and [5] -- and > issues on ephemeral support makes sense to discuss then if they still > haven't been addressed. Of course discussion on the individual > drafts > don't need to wait for the decision on basic direction. > > Make sense? > > Lou > > On 6/8/2016 12:10 PM, Susan Hares wrote: > > Lou: > > > > Thank you for your work on the two options. I'd like to comment > on the > > following statement in your message statement, and reference a > few things in > > [4] and [5] regarding ephemeral state: > > > > You state: > > " 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." > > > > In [4], the author states: > > > > "o The model foresees ephemeral datastores that are by > definition not > > part of the persistent configuration of a device. These > ephemeral > > datastores are considered to interact with the rest of the > system > > like any other control-plane mechanisms (e.g., routing > protocols, > > discovery protocols). [XXX Note that this is different > from what > > is described in some of the I2RS documents. XXX]" > > > > In [5], the author states: > > > > "5.5. Ephemeral Configuration Datastore (Optional) > > This document does not intend to formally define an Ephemeral > > Configuration Datastore. In particular, it must be noted > that the > > ephemeral configuration datastore described here does not > match that > > described in version -09 of draft-ietf-i2rs-ephemeral-state > > [I-D.ietf-i2rs-ephemeral-state]. Instead, it describes > conceptually > > how such a datastore (restricted to configuration only) might fit > > into a conceptual refined datastore model." > > > > Therefore, the result of I2RS WG spending 2 years writing > requirements for > > the ephemeral data store that both option 2 documents "do not > match" the > > I2RS ephemeral requirements set. [4] lumps ephemeral with > operational > > state. [5] provides an ephemeral architecture closer to I2RS > ephemeral > > requirements, but does not understand that > draft-ietf-i2rs-ephemeral-state > > is a requirements document. Your statement " With this > approach, model > > definitions need no explicit changes to support applied > configuration" > > cannot be true if you consider the I2RS data models (RIB, topology). > > > > How is option (2) a reasonable design for ephemeral state? I > have spent the > > last week answering questions to Juergen [4] on the I2RS > ephemeral state. > > After our discussion, he did not have any specific suggestions > to change > > these requirements > > (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html). > > > > Can I have an option 2b that considers ephemeral state based on the > > requirements listed by I2RS? > > > > Sue Hares > > I2RS WG-chair > > > > -----Original Message----- > > From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org > ] On Behalf Of > > Lou Berger > > Sent: Wednesday, June 08, 2016 9:06 AM > > To: Rtg-yang-coord@ietf.org > > Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions > discussions: > > update and request for WG input > > > > FYI this decision is likely to have some impact on models under > development, > > including in the routing area. Comments on the message itself > should go to > > netmod. > > > > Lou > > > > > > --- Forwarded message --- > > From: Lou Berger > > > Date: June 7, 2016 10:20:23 AM > > Subject: [netmod] Opstate solutions discussions: update and > request for WG > > input > > To: netmod WG > > > CC: netmod-chairs@ietf.org > > > > 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 > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > From nobody Thu Jun 9 00:37:13 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 4A2A812D0EE; Thu, 9 Jun 2016 00:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 Beddyrrtm-h1; Thu, 9 Jun 2016 00:37:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3054F12B035; Thu, 9 Jun 2016 00:37:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85D10100C; Thu, 9 Jun 2016 09:37:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id M66wJg5fAzBV; Thu, 9 Jun 2016 09:37:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Jun 2016 09:37:07 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AEAD20047; Thu, 9 Jun 2016 09:37:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rlINUO3yR46r; Thu, 9 Jun 2016 09:37:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 205822004E; Thu, 9 Jun 2016 09:37:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1509A3B0E89B; Thu, 9 Jun 2016 09:37:06 +0200 (CEST) Date: Thu, 9 Jun 2016 09:37:06 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160609073706.GB13220@elstar.local> Mail-Followup-To: Susan Hares , 'Lou Berger' , Rtg-yang-coord@ietf.org, 'Benoit Claise' , i2rs@ietf.org, 'Alia Atlas' References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Rtg-yang-coord@ietf.org, 'Benoit Claise' , 'Lou Berger' , 'Alia Atlas' , i2rs@ietf.org Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input X-BeenThere: rtg-yang-coord@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder 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: Thu, 09 Jun 2016 07:37:12 -0000 On Wed, Jun 08, 2016 at 12:10:09PM -0400, Susan Hares wrote: > > Therefore, the result of I2RS WG spending 2 years writing requirements for > the ephemeral data store that both option 2 documents "do not match" the > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > state. I tried to bring [4] to the attention of I2RS; nobody ever claimed that [4] is a final solution. I did ask concrete questions on the I2RS list concerning I2RS requirements and what the various terms used in the description of I2RS requirements actually mean. The outcome were some changes (I think) but there are also requirements I still find unclear (but where we keep going in circles). That said, I do not think '[4] lumps ephemeral with operational state' is a fair statement either. Anyway, as Lou explained, the subject of this thread is to decide on the general direction and once we have agreement on the direction, I am sure there will be further work on the details of the architectural solutions on the table. And yes, this is then the time to settle what an I2RS ephemeral datastore is and how it integrates conceptually and architecturally with the rest. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jun 9 06:42:42 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 C3E6312D0E9; Thu, 9 Jun 2016 06:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no 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 Ppcky32Qih_C; Thu, 9 Jun 2016 06:42:37 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 16D8812D0AE; Thu, 9 Jun 2016 06:42:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <20160609073706.GB13220@elstar.local> In-Reply-To: <20160609073706.GB13220@elstar.local> Date: Thu, 9 Jun 2016 09:42:42 -0400 Message-ID: <002901d1c254$cc2763f0$64762bd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6IwJELg8iAeYo0GEBfkCLqp9k4Okg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, 'Benoit Claise' , 'Lou Berger' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [Rtg-yang-coord] Fwd: [netmod] 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: Thu, 09 Jun 2016 13:42:39 -0000 Juergen: I'm sorry you felt "lumps in with operational state" [4] was pejorative, it was not intended to be. 100% agree - pick between option A and B, and then come back to ephemeral. If you have specific changes to the text, we still welcome your comments on the ephemeral requirements document. Considering your questions on how constraints work in section 8.3 of draft-ietf-netmod-6020bis-12 has led me to reconsider how these constraints apply to ephemeral state. Sue -----Original Message----- From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, June 09, 2016 3:37 AM To: Susan Hares Cc: Rtg-yang-coord@ietf.org; 'Benoit Claise'; 'Lou Berger'; 'Alia Atlas'; i2rs@ietf.org Subject: Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input On Wed, Jun 08, 2016 at 12:10:09PM -0400, Susan Hares wrote: > > Therefore, the result of I2RS WG spending 2 years writing requirements > for the ephemeral data store that both option 2 documents "do not > match" the I2RS ephemeral requirements set. [4] lumps ephemeral with > operational state. I tried to bring [4] to the attention of I2RS; nobody ever claimed that [4] is a final solution. I did ask concrete questions on the I2RS list concerning I2RS requirements and what the various terms used in the description of I2RS requirements actually mean. The outcome were some changes (I think) but there are also requirements I still find unclear (but where we keep going in circles). That said, I do not think '[4] lumps ephemeral with operational state' is a fair statement either. Anyway, as Lou explained, the subject of this thread is to decide on the general direction and once we have agreement on the direction, I am sure there will be further work on the details of the architectural solutions on the table. And yes, this is then the time to settle what an I2RS ephemeral datastore is and how it integrates conceptually and architecturally with the rest. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Rtg-yang-coord mailing list Rtg-yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Thu Jun 9 06:48:56 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 40B4B12D18C; Thu, 9 Jun 2016 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no autolearn_force=no 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 sO2brF4jtOZG; Thu, 9 Jun 2016 06:48:52 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 28D0812D09F; Thu, 9 Jun 2016 06:48:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86; From: "Susan Hares" To: "'Martin Bjorklund'" References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <20160608.194028.358336333232277992.mbj@tail-f.com> In-Reply-To: <20160608.194028.358336333232277992.mbj@tail-f.com> Date: Thu, 9 Jun 2016 09:48:56 -0400 Message-ID: <002b01d1c255$abc9e8c0$035dba40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6IwJELg8iAeYo0GEBXY3Csp9l+kNg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, bclaise@cisco.com, lberger@labn.net, i2rs@ietf.org, akatlas@gmail.com Subject: Re: [Rtg-yang-coord] [i2rs] Fwd: [netmod] 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: Thu, 09 Jun 2016 13:48:53 -0000 Martin: I agree [4] and [5] provide possible architectures that ephemeral could fit into as part of choice [B]. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Wednesday, June 08, 2016 1:40 PM To: shares@ndzh.com Cc: Rtg-yang-coord@ietf.org; bclaise@cisco.com; lberger@labn.net; akatlas@gmail.com; i2rs@ietf.org Subject: Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input Hi Sue, "Susan Hares" wrote: > In [4], the author states: > > "o The model foresees ephemeral datastores that are by definition not > part of the persistent configuration of a device. These ephemeral > datastores are considered to interact with the rest of the system > like any other control-plane mechanisms (e.g., routing protocols, > discovery protocols). [XXX Note that this is different from what > is described in some of the I2RS documents. XXX]" [...] > Therefore, the result of I2RS WG spending 2 years writing requirements > for the ephemeral data store that both option 2 documents "do not > match" the I2RS ephemeral requirements set. [4] lumps ephemeral with > operational state. I don't think this last sentence is correct. Admittedly, the details about ephemeral in [4] are not worked out (by design). But the idea was not to "lump ephemeral and operational state". The idea was rather that the content of ephemeral datastore(s) would interact with the applied config to produce the resulting operational state. If the WG agrees that B is the right way to go, we'll need to work out all the details about how the ephemeral datastore(s) work. The main point is that [4] (and [5]) provides an architecture into which ephemeral datastores can fit. /martin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jun 9 09:04:30 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 3B3C712D85B for ; Thu, 9 Jun 2016 09:04:29 -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 pgU8J7TouYqr for ; Thu, 9 Jun 2016 09:04:27 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (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 BE99B12D84C for ; Thu, 9 Jun 2016 09:04:26 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id q32so22681366qgq.3 for ; Thu, 09 Jun 2016 09:04:26 -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=J8iubSpKSnqaJ3NCjD/LE8mcYjdcVddcjAKC/+XoPNE=; b=IagVwFlycZruZHfhaRxR5NeDXCIrfyt2SyxCCKgFARsO3sviecAEEWmZ9LMJynuUGx 6hPkPWHu+Es0Ay+9vv7fxRwIVmTb+qWMkyAHhcSXcx9YVEMye31RmEWMZkb8T3oHBMGL uD75QnV5F72MYwT5aTzI8FbTeKxZLEyiJJs1pvdO1vBgd6WXCeG1mfyhLMjf58DIGtto 5TDI6PwrUIMVLwLXVTMbNwNkicE19z3jSz43wqygg5rLhrDJAFJ4T7BQKTiLjqXnDWkk GkK9cYBLSjrh/RyXPmy1nlq4Dd0BX6dTtkMXWpkJrIKM1W5p+Fqk7vUPgXA+YMo8xhzC BcSQ== 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=J8iubSpKSnqaJ3NCjD/LE8mcYjdcVddcjAKC/+XoPNE=; b=jtuO6kRwgM/+QObYmEKS5XrIs3V0E9JVLKuMV0tNwpEY211pgWlgefFxSbu7JeVsNY HaVFxU+70raSe4S0p5s/WFkoTx+Acd6Zxhs5gAlrJFfP2T3sKDEK3p8jvLcP1ImQkiib 6xct8sXXFHRHxDd/Jo8wa15/iuHtQbyS5pAWLrFEsl074fY+6VHL2wwWRT2+6zAYmpHg z1o0vbjS7YgqtC5Vl7aOh2OkugVAsmQESr73lw+BQUr8SpH5/RB5jgs05hBsTSXUutcB GAJREtGHwN/IJL1rigyCqoQfEx8MFYq6KtgvjUR+Jd3k68IBeItcV7tZ7LuijS2efTpH 8iMA== X-Gm-Message-State: ALyK8tItbAUkmiM//vtLD8vLywP8e8TvRl/jggRwfdM2Ly3hX2dHWTDNrQ4bEEQPQ/feIhSGKbCHcgb05H0m0A== X-Received: by 10.140.253.2 with SMTP id y2mr3660217qhc.68.1465488265834; Thu, 09 Jun 2016 09:04:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.57.81 with HTTP; Thu, 9 Jun 2016 09:04:25 -0700 (PDT) In-Reply-To: References: From: Alia Atlas Date: Thu, 9 Jun 2016 12:04:25 -0400 Message-ID: To: "Rtg-yang-coord@ietf.org" Content-Type: multipart/alternative; boundary=001a113aa918820e8e0534da93bf Archived-At: Subject: [Rtg-yang-coord] Fwd: [Yang-coord] YANG Model Coordination Group directory closure 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: Thu, 09 Jun 2016 16:04:29 -0000 --001a113aa918820e8e0534da93bf Content-Type: text/plain; charset=UTF-8 FYI ---------- Forwarded message ---------- From: Benoit Claise Date: Thu, Jun 9, 2016 at 11:35 AM Subject: [Yang-coord] YANG Model Coordination Group directory closure To: IETF-Discussion list , "yang-coord@ietf.org" < yang-coord@ietf.org> Dear all, The YANG Model Coordination Group has been a success, and has served its purpose. The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious: - Phase 1: List of the YANG models (inventory) - Phase 2: Tooling - Phase 3: Help with compilation - Phase 4: Training & Education - Phase 5: Coordination across SDOs/Opensource - Phase 6: Model Coordination within the IETF - Phase 7: Standardization Priorities Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me. Phase 1: List of the YANG models (inventory) Extracted all YANG data models from IETF drafts and RFCs on http://www.claise.be/ Started to work on YANG data model catalog for the industry Phase 2: Tooling YANG data models extraction from drafts/RFCs YANG data models dependency visualization YANG data model grouping extraction and compilation Created http://www.yangvalidator.org/ pyang integration in idnits/tracker pyang plugin for the YANG data model catalog Along the process we filed a couple of pyang bugs Organized the YANG track at the IETF Hackathon etc. Phase 3: Help with compilation Proactively contacted the IETF draft authors, discussing their compilation error messages Kept track of the situation here Flagged the duplicate YANG module names, groupings, etc. Phase 4: Training & Education Created some training materials, presented at IETF94 NETCONF Slides , YANG Slides , pyang Slides Phase 5: Coordination across SDOs/Opensource Coordinated with the IEEE/MEF/BBF, amongst others Worked on the YANG Data Model Classification, accepted as NETMOD WG document Based on github, we're compiling the IEEE/BBF/Opendaylight/openconfig data models Helped on URN for different SDOs YANG Modeling Efforts in the Industry Phase 6: Model Coordination within the IETF We helped with the coordination, even if the YANG routing design team contributed significantly for the routing aspects. Phase 7: Standardization Priorities This is maybe where we haven't had enough time to dedicate, even if we have identified the next steps. See YANG Data Models in the Industry: Current State of Affairs I probably missed some of the achievements. Sorry about that. Let's analyze the current situation! It's difficult, in a voluntary-based organization to dedicate so much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community. I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later. Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly. I will now request to close this directorate. Regards, Benoit (OPS AD) _______________________________________________ Yang-coord mailing list Yang-coord@ietf.org https://www.ietf.org/mailman/listinfo/yang-coord --001a113aa918820e8e0534da93bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI

---------- Fo= rwarded message ----------
From: Benoit Cl= aise <bclaise= @cisco.com>
Date: Thu, Jun 9, 2016 at 11:35 AM
Subject:= [Yang-coord] YANG Model Coordination Group directory closure
To: IETF-D= iscussion list <ietf@ietf.org>, = "yang-coord@ietf.org" = <yang-coord@ietf.org>
<= br>
=20 =20 =20
Dear all,

The YANG Model Coordination Group has been a success, and has served its purpose.

The plan and the time commitment (each person committed to spend 1/3 of his time) for this group were ambitious:
  • Phase 1: List of the YANG models (inventory)
  • Phase 2: Tooling
  • Phase 3: Help with compilation
  • Phase 4: Training & Education
  • Phase 5: Coordination across SDOs/Opensource
  • Phase 6: Model Coordination within the IETF
  • Phase 7: Standardization Priorities
Let's review the achievements. Quiet impressive for a couple of volunteers if you ask me.

Phase 1: List of the YANG models (inventory)
=C2=A0=C2=A0=C2=A0 Extracted all YANG data models from IETF drafts = and RFCs on http://www.clai= se.be/
=C2=A0=C2=A0=C2=A0 Started to work on YANG data model catalog for t= he industry

Phase 2: Tooling
=C2=A0=C2=A0=C2=A0 YANG data models extraction from drafts/RFCs
=C2=A0=C2=A0=C2=A0 YANG data models dependency visualization
=C2=A0=C2=A0=C2=A0 YANG data model grouping extraction and compilat= ion
=C2=A0=C2=A0=C2=A0 Created http://www.yangvalidator.org/
=C2=A0=C2=A0=C2=A0 pyang integration in idnits/tracker
=C2=A0=C2=A0=C2=A0 pyang plugin for the YANG data model catalog
=C2=A0=C2=A0=C2=A0 Along the process we filed a couple of pyang bug= s
=C2=A0=C2=A0=C2=A0 Organized the YANG track at the IETF Hackathon =C2=A0=C2=A0=C2=A0 etc.

Phase 3: Help with compilation
=C2=A0=C2=A0=C2=A0 Proactively contacted the IETF draft authors, di= scussing their compilation error messages
=C2=A0=C2=A0=C2=A0 Kept track of the situation here
=C2=A0=C2=A0=C2=A0 Flagged the duplicate YANG module names, groupin= gs, etc.

Phase 4: Training & Education
=C2=A0=C2=A0=C2=A0 Created some training materials, presented at IE= TF94
=C2=A0=C2=A0=C2=A0 NETCONF Slides, YANG Slides, pyang Slides

Phase 5: Coordination across SDOs/Opensource
=C2=A0=C2=A0=C2=A0 Coordinated with the IEEE/MEF/BBF, amongst other= s
=C2=A0=C2=A0=C2=A0 Worked on the Y= ANG Data Model Classification, accepted as NETMOD WG document
=C2=A0=C2=A0=C2=A0 Based on github, we're compiling the IEEE/BBF/Open= daylight/openconfig data models
=C2=A0=C2=A0=C2=A0 Helped on URN for different SDOs
=C2=A0=C2=A0=C2=A0 YANG Modeling Efforts in the Industry

Phase 6: Model Coordination within the IETF
=C2=A0=C2=A0=C2=A0 We helped with the coordination, even if the YAN= G routing design team
=C2=A0=C2=A0=C2=A0 contributed significantly for the routing aspect= s.

Phase 7: Standardization Priorities
=C2=A0=C2=A0=C2=A0 This is maybe where we haven't had enough ti= me to dedicate,
=C2=A0=C2=A0=C2=A0 even if we have identified the next steps.
=C2=A0=C2=A0=C2=A0 See YANG Data Models in the Industry: Current State of Affairs

I probably missed some of the achievements. Sorry about that.

Let's analyze the current situation!
It's difficult, in a voluntary-based organization to dedicate s= o much time on this YANG effort. On the other hand, this group efforts helped with the heavy-lifting job to promote YANG in the industry. Thanks for that. These days, even if it doesn't translate yet in many RFC numbers, YANG became a mature technology, which can now rely on a bigger community.
I expect that the YANG doctors to take over some of the effort here, helping with the proactive review of YANG data models. More on this later.
Regarding the tooling aspects, the IETF hackathon will continue to play an important role: a couple of people signed up already

Thanks to Carl, Dean, and Qin as YANG Model Coordination Group members, and to many others who helped directly or indirectly.

I will now request to close this directorate.

Regards, Benoit (OPS AD)

_______________________________________________
Yang-coord mailing list
Yang-coord@ietf.org
https://www.ietf.org/mailman/listinfo/yang-coord=


--001a113aa918820e8e0534da93bf--