On Thu, Jul 4, 2019 at 1:54 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Eric Rescorla <ekr@xxxxxxxx> wrote:
>> and your description of how tls did this with 1.3, 'marked' versions of
>> internet-drafts, seemed to work well. and those with colder feet could
>> wait for the rfc. but i note that the triel implementations seemed not
>> to be deployed in production until the ietf sausage was made.
> I don't want to debate the precise meaning of production, but what I will
> say is that at in the case of TLS 1.3, we had pre-draft versions on in
> Release
> versions of Chrome and Firefox and serving live domains at Cloudflare
> (and I think Facebook and Google, but I'd have to check my notes). This
> was actually essential to finding problems because there are environments
> which will not run prerelease software.
I agree how valuable it was.
But, the parties involved all understood (in a deep way, up to product
managers, I expect) that there might be incompatible changes.
Yes, I think this is a fair point. It's also notable that these were also protocols that
were "optional", either in the sense that you could downwardly negotiate to other
versions (TLS, HTTP) or fall back to another protocol (QUIC). So that meant that
tight coordination was less relevant.
I have been through protocols with obvious flaws waiting for a zero-day bugs
where I could not get a fix in ID-07 because "it's been deployed".
I agree that this is bad. Everybody involved in these protocols understood that
"it's deployed" wasn't going to be a very strong argument.
-Ekr
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
