Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt

Toerless Eckert <tte@cs.fau.de> Fri, 15 July 2022 04:18 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCBC16ECF5 for <architecture-discuss@ietfa.amsl.com>; Thu, 14 Jul 2022 21:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.66
X-Spam-Level:
X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdOy9jrN4HV5 for <architecture-discuss@ietfa.amsl.com>; Thu, 14 Jul 2022 21:18:57 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA44C16ED18 for <architecture-discuss@ietf.org>; Thu, 14 Jul 2022 21:18:55 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id A534B58C4AF; Fri, 15 Jul 2022 06:18:48 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8DB8C4EB47A; Fri, 15 Jul 2022 06:18:48 +0200 (CEST)
Date: Fri, 15 Jul 2022 06:18:48 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: "Bless, Roland (TM)" <roland.bless@kit.edu>
Cc: Martin Thomson <mt@lowentropy.net>, "Joel M. Halpern" <jmh@joelhalpern.com>, architecture-discuss@ietf.org
Message-ID: <YtDqqGlwVGdJ0uLi@faui48e.informatik.uni-erlangen.de>
References: <a06000c5-939a-a896-9c0f-576e9e2ff97f@gmail.com> <D20FCDD6-3756-40E7-AD6A-416A2C464DF1@gmail.com> <dbee51f0-1913-af6e-de00-c3a7f5b77f68@gmail.com> <6723979f-c496-43e1-a389-a50dd3af2224@beta.fastmail.com> <ade079ff-b8b4-76ab-626c-e74f99229205@joelhalpern.com> <0bdc5d0f-2411-4797-b116-d46643d21746@beta.fastmail.com> <e7bacfeb-e6f2-99d7-c0fa-d9067e7e4bd4@kit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <e7bacfeb-e6f2-99d7-c0fa-d9067e7e4bd4@kit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/1IFtV-SoTNDdJ8DnysEBALdmdd4>
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-08.txt
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jul 2022 04:18:59 -0000

On Thu, Jul 14, 2022 at 11:09:09PM +0200, Bless, Roland (TM) wrote:
> Your draft says:
> "Time and experience shows that negative consequences to interoperability
> accumulate over time if implementations apply the robustness principle. This
> problem originates from an assumption implicit in the principle that it is
> not possible to effect change in a system the size of the Internet. It
> assumes that once a protocol specification is published, changes that might
> require existing implementations to change are not feasible."

If i understand Martins draft argument correctly, then it is somewhere
around the lines that an underspecified protocol is bad and can not
simply excuse itself by saying "just add the robustness principle to
fill in the gaps". And the reason for that is that the robustness
principle itself is underspecified. It forgets to mention that
there is no guaranteed interoperable result when different implementers
apply it against the same spec.

If that is about right, then maybe text like that previous sentence would
help make it clearer what the intention of the text in Martin's draft is.
Otherwise it is either me being too stupid to be an approved reader of
the draft, or the draft is underspecified for me to understand it.

In any case, we (IETF) are a lot more authoritative to drive better
specifications than better implementations, so this whole discussion
even into this degree of nitpicking is hopefully useful to our work
product in the future and not just thought inspiring for those who
like to quarrel about it.

Cheers
    Toerless