Re: [netmod] Module tags

Christian Hopps <chopps@chopps.org> Sun, 12 February 2017 17:40 UTC

Return-Path: <chopps@chopps.org>
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 F008C129960 for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 09:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4FR4zswU1M_S for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 09:40:22 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B553129868 for <netmod@ietf.org>; Sun, 12 Feb 2017 09:40:22 -0800 (PST)
Received: from utops.chopps.org (97-83-46-222.dhcp.trcy.mi.charter.com [97.83.46.222]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9D080623AA; Sun, 12 Feb 2017 17:40:21 +0000 (UTC)
References: <CABCOCHQJ+ef4C=TAfH9NK47mWgO0XOy1gg-cggigWq7Fqdfkgw@mail.gmail.com> <87d1eouby0.fsf@chopps.org> <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>
User-agent: mu4e 0.9.18; emacs 25.1.1
From: Christian Hopps <chopps@chopps.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
In-reply-to: <20170212145754.GA8564@elstar.local>
Date: Sun, 12 Feb 2017 12:40:20 -0500
Message-ID: <87shnjpat7.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/CPQNDNgMqqAsEpQ04NWONS1MeIc>
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
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 17:40:24 -0000

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.

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?

Thanks,
Chris.