Maybe the survey to be done is a review of all the RFC, STD and see
which ones
- had a great abstract and introduction,
- had the better writing styles
- had the least endorsement resistance
- progress faster than most,
- had the most implementators,
- with least support/questions need to be asked,
etc, etc.
Are the RFCs that followed 2119 the more successful ones, the ones
written with clarity and knew how to separate functional and technical
descriptions? Had the right target audience(s) in mind?
Maybe we can also review which I-D and RFCs have high failure or have
trouble getting industry endorsement, and even if it did, why has it
failed in the market place?
What is the overall problem anyway? Is this part of the reason why
there are efforts to fast track documents? Because there are so much
resistance by such a broad range of disciplines with different level
mindsets and philosophies?
--
HLS
Martin Rex wrote:
John Day wrote:
It would be interesting to see you apply that.
This is what I have been talking about. The human mind's ability to
believe that the whole world sees everything the same way they do.
It really is quite amazing.
These so-called gaps often arise because they were unstated
assumptions or things that the author believed were patently obvious
and didn't need to be stated. Actually didn't know needed to be
stated. From his point of view, no one would do it differently.
Nothing had been left out and he didn't make the "mistake." What
the other guys did was a bug.
There is a much greater range of interpreting these things than it
appears that you imagine.
With "bug", I mean behaviour that is non-compliant with the spec,
where the difference is not to accomodate for a defect of the spec,
and where this behaviour is detrimental to the operation of that
implementation (vulnerability or robustness issue) or detrimental
to the interop with other implementations.
With "conflict" in a spec, I refer to distinct statements in a
spec that contradict each other (such as the same symbolic protocol
element is assigned two different values in two seperate locations
of the spec).
With "ambiguity" in a spec, I refer to an omission that precludes
that a certain feature can be implemented at all. Such as a symbolic
protocol element that represents an integer value in a PDU, but
the spec lacks the definition of the numeric value for the
on-the-wire representation.
With "gap" in a spec, I refer to omissions that do not preclude
the implementation, but can lead to unexpected behaviour of an
implementation. This result is vaguely similar to what happens when
a switch() statement lacks a default: case and is unexpectedly faced
with a value that is not covered by case statements. The result
can be "undefined" / "unpredictable", yet remain formally provable
correct with respect to the given specification.
Finally, there are "omissions" in a spec, i.e. properties that a
protocol does and can not provide, yet consumers of the protocol may
believe in "magic security pixie dust" and develop a flawed assumption
about a non-existing protocol property, as it happened in with the
TLS renegotiation. TLS renegotiation being secure/protected against
MitM was a property that was retrofitted into SSLv3/TLS with rfc5746,
and could not possibly have existed "by accident" in any of the existing
implementations. (Although servers that did not support renegotiation
at all never were vunerable to the "interesting" attacks.)
-Martin