The particular examples I am most familiar with were cases where the
vendor had implemented silicon to handle the protocol. This is one of
the differences between behaviors higher in the stack and some of the
behaviors lower in the stack.
Yours,
Joel
On 5/11/19 11:22 PM, Eric Rescorla wrote:
On Sat, May 11, 2019 at 6:53 PM Joel M. Halpern <jmh@xxxxxxxxxxxxxxx
<mailto: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 <mailto: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 <mailto: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
<mailto:mcr%2BIETF@xxxxxxxxxxxx>>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
