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

worley@ariadne.com Wed, 24 January 2024 16:54 UTC

Return-Path: <worley@alum.mit.edu>
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 98E98C14F5F4 for <urn@ietfa.amsl.com>; Wed, 24 Jan 2024 08:54:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.992
X-Spam-Level:
X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
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 dCjAQ8IaqhjJ for <urn@ietfa.amsl.com>; Wed, 24 Jan 2024 08:54:15 -0800 (PST)
Received: from resqmta-c1p-023461.sys.comcast.net (resqmta-c1p-023461.sys.comcast.net [96.102.19.42]) (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 07195C14F5EA for <urn@ietf.org>; Wed, 24 Jan 2024 08:54:14 -0800 (PST)
Received: from resomta-c1p-023278.sys.comcast.net ([96.102.18.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c1p-023461.sys.comcast.net with ESMTP id SfOmrpiSADeExSgU1rBAEQ; Wed, 24 Jan 2024 16:52:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1706115133; bh=OP24XAWF0PCKQLaZbzarKh2RI5d71tRoV5s5ugiIdVA=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=PrwcPLJtieKeRPy1CXYPv++qSln4egjK6lokwdHw7sWxYMMpwosJ27+59VwmXpzwT MHuy9LIYNwwVBqRzXrji4t47nMB+WvKpHmn+LzjM2OvQm2J/w4VE1+fKP7mtTSssqg +D2Kk/LdfXIAtfFHKEXsO8Fcj71pIGO6exn4282BA0m6PepP91m8ccUrhQIlwyFD+p oQkm2Iv5I4qL3YM5T95HCIYOE41tStrT6hn706c4renIqv1P8xYeuzUTpsZF6U85Xl nIV6TC/9qerbzfWInvJjZzJdHwmd3s6UICmLcdAb5pjgQGBptQQyss310lpZ4VhNqm e0ieQipNDFQOA==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::c362]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-023278.sys.comcast.net with ESMTPA id SgTdr3oG0pmn2SgTernZ3n; Wed, 24 Jan 2024 16:51:50 +0000
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 40OGpnTR1136050 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 24 Jan 2024 11:51:49 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 40OGpmbU1136047; Wed, 24 Jan 2024 11:51:48 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: urn@ietf.org
Date: Wed, 24 Jan 2024 11:51:48 -0500
Message-ID: <871qa6n07v.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4xfADTYvTlHabUMHsUm/jOtVcMJbZHBo3CkQPB0VTTaoujqrzUsWXShwWHcrmFoUUwu63W+gWrJvlKwzNIJgPCQbcz2PrHxVlYCgT5QnqgDReT2Nh13hSY XocMf3ZqKE5Zn5/dc1Vy3Z7d46IdOHwEtXI2ANXgmao5khkGGXyEO7kZYrvd6zKjnrAseX0mfEZJ1qGRfi4qoB/sLLVWV5Vm3XtJql+sMjrMetpNS87KbHIx lG7xH58OJz4gGET6wIiFXw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/kuwuWTb6u56CYg90j1bgZBk0OwI>
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: Wed, 24 Jan 2024 16:54:19 -0000

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