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

From: Christian Amsüss <[email-masked]>
Date: Thu, 10 Nov 2016 17:04:51 +0100

Hello,

> [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?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Christian Groves <[email-masked]>
Date: Sat, 12 Nov 2016 18:48:34 +0900

Hello Christian,

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.

Regards, Christian

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 14 Nov 2016 00:50:23 +0100

Hello Christian,

On Sat, Nov 12, 2016 at 06:48:34PM +0900, Christian Groves wrote:
> 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.
> 
> 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

---

From: Christian Groves <[email-masked]>
Date: Mon, 14 Nov 2016 09:53:12 +0900

Hello Christian,

I think its largely a non-issue. "core.*" falls under the "core" 
exception that says the CoreWG (IETF review) is responsible for 
allocating IDs in the range "core*". IANA pretty much just implements 
what the WG requests. I can add some text around the explicit 
registration of "core.*" under "core*".

Regards, Christian