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

Bernard Aboba <bernard.aboba@gmail.com> Wed, 13 November 2019 00:33 UTC

Return-Path: <bernard.aboba@gmail.com>
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 00004120130 for <architecture-discuss@ietfa.amsl.com>; Tue, 12 Nov 2019 16:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XxOwUC_DKsAH for <architecture-discuss@ietfa.amsl.com>; Tue, 12 Nov 2019 16:33:36 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731A51200B5 for <architecture-discuss@ietf.org>; Tue, 12 Nov 2019 16:33:35 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id z188so369093lfa.11 for <architecture-discuss@ietf.org>; Tue, 12 Nov 2019 16:33:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7I943FELD27quGbwgyj8EEJuC/gJQqzyV2CZ0kWadrE=; b=A70SfUylk16KXhsX8MTxo/HmFbYkGQSZEJYJ9n9qN4Kle+OZ1glmy2ozx3Xcd+2fA6 yPR/EaBvmB1j1ASkFGx2kz75097wTRL1K9xkatGGXhdRSLiVOh3f3IJ15GMSZe5n4heg /V3uKEWB0R02X5GTT3kO4XfC013Ssd5SySWSYLTZ5HU9h/qh3uITkdwJdk+OhGdAFg41 hZXrwTIy1dw3Mhak02q6bKgSHWNfzL1ftMqlHClprz0M7JWO6dzFZRQep1JOFaksHjkb VmcvNHZpUTJajDg9hUVTT1W3+5onubXDW75CG9o4BO0/p3VE/vvQCmYFWs/tlZ3cajdp luDw==
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=7I943FELD27quGbwgyj8EEJuC/gJQqzyV2CZ0kWadrE=; b=L0KhmT0c+h0qniTh3uFRRk+cU7eviSq5BloPr00WYJsc3CslNfvFbN7kTcfMuRchX7 A9XVnrEePgxunv0RqI6I/qPchJ4wuESZIkR50jR8irIZDYie054UfqAGsh6sA37MDaT5 VJZsuMgnMNsHZuCA7/oYMnn7rpLHcBhHUaLJZBRy45XEb/6H10r1FJau3Dc+lp9ilRyb uZbZH8osMZcNQC684Hf055+avl4Ris7OvKzhBfXsz9tScLBjsfWgq0jzezRtd+3PlnyX C0z+U67caOKNawIWHSsLKPGKzNS5FKsGD555BHJ7RdM0bDz9J8diDiqgYUvvodwh5MrG IRdA==
X-Gm-Message-State: APjAAAU2Llyyg4X9uk7omhpyMzbdKjiiZ3r+l7M60EnB3Sl5iPvhtmVV YneZH0azQ1/ood5AshZh4zokotKlPgd+whFNoaI=
X-Google-Smtp-Source: APXvYqwg2qkpA4f6Yvu0dKCvu3B0rNjbbFjBCV6yDTQfFVTcORuSM4oi4GxvMBQ9KSEI4X1PZCg4JbykryPDyMGThig=
X-Received: by 2002:a19:48cf:: with SMTP id v198mr380380lfa.59.1573605213195; Tue, 12 Nov 2019 16:33:33 -0800 (PST)
MIME-Version: 1.0
References: <157284936054.13440.20144182660413459@ietfa.amsl.com> <d6c4e7b7-1a43-7859-427a-35ebf1343fcf@gmail.com>
In-Reply-To: <d6c4e7b7-1a43-7859-427a-35ebf1343fcf@gmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 12 Nov 2019 16:33:22 -0800
Message-ID: <CAOW+2duvc21ss5cxXM1Kr94HW3Fpn5nOYu=6-ySzOJUYTwG3CA@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: IAB IAB <iab@iab.org>, architecture-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bfcfff05972f83a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/7S2IvESRo1L_rxKdgVe5D4ZTvdw>
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Nov 2019 00:33:41 -0000

Brian said:

">    For a protocol
>    that is actively maintained, the robustness principle can, and
>    should, be avoided.

To be blunt, I don't think there is community consensus for this
statement. "

[BA] Actually, I don't think you are being blunt enough.

The robustness principle is *fundamental* to the operation of the Internet,
which is about the interconnection of vast numbers of disparate
implementations.  With such diversity (and with the increasing complexity
of protocol specifications) it is inevitable that interoperability problems
will arise frequently.  The robustness principle says "regardless of
whether your interpretation of the specifications is the "right" one" - get
over yourself and make it work.

