Re: [urn] corporate URN namespaces

[Peter Saint-Andre <[e-mail]>]

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.

Peter