Re: Big TP codespace

Martin Duke <martin.h.duke@gmail.com> Thu, 16 May 2019 19:01 UTC

MIME-Version: 1.0
References: <CAM4esxRBmm8CVWWeg=Fq6=JzS0ftQsj=0T6CfhQ8KHmkUNpenQ@mail.gmail.com> <C91C33EC-323B-41AB-8856-9FE56A065CF3@huitema.net> <CAPDSy+4KiCaG_ap_R=qcSm9wYA8ZU94983d5YWV3AZ9Vz=WHMQ@mail.gmail.com> <CABcZeBPpLh9ejrg-VbYKyL5rYV2=Y533SrqA+A_-jM4R-sGZ0Q@mail.gmail.com> <CY4PR22MB0983FBE5C72EF1D46DAC27ECDA090@CY4PR22MB0983.namprd22.prod.outlook.com> <CAPDSy+6FtX6J1yNzf6cQC8Xr_7J60ULjiTJ2zNhRou-3+QyB+Q@mail.gmail.com> <CACpbDcew+zgZJ2Y7qC+zwoMrGrdzoagB6HtC=z=woNzB6FrhXQ@mail.gmail.com>
In-Reply-To: <CACpbDcew+zgZJ2Y7qC+zwoMrGrdzoagB6HtC=z=woNzB6FrhXQ@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 16 May 2019 12:01:32 -0700
Message-ID: <CAM4esxSmZXTj5wAEOpXtz2xwZFwK85rLLhHmMDTBErxjBOSymQ@mail.gmail.com>
Subject: Re: Big TP codespace
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Mike Bishop <mbishop@evequefou.be>, Eric Rescorla <ekr@rtfm.com>, IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="000000000000a592fb058905e538"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/cdwWKaVHu6Da3uqn_b1AVPHmfIA>
Precedence: list

yep, i'm conversing in there.

On Wed, May 15, 2019 at 6:47 PM Jana Iyengar <jri.ietf@gmail.com> wrote:

> Martin, the text in #2691 supports what you want to accomplish, but
> doesn't require everyone to do the same thing. I think that's all we need.
>
> On Wed, May 15, 2019 at 10:44 AM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>> @ekr, the principle I was endorsing is the one Mike mentioned.
>>
>> On Wed, May 15, 2019 at 10:20 AM Mike Bishop <mbishop@evequefou.be>
>> 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 <quic-bounces@ietf.org> *On Behalf Of * Eric Rescorla
>>> *Sent:* Tuesday, May 14, 2019 5:21 PM
>>> *To:* David Schinazi <dschinazi.ietf@gmail.com>
>>> *Cc:* IETF QUIC WG <quic@ietf.org>; Christian Huitema <
>>> huitema@huitema.net>; Martin Duke <martin.h.duke@gmail.com>
>>> *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 <dschinazi.ietf@gmail.com>
>>> 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 <huitema@huitema..net>
>>> wrote:
>>>
>>>
>>>
>>> > On May 13, 2019, at 1:58 PM, Martin Duke <martin.h.duke@gmail.com>
>>> 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
>>>
>>>

Big TP codespace Martin Duke
Re: Big TP codespace Matt Joras
Re: Big TP codespace Christian Huitema
Re: Big TP codespace David Schinazi
Re: Big TP codespace Eric Rescorla
RE: Big TP codespace Mike Bishop
Re: Big TP codespace David Schinazi
Re: Big TP codespace Jana Iyengar
Re: Big TP codespace Martin Duke