Subject: Making QUIC less constraining for innovation

From: "Martin Thomson" <[email-masked]>
Date: Thu, 24 Oct 2019 14:26:52 +1100

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.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Oct 2019 15:33:16 +1100

Personally -

ISTM that the biggest problem here is the tendency for people to choose the "next" value available when starting to prototype; since it's a linear space, that greatly increases the chances of collisions.

That implies that reducing the friction of registration should be a primary goal. I think Martin's proposal gets a fair way towards that.

Another way of reducing friction is to require less of registrants, and to use tools familiar to them. With my Expert hat on, I've been experimenting with using Github repositories to manage registries; e.g., see <https://github.com/link-relations/registry>. Doing something like this might be worth considering (and I'm working with IANA to make it easier).

Cheers,

> On 24 Oct 2019, at 2:26 pm, Martin Thomson <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 24 Oct 2019 16:21:08 +1100

On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote:
> Another way of reducing friction is to require less of registrants, and 
> to use tools familiar to them. With my Expert hat on, I've been 
> experimenting with using Github repositories to manage registries; 
> e.g., see <https://github.com/link-relations/registry>. Doing something 
> like this might be worth considering (and I'm working with IANA to make 
> it easier).

Do you think that that process is mature enough to have QUIC use it?  If it is, then I would be supportive of lowering the embarkation ramp further.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Oct 2019 16:40:52 +1100

> Do you think that that process is mature enough to have QUIC use it?  If it is, then I would be supportive of lowering the embarkation ramp further.

It's not a process so much as an alternate path (to using a mailing list). I think it's worth considering -- but the nice part is that you don't have to specify anything, just leave it up to the experts.

Cheers,

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 24 Oct 2019 15:25:05 +0900

Martin,

I'm not familiar with the RFCs and the policies here, so it took me a
little while of thinking to understand your proposal. Now that I do, I like
it.

That said, there's one thing I'd change. According to RFC 8126, Standards
Action is limited to Standards-track RFCs and BCPs, and I'd like to see
Experimental included in this space as well. I think RFC Required is what
I'd prefer.

- jana

On Thu, Oct 24, 2019 at 2:41 PM Mark Nottingham <[email-masked]> wrote:

> > Do you think that that process is mature enough to have QUIC use it?  If
> it is, then I would be supportive of lowering the embarkation ramp further.
>
> It's not a process so much as an alternate path (to using a mailing list).
> I think it's worth considering -- but the nice part is that you don't have
> to specify anything, just leave it up to the experts.
>
> Cheers,
>
> --

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Oct 2019 12:54:27 +0000

>     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…
   
I like this idea.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Oct 2019 12:00:14 -0700

> Experimental included in this space as well. I think RFC Required is what
I think that if you want to include experimental RFCs you'd also want to
increase the size of the reserved pool some small amount.

I'm also not sure it's a great idea over all.  Specification required
covers experimental RFCs and distinguishing between those experiments and
other specified experiments seems to expect that different range will get
different treatment by networks/middleboxes/etc.  If the main goal of this
is to reconfirm "In particular, registries are not an access control
mechanism.", a secondary goal should probably be "Placement in the range is
not a useful signal".  We want to avoid collision, so we need a code point
mapping to a spec--but we don't want people inferring much from where the
code point lies.  To me, the only point of a standards action reserved
space is to make sure that the IETF always has some unconficted area to
deploy into; it's otherwise no guarantee at all. If we think the space is
large enough to avoid a risk there, I'd say make it all specification
required and leave it at that.

Two cents as an individual,

Ted

>> > Do you think that that process is mature enough to have QUIC use it?
>> If it is, then I would be supportive of lowering the embarkation ramp
>> further.
>>
>> It's not a process so much as an alternate path (to using a mailing
>> list). I think it's worth considering -- but the nice part is that you
>> don't have to specify anything, just leave it up to the experts.
>>
>> Cheers,
>>
>> --

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 25 Oct 2019 11:22:50 +1100

On Fri, Oct 25, 2019, at 06:00, Ted Hardie wrote:
> > That said, there's one thing I'd change. According to RFC 8126, Standards Action is limited to Standards-track RFCs and BCPs, and I'd like to see Experimental included in this space as well. I think RFC Required is what I'd prefer.
>
> To me, the only 
> point of a standards action reserved space is to make sure that the 
> IETF always has some unconficted area to deploy into; it's otherwise no 
> guarantee at all. If we think the space is large enough to avoid a risk 
> there, I'd say make it all specification required and leave it at that.

My thinking was along the same lines as Ted.  As much of the space has the much lower bar of Specification Required, those experiments can use that space freely.  The only experiments that wouldn't be permitted would be those that want one-byte codepoints (and provisional registrations would still be available, though discouraged).  And yeah, I'd be OK if someone said that the whole space should be Specification Required.  But I've seen 256-value spaces chewed up very fast in the past, and our 64-value space could be more appealing.

---

From: David Schinazi <[email-masked]>
Date: Thu, 24 Oct 2019 21:34:51 -0700

I think I'm mostly in agreement with Martin here.

My intent with PR 3109
<https://github.com/quicwg/base-drafts/pull/3109/files> was to make the
overhead for experimentation as low as possible.
Based on the ideas in this thread, I'm thinking about perhaps tweaking it
as follows:

[0-63] Standards Action <https://tools.ietf.org/html/rfc8126#section-4.9>
or IESG Approval <https://tools.ietf.org/html/rfc8126#section-4.10>
    This gives the IETF a little protected garden and that means that folks
developing
    extensions and experiments won't use the next available value from here.

[64-16383] Specification Required
<https://tools.ietf.org/html/rfc8126#section-4.6>
    This creates a carveout with an intentional overhead of requiring
writing a draft.
    This ensures that we'll never run out of this space. Experimental RFCs
would
    use this registry.

[16384+] First Come First Serve
<https://tools.ietf.org/html/rfc8126#section-4.4>
    This allows anyone to request a code-point and register it without
overhead,
    as IANA does not review the request. This means that we can use the
registry
    simply as a collision-avoidance mechanism.

We should strongly encourage customers of the [64+] registries to generate
their desired codepoint randomly.

I agree with removing Private Use
<https://tools.ietf.org/html/rfc8126#section-4.1> for the reasons stated by
others, but I do think
that if someone wants to build a proprietary extension, they should be able
to
do so without having to document it publicly - because in reality people
will
be building undocumented proprietary extensions, so we can either give them
a part of the registry that works for them, or they'll resort to squatting.
And
I think First Come First Serve
<https://tools.ietf.org/html/rfc8126#section-4.4> will get us what we want
here. I don't think
Provisional Registrations <https://tools.ietf.org/html/rfc8126#section-4.13>
fit the bill here because these proprietary extensions
have no reason to be time-limited.

David

On Thu, Oct 24, 2019 at 5:23 PM Martin Thomson <[email-masked]> wrote:

> > > That said, there's one thing I'd change. According to RFC 8126,
> Standards Action is limited to Standards-track RFCs and BCPs, and I'd like
> to see Experimental included in this space as well. I think RFC Required is
> what I'd prefer.
> >
> > To me, the only
> My thinking was along the same lines as Ted.  As much of the space has the
> much lower bar of Specification Required, those experiments can use that
> space freely.  The only experiments that wouldn't be permitted would be
> those that want one-byte codepoints (and provisional registrations would
> still be available, though discouraged).  And yeah, I'd be OK if someone
> said that the whole space should be Specification Required.  But I've seen
> 256-value spaces chewed up very fast in the past, and our 64-value space
> could be more appealing.
>
>

---

From: Christian Huitema <[email-masked]>
Date: Thu, 24 Oct 2019 23:32:08 -0700

On 10/24/2019 9:34 PM, David Schinazi wrote:
> [0-63] Standards Action
> <https://tools.ietf.org/html/rfc8126#section-4.9> or IESG Approval
> <https://tools.ietf.org/html/rfc8126#section-4.10>
>     This gives the IETF a little protected garden and that means that
> folks developing
>     This ensures that we'll never run out of this space. Experimental
> RFCs would
>     use this registry.
>
>     as IANA does not review the request. This means that we can use
> the registry
> <https://tools.ietf.org/html/rfc8126#section-4.1> for the reasons
> stated by others, but I do think
> that if someone wants to build a proprietary extension, they should be
> able to
> do so without having to document it publicly - because in reality
> people will
> a part of the registry that works for them, or they'll resort to
> squatting. And
> <https://tools.ietf..org/html/rfc8126#section-4.4> will get us what we
> want here. I don't think
> Provisional Registrations
> <https://tools.ietf.org/html/rfc8126#section-4.13> fit the bill here
> because these proprietary extensions

