Re: [urn] Registration request for urn:thread:

Esko Dijk <esko.dijk@iotconsultancy.nl> Thu, 25 January 2024 15:55 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEE4C14F60E for <urn@ietfa.amsl.com>; Thu, 25 Jan 2024 07:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGoI__kMmm5l for <urn@ietfa.amsl.com>; Thu, 25 Jan 2024 07:55:39 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2138.outbound.protection.outlook.com [40.107.6.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88845C14F60D for <urn@ietf.org>; Thu, 25 Jan 2024 07:55:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FZvnXrINJZnhv/KhypNIEFIejBtAcFYZhDKQpp7MLPzERNf8VeSb9kID5bXzTbwkIvKr/AzBLqKT3Tc7Tw8SbsMZeb5K6ZMbtzRBLHiJMugIGbkrXvCedm4vN+mLGY9cmAkRUGBZdKtZQFhAYbRKc+DU0hhKXc1v3zYWHnYdmDEzEe0/WNhzZPc2m8N1AGIpdTvshDgzwOLgKXw5BJc2BwmuYzh+mzpK1uiWkQ7O36/gP/hxXeESpl40YI4AhvQB/ToM9qYdOmMCpyA4chx618bDp+9EzYNveRLLVkIFkh4+62Enis0cQ7N8LI5Myje3kheq749D/BSZuQGkKSmsQg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MwxkyTMGsCQ6+lVQVUxV1GKkN5p2KFyh1geF1t2A+bg=; b=OW0239qksV38HMgjgCcOsgIBn/3UkPH0HJA8Cz/ZDVRaCuTbiOIcSvcPyW+MsDfPNYAvUDcknzAHo6aJBrIgCJeP9aJ8ClQsglD8p8uV1HfNoDd4kno1eAiVRXdVi0n4A4FBfe96gX1IJ0DDnOx2oGZs8AyWWNvTDHB7ChqbmNK1i98ufprDyvB9emgw8YrtDYnregXuzgY1Pif3ojh1x1V2owRvLCDA6RWs6X7l4QCIKL0SICdzOqjX0SkUKkZ7GguQ8KyzPs2C78hRtmEunsp158+CW/c2lJinRmziI8eaS2TqW+GwT0Xe++OQCzWpRku3gLiTXAkDtzAj7VUuFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MwxkyTMGsCQ6+lVQVUxV1GKkN5p2KFyh1geF1t2A+bg=; b=BFrMTBclOvjLE+n33WM0ABCZtykl3RDwa6B1t04stjUsomTkH/hfivp8NrCgvQkCj3TN8QrlvG8nMMIIpI7dcyK4p0HxpXF+Gw7NOwJUU9ofY9TgQl9gHHe6Zo13rOdwf0agtJ/vBAQFJTbq/8Hp/j0iTMwaVXNjpnsCmDnc3+A=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by VE1P190MB1022.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:1ac::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7249.14; Thu, 25 Jan 2024 15:55:36 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1a28:be0b:8c84:d18]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::1a28:be0b:8c84:d18%3]) with mapi id 15.20.7249.013; Thu, 25 Jan 2024 15:55:36 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "Dale R. Worley" <worley@ariadne.com>
CC: "urn@ietf.org" <urn@ietf.org>
Thread-Topic: [urn] Registration request for urn:thread:
Thread-Index: AQHaTuWxaVa0INq060uxDHI7aTdzVrDqnouw
Date: Thu, 25 Jan 2024 15:55:36 +0000
Message-ID: <DU0P190MB1978A4A40D7E779D25AD7B4DFD7A2@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <871qa6n07v.fsf@hobgoblin.ariadne.com>
In-Reply-To: <871qa6n07v.fsf@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0P190MB1978:EE_|VE1P190MB1022:EE_
x-ms-office365-filtering-correlation-id: c5d05a30-2af8-460b-1019-08dc1dbe120e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QFfDQNZqWcKJMilIGsy6sv4SXmcsuVgGDlDhVbTgHM6doe1cpCTSLwDNSvWBHk4anL0bKAJS5NuQ+I00ga9FfZrCfibMpbiAOKcikJJCHIqNXSprxNvECKMojZ71uN0OQss6rr6DTjEqnuoiYIFHteeHHZbe/spufxCLcJXAg3lUjSZLSmYPxvcoUP+u4f7aHInejy1sZ4WER5+Vml/HLpsdUfZbWuuEAFCQImbuEaddhQJY636w44XmX7hNsJWJSnpbPSnC1KkWXQGF9JNFGQxg7S03AnOCQcXQOoSlK6BjfiKpSUu3WKeAsdWVWjrhjm66iayIrAJFVkUOX/Z9RpHtUAmAqPAwDUlBDXJuNmIx5wceynEFNH7WJsOT0b1LDBTK5CIjOsRa9of1TMyflPVECRjCnDeIKwH24iLd+NqiZYD4opcw+HZVFs/igqcJcNI7wewfsBqYHvX9OMzTcqOEKZUSLywJhebSaETgU2tN0qN5cqBM9n/AlsjqafyEo7lLwPHiP2MobFaxvTqo2rtTD9t3VSpU0joNcNRYZAbhtQxA8FEV2/fm75qjWeh+QBRYso0oNY5QOOT1jLAdc8lK2k2k+pALUPowsBJP3ihuBaLZJgsaQ66onE6JRwL8YezapewM5X4IZrOVVU/R0g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(39830400003)(376002)(396003)(366004)(136003)(346002)(230922051799003)(64100799003)(451199024)(186009)(1800799012)(33656002)(66899024)(83380400001)(2906002)(122000001)(44832011)(4326008)(8676002)(5660300002)(38070700009)(52536014)(41300700001)(478600001)(966005)(38100700002)(86362001)(76116006)(6916009)(66556008)(66946007)(66446008)(66476007)(64756008)(316002)(53546011)(9686003)(55016003)(71200400001)(7696005)(6506007)(26005)(8936002)(46800400005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: RDnjZnsJtGhooDh4yurt1CLL2X+EqYvFxU7FcglB6gQJzzRuO1RE2VqcAK3OMUMB1r+H3DzomsirTD1mCBI9WkZCa6gt0jna8FWSjOJtN0ofykVGYuXkpqSkjV2/Ec0tKztIjRATg6NmOqWJSsi+TZcpxJHMtMU+1UifasxSFbAVyD59Iz6OnxMC+6QP5mNcpP3QppTS0L9DSHEr1YCkX2eTcuHwIXZTI/Kw5Sowq3OMCNBDaqORNNvCG8YYEA7u3JP10gldHJi7/XrPOIs7bPPfK2yT6TwJAiJYTQW1Y0VU0mqZv3M7pmEU5FcNzyVXUyjWlQyQKBPfKeWOeHS4H5U9StzUIVeFaVQaEUIdSPvYji53DROeLRcQoIwHbgxoYH6HPVdo2PV3hck5NzL+9C5sl45SgruAgYJmGCvfGOP4flePzkW8Kr8R7iM2kWuCaN77Yr7USDwbygdwbe5wTRajWozs3PlepVdZ0KlDErFlnxFd0UM3PS25WNUmCorcpivYIBt7N8khT98NLO+tPSNHQBeu44lEQ7zGkEFcIQjTQfL3udt7Cbu+SNKSDLHRcgf/rLYMuJQMEqaoSroU2i1to+Flz+Hwr1UXZmUhr3cNQXBNPlbOeBYWDveBdRPsXWPID4vBYQ8BSZlTPGPkZExf0BxbIWR3KIYSuAM6Cw8iC1ql+fk2Vbg04Vja9/ocpTSENpMN/Cw//eUdpzvqTSJvTsmS/1CSCHtf//bdDEhUggYy5lGgCeZLaC4Y1xdWscJDOiqSUd+FrNcuwY88s/zFLU6MxpTRwpkWY+2Z17yjOBRjFg/rAWm0iJAWyCczJpUe/Kka1ZuxlTIP74feOrp5btYJLyy5r9Mhp9V/IuYvKexrirPW9ejVsJhSZLM/AUOhXoxtAypEXusyfdF4z0OIwBBIRFDLaajLyF16WT331teO8K6BslqDuh/4XcktULL5PJiTvjHVDbS7qiP7ncZt+k2h849zLQBUS2HvfmdK1C01MymeUdLXBFv/5C2zef3E3gB6ViQC4bIBwtzYzhpFPp5rHOmbjj+KMV7xZsID/exalagThZziOEx4lHtEz2rNxicjXzRBxV05oRmjwLa4y1kW0FL8WuzbOjj+pX2fY3XEw63CdP696iCwS7d9pHfBU6ZEuYu63zvg/EPZTl8kpsUWA8Dd2LFO13h83yP6jtEnniP/Kcu8f3LvM3vJ2wI+J3Jv6QN04aht6O1XdxAIvD9H7XfycNRREqNqPnDBbqLFasflJcYyjN1dKMPG+XbtjXz38T9h/tpmc97jHiMBGCXpgnIrHI0BSttB4SU9AK+ATIx6/8YP8CVgW1fTfTf9Ku352XjBJciu8MPyrJwxRE1soqn0Jp3jfgmYUK5R+w2z1KuvcsUo6y2naOKktT6YFIW0Oxc/NQbUrPliP2VxXqgN9SX2y8AFLHRdm1ElPmHaYbnQFlq/gN2JEkt/Uxzj6vIkrfNWjEAkiZZUhYinYxy2MlIXpYzffqgOgbSM1HJwMrBAMtybYibl+Wp4Xshky70wdOv5vBwz8mJbtzPR3Ov/pWphYZOTCA7peyp8Ksnd55DEJefPtxNB1q11
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: c5d05a30-2af8-460b-1019-08dc1dbe120e
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2024 15:55:36.3577 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: N4V9zqyXEtUKIJBofCfEquUXFW+mu4wAAyE326W5pSVYi0jeZFSU9PlrTRsKdNh6/3JCd5c94YqVp7Bj376w3co2kOBsKvGGSrEQwU8EAcM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1P190MB1022
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/hS1OEG7Pn5KlsmKtqNw0PzzzI3E>
Subject: Re: [urn] Registration request for urn:thread:
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2024 15:55:44 -0000

Hello Dale,

Thanks - I agree with your remarks and suggestions. I will do an update of the request template with these items included.

> This text says "published" but the page at the URL only allows access under NDA.

Right, the "internal use only" in the EULA seems to prohibit public discussion on content or quoting. 
Could we say "made available by Thread Group to members and non-member licensees" ?

For the sub-namespaces we can define the syntax & semantics already now in the request doc; so that part at least is public.

For the email addresses: if personal addresses are not preferred, we could also list a single role address help&threadgroup.org which can forward technical questions to the right people. Is this preferrable?

Esko 

-----Original Message-----
From: Dale R. Worley <worley@ariadne.com> 
Sent: Wednesday, January 24, 2024 17:52
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: urn@ietf.org
Subject: Re: [urn] Registration request for urn:thread:


Esko Dijk <esko.dijk@iotconsultancy.nl> writes:
> Below is the RFC 8141 registration template for this request for
> "urn:thread:".

Overall I approve of the registration, but there are some issues that
should be addressed.

> URN Namespace Registration for Thread Group, Inc.
>
> Namespace Identifier:  thread
>
> Version:               1
>
> Date:                  2024-01-22
>
> Registrant:
>
>   Name:                Thread Group, Inc.
>
>   Address:             5000 Executive Parkway, Suite 302
>                        San Ramon, CA 94583
>                        United States of America
>
>   Website:             https://www.threadgroup.org/
>
>   Contact (general):   help&threadgroup.org
>
>   Contacts(technical): tom&threadgroup.org
>                        esko.dijk&iotconsultancy.nl

It would be preferable if the technical contact e-mail address was a
"role address" rather than being a list of two personal addresses.  For
how long will this contact definition remain correct?

> The syntax of the URNs complies to the Namespace Specific String (NSS)
> rules as defined by [RFC 8141].

What you want is maximum flexibility, and a lot of SDOs have made
applications that have maximum flexibility.  But it would be much better
if you explicitly stated the minimum details involved.  The typical
boilerplate is something like RFC 5279 sec. 2:

   Declaration of syntactic structure:

      The Namespace Specific String (NSS) of all URNs that use the
      "3gpp" NID will have the following structure:

            urn:3gpp:{3gpp-urn}

      where the "3gpp-urn" is a US-ASCII string that conforms to the
      NSS(Namespace Specific String) Syntax described in RFC 2141
      [RFC2141] ...

> The Thread Group will operate its own registry for any URNs (including
> sub-namespaces) within the namespace; and additional requirements for
> each of the allowed sub-namespaces will be defined by the Thread
> Specification.

Likely when you speak of sub-namespaces, you mean a syntax of

    urn:thread:subnamespace:somethingmore

but you don't say it, and the generic URN syntax doesn't specify such a
concept.  (Also, you don't specify the allowed syntax of
<subnamespace>.)  Indeed RFC 8141 sec. 5 says:

   Because the colon character (":") is used to separate "urn" from the
   NID and the NID from the NSS, it's tempting to think of the entire
   URN as being structured by colon characters and to assume that colons
   create a structure or hierarchy within the NSS portion of the URN.
   Such structure could be specified by a particular NID specification,
   but there is no implicit structure.  In a URN such as

      urn:example:apple:pear:plum:cherry

   the NSS string is "apple:pear:plum:cherry" as a whole, and there is
   no specific meaning to the colon characters within that NSS string
   unless such meaning is described in the specification of the
   "example" namespace.

What you seem to imply is that it's possible to *register*
sub-namespaces within which URNs may be allocated by mechanisms *other
than registration*.  But it would help to say that explicitly, and also
to include that a sub-namespace registration must specify the procedures
to be followed (perhaps by multiple parties) when creating URNs within
the sub-namespace.

> Security and Privacy:
>
> Any registered URNs (or URN sub-namespaces) will not contain
> privacy-sensitive information about persons such as names, addresses,
> or personal data. URNs used in communication within designated
> sub-namespaces may contain privacy-sensitive information or sensitive
> security material only if the communication is cryptographically
> protected as defined by the Thread Specification.

I think you have the right idea, but it needs rephrasing.
E.g. "communication within designated sub-namespaces" doesn't seem to
mean the right thing.  Perhaps:

    Some URN sub-namespaces may allow that URNs within the sub-namespace
    may contain privacy-sensitive information or security-sensitive
    material.  Registrations of such sub-namespaces will specify that such
    URNs may only be communicated when the communication is
    cryptographically protected as defined by the Thread Specification.

> Documentation:
> 
> Thread Specification (most recent version higher than v1.3) as
> published by Thread Group. Available at:
> https://www.threadgroup.org/ThreadSpec Note: some versions of the
> Thread Specification are only available to members of the Thread
> Group, or its affiliates. Future versions of the Thread Specification
> are expected to contain URN definitions and the contents of the
> internal registry as described in this registration request.

This is not consistent.  This text says "published" but the page at the
URL only allows access under NDA.  As things stand now, it would not be
allowed to e.g. discuss the relevant parts of the Thread Specification
on this mailing list.  So the Thread Specification is not "published" in
any functional way.

Dale