Re: Big TP codespace

[David Schinazi <[e-mail]>]

@ekr, the principle I was endorsing is the one Mike mentioned.

On Wed, May 15, 2019 at 10:20 AM Mike Bishop <[e-mail]> wrote:

> We agreed in Tokyo that we would not mandate that implementations check
> for improper peer behavior when doing so required substantial extra work.
> Implementations MUST error out on easily-detected errors, but only
> SHOULD/MAY error on things they would have to actively check (unless
> they’re already required to actively check for security reasons, in which
> case there’s no *extra* work).
>
>
>
> *From:* QUIC <[e-mail]> *On Behalf Of * Eric Rescorla
> *Sent:* Tuesday, May 14, 2019 5:21 PM
> *To:* David Schinazi <[e-mail]>
> *Cc:* IETF QUIC WG <[e-mail]>; Christian Huitema <[e-mail]>;
> Martin Duke <[e-mail]>
> *Subject:* Re: Big TP codespace
>
>
>
> What's the bigger principle you are endorsing? What errors "like this" are
> we not requiring detection of?
>
>
>
> On Mon, May 13, 2019 at 5:19 PM David Schinazi <[e-mail]>
> wrote:
>
> Our implementation checks for duplicates only for the transport parameters
> it supports. I think #2691
> <https://github.com/quicwg/base-drafts/pull/2691/files> is the correct
> solution.
>
>
>
> +1 to the design principle of encouraging but not requiring detection of
> errors like this
>
>
>
> David
>
>
>
> On Mon, May 13, 2019 at 2:06 PM Christian Huitema <[e-mail]
> <huitema@huitema..net>> wrote:
>
>
>
> > On May 13, 2019, at 1:58 PM, Martin Duke <[e-mail]>
> wrote:
> >
> > What do people think?
>
> I think the general rule of protocol policing should be "MUST NOT" do
> dastardly stuff, and "MAY" drop the connection when that happens.
>
> -- Christian Huitema
>
>