worley@ariadne.com (Dale R. Worley) Mon, 24 February 2014 19:53 UTC

Return-Path: <worley@shell01.TheWorld.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E613C1A01AB for <urn-nid@ietfa.amsl.com>; Mon, 24 Feb 2014 11:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.098
X-Spam-Level: ****
X-Spam-Status: No, score=4.098 tagged_above=-999 required=5 tests=[BAYES_95=3, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=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 iLGnGyi0wqrh for <urn-nid@ietfa.amsl.com>; Mon, 24 Feb 2014 11:53:28 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4D11A0198 for <urn-nid@apps.ietf.org>; Mon, 24 Feb 2014 11:53:28 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1OJq4CN013510; Mon, 24 Feb 2014 14:52:06 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1OJhrW45671068; Mon, 24 Feb 2014 14:43:53 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1OJhoGO5625537; Mon, 24 Feb 2014 14:43:50 -0500 (EST)
Date: Mon, 24 Feb 2014 14:43:50 -0500 (EST)
Message-Id: <201402241943.s1OJhoGO5625537@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: urn-nid@apps.ietf.org
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/5Iv25BrxpK60dd4XiPX65EYHiww
Cc: Phillip Maness <Phillip.Maness@dts.com>, Mark.Johnson@dts.com
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 19:53:30 -0000

This is an idea that appeared in a previous message to urn-nid.  I
want to extract it and present it as a stand-alone message so I can
get more feedback on the idea.

The question is, "What do we do if an enterprise (business or other
organization) wants to have a NID of its own?"

("Enterprise" is used as a generic term for organizations in RFC 2578
and the IANA registry of "private enterprise numbers"
(https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers).)

I feel that this raises several questions which I have not seen
involved in other NID definitions:

- Because the registrant is a single enterprise, it would be desirable
  if the delegation was done under a policy that was explicitly
  even-handed toward all enterprises that might want a delegation.

- There are a *lot* of potential enterprise registrants, leading to
  the possibility of "NID pollution", filling the registry with names
  to the point that new names that are meaningful would be difficult
  to assign.

- Enterprises will likely desire an NID based on the enterprise's
  name, making it harder to resolve conflicts regarding desired NIDs.

It seems to me that a good way to address these issues is to create a
single NID whose sub-NIDs are delegated to enterprises.

I can see at least three ways to handle all enterprises in a
systematic way:

- urn:enterprise:<enterprise-number>:<NSS>

This technique uses the existing private enterprise numbers to
identify the enterprise.

- urn:enterprise:<identifier>:<NSS>

This technique would create a new registry, from which enterprises
would allocate identifiers on a first-come basis.  The syntax of
<identifier> would probably be the same as <NID> in RFC 2141.

- urn:enterprise:<domain-name>:<NSS>

This technique uses the enterprise's domain name.  (There are a bunch
of details that are needed to make domain names permanent.  See
draft-ietf-salud-alert-info-urns-11 for how to do it.)

Using my consulting company (Ariadne Internet Services) as an example
enterprise, these techniques would produce the following examples,
assuming that the overall NID was "enterprise", using the different
formats:

- urn:enterprise:14490:nss

- urn:enterprise:ariadne:nss

- urn:enterprise:ariadne.com:nss, or
  urn:enterprise:ariadne.com(2012-01-01):nss

If we wanted to be terse, we could assign the NID "e", giving these
examples:

- urn:e:14490:nss

- urn:e:ariadne:nss

- urn:e:ariadne.com:nss, or
  urn:e:ariadne.com(2012-01-01):nss

Perhaps this concept has been discussed in the URN working group and
they have already come to a decision.

Dale