Re: [core] Fwd: New Version Notification for draft-groves-core-rfc6690up-00.txt

Christian Amsüss <c.amsuess@energyharvesting.at> Sun, 13 November 2016 23:50 UTC

Return-Path: <c.amsuess@energyharvesting.at>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB721294B5 for <core@ietfa.amsl.com>; Sun, 13 Nov 2016 15:50:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JDT-g-OlOBtU for <core@ietfa.amsl.com>; Sun, 13 Nov 2016 15:50:28 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3D1129412 for <core@ietf.org>; Sun, 13 Nov 2016 15:50:28 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id BF191404A2; Mon, 14 Nov 2016 00:50:26 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B3A521E0; Mon, 14 Nov 2016 00:50:25 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [10.13.13.129]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 75DE03EE; Mon, 14 Nov 2016 00:50:25 +0100 (CET)
Received: (nullmailer pid 17921 invoked by uid 1000); Sun, 13 Nov 2016 23:50:23 -0000
Date: Mon, 14 Nov 2016 00:50:23 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <20161113235023.afbm2mgtyhnytcnp@hephaistos.amsuess.com>
References: <147669921707.4489.15070761418407896856.idtracker@ietfa.amsl.com> <7a174518-1ab8-103a-ca19-100d523ef706@nteczone.com> <20161110160451.5k3lqxfxonwj7nne@hephaistos.amsuess.com> <992f4fca-0881-e3d2-5cb3-29eac3586670@nteczone.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="kwiljta6u2l6e7i2"
Content-Disposition: inline
In-Reply-To: <992f4fca-0881-e3d2-5cb3-29eac3586670@nteczone.com>
User-Agent: NeoMutt/20161104 (1.7.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/H3O6AJ2sfZ0uIM_35SV5Eav0hLk>
Cc: core <core@ietf.org>
Subject: Re: [core] Fwd: New Version Notification for draft-groves-core-rfc6690up-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Nov 2016 23:50:30 -0000

Hello Christian,

On Sat, Nov 12, 2016 at 06:48:34PM +0900, Christian Groves wrote:
> > > [The prefix] MUST be followed by a ".".
> > the "core" prefix claimed in RFC6690 already violates that rule. Should
> > it be mentioned explicitly as an exception? Should the IETF "hand back"
> > all "core[^.]" to IANA?
>
> I'm not sure why RFC6690 violates the rule? RFC6690 indicates that "the
> value starts with a lowercase alphabetic character, followed by a sequence
> of lowercase alphabetic, numeric, ".",...". It then further recommends "that
> the period "." character be used for dividing name segments.
> 
> The only core value registered with IANA is core.gp so it follows the
> recommendation in the draft. If the MUST is a problem then I'm happy to fall
> back to the "it is recommended" text.

"violates" was maybe too strong a word; it's just that if we limited the
reserved names from "core*" to "core.*", "core" wouldn't need to be an
exception any more (as it is now) but could be just one organisation
prefix.

On second thought, making 'core.' an organisation prefix would make the
CoRE WG responsible for publishing (or at least managing) a part of the
namespace we just handed off to IANA, so maybe it does need to stay an
exception.

On "third thought": I didn't find that it says anything ruling out still
registering parameters with IANA inside a registered organisation
prefix. Can a (general, but of course I'm thinking of "core." here)
organisation prefix registrant submit a specification that says that
paremeters need to be registered as individual parameters in the CoRE
parameters registry (after all, that's still possible), provided it's
within what IANA will do? (A different working group could then, for
example, claim a "homenet." organization prefix, set the "RFC required"
policy or maybe name their own expert without opening up a IANA new
registry that would receive a delegation from the CoRE parameters).

Is this, in general, something that the draft allows or forbids, and it
is allowed, is it the way to go with "core."? Or do you think it's a
non-issue anyway?

Best regards
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn