Re: [netmod] OpsState and Schema-Mount
Andy Bierman <andy@yumaworks.com> Tue, 09 August 2016 21:01 UTC
Return-Path: <andy@yumaworks.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 5468F12D89B for <netmod@ietfa.amsl.com>; Tue, 9 Aug 2016 14:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 hVZFbgDJ8pbQ for <netmod@ietfa.amsl.com>; Tue, 9 Aug 2016 14:01:11 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 8A76C12B047 for <netmod@ietf.org>; Tue, 9 Aug 2016 14:01:11 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 74so39812386uau.0 for <netmod@ietf.org>; Tue, 09 Aug 2016 14:01:11 -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:from:date:message-id:subject:to; bh=X83mQZneAhoAO4phLE2gg1s/toURlt/Y/CS+3kBG8ls=; b=dXGxtfeWp7zmEMtveG6/psF2sfT4G2tiPPUa26zcRmWsogJoc2OsuL7zbRlM8SBPqv 4nSJMGhyNvNvIkc+Vrxwt34dO2InvyKseQyDpFJQLNrfSSarBUYpw2iec6DCcCoQOuP/ KV0tVJz8ooJZbHFyBJBHM7YKJLRxFbrM5/kNlhGZPleo7YFMZyItxM1Qt24ps+wM/nx3 khoDzxfeZRgCT6PXIA7X5lkfPPD5jSFj+SESz4PGPCYCv8cVp3hb7pIZ5S3KAvB+7qVt KAXe3QepfDo069C9utfc/DKtfQtGP01CD3oorhR7iwgbRfJapUuIk7Gs6ori4RBPd+C5 nuXw==
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=X83mQZneAhoAO4phLE2gg1s/toURlt/Y/CS+3kBG8ls=; b=hHmq3TdGUoa1OCqQyDL3oAETHWL+o82lqAjGmnPV1Dcb0lh0uySZxdu8Q+QM789l+5 enM70h37reEjckA9VtkYkYWa6BKO+iOSoRHwTDK7FES6MIwaCkU3DY3u2tnicMJDwkqV g7QuxINo4H3AywkYyfiK39THO7rIvQsrtBVnPtobLCbhm1zd9Ihmem/kZv0QSKDcLWQ0 cQIRZhQIZGAONHe8k+8zOJDBLMXRqDNOsQjgxj1yXLj1dX0LaGguNabWc6UaTpkD3AJX mGRNLRnZSum6vYltCAhG7ScgPlCGzZCCIiG683KceAMInmcaFI6jakvyY4ZM8KzUCo4A ei5Q==
X-Gm-Message-State: AEkoouupQWIHaDQdiSNu8cmsUM+VHn7w35yEBpCcI/Ud9R0c9Bw0dopOhHlNHrF4bs0JM4SL00t9qpzFdP96kA==
X-Received: by 10.176.3.72 with SMTP id 66mr204536uat.105.1470776470502; Tue, 09 Aug 2016 14:01:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 9 Aug 2016 14:01:09 -0700 (PDT)
In-Reply-To: <20160809133854.GD313@elstar.local>
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com> <D3C7B1A4.7482A%acee@cisco.com> <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com> <D3C8C14F.74A40%acee@cisco.com> <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net> <CABCOCHRuzTTBM-9OU5GaXS_fHmpNSn5Yp-3K6oXF33SeObSonA@mail.gmail.com> <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net> <CABCOCHTkUsLfrDZh4a3fGvpcTR0YVjpG2AHUwfLQGSa30JqQcA@mail.gmail.com> <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com> <20160809133854.GD313@elstar.local>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 09 Aug 2016 14:01:09 -0700
Message-ID: <CABCOCHS0HyeSDvoCK1adarhj5596azjfJ9hkASbjH0t4Evg4kQ@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>, netmod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f26941198670539a9d57e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-ENQnM5ncGrF2xA0SR9HVV2ei0c>
Subject: Re: [netmod] OpsState and Schema-Mount
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: Tue, 09 Aug 2016 21:01:18 -0000
On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote: > > > > In particular, I think that the guideline would be along the lines: > > If a given module "foo" only contains state and no configuration, then > > having a single top-level "foo" config false node is fine, but if a given > > module contains both config and state then the recommendation is to put > that > > under a config=true "foo" top-level node. Refining that slightly, If the > > state data is relevant even if "foo" hasn't been enabled then make the > top > > level "foo" an NP container. If "foo" has to be enabled on the system > for > > the state data to be relevant then make "foo" a P container (or give it a > > separate foo/enable leaf). In summary, I would suggest that the foo > state > > data should be pushed as far down the combined config/state tree as > > possible. It should be sited below (or adjacent to) whichever config > node > > is required to make that state data relevant. > > > > If config and state are in the same tree then it is easy to return all > the > > data in one RPC, or have separate RPC operations that just return > > configuration (e.g. <get-config>), or just return "state + containing > > hieararchy" (e.g. a newly defined <get-state>, or equivalent). > > > > Having separate foo vs foo-state trees at the top level is always going > to > > make it harder to return and manage a combined view of the config and > state > > data. > > I think it is crucial to separate (a) what protocols do today and (b) > what protocols might do at some time in the future. > > The current protocol reality, that is (a), paired with the reality of > network interfaces has lead to the (/interfaces, /interfaces-state) > design pattern and until we have (b) in place I do not think we have > really an alternative for the (/interfaces, /interfaces-state) > design pattern. > > If you have config and state are in the same tree, you simply can't > represent certain things that exist in reality. A single tree may look > 'simpler' but in several cases also simply 'unusable'. We did not > particularly like the (/interfaces, /interfaces-state) design but it > was the only solution that seemed to work for all cases given the > protocol reality we were in. > > +1 IMO the suggestion of using YANG extensions to associate data from different subtrees was the most practical approach so far. Moving objects and overloading object location semantics will have a big impact on existing code. Adding metadata and RPC operations will not be disruptive, and it allows more complex associations to be expressed. If the config needs to exist in order for the opstate and statistics to be relevant, then of course put them in the config subtree. But if they can be relevant without config, then the config data model has to be more complex to distinguish bogus entries from real ones. The YANG validation has to know the difference as well, adding hacks to that code. The access model needs to account for creation of bogus entries vs. real ones, adding an operational cost to this solution approach. The YANG to use depends on the requirements. The /foo-state tree can be considered "always on". If this is not desired then a better design is to use a P-container: container foo { presence "Indicates foo counters are being collected"; container foo-stats { config false; /... } } This combination of config and state has a use-case. I don't see a use-case for NP-container though. /js > Andy > > -- > 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/> >
- [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