[urn] Registration requirement for separation of namespaces

John C Klensin <john-ietf@jck.com> Fri, 18 March 2016 19:04 UTC

Return-Path: <john-ietf@jck.com>
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 27E7912D625 for <urn@ietfa.amsl.com>; Fri, 18 Mar 2016 12:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 ddozoexCmsSh for <urn@ietfa.amsl.com>; Fri, 18 Mar 2016 12:04:03 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7F812D52E for <urn@ietf.org>; Fri, 18 Mar 2016 12:04:03 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1agzgo-000MwL-BS for urn@ietf.org; Fri, 18 Mar 2016 15:04:02 -0400
Date: Fri, 18 Mar 2016 15:03:57 -0400
From: John C Klensin <john-ietf@jck.com>
To: urn@ietf.org
Message-ID: <0D5CC22F0F4285FAF4294291@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn/TVHlL575dM55PYcMyB7WlEoxMcY>
Subject: [urn] Registration requirement for separation of namespaces
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 18 Mar 2016 19:04:05 -0000

Hi.

This note is prompted by a recent Last Call discussion on the
IETF List about a new namespace proposal,
draft-martin-urn-globus.   Those who are interested in details
should have a look at that draft and archives of the IETF
discussion list for messages with subject lines containing that
string and posted within the last week or so.  I don't believe
those details are needed to understand what follows.

Section 4.3 of RFC 3406 requires that a registration request for
a new namespace have a "Namespace Considerations" section that

	"outlines the perceived need for a new namespace (i.e.,
	where existing namespaces fall short of the proposer's
	requirements)."

That requirement was dropped when we folded the registration
procedures and requirements into 2141bis and, indeed, was
dropped before the posting of the now-obsolete
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-09 in February 2014 (and
probably earlier).

That was some time ago.  Just to prevent any last-minute
surprises, does anyone see a need for a requirement that
proposals for new namespaces include consideration of existing
ones and why they are not applicable?  I note that such a
requirement may require significant research, especially as more
NIDs are registered, and may not actually be helpful.  I assume
that is the reason why the requirement was dropped.   If anyone
does feel that the requirement (or something like it) should be
reinstated, I'd appreciate it if they would speak up soon... and
that their comment justify the additional costs and explain how
whatever claims are made will be evaluated (or not).  Sending
proposed text would be ideal, but the most important thing, IMO,
is to know whether that is an issue that anyone plans to bring
up during WG or IETF Last Call.

thanks,
   john