Hi Phillip,
> On 22 Jul 2020, at 1:17 pm, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
>
> On Tue, Jul 21, 2020 at 2:42 AM Mark Nottingham <mnot@xxxxxxxx> wrote:
>> That's a good summary. To me, the question is whether there are ways to avoid spurious / vanity registrations without creating unnecessary barriers to entry.
>
> I have railed against 'vanity crypto' in the past. And there is actually a pretty good argument that less crypto is more. But I have since realized even that type of gatekeeping is counterproductive.
>
> There are some important and valid concerns, the two most important for me being:
>
> * Avoiding ambiguity where two communities attempt to use the same scheme.
> * Avoiding namespace exhaustion.
> There is also:
>
> * Enabling interoperability.
> * Ensuring availability of documentation
> * Maintaining quality
>
> Which are important to some of course. BUT is it worth our time and effort to save people from their own folly unasked? I don't ask people to look at my stuff because I enjoy having people jump up and down on the little pieces. I do it because I want it to work, and to be useful. If people want to shoot themselves in the feets, why not let them?
>
> I come to the IETF for advice and to build a deployment coalition for my proposals. I have never come to ask permission.
You make many good points above, and I don't disagree with any of them.
However, I'm concerned about another phenomenon; as we lower the barrier to entry for registries (especially when we do things like GitHub management of issues lists, which is *much* friendlier than using e-mail lists for many non-IETF-encultured registrants), it becomes trivial to register a value pre-emptively, sometimes on a whim (as in, "I had this idea, let's register it."). Without pointing fingers, I have seen some evidence of this.
If doing so has no impact upon the registry then I agree that it shouldn't matter. However, I think there is some undesirable impact, if enough of these registrations occur.
For example, take link relations and well-known URIs (two registries where I currently serve as an Expert). Plain english terms that have applicability in the field of the registry can be consumed by such registrations, leaving us in a situation where registered values backed by a broader and larger community will be forced to use unintuitive (and sometimes longer) terms. All potential values in these registries are *not* equivalent.
Simply put, I don't think it's reasonable for someone to have an idea in the shower one morning and then register the value an hour later, *if* that value has significant potential value to the community, *and* that person isn't willing to work with others. Good names are valuable, and many people think that if they grab an intuitive name, the users will follow.
Since I don't think that the ICANN model is suitable for these registries, there are a few ways that we try to mitigate this risk (backed by the defining RFCs) while still meeting the goals you mention:
1. They are Specification Required. Writing something down requires some amount of effort, but it can be brief. Importantly, we shouldn't block registration on "correctness" or "purity" beyond applying any requirements stated for the extension point in question. Sometimes we provide advice ("have you thought about...") but in doing so, we should make it clear that addressing it isn't blocking.
2. We require the specification to be _reasonably_ stable and available. This is an evolving and still somewhat flexible criteria; because we're able to update the registry pretty easily now, the barrier is lower than that in many other registries (I understand that some require publication by an Open Standard body in most cases). We prefer that, but also accept values from commercial entities, Open Source projects, and community organisations; really any group of people who have the ability to maintain the reference. The spec doesn't have to be an I-D; it could be e.g. a page on GitHub.
3. There is language in the defining RFCs that encourages names that have a specificity corresponding to their applicability. So, if a proposed name is limited to one application or doesn't have a broad community behind it, we might steer them towards a name like 'myApp-metadata' rather than 'metadata'.
4. Registrations that aren't sourced from Standards are provisional. Provisional registrations can be made permanent if the Expert(s) find that they're in broad use, after consultation with the community.
5. Provisional registrations can be removed by the Expert(s) after consultation with the community if they're found to be in disuse. That hasn't been attempted yet, and I'd expect that if we decided to do so, there's be some discussion about how to go about it, and whether removal or just marking as 'historic' or similar was the right way to go.
6. The Expert(s) can, after consultation, register values that are found to be in broad use. To me, this is an alternative to the model that URI schemes currently uses; rather than severely lowering the bar to enable population of the registry (mostly through one or two 'heroic' catch-up drafts, like Dave did), keep the bar at a reasonable level, but allow the Experts to catch it up when there's a value that's been obviously consumed without registration.
While not perfect, I do think that this approach has some good qualities; it's not so much "gatekeeping" as it is making the Expert(s) "custodians." Yes, they have some powers, but they're fairly limited, in the interest of balancing the different needs of the registry community.
> Gatekeeping can be a useful function but it can also do immense damage. Stopping one good idea does real harm. And lets not be prejudiced about ideas people have in the shower. I do much of my best thinking in the hot tub.
I don't have a hot tub, but I agree with the general sentiment (perhaps its the inability to have electronic devices nearby). We shouldn't stop these folks from registering, but they shouldn't be allowed to consume valuable names on a whim; if it's a good idea, a slightly longer name won't hurt it. We should also have some mechanism for cleaning up after the ones who lose interest and/or fizzle a few weeks/months later.
> There have always been people who think that their role in the Internet is to identify bad ideas and stop them happening and that this is doing the community a favor.
>
> So while the second set of concerns are valid, I don't see the IETF achieving anything good by attempting to enforce them, on the contrary, it is only causing harm.
I agree it's a tricky balance. I think that here -- as in many other places -- we need to write down our intent *much* more carefully, if we expect it to persist.
> My proposal is this:
>
> Collapse the protocol, .well-known and uri registries into one registry of application name labels. Registering a label in the application name labels registry would be 'essentially' first come first served and automatically create reservations for the .well-known and uri scheme, to be used if required.
>
> By 'essentially', I mean we should have guards in place to stop speculative reservation of namespace, namejumping and the like.
Sorry, you're losing me here.
Cheers,
--
Mark Nottingham https://www.mnot.net/
