Hi, Am 08.05.19 um 07:26 schrieb Carsten Bormann: > 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. +1 I think that the interpretation of the Postel principle in https://tools.ietf.org/html/draft-iab-protocol-maintenance-03 is somehow too rigid. I always understood it in the way it is described in RFC 1122: Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. and: Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure. The latter paragraph shows that the Postel principle tries to ensure extensibility. The "be liberal" part in reception mainly refers to implementation robustness, whereas the "send conservatively part" mainly to interoperability. I remember a case where ATM switches were not able to setup a connection because one switch required a specific option (that was non-mandatory) for setup whereas the other one did not understood and accept the option. A more conservative switch implementation would not have sent the option and a more liberal switch implementation would have ignored the non-mandatory option. I think that a major point of the draft draft-iab-protocol-maintenance-03 is mentioned in section 3: An implementation that reacts to variations in the manner recommended in the robustness principle sets up a feedback cycle. Over time: o Implementations progressively add logic to constrain how data is transmitted, or to permit variations in what is received. o Errors in implementations or confusion about semantics are permitted or ignored. o These errors can become entrenched, forcing other implementations to be tolerant of those errors. The second bullet is not a consequence of the Postel principle. In the example above: such errors could be caught by corresponding log messages and should be discussed in interoperability tests, i.e., they should NOT be silently ignored by developers. Usually, this should support the process of discovering parts of the specification that are ambiguous. Again, the Postel principle does not require to completely ignore these problems: they should be used as feedback for improving the specification. Regards Roland