I think I like Martin's proposal better. My reasoning is that there is
no practical difference between the numbers as long as TP are encoded on
16 bits, and I have a hard time believing that any IANA registry could
efficiently manage more than a few thousand code points. Plus
specification required is really nice for the community.

-- Christian Huitema

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 25 Oct 2019 12:19:07 +0000

Hi Martin, hi all,

just replying to the last mail in this thread, but I have two points (which to some extend may relate to other points already made):

  1.  Private use: David said something that he still would like private use for cases where someone don’t want to reveal anything (?). I think just registering a codepoint with a random name and without any documentation wouldn’t actually reveal anything but still helps the requester  that nobody else will every use the same code for a different parameter in future which would case the request to update their code. I think that’s exactly the point of the registry. However, I would still like to reserve one or two codepoints for (private) experimentation. That’s basically the codepoint you would use in your initial implementation for your initial testing because something these code fragment just hang around without usage until someone suddenly finds it and that would increase the need to actually go and register if you really want to use it. Not sure if it helps, but I would like to try.
  2.  I’m afraid that if we have the provisional FCFS that there is actually no perceived need any more to make a real registration at some point. Also FCFS is usually without any expert review because the task of removing junk or doube-checking if too many request are send at once from the same party is usually something IANA can do on its own. So I wondering if having experts and having the Spec required part is actually useful, if this model will end up anyway such that everybody can get a registration no matter what. On the other hand it would be nice to provide an incentive to also provide a pointer to a spec (which btw does not have to be an I-D), however, I don’t see that the difference between a theoretical permanent or “only” provisional registration will provide this incentive. My guess is rather that if we have a field for a reference link in the registry that people will provide that pointer anyway if available.

Mirja

From: QUIC <[email-masked]> on behalf of Christian Huitema <[email-masked]>
Date: Friday, 25. October 2019 at 08:39
To: David Schinazi <[email-masked]>, Martin Thomson <[email-masked]>
Cc: QUIC <[email-masked]>
Subject: Re: Making QUIC less constraining for innovation

On 10/24/2019 9:34 PM, David Schinazi wrote:
[0-63] Standards Action<https://tools.ietf.org/html/rfc8126#section-4.9> or IESG Approval<https://tools.ietf.org/html/rfc8126#section-4.10>
    This gives the IETF a little protected garden and that means that folks developing
    extensions and experiments won't use the next available value from here.

[64-16383] Specification Required<https://tools.ietf.org/html/rfc8126#section-4.6>
    This creates a carveout with an intentional overhead of requiring writing a draft.
    This ensures that we'll never run out of this space. Experimental RFCs would
    use this registry.

[16384+] First Come First Serve<https://tools.ietf.org/html/rfc8126#section-4.4>
    This allows anyone to request a code-point and register it without overhead,
    as IANA does not review the request. This means that we can use the registry
    simply as a collision-avoidance mechanism.

I agree with removing Private Use<https://tools.ietf.org/html/rfc8126#section-4.1> for the reasons stated by others, but I do think
that if someone wants to build a proprietary extension, they should be able to
do so without having to document it publicly - because in reality people will
be building undocumented proprietary extensions, so we can either give them
a part of the registry that works for them, or they'll resort to squatting. And
I think First Come First Serve<https://tools.ietf..org/html/rfc8126#section-4.4> will get us what we want here. I don't think
Provisional Registrations<https://tools.ietf.org/html/rfc8126#section-4.13> fit the bill here because these proprietary extensions
have no reason to be time-limited.

I think I like Martin's proposal better. My reasoning is that there is no practical difference between the numbers as long as TP are encoded on 16 bits, and I have a hard time believing that any IANA registry could efficiently manage more than a few thousand code points. Plus specification required is really nice for the community.

-- Christian Huitema

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 12:30:22 +0000

*   Private use: David said something that he still would like private use for cases where someone don’t want to reveal anything (?).

I don’t think we have to support that.  If you want something reserved for yourself, and you want to avoid collisions, then saying you have to describe things – that’s a fair trade-off.

If the WG wants to set aside private code-points, with no guarantee about conflicts if found on the public internet, that’s also reasonable to me.

If you want packets on the Internet, and you want them to avoid conflict with anyone else’s packets on the Internet, then you have to document them or encrypt them.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 25 Oct 2019 16:41:35 +0000

Re “a”: My suspicion is that if it has to be registered, it won’t be private-- if it is in an implementation that is interoperating broadly with others, it won’t remain private.
-=R

