Subject: [urn] Registration requirement for separation of namespaces

From: John C Klensin <[email-masked]>
Date: Fri, 18 Mar 2016 15:03:57 -0400

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

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Mar 2016 20:23:13 +0000

I'll say this as a participant only, but informed by my experience
over the last four years as the AD responsible for handling URN NID
requests:

Essentially all (perhaps exactly all, though I can't remember
definitively) NID requests that I've handled over the last four years
are from organizations who want namespaces for use by their
organizations or industries.  It's quite clear that there is little to
no value in asking them to document why they need a new namespace:
it's because they want one associated with their organization or
industry, and that they control.

There could be situations where it would be useful to ask the
question: if there's already a namespace for, say, naming movies (call
it "movie:"), and a film-industry organization asked for one called
"film:".  We'd definitely want to know why "movie:" doesn't suffice.
The problem is that in order for us to ask the question, *we* would
have to know that "movie:" exists and seems related, and all the
requestor would have to do is to put a boilerplate "we need our own
industry namespace that we control" statement in.  Unless we notice
that they've missed (or intentionally ignored) the related namespace,
nothing will be accomplished.

I'd support something that said that if there are related namespaces,
the request should note them and explain why they are not adequate and
this one is different.  But I'd not support its being a requirement,
because in most cases it's unnecessary and in the others its a
requirement that's unlikely to be enforceable.

Barry, as participant

On Fri, Mar 18, 2016 at 7:03 PM, John C Klensin <[email-masked]> wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Mar 2016 16:44:50 -0400

--On Friday, March 18, 2016 20:23 +0000 Barry Leiba
<[email-masked]> wrote:

> I'll say this as a participant only, but informed by my
> experience over the last four years as the AD responsible for
> handling URN NID requests:
> 
> definitively) NID requests that I've handled over the last
> four years are from organizations who want namespaces for use
> by their organizations or industries.  It's quite clear that
> there is little to no value in asking them to document why
> they need a new namespace: it's because they want one
> associated with their organization or industry, and that they
> control.
>...
> I'd support something that said that if there are related
> namespaces, the request should note them and explain why they
> are not adequate and this one is different.  But I'd not
> support its being a requirement, because in most cases it's
> unnecessary and in the others its a requirement that's
> unlikely to be enforceable.

Thanks.  That is certainly consistent with my experience and
observations.  It would be easy to add a sentence or two to the
above effect.  I'd personally recommend that we add an entry to
the registration template (Appendix A of 2141bis), between
"Documentation" and "Revision Information", and say something
like 

 "Additional Information.   Please include any additional
	information that would be useful to those trying to
	understand this registration or its relationship to
	others, such as comparisons to existing namespaces that
	might seem to overlap."
	
Better wording would obviously be welcome, as would
recommendations as to whether that needs to explicitly include
"(Optional)".   It is not as strong as "if you know of related
namespaces, please explain" or your wording above, but my quick
thought is that might be overly-specific and we are better off
inviting comments but not trying to specify what is and is not
wanted.  The people who want to be helpful about other
information, including the comparisons, will supply it and the
others will just say nothing or, as you suggest, "we just need
our own" or "those folks are turkeys".   I think that something
like the above would deal with this issue and any others that
might come along.

Does that work for you?  Everyone else?

      john

---

From: Barry Leiba <[email-masked]>
Date: Fri, 18 Mar 2016 18:20:59 -0400

Works for me, especially in the milder formulation.

b

On Friday, March 18, 2016, John C Klensin <[email-masked]> wrote:

> <[email-masked] <javascript:;>> wrote:
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Mar 2016 01:41:08 -0400

On 03/18/2016 03:03 PM, John C Klensin wrote:
> ones and why they are not applicable?

It is not a good idea to federate URN space into distinct categories, as 
this would have the undesirable effect of giving control over naming and 
perhaps resolution of particular kinds of resources to specific 
organizations.   So the existence of one or more namespaces that are 
defined for a particular purpose should absolutely not prevent a new 
namespace being defined with a similar or overlapping purpose.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 07:33:18 -0400

--On Monday, March 21, 2016 01:41 -0400 Keith Moore
<[email-masked]> wrote:

> It is not a good idea to federate URN space into distinct
> categories, as this would have the undesirable effect of
> giving control over naming and perhaps resolution of
> particular kinds of resources to specific organizations.   So
> the existence of one or more namespaces that are defined for a
> particular purpose should absolutely not prevent a new

Keith, I don't think even the original requirement, which has
been in effect for years, "prevented" registering overlapping
namespaces, it just required identifying them and explaining the
overlaps.  My personal view is that may have been appropriate
with the older registration process that attempted to require
IETF approval for creating a namespace and, as a side-effect,
made overlaps easier to identify, but is not appropriate with
the newer, more flexible, and registration-oriented (rather than
approval-oriented) approach, so I think our conclusion is the
same.

I have tentatively added a version of the suggestion from the
discussion Barry and I had last week to the working version of
-16.  In other words, there is now a provision in the
registration template for registrants to provide other
information of interest including information about overlapping
namespaces, but they are under no obligation to do so.

best,
    john

---

From: Sean Leonard <[email-masked]>
Date: Mon, 21 Mar 2016 04:45:12 -0700

> On Mar 20, 2016, at 10:41 PM, Keith Moore <[email-masked]> wrote:
> 
> It is not a good idea to federate URN space into distinct categories, as this would have the undesirable effect of giving control over naming and perhaps resolution of particular kinds of resources to specific organizations.   So the existence of one or more namespaces that are defined for a particular purpose should absolutely not prevent a new namespace being defined with a similar or overlapping purpose.

