Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04

Christian Hopps <chopps@chopps.org> Wed, 13 February 2019 13:38 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 340C01310C6 for <netmod@ietfa.amsl.com>; Wed, 13 Feb 2019 05:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=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 x4muR0tEH4Nd for <netmod@ietfa.amsl.com>; Wed, 13 Feb 2019 05:38:01 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39FFB13108B for <netmod@ietf.org>; Wed, 13 Feb 2019 05:38:01 -0800 (PST)
Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 39D6A60428; Wed, 13 Feb 2019 08:38:00 -0500 (EST)
References: <155001540814.8555.686066688931046366.idtracker@ietfa.amsl.com> <20190213065309.algwcdny2k2x57ss@anna.jacobs.jacobs-university.de> <sa6tvh8hxvf.fsf@chopps.org> <20190213094938.cwvjjie24dm2kgi2@anna.jacobs.jacobs-university.de> <sa6y36kyore.fsf@chopps.org> <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de>
User-agent: mu4e 1.1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: Christian Hopps <chopps@chopps.org>, Joel Jaeggli <joelja@gmail.com>, netmod@ietf.org
In-reply-to: <20190213112221.j5s7uwm2jnlmv6sz@anna.jacobs.jacobs-university.de>
Date: Wed, 13 Feb 2019 08:37:59 -0500
Message-ID: <sa64l97x0zs.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/MsfENQtMBO9MxN8bVLkYeQigy9o>
Subject: Re: [netmod] Publication has been requested for draft-ietf-netmod-module-tags-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Feb 2019 13:38:10 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

>> > The 'rfc8199-' part in some of the tags does look to me like an
>> > attempt to scope 'service', 'element' etc. If this is being used, you
>> > will see that labels will use ad-hoc forms of scoping. The networking
>> > vocabulary is small and reuse of terms with different meanings in
>> > different contexts is common. If scopes are not needed, then I would
>> > argue 'rfc8199-' is not needed. Or it is needed and then it would be
>> > useful as well for ietf-qos and friends.
>>
>> RFC8199 defines an element vs service. Given those definitions these 2 tags seem USEFUL. So what do you suggest we call these tags to remove your "adding scope" objection? Would "ietf:module-class-element" and "ietf:module-class-service"? and reference RFC8199 in the doc/registry, clear your objection?
>
> I simply asked why we are inconsistent with the initial tags that we
> allocate. Others will want to allocate tags in the future, what do we
> tell them how to do it? If the idea is to go with a true flat
> namespace, then simply remove 'rfc8199-' from the tags and we have
> ietf:element, ietf:service, ietf:standard, ietf:vendor, ietf:user,
> which lines up with ietf:routing and the like.

But, ietf:element is too generic to assign the meaning "RFC8199 module classification of element" which is what "rfc8199-element" is supposed to be. It'll need to be something like "ietf:module-class-element" or "ietf:an-rfc8199-elemenet" or nothing I guess.

I have this suspicion that if it had been "ietf:an-rfc8199-element" you might not have brought up this introducing scope stuff. What if there was no "-" symbol used (i.e., "ietf:rfc8199element"?

The normative text says that we are defining no structure outside the prefix (i.e., it's flat). I believe what your saying is that if you ignore this normative text and just look at the "ietf:rfc8199-element" tags by themselves, one might imagine some meaning of scope. Do we need to repeat or reword the fact we are defining no structure beyond the prefix to make this more clear so people don't start imagining structures where we've normatively said they don't exist?

>> Please help clear your objections here as we're in the final stages of publication, and raising objections now I think should be accompanied with suggestions on how to clear them as well.
>
> I am not raising objections. I asked a question. And it is fine to be
> told that I should shut up because we are past WG last call and the WG
> likes what we have (and the WG or the IETF we will later figure out
> what lets say ietf:protocol is really good for or whether scopes like
> 'rfc8199-' are a good or bad idea).

Your opinion rightly carries a lot of weight in this group, and so your questions need to be addressed even though they are coming late in the process.

Thanks,
Chris.

>
> /js