IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Thu, 09 May 2019 11:02 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 6AF8012001B; Thu, 9 May 2019 04:02:10 -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 K9sc4MXwPu5T; Thu, 9 May 2019 04:02:06 -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 5A0F9120096; Thu, 9 May 2019 04:02:06 -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 4509Qg747yzyYW; Thu, 9 May 2019 13:02:03 +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: <E7769BC3-472E-4161-85C9-E534C9E393EC@cisco.com>
Date: Thu, 09 May 2019 13:02:06 +0200
Cc: The IESG <iesg@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>, "ietf@ietf.org" <ietf@ietf.org>
X-Mao-Original-Outgoing-Id: 579092524.598793-07e700d4ae0b5aedccf8ebd69cc2d082
Content-Transfer-Encoding: quoted-printable
Message-Id: <161AB266-8DFE-49BF-8045-412A3844C9EF@tzi.org>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <DBD4837F-299B-497C-8922-AFF858B06C0F@strayalpha.com> <EDB037CE-F16A-4392-B36C-F44E30F29753@tzi.org> <E7769BC3-472E-4161-85C9-E534C9E393EC@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Q5G2QJa_xK9JX0LaHcl8yPQIr88>
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 11:02:10 -0000

On May 9, 2019, at 11:34, Eliot Lear <lear@cisco.com> wrote:
> 
> technical deficit

I think we were discussing Technical Debt.

https://en.wikipedia.org/wiki/Technical_debt

The term is widely used to describe code bases in software development that, through lack of oversight, have acquired properties that make them hard to move forward (or even fix).
It doesn’t quite transfer to protocols, because here it is often different parties that incur the debt and that ultimately have to pay it up.

A protocol that has turned into soup has acquired technical debt.
It is very hard to pay back that debt: that requires coordinated effort throughout the ecosystem.  It occasionally can be done, but these are the hero stories of our time.

Grüße, Carsten

v2.23.0 | Report a Bug | By Email