I'm glad to hear that this works, at least when there are resources available to do all the things you did (test site, coordination, outreach, ...). I think it would be helpful if the draft could point to such examples, and maybe failed examples, of how to get out of the bad-liberalism condition. I suspect that this is workable where the dominant implementations are open source and where the open source developers maintain close ties to the IETF community. Maybe we do need a protocol police in the IETF :-) ("Sir, do you know that you didn't signal properly?")
Henning
On Tue, May 7, 2019 at 7:52 PM Mark Andrews <marka@xxxxxxx> wrote:
The fix for that is to implement the new feature and get customers to log
bug reports against the other implementation. It does work. Even Fortune
500 companies listen to their customers.
Implementations can be fixed and with regular update mechanisms in place
the fixes do get deployed.
In early 2018 the open source DNS vendors declared a flag day on Feb 1, 2019.
We where no longer going to treat timeout as “the server doesn’t understand EDNS”.
I.e. we where intending to deliberately break interoperation with servers that
where stuck in the last century. We set up a site where you could test your
servers to see if your servers where broken. We also had that site report
a whole lot of other EDNS protocol violation. You got RED if there was a
fatal fault, ORANGE if any other fault was detected and GREEN if the server
passed the test queries. The number of sites which would get RED was << 1 in
10000.
We advertised this flag day, in a number of places. The testing server got
overwhelmed and DNS vendors with broken servers got thousands of “this
site says your product is broken, when are you going to fix it” complaints.
Implementations got fixed and the fixes got deploy. This included firewall
vendors fixing their default blocking rule.
https://ednscomp.isc.org/ has lots of graphs which show failures of various
populations of servers and how things changed in the lead up to Feb 1 and
later fixes being released and deployed. In particular
https://ednscomp.isc.org/compliance/ts/au.optfail.html show Microsoft fixing
their servers (see the “echoed” line). The Jan 28 was when they fixed their
Azure service. The drop around April 11 is when fix pushed out in the March
patch Tuesday release started to take effect.
The March 1 failure spike was when one of the links from the testing site
started dropping DNS UPD packets but passed DNS TCP packets. It took a
couple of days to track down the bad (wrong style for the conductor) RJ48
connector that caused that failure.
> On 8 May 2019, at 8:53 am, Henning Schulzrinne <hgs@xxxxxxxxxxxxxxx> wrote:
>
> It's kind of the inverse robustness problem - lots of perfectly-well documented protocol features are not usable in practice since they break "lazy", but important, implementations. The SIP crowd will remember the endless discussions about MIME multipart.
>
> In those cases, it would probably be wise to simply declare that a well-intentioned feature is no longer recommended for new implementations and possibly look for alternative options. (We seem to get into the circular arguments of "We need X", "use standard mechanism M to do X", "but none of the major implementations do M and are unlikely to in the foreseeable future", "but we cannot have two ways to do X and M is actually a better idea"; wait two years; repeat. Alternative: people develop a kludge that kind of works.)
>
> The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to catch this, but that process protocol path obviously was also rarely exercised.
>
> Henning
>
>
> And then for a counter example, also related to IPv6. The IPv6 specs
> allows implementations to insert a variety of intermediate headers
> between the IPv6 header and the transport packet, but many router
> implementations just don't like that and slow down or drop packets if
> such intermediate routers are present. A case where the spec is arguably
> too permissive, or the implementations too strict.
>
> -- Christian Huitema
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
