On Wed, Apr 24, 2024 at 3:19 PM David Schinazi
wrote:
> I see, thanks for clarifying. So this proposal would require every
> implementation that chooses to ever deploy a new codepoint to implement
> this new extension, for all eternity. That seems brittle to me, as things
> would break in the
> On 25 Apr 2024, at 07:59, Brian Dickson wrote:
>
>
>
> On Wed, Apr 24, 2024 at 2:28 PM David Schinazi
> wrote:
> If I understand your proposal correctly, this would require the receiver to
> support this new EDNS option in order to properly remove values that the
> sender thought were
I see, thanks for clarifying. So this proposal would require every
implementation that chooses to ever deploy a new codepoint to implement
this new extension, for all eternity. That seems brittle to me, as things
would break in the presence of a single lazy implementer. What made GREASE
viable was
On Wed, Apr 24, 2024 at 2:28 PM David Schinazi
wrote:
> If I understand your proposal correctly, this would require the receiver
> to support this new EDNS option in order to properly remove values that the
> sender thought were unused but that the receiver did not. Such a
> requirement on
If I understand your proposal correctly, this would require the receiver to
support this new EDNS option in order to properly remove values that the
sender thought were unused but that the receiver did not. Such a
requirement on receivers makes it impossible for the sender to know it can
safely
On Wed, Feb 28, 2024 at 7:11 AM Shumon Huque wrote:
> Thanks for your comments David. I hope it will progress too, and good to
> hear that that grease worked well for TLS and QUIC.
>
> On random vs reserved values, we do intend to propose some reserved ranges
> (there is a placeholder section in
Thanks for your comments David. I hope it will progress too, and good to
hear that that grease worked well for TLS and QUIC.
On random vs reserved values, we do intend to propose some reserved ranges
(there is a placeholder section in the draft for this already). And then
try to have a debate
I think this draft is a great idea and I'd love to see it progress. GREASE
did well in TLS and worked wonders in QUIC - it helped us catch multiple
real production issues early on.
That said, I do worry about the idea of using random unallocated values.
Not all software gets updated, and no
Yep, we are in a much better position than we were in 2019. Most failures are
well < 1% when talking to authoritative servers. Broken firewall defaults have
been fixed and mostly deployed.
> On 27 Feb 2024, at 16:41, George Michaelson wrote:
>
> so yet again, I voice things which show my
so yet again, I voice things which show my ignorance, not yours. I
thank you for the gentle clue-stick hit, it was educational.
-G
On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque wrote:
>
> On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews wrote:
>>
>>
>> > On 27 Feb 2024, at 15:53, George
On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews wrote:
>
> > On 27 Feb 2024, at 15:53, George Michaelson wrote:
> >
> > Not in any way to stop this specific draft, I wonder if this is a more
> > general principle of exercising code points which are not marked
> > "never to be used" and should
> On 27 Feb 2024, at 15:53, George Michaelson wrote:
>
> Not in any way to stop this specific draft, I wonder if this is a more
> general principle of exercising code points which are not marked
> "never to be used" and should also be raised cross-area, or in another
> place?
>
> Maybe the
Not in any way to stop this specific draft, I wonder if this is a more
general principle of exercising code points which are not marked
"never to be used" and should also be raised cross-area, or in another
place?
Maybe the best path is to get this proved here, and then embrace-extend.
I tend
13 matches
Mail list logo
