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

"Kiran Koushik Agrahara Sreenivasa (kkoushik)" <kkoushik@cisco.com> Fri, 17 June 2016 18:36 UTC

Return-Path: <kkoushik@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 F1DEC12D84D; Fri, 17 Jun 2016 11:36:04 -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 yErd8cDUz1kv; Fri, 17 Jun 2016 11:36:03 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878A512D815; Fri, 17 Jun 2016 11:36:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9878; q=dns/txt; s=iport; t=1466188563; x=1467398163; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8oymEf9JYNYNQ9R/qzO7nUGaGjs2uqWHmBQPa1an3Bo=; b=Z2GE4oeJBVptz+PrMC14fwwrfSJoP5s7ly48+qnv5YzfgIuuSoeQW5Ft 3wvQXAlgHlHZpoHjLMc4/ftsbcNt2G4XY+/nd2fgAdfPndcwuekhBihyu 13BFNyHTW1r3xbRYgrSmsgcS0i4osbLWOp73nJdaGdxftOmOOUtSifMHm E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAwARQmRX/5NdJa1dgnBOVn0GtVqFAYF6FwEKhStKAoEkOBQBAQEBAQEBZSeETAEBAwEBAQFrCxACAQgOMQcnCxQRAgQOBRuIDQgOwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYp0gSKIeQWOLIpFAYYEiCSBaY05hk6JJgEeNoNwboh8fwEBAQ
X-IronPort-AV: E=Sophos;i="5.26,484,1459814400"; d="scan'208,217";a="286997887"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2016 18:36:02 +0000
Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5HIa2JV004654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Jun 2016 18:36:02 GMT
Received: from xch-rcd-014.cisco.com (173.37.102.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 17 Jun 2016 13:36:01 -0500
Received: from xch-rcd-014.cisco.com ([173.37.102.24]) by XCH-RCD-014.cisco.com ([173.37.102.24]) with mapi id 15.00.1104.009; Fri, 17 Jun 2016 13:36:01 -0500
From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <kkoushik@cisco.com>
To: Lou Berger <lberger@labn.net>
Thread-Topic: [netmod] Opstate solutions discussions: update and request for WGinput
Thread-Index: AQHRyMbMg9jP/RxUKEKiv54jnb2EsZ/t/JyA
Date: Fri, 17 Jun 2016 18:36:01 +0000
Message-ID: <D389AD13.1CDBF%kkoushik@cisco.com>
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <008701d1c8ab$211bfc20$4001a8c0@gateway.2wire.net> <a9502fb2-2541-3d19-1625-9f1da0560758@labn.net> <CABCOCHSjSWZRVaWEfhCngdinQ4Tav3d6v_T=xxwMrduphZ3KOw@mail.gmail.com>
In-Reply-To: <CABCOCHSjSWZRVaWEfhCngdinQ4Tav3d6v_T=xxwMrduphZ3KOw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.243.35]
Content-Type: multipart/alternative; boundary="_000_D389AD131CDBFkkoushikciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3tlGnnX3o-ofgH-lwWuP1zfb77Q>
Cc: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, netmod WG <netmod@ietf.org>
Subject: Re: [netmod] Opstate solutions discussions: update and request for WGinput
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: Fri, 17 Jun 2016 18:36:05 -0000

Hi All
I'd like to support Option B below.
>>     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].

Thanks
Kiran


>> 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<mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>


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