Re: [urn] corporate URN namespaces

[John C Klensin <[e-mail]>]

Peter,

I agree with 90% of what you say.  Other 10% inline below.

--On Wednesday, January 31, 2024 11:53 -0700 Peter Saint-Andre
<[e-mail]> wrote:

> Hi John, thanks for sharing your perspective. Comments inline.
> 
> On 1/30/24 8:32 AM, John C Klensin wrote:
> 
>> I wonder whether we could borrow a note from some very early
>> IANA registration policies and allow third-party
>> registrations, e.g., allow you or someone else who notices
>> one of these things to record the usage in the database as a
>> third-party registration.  If one of our primary goals for
>> having the registry is to avoid inadvertent name conflicts,
>> then knowing that (using your examples) LinkedIn is using
>> "li" for a namespace and Amazon is using "rtn", and both are
>> using them on the public Internet (embedded or not), there
>> would seem to be a public interest in having those names
>> registered. 
> 
> RFC 8141 states:
> 
>     This document rests on two key assumptions:
> 
>     1.  Assignment of a URN is a managed process.
> 
>     2.  The space of URN namespaces is itself managed.
> 
> One thing I'm uncomfortable with here - not with your proposal
> but with the underlying situation - is the fact that if at
> some level we accept unregistered URN namespaces, then we're
> not living up to assumption #2.

Yes.

> Overall I'd say we have done a decent job of managing the
> space of URN namespaces: the vast majority of SDOs and other
> projects we've engaged with have worked in good faith to
> define their usage of URNs, and for the most part this
> discussion list has led to improved transparency regarding URN
> usage on the Internet. (To be clear, we've had a few failures
> along the way, e.g. namespaces we didn't get registered
> because the registrants ran out of energy or patience with the
> review team.)
> 
> It seems less than ideal to allow third-party registrations
> that are mere placeholders so that we can avoid conflicts.
> Indeed, those don't feel like *registrations* at all, in the
> sense of fulfilling our responsibility to manage the space of
> URN namespaces. (Furthermore, it feels disrespectful toward
> everyone who has properly registered their namespaces.)
> 
> I'm not completely opposed to what you suggest, but I'm not
> completely happy with it, either.

I agree and share your unhappiness.  I was just trying to
reflect what seems to be a general IETF trend that I would
describe as "forget all that other stuff and the reasons for it,
just get it registered to prevent conflicts".  That has resulted
in updates to several protocol specs moving, e.g., from "RFC or
IESG-approved Experimental" to "Specification Required" or
lower.  That does not make me happy either, but I recognize the
reasoning and the trend.

Given that, and given that allowing third-party registrations
would presumably require an update to RFC 8141 anyway, let me
suggest a different alternative.   I haven't quite figured out
how this would be defined, much less what we would tell IANA
about naming (because any list they keep is called a registry)
but what would happen if created a separate list, not for
registration of a URN namespace but of names that had been seen
in the wild and, in violation of the clear intent of 8141, had
not gone through that process?

Such a listing would clearly require some minimal protection
against DoS attacks, but so would a third-party registration.
Submission of copies of web pages or messages would be a start.

I think I'd rather see it as an IANA collection because presence
in that hall of shame might motivate some companies to actually
register but, if if that would be problematic, I could see a
wiki or github listing somewhere and a sentence in the header of
the IANA URN namespace registry that said something like "an
informal list of known names in use in violation of the specs
may be consulted to avoid unintentional naming conflicts if one
is considering a new namespace and name".

Would something along those lines feel more comfortable?

best,
  john