Re: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

"Susan Hares" <shares@ndzh.com> Thu, 09 June 2016 13:42 UTC

Return-Path: <shares@ndzh.com>
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" <shares@ndzh.com>
To: "'Juergen Schoenwaelder'" <j.schoenwaelder@jacobs-university.de>
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: <https://mailarchive.ietf.org/arch/msg/rtg-yang-coord/mWzokyPZwcNYqe1rcicLYIzSdco>
Cc: Rtg-yang-coord@ietf.org, 'Benoit Claise' <bclaise@cisco.com>, 'Lou Berger' <lberger@labn.net>, i2rs@ietf.org, 'Alia Atlas' <akatlas@gmail.com>
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\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=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         <http://www.jacobs-university.de/>

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