On Sat, May 11, 2019 at 6:53 PM Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote:
Several folks have mentioned early implementations. In general, they
are a great thing that gives us lots of feedback.
Having said that, I will note that if a major vendor invests too much in
that early implementation, they get rather wedded to the version of the
spec they implemented. Which can create problems for the working group
when it discovers that changes are needed.
In particular, if that early implementation is very strict, it is harder
for it to work with something different that the IETF determines is needed.
Certainly this is a risk, but my experience with both TLS and QUIC has been that this
has not really been the case, for two reasons:
1. The vast majority of the implementors in both cases have been very good about
changing their implementations.
2. Because we are indicating separate version numbers for each draft version,
there is an opportunity to debug interop issues at the time you rev your version.
Of course, this may be a set of conditions which mostly apply to protocols like
those on the Web where many of the vendors are able to quickly roll out each
new version. YMMV.
-Ekr
Yours,
Joel
On 5/11/19 6:59 PM, Michael Richardson wrote:
>
> Eric Rescorla <ekr@xxxxxxxx> wrote:
> > I think this graf does a good job of bringing out the key point which I take
> > Martin to be pushing on. As you say, it would be nice to have fewer bug "bug
> > compatibility switches".
>
> I really like how you wrote this.
> The worse case is where one vendor plows ahead (or has some legacy system),
> and then everyone else has to adjust to their bugs, and that never goes away.
>
> > One way to achieve that is for the initial implementations to be very strict
> > about rejecting violations of the specification. Then, when new
> > implementations are introduced into the ecosystem, if they do not conform to
> > those aspects of the specification and are forced to implement the protocol
> > correctly. By contrast, if the early implementations are very loose in their
> > enforcement of protocol violations, then it is likely that some set of
> > implementations will also violate the specification in the data they
> > transmit, with the result that future implementations will have to implement
> > "bug compatibility switches" in order to be able to function correctly.
>
> I wonder how we could, without really giving up the Postel principle, capture
> this sense into our Internet Standard step.
>
> Eric Rescorla <ekr@xxxxxxxx> wrote:
> > There seem to be two main equilibria:
>
> > 1. There's a critical mass of very strict implementations; in this case it's
> > very hard for a non-conformant implementation to enter the ecosystem.
> > 2. There's a critical mass of non-conformant implementations; in this case
> > it's very hard for a strict implementation to enter the ecosystem.
>
> > Once you're in one equilibrium or the other, it's very hard to get out.
>
> I am repeating what you said here, because I like the analysis of equilibria,
> and maybe this is the clue to answering my question above.
>
> > was pretty clear. Also, at least in QUIC/TLS, etc. the early adopters
> > coordinate pretty well, so they mostly agree on how to interpret the
> > protocol.
>
> And, if the running code is done early enough, then the rough consensus in
> the document will reflect that majority view, and there won't be
> compatibility bugs. But, that requires multiple implementations, and it
> requires implementing before RFC, and many vendors won't do that.
>
> (ps: EKR great write-up/blog about the firefox add-on fix last weekend.. Sorry
> that everyone lost their weekend to that...)
>
> --
> Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
