Re: [urn] corporate URN namespaces

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

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

> On 2/2/24 6:15 PM, John C Klensin wrote:
>> (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.
> 
> Before we put an admittedly aspirational process in place at
> the IETF or IANA to address misbehavior by a relatively few
> neglectful actors, I suggest that we attempt more active
> outreach of the kind I've just done with Microsoft / LinkedIn
> and now Netflix:
> 
> https://github.com/Netflix/dial-reference/issues/60
> 
> Yes yes, I know, we're not the protocol police and it's not
> really our responsibility to nag these multi-billion-dollar or
> trillion-dollar companies into doing the right thing. But I do
> think we have a fiduciary responsiblity to make best efforts
> toward ensuring that "the space of URN namespaces is itself
> managed" as RFC 8141 puts it.
> 
> If such efforts do not yield fruit, I'm open to alternatives.

Sounds entirely reasonable to me.   I hope those efforts work
out and that ones that could be even more problematic do not
appear.   

best,
   john