Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
Robert Wilton <rwilton@cisco.com> Thu, 21 July 2016 16:39 UTC
Return-Path: <rwilton@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 5C19B12D7BD for <netmod@ietfa.amsl.com>; Thu, 21 Jul 2016 09:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.809
X-Spam-Level:
X-Spam-Status: No, score=-15.809 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, 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 zR74q4z0CXCi for <netmod@ietfa.amsl.com>; Thu, 21 Jul 2016 09:39:33 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531E812D7B2 for <netmod@ietf.org>; Thu, 21 Jul 2016 09:39:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8579; q=dns/txt; s=iport; t=1469119172; x=1470328772; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NY5ClPiG9soy3svgNZaLcOKFyGzdmKKvt3C0hO/R5rw=; b=e1CkDV9S+FKu8FxYsA0zHLfEH7ybSZTIK9Nf7KIBXSJ2xSXywyXbNXwF lmSJ2usPeuvVC1YVhQGKqgJ4VRXzvPiHWvz7cO4Y2M1Nc9N6WK25oUmKv IOqzZFiwQ/vk+koKR6UkpzkrLF2xQvGN5CUVSiYXH5UuCKWlyUJ5UcmPf Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B2LwCK+ZBX/xbLJq1dhBUqA0+4bYF7IoUuSgKBaBIBAQEBAQEBZSeEXQEFAQEhDwEFNhsLGAICJgICJzAGDQYCAQEXiBUOr1+NWgEBAQEBBQEBAQEBARwFgQGFKYF4gVKBA4dBgloFjgyLGoYWiFWBbIdmI4VFhmCJQSUEK4ILHIFOOjKHTgEBAQ
X-IronPort-AV: E=Sophos;i="5.28,399,1464652800"; d="scan'208";a="678491828"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jul 2016 16:39:29 +0000
Received: from [10.61.86.58] (ams3-vpn-dhcp5691.cisco.com [10.61.86.58]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u6LGdT5C026582 for <netmod@ietf.org>; Thu, 21 Jul 2016 16:39:29 GMT
To: netmod WG <netmod@ietf.org>
References: <D3A935F0.6A4DC%acee@cisco.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <eb15fd23-2c0a-50c4-1ebc-7c0e4867dfd8@cisco.com>
Date: Thu, 21 Jul 2016 18:39:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <D3A935F0.6A4DC%acee@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/eBdDofKC271lt06aEV04jnMlXl4>
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
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: Thu, 21 Jul 2016 16:39:35 -0000
Hi, So after the various meetings and discussions this week, I think that the most important thing for IETF to do is to publish reviewed YANG models quickly, with the understanding that it is better to publish imperfect models than to end up not publishing any models at all. This is with the understanding that these models could be fixed by subsequent RFCs if required. So, I effectively support Acee's solution (2). But to state this more precisely, I would suggest that the specific guidance should be: 1) IETF Models MUST NOT have a split for applied configuration leaves. All IETF models that have not been turned into RFCs must be modified to remove any applied configuration nodes. Any models that have this convention in RFCs should be revised to follow a consistent intended/applied convention for IETF models. [The justification here is that IETF standard models have to be able to assume that the applied configuration will be available via a separate applied configuration (or operational state) datastore or equivalent mechanism.] 2) All IETF Models MUST put "derived state and statistics" into a separate namespace from the configuration (i.e. top level "feature" and "feature-state"). The two trees must be as structurally similar as possible, sharing the same paths, node names (except the top level node), using the same lists keys where appropriate, etc.* 3) Both of these rules should be written into rfc6087bis. We should then get this guidelines document finished as quickly as possible at the highest priority, and use that as the definitive guideline for the modules that the working groups are working on. * Note, I chose this option not because I think that it is elegant (because I don't) but because it seems to me that it is the only pragmatically option that we have available. The alternatives appear to be: (i) we wait another year before publishing any models (if ever), or (ii) we publish models that no-one can use today without violating the existing RFCs, or (iii) we end up with a hybrid mess without any consistency. Thanks, Rob On 11/07/2016 18:36, Acee Lindem (acee) wrote: > While there are details to be worked out between the two data stores > models (as indicated below), we now have implicit modeling of applied > configuration. Existing models (both standard and draft) do not take this > into consideration and, consequently, much of the state that is modeled > explicitly represents the application configuration. For the RFC models, > it probably doesn’t make much sense to redo them (unless they are being > reworked for other reasons). This still leaves the existing WG draft > models for which we have basically 3 options: > > 1. Do nothing - allow them proceed as they are with multiple ways of > representing the applied configuration. This would provide visibility to > the data independent of whether or not the device supported the revised > data-stores supporting implicit retrieval of the applied configuration. > 2. Prune out the redundant data nodes except those required as list > keys, etc, since they can be obtained from the applied state data store. > 3. #2 plus collapse the config (read-write) and system-state > (read-only) into common containers. No more branching of > <model-name>-config and <model-name>-state at the top level of the model. > > At I high-level, I feel these are the options. I’m not married to any one > of these and the worse thing we could do is hold up progression of the > existing YANG model drafts for another couple years while we debate the > best course. Having said that, #3 is compelling since it will yield the > most concise models and colocates the schema data nodes for any managed > object. > > Thanks, > Acee > > On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger" > <netmod-bounces@ietf.org on behalf of lberger@labn.net> wrote: > >> 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod
- [netmod] OpsState Direction Impact on Recommended… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Rob Shakir
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Alex Campbell
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Juergen Schoenwaelder
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Andy Bierman
- Re: [netmod] OpsState and Schema-Mount Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Acee Lindem (acee)
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState and Schema-Mount Robert Wilton
- Re: [netmod] OpsState and Schema-Mount Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Balazs Lengyel
- [netmod] OpsState and Schema-Mount Balazs Lengyel
- Re: [netmod] OpsState Direction Impact on Recomme… Balazs Lengyel
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- [netmod] Corollary to [OpsState Direction Impact … Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Ladislav Lhotka
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Mahesh Jethanandani
- Re: [netmod] OpsState Direction Impact on Recomme… Xufeng Liu
- Re: [netmod] OpsState Direction Impact on Recomme… thomas nadeau
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Kent Watsen
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Alex Campbell
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Rob Shakir
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Juergen Schoenwaelder
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Acee Lindem (acee)
- Re: [netmod] OpsState Direction Impact on Recomme… Lou Berger
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman
- Re: [netmod] OpsState Direction Impact on Recomme… Robert Wilton
- Re: [netmod] OpsState Direction Impact on Recomme… Andy Bierman