On Thu, Jul 04, 2019 at 08:31:47AM -0700, Eric Rescorla wrote:
> Ignoring labelling for a moment, in a number of WGs (HTTP, TLS, and
> QUIC) we have found it necessary to have full implementations and
> large-scale deployments quite early in the design process, long before
> anyone thinks that the document is done.
I had that experience in mind.
Except for QUIC (whose implementors and deployers understood and
expected to have to make backwards-incompatible changes / move to HTTP/2
and /3), HTTP/2 and TLS 1.3 didn't get widespread deployment during this
process. But they did get some, and that "some deployment" was
absolutely critical to their success.
> Common practice has become something like this:
>
> [...]
>
> This does not really fit into the PS/DS model: We absolutely need
> to deploy early versions to find potential issues (this was critical
> to TLS 1.3) but we all know that those documents don't meet the PS
> bar as they may have known defects or at least open issues. There's
> also no real use for Full Standard. The market doesn't care about it
> and the people who are doing the work either are (1) fixing/extending
> the protocol (using the process above) or (2) have moved onto some
> other protocol.
Not only that, but when a WG has the energy for this, it's the only way
to move at a pace that doesn't kill that energy.
I-D -> PS -> DS -> STD == fizzle
> It's not clear to me how well this Evolving Documents proposal would
> fit into such a model [0], but I thought a field report on what is becoming
> common practice might be useful.
>
> -Ekr
>
> [0] The real need I find is to be able to make minor fixes to the
> documents (mostly editorial errata or clarification of points on which
> there was consensus) without re-spinning the RFC, which people don't
> have the energy for.
And if we're going to continue to have STDs, then we'll want to have
tooling for submission of implementation, deployment, and interop
reports.
Also, if we want to stick to the idea of removing parts of PSes that are
not interop tested, then we might want to have a more formal way of
marking every "feature" that needs interop testing. Heck, even if we do
drop that old idea, we should do this.
Perhaps we could take a page from specs like x.680 and x.690 and
friends, which have lots of very short sub-sections that match closely
to features that one could then list by their section numbers.
Nico
--