The idea that "the robustness principle should be avoided" sounds like
something that would belong in a modern remake of a 1960s movie by Stanley
Kubrick:

"Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb"
We could rename it "Dr. NoPackets or: How I Learned to Stop Worrying and
Love Loss of Connectivity"

Brian also said:

"Now the IAB can of course express an opinion, but for something as
contentious as this, I think it needs to be labelled
as an opinion statement"

[BA]  You are being far too kind here.  This is an opinion that just can't
be taken seriously.  Are we sure that it wasn't intended for publication on
April 1?

On Mon, Nov 4, 2019 at 5:13 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Hi,
>
> Thanks for the updates, but I still have concerns about this draft.
>
> > Abstract
> ....
> >    For a protocol
> >    that is actively maintained, the robustness principle can, and
> >    should, be avoided.
>
> To be blunt, I don't think there is community consensus for this
> statement. Now the IAB can of course express an opinion, but for
> something as contentious as this, I think it needs to be labelled
> as an opinion statement, especially in the Abstract which tends
> to bias the reader's mindset. Or a more neutral phrasing could
> be used; for example:
>
> For a protocol that is actively maintained, the impact of
> applying the robustness principle should be carefully considered.
>
> > 1.  Introduction
> ....
> >    Ideally, protocol implementations never have to apply the robustness
> >    principle.  Or, where it is unavoidable, use of the robustness
> >    principle is viewed as a short term workaround that needs to be
> >    quickly reverted.
>
> In an ideal world, all implementations would be perfect, so the
> robustness principle would be unnecessary. But the very basis for
> it is that the world *is not* ideal and many implementations *are
> not* perfect. So, really, what is the point of the first sentence?
>
> And no, I don't believe it's a short term workaround. That's like
> saying: when I've finished testing my Python program, I can take
> out all the try:... except:... statements because I've fixed
> all the errors, so I don't need the except: cases any more.
>
> On the contrary - good engineers leave the exception handling
> in for ever. When they don't, planes crash.
>
> Is there really a consensus view in the community that
> "the robustness principle is viewed as a short term workaround"?
> I don't believe it.
>
> > 4.  Ecosystem Effects
> >
> >    Once deviations become entrenched, it can be extremely difficult - if
> >    not impossible - to rectify the situation.
>
> I take the point. Sloppy usage of the robustness principle can indeed
> allow sloppy errors in the spec or in an implmentation to survive. But
> there's a trade-off that, IMHO, the draft does not recognize: non-robust
> implementations that do not tolerate sloppy inputs are bad for users
> trying to accomplish something.
>
> It's perfectly reasonable to argue that an implementation should have
> a strict mode, in which it logs errors etc., in a way that allows the
> detection of sloppiness at the other end. And I agree that this is of
> particular value during active development of the protocol and its
> ecosystem**. But I don't see any developer shipping code to the mass
> market that has strict mode on by default. I don't see any recognition
> of this reality in the draft.
>
> It's also correct to argue that sloppiness in certain security
> functions such as algorithm negotiation is never OK.
>
> ** If anyone here is masochistic enough to try my prototype
> of GRASP, they'll discover that its first two questions to
> the user are:
>
> Test mode (many extra diagnostics)? Y/N:
> Diagnostics for inbound message parse errors? Y/N:
>
> So yes, I agree with a lot of the points this draft makes.
>
> Regards
>    Brian Carpenter
>
> On 04-Nov-19 19:36, internet-drafts@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Internet Architecture Board IETF of the
> IETF.
> >
> >         Title           : The Harmful Consequences of the Robustness
> Principle
> >         Author          : Martin Thomson
> >       Filename        : draft-iab-protocol-maintenance-04.txt
> >       Pages           : 12
> >       Date            : 2019-11-03
> >
> > Abstract:
> >    The robustness principle, often phrased as "be conservative in what
> >    you send, and liberal in what you accept", has long guided the design
> >    and implementation of Internet protocols.  The posture this statement
> >    advocates promotes interoperability in the short term, but can
> >    negatively affect the protocol ecosystem over time.  For a protocol
> >    that is actively maintained, the robustness principle can, and
> >    should, be avoided.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-iab-protocol-maintenance-04
> > https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance-04
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-iab-protocol-maintenance-04
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
>
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>