Re: Making QUIC less constraining for innovation

[Ted Hardie <[e-mail]>]

On Wed, Oct 23, 2019 at 11:25 PM Jana Iyengar <[e-mail]> wrote:

> 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.
>
>
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



> - jana
>
> On Thu, Oct 24, 2019 at 2:41 PM Mark Nottingham <[e-mail]> wrote:
>
>> On 24 Oct 2019, at 4:21 pm, Martin Thomson <[e-mail]> wrote:
>> >
>> > 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.
>>
>> 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,
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>>