Iljitsch van Beijnum wrote:
There are also specifications that would have been good to have
implementations before leaving the WG, because they are not
implemented-able as is (spkm).
Is that because the designers did a bad job or because there was no
way to anticipate the implementation difficulties?
Protocol specs are like other pieces of engineering results:
they benefit greatly from testing and experience, particularly
if you've never created this specific type of entity before.
Sometimes what looks good on paper works but has nits and
missing details that need to filled out. In some other cases
there are more serious problems. In yet another cases there
are no issues.
I've seen many cases where supposedly well debated and
edited specifications had problems that could have been
detected by implementation experience. State transitions
or error conditions missed by specs written in prose rather
than in state machine form; security pixie dust that provides
a general solution but for which we cannot create a working
set of policy rules due to the nature of the application;
ambiguous requirements; lack of sufficient behaviour rules
to go with message formats; interactions between protocols
or layers that are hard to implement in commonly available
stack designs; optimizations that look good but turn out to
optimize an unimportant part of the problem; etc.
Obviously, I'm not advocating that we only listen to implementation
experience. A good spec combines input from multiple sources:
architetural insight, protocol design expertise, implementation
experience, marketing demand, different application areas, ...
You may also be able to trade one source to another one, but
not without limits.
--Jari
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf