Making QUIC less constraining for innovation

["Martin Thomson" <[e-mail]>]

Issue 3020 (https://github.com/quicwg/base-drafts/issues/3020) raises the question of IANA registration policies in the core drafts.  The thesis is that the constraints on registrations pushes people into a small space of available numbers (in that specific case the space is 256 values) or has registration requirements that are too onerous.

We aim to address this in most places in QUIC and h3 with varints, which all have a similar registration scheme.  I think that David's intent with #3020 was to push more of our code to use varints.  But we're nothing if not consistent when it comes to these things and after lengthy discussion in Cupertino the group decided not to use varints for transport parameters.

Instead, we want to revise the registration policies to better allow implementations to experiment with new features (which is what I think David intended by the use of the word "innovation").  For varints, we divide the space into three partitions:

  0-63 = Standards Action
  64-16383 = Specification Required
  16384+ = Private Use

David's PR #3109 (https://github.com/quicwg/base-drafts/pull/3109) proposes the same split for transport parameters.  That greatly increases the size of the Private Use space.  The Private Use section is still a lot smaller than with varints, but the cut points are the same and the belief is that ~2^16 values is plenty of room to play with.

The main problem with all of these policies is described in RFC 6648, namely that a codepoint from Private Use space can get wide adoption.  RFC 6648 basically concludes that these can be impossible to move to a registered portion of the codepoint space.  Furthermore, RFC 8126 says that IANA doesn't register these codepoints and so no mechanism exists to prevent collisions.  That's a shame, because that's what registries are for.

---
I propose that we instead remove Private Use space from specifications and instead adopt a Specification Required policy for all codepoints except the first 64 values of a varint value (we can keep that as Standards Action).

To allow for experimentation and proprietary extensions, add the ability to provisionally register any codepoint.  Provisional registrations are registrations can omit values that would be required for a permanent registration, include an expiry date, and operate on First-Come, First-Served basis.  

This is intentionally lightweight so that anyone can initiate registration, even without complete information.  A Designated Expert will be assigned to ensure that the registries don't end up crammed with junk and to discourage use of codepoints with small encodings, large blocks of codepoints, or codepoints that are likely to be used by future standardization (those that are adjacent the first contiguous block of allocated values, which we might want to use later).  I emphasize discourage intentionally, because this can't be a hard rule - this is why we use a human for this job and not a machine.

To recognize that people will inevitably use values before they even provisionally register them, we should encourage people to select from the space at random.  Random selection from a larger space greatly reduces the chances of collision.  For varints, people will be encouraged to choose values that have the longest encoding tolerable for their use case.  In particular, extensions that are fully proprietary will be encouraged to use values that encode to 4 or 8 bytes.  I recognize that this might not avoid people having inflated notions of the value of their extension.  And maybe it's not worth protecting the 2 byte space on the basis that we might never run out of the 16320 values available.  Either way, I think that it's worth providing some text to help the expert in case this protocol gets unexpectedly busy.

Registrants are specify the codepoint they want when registering, rather than have IANA make an allocation on request.  For standards that want to use codepoints that are adjacent the first set of values, we might still use TBD in specifications to avoid having the same value specified in multiple specifications.  The TLS working group had the same codepoint in three different drafts last year, which wasn't great.

Provisional registrations can be removed or refreshed after a year (period negotiable) after consultation with the expert, who is encouraged to consult with the broader community. Experts would be advised to refresh registrations unless there is evidence that the value is no longer in use and there is a need to free up space for new registrations.

The motivation behind this proposal is to recognize that the overriding goal of a protocol registry is to avoid the interoperability failures that arise from codepoint collisions.  In particular, registries are not an access control mechanism.