Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 29 July 2016 16:32 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 A0C9712D814 for <netmod@ietfa.amsl.com>; Fri, 29 Jul 2016 09:32:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level:
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham 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 tY3C5z6kDBnx for <netmod@ietfa.amsl.com>; Fri, 29 Jul 2016 09:32:29 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11EA12D812 for <netmod@ietf.org>; Fri, 29 Jul 2016 09:32:28 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 81269A53; Fri, 29 Jul 2016 18:32:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id SexHfq9h-xqM; Fri, 29 Jul 2016 18:32:21 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 Jul 2016 18:32:26 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2554720077; Fri, 29 Jul 2016 18:32:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id o7b9z2SheDC3; Fri, 29 Jul 2016 18:32:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04F5620075; Fri, 29 Jul 2016 18:32:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7D5C03BFAD3D; Fri, 29 Jul 2016 18:32:20 +0200 (CEST)
Date: Fri, 29 Jul 2016 18:32:20 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Robert Wilton <rwilton@cisco.com>
Message-ID: <20160729163220.GA3579@elstar.local>
Mail-Followup-To: Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Ladislav Lhotka <lhotka@nic.cz>, netmod WG <netmod@ietf.org>
References: <bed9398c-0e6a-450e-d2ac-b381b6bebf87@cisco.com> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com> <m24m79c1ja.fsf@birdie.labs.nic.cz> <D3BF8708.72620%acee@cisco.com> <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com> <m260roedim.fsf@birdie.labs.nic.cz> <CABCOCHRF98sTa=MA1VTkZovOufL-=yQr9Gzy+ojnncjSfK1y0Q@mail.gmail.com> <e307c2fc-e621-b5c6-4fcc-67bbcdcb87b9@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e307c2fc-e621-b5c6-4fcc-67bbcdcb87b9@cisco.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Ux2xFjy7o9WAzF0WCt-RpkZAGI8>
Cc: netmod WG <netmod@ietf.org>
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
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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, 29 Jul 2016 16:32:30 -0000

On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 
> I would like to know what should the common approach for IETF standard
> models be?  E.g. is it one of the following:
> 
> 1) All config false leaves for foo must go under /foo-state.

I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?

> 2) All config false leaves for foo must go under /foo

This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.

> 3) All config false leaves go under /foo where possible, or /foo-state
> otherwise (e.g. for restconf-monitoring).

I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.

> 4) Config false leaves go wherever the model writer decides is appropriate.

I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/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/>