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

["Bless, Roland (TM)" <[e-mail]>]

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