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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, all,

...
>   Title           : The Harmful Consequences of
>         Postel's Maxim
> https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01
I completely agree with John Klensin that a test suite defines the
protocol standard (warts and all).

However, I disagree with the characterization of the Postel Principle in
this doc, and strongly disagree with one of its key conclusions ("fail
noisily in response to...undefined inputs"). Failing in response to bad
inputs is fine, but "undefined" needs to be treated agnostically.

IMO, the Postel Principle is an admission of that sort of agnosticism -
if you don't know how the other end will react, act conservatively. If
you don't know what the other end intends, react conservatively. Both
are conservative actions - in one sense, you try not to trigger
unexpected behavior (when you send), and in another you try not to
create that unexpected behavior (when you receive).

That's the very definition of how unused bits need to be handled. Send
conservatively (use the known default value), but allow any value upon
receipt.

The principle does not setup the feedback cycle in Sec 2; a bug is a bug
and should be fixed, and accommodating alternate behaviors is the very
definition of "be generous in what you receive". "Being conservative in
what you send" doesn't mean "never send anything new" - it means do so
only deliberately.

-----
Failing noisily is, even when appropriate (e.g., on a known incorrect
input), an invitation for a DOS attack.

That behavior is nearly as bad as interpreting unexpected (but not
prohibited) behavior as an attack. Neither one serves a useful purpose
other than overreaction, which provides increased leverage for a real
DOS attack.

Joe




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]