Re: [arch-d] deprecating Postel's principle- considered harmful

[Henning Schulzrinne <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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: [phone]              INTERNET: [e-mail]
>
>