[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]