[urn] Re: third-party registrations

Peter Saint-Andre <[email protected]> Fri, 3 Apr 2026 16:32:09 -0600
Newsgroups gmane.ietf.urn
Message-ID <[email protected]>
Thanks, Dale. Comments below.

On 4/3/26 3:19 PM, Dale R. Worley wrote:
> Peter Saint-Andre <[email protected]> writes:
>> 1. Dale, I'd like to understand your reasoning behind saying that a WG
>> could reach consensus that non-coordinated incorporation is OK. Are you
>> suggesting that a future URN WG could make a policy decision along the
>> lines of what you propose and update RFC 8141 accordingly? Or are you
>> suggesting that some other kind of working group (such as the SPICE WG)
>> could make such a decision as long as it receives IETF consensus?
> 
> Let me try to clarify my thoughts:
> 
> In the present instance, the GLUE URN proposal, we have the parallel
> technical and political problems of incorporating an External Authority's
> identifiers into a URN namespace.  Technically, the proposal depends on
> the External Authority enforcing the uniqueness/persistence requirements
> of URNs without the External Authority taking responsibility for doing so.
> Politically, the Eternal Authority might see the proposal as the IETF
> incurring on their domain of expertise/authority/responsibility/turf.
> 
> As a committee of "designated experts", we operate under the authority
> delegated by "the IETF consensus process", which seems to mean what is
> stated in RFCs that have been ratified by the IESG, currently RFC 8141.
> 
> It seems clear to me that this situation of "third-party registrations"
> had not been thought of at the time when RFC 8141.  In particular,
> section 6.3 is provided for namespaces that incorporate identifier
> systems defined by External Authorities, but it clearly assume that all
> such registrations will be done by the External Authority in question.
> 
> So the committee is saddled with a techno-political problem with no
> guidance.
> 
> My concept is that the proper resolution is further guidance from "the
> IETF consensus process", which means that a suitable working group needs
> to chew over this problem and produce an RFC.  It doesn't seem to me to
> be critical whether it is officially a revision of RFC 8141 or not; it
> will be an extension of the guidance from the RFCs to the committee.
> 
> In the present instance, the place where I expect it would have happened
> is the SPICE WG.  However, at this point, I have not seen evidence that
> this problem has been explicitly discussed and the WG come to a
> consensus regarding these issues.
> 
> This does raise the question of whether certain working groups have
> "more authority" over certain areas than other working groups, or what to
> do if two working groups come to conflicting "consensuses" over some
> item.  Regarding that, my only thought is that the IESG would be the
> place to resolve the conflict.  And in a sense, the IESG would
> automagically do so, since it has to ratify all documents in order for
> them to become RFCs, and a newer RFC updates an older RFC.
> 
> The preceding paragraph is qualified by the fact that a WG can't produce
> a proposed RFC that is outside the scope of its charter.  (As witnessed
> by the "ballot discuss" items for this very I-D listed in
> https://datatracker.ietf.org/doc/draft-ietf-spice-glue-id/history/.)
> And charters have to be approved by the IESG.  So in practice, for a WG
> to produce a policy on these questions, it must first have the IESG
> approve that work as part of its charter, that is, de-facto approve that
> it can extend the URN policies to deal with "third-party registrations"
> (though that might mean forbidding them).

Your explanation is helpful. Broadly speaking, you and I see things in a 
similar way. Given that (PWID possibly excepted) we've never received a 
third-party registration request until now, and that we might never 
receive another one, I doubt that chartered IETF action is required to 
establish an official policy which can guide the expert review team in 
the future.

Indeed, I will go further: I don't think the lack of guidance in RFC 
8141 regarding third-party registrations was necessarily an oversight, 
or at least not an error, because I think it was a reasonable assumption 
that what the GLUE I-D calls an External Authority is the only entity 
with the *authority* to request a URN namespace that encapsulates or 
incorporates their identifier system. This seems consistent with the 
underlying principle that URNs are a managed ecosystem of names: who 
better to manage the "name" (URN) for an identifier system than the 
entity that defined it in the first place and is responsible for its 
maintenance and further development? In an earlier message in these 
threads I used an unfortunate term when I called this a "political" 
problem of coordination with the External Authority, but I think the 
problem entails something more fundamental than mere political niceties 
and professional coordination with other SDOs.

Thus I conclude that if we ever receive another third-party registration 
request it would be appropriate for us to say "sorry, your request is 
not consistent with the principles for managing the space of URN 
namespaces enunciated in RFC 8141 and therefore we can't approve your 
request" (but if you disagree with RFC 8141 or our interpretation 
thereof, feel free to write an Internet-Draft and attempt to gain IETF 
consensus for changes to the URN management model).

Peter

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]