This.

+1

> 
> On Mar 18, 2016, at 12:03 PM, John C Klensin <[email-masked]> wrote:
> 
> 
[...]
> does anyone see a need for a requirement that
> that is the reason why the requirement was dropped.

Keep it dropped. Simpler and easier are better.

Sean

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Mar 2016 07:59:30 -0400

> approval-oriented) approach, so I think our conclusion is the

I think so also.  I was somewhat surprised to reach that conclusion.   I 
started out writing that message by expressing my disappointment that 
there are now so many URN namespaces devoted to very narrow purposes 
and/or are delegated to organizations that don't exist for the purpose 
of information dissemination or archiving.   I suspect that in the long 
run this will harm URN persistence and the ability to resolve URNs.   So 
in a way I'd like to see the registration process discourage those 
registrations. But the original rule clearly did not serve that purpose, 
and I'm not sure what rule would serve that purpose without creating 
other problems.

(I've never been really comfortable with the registration-oriented 
rather than approval-oriented fashion that swept IETF a few years ago.)

> namespaces, but they are under no obligation to do so.

I'm curious - is there any scenario where a registrant would benefit by 
including such information?

Keith

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 Mar 2016 06:46:01 -0700

> started out writing that message by expressing my disappointment that there
> are now so many URN namespaces devoted to very narrow purposes and/or are
> delegated to organizations that don't exist for the purpose of information
> dissemination or archiving.   I suspect that in the long run this will harm
> URN persistence and the ability to resolve URNs.   So in a way I'd like to
> see the registration process discourage those registrations.

Actually, I think it's better to have those sorts of URNs corralled
off into their own namespace, so one could say, "Yeah, 'urn:flarb:'
isn't a reliable namespace because the Flarb organization is flakey
about how they manage their URNs."  I think that's better than having
their stuff mixed in with other stuff in a more general namespace.

I also think that discouraging registrations will simply have the
effect that organizations will use namespaces without registering
them.  Saying that Flarb can't register their namespace because they
don't have a good plan for handing out persistent URNs isn't going to
stop Flarb from using urn:flarb:, if that's what they really want to
do.

> including such information?

Good point...
I think it would slightly benefit them by heading off questions that
might come up when the registration request is in review.  But that's
all I can think of.

Barry

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Mar 2016 11:23:06 -0400

Sent from my iPhone

> their stuff mixed in with other stuff in a more general namespace.

I disagree, and I think this is a fairly fundamental misunderstanding of URNs.  URN namespaces aren't like URI prefixes.  The fundamental URN properties like persistence aren't supposed to be dependent on the namespace at all.  

> them.  

Well, that has certainly happened.    Vendors' willingness to violate or ignore published specifications never ceases to amaze me .   Though I have yet to see evidence that registration is actually the barrier or that making registrations easier actually helps.  

> Saying that Flarb can't register their namespace because they

Right, but we should not legitimize the practice by declaring such a namespace to be valid.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 Mar 2016 08:28:32 -0700

> I disagree, and I think this is a fairly fundamental misunderstanding of
> URNs.  URN namespaces aren't like URI prefixes.  The fundamental
> URN properties like persistence aren't supposed to be dependent on
> the namespace at all.

I'm not suggesting that they are or should be.  I'm merely saying that
*if* an organization is going to be bad about the persistence (for
example) of its URNs, it's better to have that problem isolated to a
readily identifiable subset than to have it scattered around and mixed
with URNs that do what they're supposed to do.

b

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Mar 2016 12:53:12 -0400

--On Monday, March 21, 2016 07:59 -0400 Keith Moore
<[email-masked]> wrote:

>> information of interest including information about
>> overlapping namespaces, but they are under no obligation to
>> do so.
> 
> I'm curious - is there any scenario where a registrant would
> benefit by including such information?

Two answers.  The more important one is that, if a registrant
wants to supply that information, I think we should let them.
If they don't, I don't want to lose sleep over it.  That is, I
think, consistent with Barry's comment about making this
optional.     The other, less likely IMO but plausible, is when
registrant X comes along and wants to register namespace foobis
because, in their opinion, registrant Y, the registrant for foo,
has not been sufficiently diligent about persistence or how
excluded things things that Y believes should be included and
they have been unable to resolve that disagreement.  I hope
everyone could behave like adults (and that we may have issues
to deal with in the future if they don't), but allowing a "this
is just like that except..." statement seems to me to be in
everyone's best interests.

And, fwiw, 

--On Monday, March 21, 2016 11:23 -0400 Keith Moore
<[email-masked]> wrote:

> I disagree, and I think this is a fairly fundamental
> misunderstanding of URNs.  URN namespaces aren't like URI
> prefixes.  The fundamental URN properties like persistence
> aren't supposed to be dependent on the namespace at all.

Unfortunately, once we tried to get down to defining
"persistence" in a way that could be incorporated into a
document and that was actionable in considering namespace
registration applications, we completely failed to reach any
sort of consensus.  So it is nice as a concept, I think I know
it when I see it and assume you do too but that we might not
identify exactly the same things.  So, sure, "all URNs are
persistent" is a great statement.  It may even be a definitional
tautology.  But I'm not sure what it actually does for us,
especially in the quest to get this WG's work wrapped up and out
the virtual door.

best,
    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Mar 2016 21:32:52 -0600

WFM too (in part because my experience with handling URN NID requests as 
an AD was consistent with Barry's more recently).

Peter

On 3/18/16 4:20 PM, Barry Leiba wrote:
> On Friday, March 18, 2016, John C Klensin <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>