Re: [urn] corporate URN namespaces

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

(Barry, see inline)

--On Friday, February 2, 2024 16:49 -0700 Peter Saint-Andre
<[e-mail]> wrote:

> I agree with 90% of your 10%. The remaining 1% inline.
> 
> On 2/1/24 6:22 AM, John C Klensin wrote:
>> 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?
> 
> It might not surprise you that I had a similar thought.
> ("Great minds think alike" or "fools never differ"?)
> 
>> 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".
> 
> To some extent, I think it depends on what we're trying to
> accomplish with this list. I see two main purposes:
> 
> 1. Encouraging organizations to register their namespaces
> 
> 2. Avoiding namespace conflicts
> 
> It's not clear to me that purpose #1 will be met more
> effectively with a public list than with reaching out to
> people we know at the offending organizations, but just
> possibly it might help. Do we know if this method has been
> successful with other registries?

No idea.  It might be reasonable to reach out to Barry Leiba
(don't remember whether he is on this list or not) because my
impression is that he has been one of the sensible people
pushing most strongly for "just get it registered somehow".  If
there have been successes, he would be likely to know.   But I
don't know that it is particularly useful knowledge because ...

If we disagree, it might be closer to 5% or 1% than 10%.  What I
was thinking, although I was no coherent enough to write down,
was that we should encourage third parties who notice such
things to reach out to "people they know" if they know anyone
and provide some mechanism for them to post a message to see if
anyone else can do some gentle arm-twisting otherwise (posting
to this list or even [e-mail] might be reasonable).  Only
if those entreaties failed to produce a registration by the
organization involved, would the name be added to what I think
of as a "this name is in use by the the organization involves is
too anti-social, arrogant, or opposed to a URN system that works
well" list.  Of course, we wouldn't say that unless we could
figure out how to be really polite about it.

That sort of approach would constitute doing our best at the
"encouraging" part, providing some (at least minimal) pressure
on those who were not easily encouraged and, either way, address
purpose #2.

> Purpose #2 is more limited but potentially useful (and as you
> say could be met with a simple web page at a wiki or GitHub).

best,
   john