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

Carsten Bormann <cabo@tzi.org> Thu, 09 May 2019 06:24 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0659B120108 for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 23:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gcxjcF0Ar3n for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 23:24:53 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0CA120052 for <ietf@ietf.org>; Wed, 8 May 2019 23:24:52 -0700 (PDT)
Received: from [192.168.217.106] (p54A6CC75.dip0.t-ipconnect.de [84.166.204.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPSA id 4503Gn5sNVzyW6; Thu, 9 May 2019 08:24:49 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <266adfd4-6eec-46cb-9c62-36735db9bd24@www.fastmail.com>
Date: Thu, 09 May 2019 08:24:49 +0200
Cc: IETF Discussion Mailing List <ietf@ietf.org>, Colin Perkins <csp@csperkins.org>
X-Mao-Original-Outgoing-Id: 579075887.271405-001210fb5fd6a8f83581291cad33fcf6
Content-Transfer-Encoding: quoted-printable
Message-Id: <A07C275B-DABC-4FBE-B9E9-8EC89740C7FD@tzi.org>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <CAHw9_iKE9SSOK_9AUpoMaS9pGz91LuJr1_HNv0B-6RxT_rb2dw@mail.gmail.com> <BA365F84-3BD8-4B6B-B454-B32E4B6B6D23@piuha.net> <99FE5EE91CE738A39D99CAC2@PSB> <266adfd4-6eec-46cb-9c62-36735db9bd24@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/y4vQqR4lMALwKonIBPYwnxxVn2Q>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 06:24:55 -0000

Hi Martin,

A hearty +1 to most of what you wrote.  Many IETFers now understand that it is important to prevent protocols from degenerating into soup, and we may be unique as an organization by actually started making that a part of our culture.  We should continue on this trajectory.

I think there is one detail missing from this dilemma:

>> — trying to specify every possible detail […]
>> — specifying the normal cases and general philosophy […]

In some parts of the specification, we actually can achieve the former without loss of the latter: Where we have formal description techniques (FDT) that are actually *usable*.

Admittedly, we are as far away from covering whole protocols with usable FDTs as we were 30 years ago when the misapplication of FDTs helped OSI fail.  But for those narrow parts where we have made progress, we should be embracing those usable FDTs, and should actively work on capability building.  We can already achieve good coverage of some areas where many implementation bugs previously tended to lurk.  And FDTs can be an effective bulwark against soupification.

Extending the (usable) reach of FDTs is research, and the new IRTF chair, Colin Perkins, has mentioned that FDTs are high on his agenda.  For IETF use, usability is key; as you say, a thousand pages of assembly language level detail without a big picture visible doesn’t cut it, and I’d add that is true independent of whether the “assembly language” is presented in stylized English or in an unusable FDT.

Grüße, Carsten