Re: [netmod] Closing on an OpState Solution Direction

Benoit Claise <bclaise@cisco.com> Wed, 06 July 2016 09:31 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7928F12D08D; Wed, 6 Jul 2016 02:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 sd0-FjCxrLeA; Wed, 6 Jul 2016 02:31:35 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6901112B037; Wed, 6 Jul 2016 02:31:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11225; q=dns/txt; s=iport; t=1467797494; x=1469007094; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=RJUsnV8U4eT2jPXMLvj3jkwnlVr9qfN/UQPZG6dLb+A=; b=duhpitc+gz7sLJAjhcJWLBbaBRg+xA0vXrprkY6F8yuY/HWsYrzbgCZo WjbuN8OYT9O+i1HsrN1zmJPuE5lvWyVNpMUqr5H2z82LjWzNyEVyUJ8KF tXMsDJMjncPSSBcVErBj5UK5UOrLrhVp0XguOKK0nX/Zh91t1JKyXlqVM w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DjBQD1znxX/xbLJq1dhBQqUrRHhngkhSpKAoF3AQEBAQEBZieETQEFAQFsCxALDgouJzAGAQwGAgEBF4gVDrtaAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4F4CIJNihsBBJNZhTqGCYg+gWqHYYVfhleJM1SDcjoyiHIBAQE
X-IronPort-AV: E=Sophos;i="5.28,318,1464652800"; d="scan'208,217";a="636572235"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 09:31:32 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u669VV2a000810; Wed, 6 Jul 2016 09:31:32 GMT
To: Lou Berger <lberger@labn.net>, netmod WG <netmod@ietf.org>
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <e29fc8e1-8652-5555-dace-f8f511e50c89@labn.net>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <c1dc0c18-b09f-e5be-3520-d05d103bb8d1@cisco.com>
Date: Wed, 06 Jul 2016 11:31:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <e29fc8e1-8652-5555-dace-f8f511e50c89@labn.net>
Content-Type: multipart/alternative; boundary="------------42859E66D57844B9405D4541"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/VI-S1PKEkWJwmNcXhIJyFL4T9eE>
Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>
Subject: Re: [netmod] Closing on an OpState Solution Direction
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 09:31:37 -0000

Thanks Lou and Kent.

As mentioned in YANG Data Models in the Industry: Current State of 
Affairs 
<https://www.ietf.org/blog/2016/03/yang-data-models-in-the-industry-current-state-of-affairs/>: 
"Once those two issues are resolved, this will for sure open the gate to 
publish all these much-needed models."
While the operation status is not yet solved, the key message is that 
the YANG modules don't need to be modified.
So, now is THE time to publish those YANG models.

Regards, Benoit
> All,
>
> It's time to make a consensus call on this topic, so that we can all move on to defining a solution and aligning modules under development. Based on the feedback received and the overall discussions on the topic, we see that there is consensus to follow a datastore based approach to supporting operational state, i.e., direction 'B'.
>
> We will be asking the authors of [4] and [5] to review their proposals (individual drafts) in Berlin, as well as to highlight differences and suggest ways that their work could be consolidated. Of course, others may also choose to submit their own proposals. Given the importance of this work, we will be looking to have active discussion on the topic both in Berlin and on the list, with an objective of having a draft ready for considerations as a WG document by the November IETF.
>
> We have reviewed this decision with our AD and the NetConf chairs and have agreed to begin this work in NetMod. We certainly expect to coordinate the work with the NetConf WG and re-home work as/if needed.
>
> Finally, we'd also like to thank all those who have contributed to this discussion to date, from problem identification to proposed solutions, and we look forward to your continued efforts to publish a standard solution.
>
> Lou (and Kent)
>
>
> On 6/7/2016 10:19 AM, Lou Berger wrote:
>> All,
>>
>> We want to provide an update based on the off line discussions
>> related to OpState Solutions that we have been having and solicit
>> input from the WG.
>>
>> All authors of current solution drafts [1,2,3] together with those
>> who helped conduct the solutions analysis* were invited to the these
>> discussions -- with the objective of coming up with a single
>> consolidated proposal to bring to the WG. (I/Lou acted as facilitator
>> as Kent and Juergen were and are involved with the technical details.)
>>
>> The discussions have yielded some results but, unfortunately,
>> not a single consolidated proposal as hoped, but rather two
>> alternate directions -- and clearly we need to choose one:
>>
>>      1) Adopt the conventions for representing state/config
>>         based on Section 6 of [1].
>>
>>         From a model definition perspective, these conventions
>>         impact every model and every model writer.
>>
>>      2) Model OpState using a revised logical datastore definition
>>         as introduced in [4] and also covered in [5]. There is
>>         also a variant of this that we believe doesn't significantly
>>         impact this choice.
>>
>>         With this approach, model definitions need no explicit
>>         changes to support applied configuration.
>>
>> >From a technology/WG standpoint, we believe an approach
>> that doesn't impact every model written (i.e., #2) is superior.
>> The counterpoint to this is that the conventions based
>> approach (i.e., #1) is available today and being followed in
>> OpenConfig defined models.
>>
>> We would like to hear opinions on this from the WG before
>> declaring one of the following as the WG direction:
>>
>>      A) models that wish to support applied configuration MUST
>>         follow conventions based on [1] -- and the WG needs to
>>         formalize these conventions.
>> or
>>      B) no explicit support is required for models to support
>>         applied configuration -- and that the WG needs to
>>         formalize an opstate solution based on the approach
>>         discussed in [4] and [5].
>>
>> We intend to close on this choice before Berlin.
>>
>> Thank you,
>> Lou (and co-chairs)
>>
>> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
>> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
>> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
>> [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
>> [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
>> * - Chris H. and Acee L.
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>