From: QUIC <[email-masked]> on behalf of Mirja Kuehlewind <mirja.kuehlewind=[email-masked]>
Date: Friday, October 25, 2019 at 5:19 AM
To: Christian Huitema <[email-masked]>, David Schinazi <[email-masked]>, Martin Thomson <[email-masked]>
Cc: QUIC <[email-masked]>
Subject: Re: Making QUIC less constraining for innovation

Hi Martin, hi all,

Mirja

On 10/24/2019 9:34 PM, David Schinazi wrote:
[0-63] Standards Action<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.9&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=b8QdP9RaVAu7Ml6iPwkwWUr8En7OD3buoZC5iX6JsSc&e=> or IESG Approval<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.10&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=6JoczjsujKifSLlYmqTIqu4Jo8OHYWSxfaAZN2TaOTA&e=>
    This gives the IETF a little protected garden and that means that folks developing
    extensions and experiments won't use the next available value from here.

[64-16383] Specification Required<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.6&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=eM5EOoeobcdCv3a2ifRMD84YG6bM-yaJtwk9yzXGCtg&e=>
    This creates a carveout with an intentional overhead of requiring writing a draft.
    This ensures that we'll never run out of this space. Experimental RFCs would
    use this registry.

[16384+] First Come First Serve<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.4&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=oyApzcfcaERkuzrstLo9_obYQ42MIzdnh49wa-YznyQ&e=>
    This allows anyone to request a code-point and register it without overhead,
    as IANA does not review the request. This means that we can use the registry
    simply as a collision-avoidance mechanism.

I agree with removing Private Use<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.1&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=fW1BFhUjtyldS9jR0LuGoCfSlZc3ReRP0f0ViBYrNGs&e=> for the reasons stated by others, but I do think
that if someone wants to build a proprietary extension, they should be able to
do so without having to document it publicly - because in reality people will
be building undocumented proprietary extensions, so we can either give them
a part of the registry that works for them, or they'll resort to squatting. And
I think First Come First Serve<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_rfc8126-23section-2D4.4&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=ZRJc2Ze4LCqR6sxT7Bq4Py8h9vXtM5z5VhhDzB6lmP4&e=> will get us what we want here. I don't think
Provisional Registrations<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.13&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=1hwEhn6m9qfzSjK6durqdy7q-B0o-h9AQSwgLHElwLk&e=> fit the bill here because these proprietary extensions
have no reason to be time-limited.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Oct 2019 11:42:38 -0700

I don't think requiring folks to document their extensions is realistic.
In practice, some won't. Now we get to decide if we'd like them to register
their codepoints or not. So I see three options:
1) We pick Private Use and have folks pick randomly there and hope to
avoid collisions (fine for varints, not quite so sure for 16-bit)
2) We pick First Come First Serve and let folks easily register
3) We add constraints such as Specification Required to the entire space,
and accept the fact that these folks will squat on values in the space.

I understand the impulse of encouraging folks to document their codepoints,
but we have to accept the reality that some won't.

On Fri, Oct 25, 2019 at 9:42 AM Roberto Peon <[email-masked]> wrote:

