I think that this is the biggest mental obstacle. If we believe our work is done when the specification is done, then we will fail to reach the full potential of our work. I understand that this message is inconvenient because many participants have difficulties to influence the deployment or even implementations. This is also the cause of a lot of frustration in the IETF work because person A says or writes "I went feature foo." but persons B and C then need to implement 'foo' and then deploy it. Needless to say that persons B and C are less excited about doing the work for person A. IMHO this is the root cause of many conflicts as far as I can see.
My impression is that IETF has always been (at least since 1990 which is about when I started) much more about producing specifications than code. Implementation experience was always valued in WG discussions, but implementations were not the main goal or even an explicit goal except as needed for advancement beyond Proposed.
Yes, at the end of the day the IETF will produce specifications.
But there is a world of differences between specifications that
result only from theoretical considerations and specifications
that were produced and tested by developing implementations. It is
a bit like the famed difference between theory and practice.
Part of this was rooted in experience that interoperability was obtained from clear specifications of "bits on the wire", rather than by either APIs or a reference implementation. But conditions were somewhat different then, because then you had more diverse hardware, (you still had machines with 36-bit words for example), more diversity in operating systems, and it wasn't the case that you could expect the same programming languages to be supported everywhere. (perhaps not even C).
Similar considerations happen today. Different languages of
course, but also different deployment conditions, dealing with
different load balancers, different architectures of server farms,
firewalls, transmission medias... And, by the way, developing in C
is somewhat controversial these days, but there are different
schools of thought about what the replacement language should be.
-- Christian Huitema
