Re: [netmod] Module tags

Christian Hopps <chopps@chopps.org> Sun, 12 February 2017 19:30 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 50E05129ACF for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 11:30:41 -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 m2tGgfy-9kfk for <netmod@ietfa.amsl.com>; Sun, 12 Feb 2017 11:30:39 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 912C1129AC2 for <netmod@ietf.org>; Sun, 12 Feb 2017 11:30:39 -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 D4F94623AA; Sun, 12 Feb 2017 19:30:38 +0000 (UTC)
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> <20170212180506.GA8995@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: <20170212180506.GA8995@elstar.local>
Date: Sun, 12 Feb 2017 14:30:37 -0500
Message-ID: <87r333p5pe.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/wHmA0p92xJDL4ajJtioJZGn_p3g>
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 19:30:41 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
>> 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?

I don't break your software, I break my network. I bought your software
I want control over it.

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

Indeed, the application should rely on those tags being set. That's
what gives me control over what the application uses or doesn't.

I'd like to hear what is gained by *not* providing the user (customer!)
this option.

Thanks,
Chris.

> /js