Allow provisional registrations for all registries

[martinthomson]

This overhauls the system for IANA registries to use a unified scheme that allows provisional registration. This seems pretty complicated in terms of nailing down all the corner cases, but it is fairly simple in practice:

• Provisional registration is easy, it only requires that the requester provide contact information and (ideally) the codepoint they want. They could provide more, but at their discretion.

• Permanent registration requires that you fill out the fields.

Experts are required for both, but only really to prevent spam. We have a few more requirements for permanent registrations of frame types, but that is more for the purposes of advice, because sending an new frame leads to protocol errors if you haven't agreed to that in the past.

I've sketched out a strawman for a codepoint reclamation process. That advises that experts try to find some use of the codepoint. There is a date on registrations that can guide the selection of codepoints to reclaim, but these can be updated any time by anyone who wants to keep the registration "live".

I wanted to sketch this out for transport first, but I intend to update this PR with changes to the HTTP draft if these policies are agreeable.

Closes #3109.
Closes #3020.
Closes #3102.

[mikkelfj]

Could contact information be replaced with a domain name. There is much abuse of contact information and domain names can have private contact information? Also, maintaining an email address is harder over time. I realize the field contact field doesn't say email, but that is sort of implied.

[hardie]

On Wed, Oct 30, 2019 at 12:31 AM MikkelFJ ***@***.***> wrote: Could contact information be replaced with a domain name. There is much abuse of contact information and domain names can have private contact information?

You can specify this so that IANA collects the information and thus can follow up if needed, but where the registry does not display this information. I understand that the authors of RFC 8126 are working on a bis that will make this much more common, if not the default.

Also, maintaining an email address is harder over time. I realize the field contact field doesn't say email, but that is sort of implied.

You can also split the contact information from the change controller, if you want to have, say Joe be the contact but Example Corp be the change controller. There's also a presumption that if the change controller is gone that the change controller for the entire registry (usually the IESG) can make a determination of what to do in the case that a change is needed. For many registries this amounts to "do nothing" since there is no scarcity of code points. In the case of scarcity, that's how you get re-use when the change controllers are gone. Ted

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3170?email_source=notifications&email_token=AAKVXZGW4DLXVXEZDME5SHLQREZ5BA5CNFSM4JGUI6W2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECTFPAI#issuecomment-547772289>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKVXZDFDTCYMGMTNCEWAPDQREZ5BANCNFSM4JGUI6WQ> .

[DavidSchinazi]

typo: stricter

[DavidSchinazi]

I think this example contradicts these two statements from this PR?

The "QUIC Frame Types" registry [...] values between 0x00 and 0x3f are assigned using Standards Action or IESG Approval.

Provisional registrations require Expert Review.

[martinthomson]

You clipped the key piece of the first quote:

Permanent registrations in this registry are assigned using [...] except for values between 0x00 and 0x3f [...] which are assigned using Standards Action or IESG Approval [...]

[DavidSchinazi]

Ah, thanks for clarifying.

If we decide to allow provisional in [0, 63], then we should add text explaining how the Expert Reviewer should handle those requests, because (unless I missed another sentence) it sounds like they're currently instructed to grant all values except for the first unassigned value. I worry that [0, 63] will fill up pretty quickly if we allow provisional use.

[martinthomson]

I share that worry, but I'm trying to let those go. The main pressure here is that if things start filling up, then we start ejecting registrations sooner.

[DavidSchinazi]

I fear that ejecting won't always be possible if the provisional code point is widely used. I think disallowing provisional for [0, 63] might be best.

[martinthomson]

We're talking about abuse now. Those same people could just deploy in this space without creating a registration.

[MikeBishop]

Minor nits; otherwise looks good.

[MikeBishop]

In lots of places, you reference {{iana-policy}} for things that aren't actually described there -- it just contains a pointer to the QUIC spec for the policy. It might be better to point directly to the QUIC spec in those places. (Though given that the section number in QUIC could potentially change, it's also a reasonable argument that we want to have one place to update.) Just want to make sure that's intentional, rather than a copy-paste of the policy from the QUIC registries.

[martinthomson]

I did that intentionally, mostly just to avoid the wordy reference. I'm happy to defer to you on that. (Julian can say "told you so" again if he likes :)

An editorial suggestion that Mike can sort out later