ietf
[Top] [All Lists]

Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

2017-06-15 20:07:32

In message <be856ef3-7bef-244e-bf94-b0af1f1ba99b(_at_)huitema(_dot_)net>, 
Christian Huitema writes:
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
On 6/15/2017 11:28 AM, Bob Hinden wrote:
p.s. The file name chosen for this draft appears to be a good example
of stepping on the toes of those who came before, instead of standing on
their shoulders.  See: http://wiki.c2.com/?ShouldersOfGiants

On the other hand, there is something to be said for "being nice
considered harmful".

Martin describes a very real failure mode. Implementations deviate from
the standard, gain market share as the deviations are happily tolerated,
and then prevent standard evolution that would contradict their own
"extensions". Martin gives examples of that happening with JSON.

Or, implementations fail to properly implement the extension mechanism
specified in the standard, and then prevent deployments of perfectly
good options. The slow deployment of early congestion notification comes
to mind.

DNS and EDNS fall into this category.  The AD bit in responses can't
be trusted as there are servers that just echo back (formally)
reserved bits.  STD 13 says these bits MUST be zero.

Then there are all the servers that fail to do EDNS version negotiation
correctly.  They talk EDNS but ignore the version field or return
FORMERR rather than the specified BADVERS error code. etc.  About
half the servers we have tested get EDNS version negotiation wrong
in one way or another.

When we tighted the unknown EDNS option behaviour (RFC 6891, RFC
2671 under specified the behaviour) updating the EDNS version field
would have been appropriate but we couldn't do this due to the level
of poor implementation of EDNS version negotiation and idiotic (yes,
name calling is appropriate) default firewall rules from multiple
vendors that dropped any EDNS request with a version field that
wasn't 0.

Mark
--
Christian Huitema

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka(_at_)isc(_dot_)org

<Prev in Thread] Current Thread [Next in Thread>