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

[Eliot Lear <[e-mail]>]

I like Martin’s draft, although I would frame things a bit differently.

There is an aspect of maturity to all of this.  Martin’s experience is with web-related protocols that are largely mature.  In those cases, it simply is not possible for FF/Chrone/… to accommodate most errors or ambiguities because the code path is already quite complex and represents a large attack surface.  I view QUIC largely as an evolution of the existing well known system.

On the other hand, early work is quite difficult to nail down.  Getting something to work at all requires Postel’s principle.  That’s not a matter of programmer or spec writer laziness, but simply a matter of lack of experience everyone’s part.

Let’s not emotionally claim that protocol immaturity introduces a “technical deficit”.  The bell telephone standard arguably had no technical deficits for what it delivered, but it delivered bubkas compared to what we have today, “deficits" and all.

In the next rev, what would be good to see is how and when the principle should be applied, and the other principles that may also conflict with or limit this one.

Eliot

> On 8 May 2019, at 07:26, Carsten Bormann <[e-mail]> wrote:
> 
> Like the end-to-end principle, the robustness principle is one of the most misunderstood, misapplied design principles in networking.  That doesn’t make either principle wrong, it just seems they need good explanations.  Documenting the results of misapplying the robustness principle (including the degenerated end state that I call “soup”) is a good thing, but should be done under the correct heading.  “Deprecating” it is not.
> 
> Grüße, Carsten
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss