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

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 07 May 2019 22:54 UTC

Return-Path: <hgs10@columbia.edu>
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 D8FFB1202B7 for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 15:54:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 OtMUE1mD_VP4 for <ietf@ietfa.amsl.com>; Tue, 7 May 2019 15:54:31 -0700 (PDT)
Received: from outprodmail02.cc.columbia.edu (outprodmail02.cc.columbia.edu [128.59.72.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7855512027C for <ietf@ietf.org>; Tue, 7 May 2019 15:54:30 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x47MqjCJ014666 for <ietf@ietf.org>; Tue, 7 May 2019 18:54:28 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 913366D for <ietf@ietf.org>; Tue, 7 May 2019 18:54:28 -0400 (EDT)
Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 47D6285 for <ietf@ietf.org>; Tue, 7 May 2019 18:54:26 -0400 (EDT)
Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x47MsPup042657 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ietf@ietf.org>; Tue, 7 May 2019 18:54:26 -0400
Received: by mail-oi1-f199.google.com with SMTP id m207so6472712oig.4 for <ietf@ietf.org>; Tue, 07 May 2019 15:54:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0ivDN1gtgM8qOb/1RWMBeELaUp81VzUXJyNuFz+YK4I=; b=bpwdmUxuFlY0rBcA4s+wqgnE4aj/Nxut+GnRvypFtEmwPtQJ2UOfaw/r+SWJDt4lfg wK6/O+5rFQtbMGwO29S+bB4e898w7EQeVS7716SGm/0yhz3k1PR7aba9OvYHozvWqF79 FHAbWszLxOdieSenMurT7KIWew6ZsnP5v6Fj1ZeEhbyaaouCWCS4yFT58VmaPdHwt5C8 hH25IyrKZMV3Fxe82hiDxurASSE1mjeBcorm9102GsFZdH7eX0+rzHA1ZQRWb4dJsves b+I9P+xTGyNhJXhWVxnaVd+FH5Q6VFvA6BW1+UBWbtlHPjM+FDhVZaY0CyckJcTmPnK0 IgnA==
X-Gm-Message-State: APjAAAUy/n/cD83wkxiHzgLQjpLr2Gve9s8JWFLXlEt5AvUsOE3om7Xh MCKM3oungfQt++7F2bsf20BQ+jRGh+zdXayzoziVa4MJIJ9sOnflRLIi/APK6rL8zD0pFr4q6rN /j4XdIEpUYMA+75akagEn1wC6x6JD
X-Received: by 2002:aca:ec0f:: with SMTP id k15mr32533oih.43.1557269665442; Tue, 07 May 2019 15:54:25 -0700 (PDT)
X-Google-Smtp-Source: APXvYqzN1E6XCXN6/N9SzBSWRFJ2fFytPF5BA1LehAJpq32euEUFiTFat8ec2meEKXM8JfjknnI4JS5LKdK+uXOuLXs=
X-Received: by 2002:aca:ec0f:: with SMTP id k15mr32519oih.43.1557269665055; Tue, 07 May 2019 15:54:25 -0700 (PDT)
MIME-Version: 1.0
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <CAA=duU1TxZx9W8huPp5md25Wf+9=f50WYGpU=Bb1OQ+OdF6k6A@mail.gmail.com> <CACgrgBYs95Q4hb=y-6i7SW9mEx9Bg-gp0TrpAYpsP-aODSx+YA@mail.gmail.com> <eb979c24-e9d2-4ebb-1d4b-94b8c9aa16e1@huitema.net>
In-Reply-To: <eb979c24-e9d2-4ebb-1d4b-94b8c9aa16e1@huitema.net>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Tue, 07 May 2019 18:53:59 -0400
Message-ID: <CACgrgBahawkXbyXoYHbwYSkfCG9zxn6M8jgwswDpcFjfZVcffw@mail.gmail.com>
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
To: Christian Huitema <huitema@huitema.net>
Cc: "Andrew G. Malis" <agmalis@gmail.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, Barry Leiba <barryleiba@computer.org>, "ietf@ietf.org" <ietf@ietf.org>, "iab@iab.org" <iab@iab.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000349b3f05885419d2"
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.84 on 128.59.72.14
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7juOybzagqOlqy1I-tYXWDAsWYI>
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: Tue, 07 May 2019 22:54:40 -0000

It's kind of the inverse robustness problem - lots of perfectly-well
documented protocol features are not usable in practice since they break
"lazy", but important, implementations. The SIP crowd will remember the
endless discussions about MIME multipart.

In those cases, it would probably be wise to simply declare that a
well-intentioned feature is no longer recommended for new implementations
and possibly look for alternative options. (We seem to get into the
circular arguments of "We need X", "use standard mechanism M to do X", "but
none of the major implementations do M and are unlikely to in the
foreseeable future", "but we cannot have two ways to do X and M is actually
a better idea"; wait two years; repeat. Alternative: people develop a
kludge that kind of works.)

The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to
catch this, but that process protocol path obviously was also rarely
exercised.

Henning


>
> And then for a counter example, also related to IPv6. The IPv6 specs
> allows implementations to insert a variety of intermediate headers
> between the IPv6 header and the transport packet, but many router
> implementations just don't like that and slow down or drop packets if
> such intermediate routers are present. A case where the spec is arguably
> too permissive, or the implementations too strict.
>
> -- Christian Huitema
>
>