> Re “a”: My suspicion is that if it has to be registered, it won’t be
> private-- if it is in an implementation that is interoperating broadly with
> others, it won’t remain private.
> -=R
>
>
>
> *From: *QUIC <[email-masked]> on behalf of Mirja Kuehlewind
> <mirja.kuehlewind=[email-masked]>
> *Date: *Friday, October 25, 2019 at 5:19 AM
> *To: *Christian Huitema <[email-masked]>, David Schinazi <
> [email-masked]>, Martin Thomson <[email-masked]>
> *Cc: *QUIC <[email-masked]>
> *Subject: *Re: Making QUIC less constraining for innovation
>
>
>
> Hi Martin, hi all,
>
>
>
> just replying to the last mail in this thread, but I have two points
> (which to some extend may relate to other points already made):
>
>
>
>    1. Private use: David said something that he still would like private
>    use for cases where someone don’t want to reveal anything (?). I think just
>    registering a codepoint with a random name and without any documentation
>    wouldn’t actually reveal anything but still helps the requester  that
>    nobody else will every use the same code for a different parameter in
>    future which would case the request to update their code. I think that’s
>    exactly the point of the registry. However, I would still like to reserve
>    one or two codepoints for (private) experimentation. That’s basically the
>    codepoint you would use in your initial implementation for your initial
>    testing because something these code fragment just hang around without
>    usage until someone suddenly finds it and that would increase the need to
>    actually go and register if you really want to use it. Not sure if it
>    helps, but I would like to try.
>    2. I’m afraid that if we have the provisional FCFS that there is
>    actually no perceived need any more to make a real registration at some
>    point. Also FCFS is usually without any expert review because the task of
>    removing junk or doube-checking if too many request are send at once from
>    the same party is usually something IANA can do on its own. So I wondering
>    if having experts and having the Spec required part is actually useful, if
>    this model will end up anyway such that everybody can get a registration no
>    matter what. On the other hand it would be nice to provide an incentive to
>    also provide a pointer to a spec (which btw does not have to be an I-D),
>    however, I don’t see that the difference between a theoretical permanent or
>    “only” provisional registration will provide this incentive. My guess is
>    rather that if we have a field for a reference link in the registry that
>    people will provide that pointer anyway if available.
>
>
>
> Mirja
>
>
>
> *From: *QUIC <[email-masked]> on behalf of Christian Huitema <
> [email-masked]>
> *Date: *Friday, 25. October 2019 at 08:39
> *To: *David Schinazi <[email-masked]>, Martin Thomson <
> [email-masked]>
> *Cc: *QUIC <[email-masked]>
> *Subject: *Re: Making QUIC less constraining for innovation
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.9&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=b8QdP9RaVAu7Ml6iPwkwWUr8En7OD3buoZC5iX6JsSc&e=>
> or IESG Approval
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.10&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=6JoczjsujKifSLlYmqTIqu4Jo8OHYWSxfaAZN2TaOTA&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.6&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=eM5EOoeobcdCv3a2ifRMD84YG6bM-yaJtwk9yzXGCtg&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.4&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=oyApzcfcaERkuzrstLo9_obYQ42MIzdnh49wa-YznyQ&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.1&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=fW1BFhUjtyldS9jR0LuGoCfSlZc3ReRP0f0ViBYrNGs&e=>
> for the reasons stated by others, but I do think
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf..org_html_rfc8126-23section-2D4.4&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=ZRJc2Ze4LCqR6sxT7Bq4Py8h9vXtM5z5VhhDzB6lmP4&e=>
> will get us what we want here. I don't think
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8126-23section-2D4.13&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=Kq6awpWJuEQdYkWDrsF3gnoUsmVCnuF6qgVVLidCzLg&s=1hwEhn6m9qfzSjK6durqdy7q-B0o-h9AQSwgLHElwLk&e=>
> I think I like Martin's proposal better. My reasoning is that there is no
> practical difference between the numbers as long as TP are encoded on 16
> bits, and I have a hard time believing that any IANA registry could
> efficiently manage more than a few thousand code points. Plus specification
> required is really nice for the community.
>
> -- Christian Huitema
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 18:47:14 +0000

*   I understand the impulse of encouraging folks to document their codepoints,
but we have to accept the reality that some won't.

And what happens if so?  That’s a serious question, not  flippant one.

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Oct 2019 11:55:20 -0700

> And what happens if so?  That’s a serious question, not  flippant one.

I suspect they'll simply squat on IANA-owned space.
That's not the end of the world, but we need to decide if we prefer
that to allowing low-overhead registrations.

I personally would like these folks to register so we don't end up
with IANA allocating a widely deployed squatted codepoint.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Oct 2019 19:23:45 +0000

*   I personally would like these folks to register so we don't end up
with IANA allocating a widely deployed squatted codepoint.

I get it, and I expect the WG may do that.

But I can be a real jerk, and I want us to do that. :)

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 26 Oct 2019 12:18:51 +1100

> I don't think requiring folks to document their extensions is realistic.

Nothing in the proposal required that they be documented.  I proposed to have provisional registrations explicitly allow for registrations with no information attached.

As an aside, I think we might want to require contact information, which is (I think) normal practice for registries.  I don't think that we should insist on that contact information being "good"; there's no guarantee that is remains that way even if we did want to test it.

---

From: David Schinazi <[email-masked]>
Date: Fri, 25 Oct 2019 18:44:51 -0700

By provisional, do you mean that they’d expire after some time? I’m not
sure that’s satisfactory for undocumented proprietary extensions.

Requiring contact information doesn’t sound like much of a hurdle though,
I’m happy with that.

On Fri, Oct 25, 2019 at 18:19 Martin Thomson <[email-masked]> wrote:

