Re: [netmod] Module tags

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 12 February 2017 18:05 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 317591299A1 for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 10:05:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 6dCtkrsFgTeC for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 10:05:06 -0800 (PST)
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 E71A01293E0 for <netmod@ietf.org>; Sun, 12 Feb 2017 10:05:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6FA4674D; Sun, 12 Feb 2017 19:05:04 +0100 (CET)
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 mTWVDgxybmwN; Sun, 12 Feb 2017 19:04:58 +0100 (CET)
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; Sun, 12 Feb 2017 19:05:03 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA40E200C1; Sun, 12 Feb 2017 19:05:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rzbpJwpT4h4I; Sun, 12 Feb 2017 19:05:03 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4940B200BE; Sun, 12 Feb 2017 19:05:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 262E63E72BE0; Sun, 12 Feb 2017 19:05:07 +0100 (CET)
Date: Sun, 12 Feb 2017 19:05:06 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Christian Hopps <chopps@chopps.org>
Message-ID: <20170212180506.GA8995@elstar.local>
Mail-Followup-To: Christian Hopps <chopps@chopps.org>, Andy Bierman <andy@yumaworks.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <20170211135417.GC6490@elstar.local> <8737fju4n5.fsf@chopps.org> <20170212104106.GA8142@elstar.local> <871sv3r7xf.fsf@chopps.org> <20170212115135.GB8250@elstar.local> <87wpcvpo0z.fsf@chopps.org> <20170212130412.GA8415@elstar.local> <87vasfpl8n.fsf@chopps.org> <20170212145754.GA8564@elstar.local> <87shnjpat7.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87shnjpat7.fsf@chopps.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2kn4lVAh-8t9BR5il8uBUa9KGG4>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Module tags
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: Sun, 12 Feb 2017 18:05:08 -0000

On Sun, Feb 12, 2017 at 12:40:20PM -0500, Christian Hopps wrote:
> 
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> 
> > On Sun, Feb 12, 2017 at 08:55:04AM -0500, Christian Hopps wrote:
> >> The tags defined by (a) and (b) are still for the users use. In fact
> >> aren't there plenty of defaults in configuration on devices that the
> >> user can override or remove? I guess I don't understand why this is so
> >> controversial.
> >>
> >
> > In YANG, you can overwrite defaults by configuring explicit values,
> > you can't remove the default - the default is just not used anymore
> > once there is a configured value - the default still exists and it
> > will come back when there is no configured value anymore. But I am not
> > sure the analogy is a good one.
> >
> > If a data model defines an implementation should set the tag 'foo',
> > then it feels odd to me to go to the device and to remove that
> > tag.
> 
> Perhaps strictly from a module designers point of view it might seem
> odd. One reason we allow for changing things from strictly the designers
> point of view though is because the designer can't anticipate all use
> cases and situations that arise from here to eternity. As I'm the user,
> unless there is a very good reason not to the default should be to let
> me do what I want. That's the unix way, and I certainly like unix. :)
>
> > The tag 'foo' after all is there because the data model says it
> > should be there - so in an ideal world all implementations of this
> > data model will set the tag. Why would be removing the 'foo' tag on
> > all these correct implementations be significantly cheaper than simply
> > using your own (application specific) tag instead of the 'foo' tag
> > (that does not seem to do what you like)? Or you add a tag
> > 'ops-foo-broken' to those implementations where you believe the foo
> > tag is inappropriate.
> >
> > At the end, it is not a big deal to remove tags but somehow I am not
> > sure whether there is not a difference between (a), (b), and (c) tags.
> 
> The tag is there to help identify things about the module to the users
> of that module, as the ultimate authority on the use of this module I
> want to be able to override that default just like I can override other
> default values.
> 
> Your right I can add a new tag to be used by software that I can modify,
> but what if other software I need to use is also using the designer's
> tag? I can only control it by removing the tag in that case.

Or you break software by removing that tag. If a module says an
implementation must set a certain tag, how can it help to remove this
tag? Are you not breaking a part of a contract between a module and
implementations using the module?

> It doesn't cost anything really to allow for this, and it provides
> future-proofing control to the user, conversely what do we gain from
> disallowing it?

I am simply challenging you in order to better understand how people
expect tags to be used, what it means to have type (a), (b), and (c)
tags and why it is necessary to be able to remove type (a) and (b)
tags. I guess it all boils down to what it really means to say in a
module that a certain set of tags must be set, i.e., whether an
application can rely on these tags to be set or not.

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