In message <be856ef3-7bef-244e-bf94-b0af1f1ba99b@xxxxxxxxxxx>, 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@xxxxxxx