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
- [core] Fwd: New Version Notification for draft-gr… Christian Groves
- Re: [core] Fwd: New Version Notification for draf… Christian Amsüss
- Re: [core] Fwd: New Version Notification for draf… Christian Groves
- Re: [core] Fwd: New Version Notification for draf… Christian Amsüss
- Re: [core] Fwd: New Version Notification for draf… Christian Groves