Re: [arch-d] deprecating Postel's principle- considered harmful
Henning Schulzrinne <hgs@cs.columbia.edu> Wed, 08 May 2019 13:58 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 3D5F812011C for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 06:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 tgWA38ZkpNIt for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 06:58:48 -0700 (PDT)
Received: from outprodmail01.cc.columbia.edu (outprodmail01.cc.columbia.edu [128.59.72.39]) (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 2FA92120026 for <ietf@ietf.org>; Wed, 8 May 2019 06:58:47 -0700 (PDT)
Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by outprodmail01.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x48DwTta055479 for <ietf@ietf.org>; Wed, 8 May 2019 09:58:46 -0400
Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id D6673A1 for <ietf@ietf.org>; Wed, 8 May 2019 09:58:46 -0400 (EDT)
Received: from sendprodmail02.cc.columbia.edu (sendprodmail02.cc.columbia.edu [128.59.72.14]) by hazelnut (Postfix) with ESMTP id 377569F for <ietf@ietf.org>; Wed, 8 May 2019 09:58:41 -0400 (EDT)
Received: from mail-oi1-f200.google.com (mail-oi1-f200.google.com [209.85.167.200]) by sendprodmail02.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id x48DwegI024379 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <ietf@ietf.org>; Wed, 8 May 2019 09:58:41 -0400
Received: by mail-oi1-f200.google.com with SMTP id x193so2373452oix.1 for <ietf@ietf.org>; Wed, 08 May 2019 06:58:40 -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=ode9IDoqI4YqIHKU55UTLaXKUKIVWOuUeLUbdUic9iU=; b=XHjRnn9Zz08cMuLP1+jttlYcWb05IuI6BVVv+2i+pfzg4tQ0nF82NsRTctud555xum j6hC9PZny8IXw6qyGtTR072L69yfs45abVO6nsMX+R2/j8WMWu2U9FTUCYiaFigWwyg4 wrHw98cajZV7lODQJj8UunG3XVybcZ+BNWXeGNCkhQ6iWSG7rLI2VpakxvhyTd/5jQJa LPQG4BxyQCug+uxCuQ4KDTNCo3YFWIOZlPYp+7oLN7/aE/nNQIxwre6JgGYyLFXfW/rG g6t5XKcfiVcNJrOjVvZ0E4M7ZwRpfYcUZj5bf5zweG/9OrOnvVc4NAfs65PiDoUJ5f+u s2fg==
X-Gm-Message-State: APjAAAVersYNIZSckTMEkAA6aGDRbsDtLxfb1EcF7CKpt3xg2lUr7Z8B 7N7kvQ2Z4VxKrmdl5LADG7T5P8xTtN3k2Z0+gtfdSQd2NJm3SKwMPA6pzULnxYL8M7AEHoXNvi/ otiVIrXpS4dchZKAWKKhwoA9GzZn6
X-Received: by 2002:aca:f5d5:: with SMTP id t204mr1138987oih.137.1557323920376; Wed, 08 May 2019 06:58:40 -0700 (PDT)
X-Google-Smtp-Source: APXvYqz/JEPeQNCRjpXIcvEuFwKypbs4TuzbYmD5C5ktT+nEzC1A3VBpxlYn+yqUrIZ/9JCsah3fTKBVsXXFfH+zZ7M=
X-Received: by 2002:aca:f5d5:: with SMTP id t204mr1138949oih.137.1557323919469; Wed, 08 May 2019 06:58:39 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BA365F84-3BD8-4B6B-B454-B32E4B6B6D23@piuha.net>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Wed, 08 May 2019 09:58:12 -0400
Message-ID: <CACgrgBYBW9zi+jzdGK55aQUa36UK669A2an6gm=Tm=fxDgP68A@mail.gmail.com>
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
To: Jari Arkko <jari.arkko@piuha.net>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, Warren Kumari <warren@kumari.net>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000054307058860bb1d"
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/hNVEoG0FI7EPkDy3MJ_hXS5A19w>
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: Wed, 08 May 2019 13:58:50 -0000
To a different degree, the security community has struggled with this in the "responsible disclosure" discussion. The incentives are different, but there seem to be three best practices that might generalize: (1) a well-documented mechanism to reach the right part of the organization, beyond the general support mechanism; (2) a reasonable time period to address the problem; (3) public disclosure after that time period. A related problem is that it is often difficult for developers to get advice and help. If they are lucky, they find the IETF mailing list, but it may no longer be active or such questions may be seen as out-of-scope. We had the sip-implementors@ list for a while, and it generally seemed helpful. But this requires somewhat-experienced people willing to help relative newbies and does not scale well. Interop events (plugfests and the like) are also helpful, particularly if these include torture tests. Henning On Wed, May 8, 2019 at 7:38 AM Jari Arkko <jari.arkko@piuha.net> wrote: > I find myself agreeing with many of the posts, but maybe Warren put it > most nicely and compactly: "The principle should be applied judiciously > (sometimes it isn't), not discarded." > > And having seen some of the too-big-to-demand-compliant-interoperability > situations that Paul and others mention, I’ve also felt the pain :-) > > I find it interesting to compare the situation to analogue situations in > other kinds of systems. For instance, I always like to program in defensive > style, where my software is as brittle as possible to catch errors. Yet, > for delivered software, one often switches to maximum survivability, and > often your software components can at least attempt reasonable recovery > from many situations that shouldn’t have occurred. More modern software > development practices combine development with monitoring, feedback, > instrumentation, tracking of new versions in small populations before > enlarging their usage, etc. That is kind of a best of both worlds setup, > because you can make things survivable but you’ll be receiving real-time > feedback on what’s actually happening in the field, and can take corrective > action. > > This is obviously usable also in our protocol world, but there’s a > problem. You can quite easily get a lot of feedback on your own thing > working well. You can also get feedback about who you are having problems > with. But it isn’t easy to send that feedback to where it might actually > belong in many cases: the other implementation’s maintainers. Disconnecting > or 4xxing is the crudest form of signal. Yes, sometimes effective. But it > also an action between two parties (me as an implementor of my thing and > you as an implementor of the peer) that hurts a third party: the user. > > I wish there was some other option between the silent obedience and the > refusal to talk. But I don’t know what it could be. > > Jari > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >
- RE: deprecating Postel's principle- considered ha… BRUNGARD, DEBORAH A
- Re: deprecating Postel's principle- considered ha… Barry Leiba
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Brian E Carpenter
- Re: deprecating Postel's principle- considered ha… Andrew G. Malis
- Re: [arch-d] deprecating Postel's principle- cons… Barry Leiba
- Re: deprecating Postel's principle- considered ha… Warren Kumari
- Re: [arch-d] deprecating Postel's principle- cons… Tony Li
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: deprecating Postel's principle- considered ha… Adam Roach
- Re: deprecating Postel's principle- considered ha… Salz, Rich
- Re: deprecating Postel's principle- considered ha… Joel M. Halpern
- Re: deprecating Postel's principle- considered ha… Adam Roach
- Re: [IAB] [arch-d] deprecating Postel's principle… Christian Huitema
- Re: [IAB] [arch-d] deprecating Postel's principle… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Matthew Kerwin
- Re: [arch-d] deprecating Postel's principle- cons… Rich Kulawiec
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] [IAB] deprecating Postel's principle… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Randy Presuhn
- Re: [arch-d] deprecating Postel's principle- cons… Christian Huitema
- Re: [arch-d] deprecating Postel's principle- cons… Brian E Carpenter
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Mark Andrews
- Re: deprecating Postel's principle- considered ha… Martin Thomson
- Re: [arch-d] [IAB] deprecating Postel's principle… Randy Bush
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… Masataka Ohta
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: [arch-d] deprecating Postel's principle- cons… Jari Arkko
- Re: [arch-d] deprecating Postel's principle- cons… John C Klensin
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Phillip Hallam-Baker
- Re: deprecating Postel's principle- considered ha… Paul Wouters
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: deprecating Postel's principle- considered ha… Dave Cridland
- Re: [arch-d] deprecating Postel's principle- cons… Bless, Roland (TM)
- Re: deprecating Postel's principle- considered ha… Paul Wouters
- Re: deprecating Postel's principle- considered ha… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… John Levine
- Re: [arch-d] deprecating Postel's principle- cons… Keith Moore
- Re: deprecating Postel's principle- considered ha… Brian E Carpenter
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Keith Moore
- Re: deprecating Postel's principle- considered ha… John C Klensin
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Stephen Farrell
- Re: [arch-d] deprecating Postel's principle- cons… Joe Touch
- Re: [arch-d] deprecating Postel's principle- cons… Martin Thomson
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… S Moonesamy
- Re: [arch-d] deprecating Postel's principle- cons… Lloyd Wood
- Re: [arch-d] deprecating Postel's principle- cons… Eliot Lear
- Re: [arch-d] deprecating Postel's principle- cons… Carsten Bormann
- Re: [arch-d] deprecating Postel's principle- cons… Eliot Lear
- Re: [arch-d] deprecating Postel's principle- cons… Joel M. Halpern
- Re: [arch-d] deprecating Postel's principle- cons… Bob Briscoe
- Re: [arch-d] deprecating Postel's principle- cons… Phillip Hallam-Baker
- Re: [arch-d] deprecating Postel's principle- cons… Masataka Ohta
- Re: [arch-d] deprecating Postel's principle- cons… Aaron Falk
- Re: [arch-d] deprecating Postel's principle- cons… Henning Schulzrinne
- Re: [arch-d] deprecating Postel's principle- cons… Henry S. Thompson