Actually, no, similar holdups do not occur for concerns of error-handling.
Examples:
in DTNRG (which, though IRTF, is highly relevant, being chaired as it is by the
now security AD):
- LTP was developed with no error detection: RFC5326. Managed to get some
shoehorned in at
the last moment in the NULL bits of RFC5237, but that was not a holdup.
- the bundle protocol was developed with no error detection, and no following
of the
end-to-end principle. That took ten years or so, a lot of researchers, a
national space agency...
but in DTNRG, security was paramount in the design (and focused on by the
chairs). Those are the results.
The judgement calls come down in favour of security concerns above all else.
In the IETF:
RFCs 6935 and 6936, which relax the endpoint payload and pseudoheader check by
allowing zero checksums in IPv6, because tunnelled payloads with their own
checks
just don't need it. (That other applications do because IPv6 itself is lax on
reliability checks, has no header-only check and the closest it would get to an
endpoint
header check would be UDP-lite, and the applications can be polluted by
mis-arriving
errored zero-checksum UDP packets, is neither here nor there. This is arguably
the
predictable outcome of some poor design decisions in IPv6 twenty years ago.)
I'd welcome counterexamples where errors forced a holdup and rethink. I know of
none.
We're heading into a world where security is paramount, and the only reason we
have
any reliability in protocols at all is as a sideeffect of the security
rejecting perceived attacks,
and not because we actually know how to design error-rejecting protocols. (How
many
people here could design a CRC? How many design secure systems?)
There will be no further internet engineering (which, given that 6935/6936 are
proposed standards, never mind the horse-designed-by-committee IPv6 camel,
may actually not be a bad thing); any internet engineering done, or any
reliability obtained in implementations, will just be an unintended sideeffect
of security as a discipline.
Lloyd Wood
http://about.me/lloydwood
http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
________________________________________
From: Tim Bray [tbray(_at_)textuality(_dot_)com]
There are very few (any?) absolutes in any of the protocols we build, just a
wealth
of often-conflicting design criteria, which force us to trade off and make
judgment calls.
draft-perpass-attack says that mitigation of pervasive surveillance should
be seen as
one of the design criteria, and it’s not OK to ignore it. A reasonable take
is that a specification
could be held up if there are plausible arguments that this criterion has not
been given appropriate
consideration, and I see nothing wrong with that. Similar hold-ups regularly
occur when there are
concerns that there hasn’t been appropriate consideration for efficiency or
error-handling or, well, lots of other criteria.