> Nothing in the proposal required that they be documented.  I proposed to
> have provisional registrations explicitly allow for registrations with no
> information attached.
>
> As an aside, I think we might want to require contact information, which
> is (I think) normal practice for registries.  I don't think that we should
> insist on that contact information being "good"; there's no guarantee that
> is remains that way even if we did want to test it.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 26 Oct 2019 13:32:59 +1100

> sure that’s satisfactory for undocumented proprietary extensions.

Yeah, the idea is that these have no expectation of being permanent, so that there is some hope of reclaiming spent codepoints.  But they can won't be reclaimed unless necessary, and renewal should be easy.

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 25 Oct 2019 19:34:54 -0700

Requiring contact information (knowing that it might be stale) sounds
great. Asking for a completely optional description also sounds good to me.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 26 Oct 2019 03:09:03 -0400

If transport parameters are ordered and variable length you can sidestep
the problem by reserving a specific range to custom values and require a
preceeding parameter to have a random UUID value to namespace that range.

In principle the namespace and range can be repeated for different
namespaces.

You can then optionally allow for the namespace to be registered but it
isn’t necessary because the chance is effectively zero.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 26 October 2019 at 04.33.32, Martin Thomson ([email-masked]) wrote:

> sure that’s satisfactory for undocumented proprietary extensions.

Yeah, the idea is that these have no expectation of being permanent, so
that there is some hope of reclaiming spent codepoints. But they can won't
be reclaimed unless necessary, and renewal should be easy.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 28 Oct 2019 13:57:55 +0000

IANA will usually always require some contact information because usually they would like to at least tell you if your request was registered or not (for whatever reason). However, if we should publish this contact information in the registry is a different question.

From: Ryan Hamilton <rch=[email-masked]>
Date: Saturday, 26. October 2019 at 04:35
To: David Schinazi <[email-masked]>
Cc: Martin Thomson <[email-masked]>, Mirja Kuehlewind <[email-masked]>, QUIC <[email-masked]>, Christian Huitema <[email-masked]>, Roberto Peon <[email-masked]>
Subject: Re: Making QUIC less constraining for innovation

Requiring contact information (knowing that it might be stale) sounds great. Asking for a completely optional description also sounds good to me.

On Fri, Oct 25, 2019 at 6:45 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
By provisional, do you mean that they’d expire after some time? I’m not sure that’s satisfactory for undocumented proprietary extensions.

Requiring contact information doesn’t sound like much of a hurdle though, I’m happy with that.

On Fri, Oct 25, 2019 at 18:19 Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Rui Paulo <[email-masked]>
Date: Mon, 28 Oct 2019 10:55:33 -0700

> Requiring contact information (knowing that it might be stale) sounds great. Asking for a completely optional description also sounds good to me.

I agree.  This has the advantage that if an extension has a description, I might read it and realize someone else already solved the problem I’m trying to solve.  I could then reach out to that person and perhaps I won’t re-invent the wheel...

—
Rui Paulo

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 30 Oct 2019 17:50:19 +1100

I've written up this proposal here:

https://github.com/quicwg/base-drafts/pull/3170

Thanks to everyone who provided input here.  I think that I got all of it, but feel free to pitch in on the PR with notes about errors and omissions.

The only bit of this that I'm hesitant over is the use of Expert Review for the provisional entries.  I don't know if we could instead use First-Come, First-Served and rely on IANA to watch for spamming.  It would probably be faster without an expert review step involved.

On Thu, Oct 24, 2019, at 14:26, Martin Thomson wrote:
> 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
> 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.
> 
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 30 Oct 2019 14:19:46 -0700

Thanks for writing this up! My main pushback against Provisional
Registrations was that I expected them to expire after some number of days,
and seeing that this is not the case in the PR explains things.

The PR sounds like a reasonable approach to me, I sent some more specific
comments there.

I'm supportive of trying out First Come First Served for provisional
entries. We can change the rules later if we see the space fill up too
quickly.

On Tue, Oct 29, 2019 at 11:50 PM Martin Thomson <[email-masked]> wrote:

> Thanks to everyone who provided input here.  I think that I got all of it,
> but feel free to pitch in on the PR with notes about errors and omissions.
>
> The only bit of this that I'm hesitant over is the use of Expert Review
> for the provisional entries.  I don't know if we could instead use
> First-Come, First-Served and rely on IANA to watch for spamming.  It would
> probably be faster without an expert review step involved.
>