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

Brian E Carpenter <> Tue, 05 November 2019 01:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3D18120874 for <>; Mon, 4 Nov 2019 17:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Qg7h1b1Y5bPp for <>; Mon, 4 Nov 2019 17:13:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7712120911 for <>; Mon, 4 Nov 2019 17:13:30 -0800 (PST)
Received: by with SMTP id n13so2163946pff.1 for <>; Mon, 04 Nov 2019 17:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=YUhnxTmgc+FWSiqO7tDEestw1hag5mgJW64avGssIEL3DCB2/qoUrgpa3XjC00L74U NfwZVY5VT68ELn/KRW0UEBZBMNLSevMDlD78zFhLx/+IqLYTOav+nADImQnpzB6OHg0n GDse3jw/omxevwo9K+TUnv5SAmFxV9H0N+7FPzRSDMjjE5688c6Dus7EA0iWxfz3YT4Z q4FnVXA0BfllkRSOCseIgjIRK66HIJKUrRZsnLbb9YPrQ41eFYwv27Q/uhXY8DC9sdsk rYRaOoUEHWkCrBySEcRNADafwMiFsI/XjN54hkbDnKN+71HweqJ3Xu0D29dUslMu74b6 kBig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WssBwUzovYxE8kMNxwxNGkWEYgJBh43GPHZk9UoCpYA=; b=e1vmZu7DzbUmzxYR2R9pADANyvF7/QRVk6ADs2wQaeqVT5c221iGYwUp05zO7U7+Eb SWODITIB95aHeKPpBErKwKdnC+nLFc4i6xy66tcXudkwi+ZWYWbAbMTRbhCi1OXX06h+ cGz76ZcnrLhkloRGET3KEYKw9EiTYbn9uRClc5bRNZ1OFd+etRvt3VaP0NCMKfQAWEIa EO9IB6fEXT5jGBA95GDfAdnX/NTHK7wxPFDzDOa30e8zcoQ7coDn3f6demyxmNK9ASkE 5iPNPjmfhod25ibkFEwaPLrdwZkaxPLm5gsbWB3OoVpwgUvD1+gSETcvYkjiEueyi41Y IHPw==
X-Gm-Message-State: APjAAAXErRNTZcFCVa3toZ2mDZRu9vf86HFt+Z7WsfWd5naM8E7bAcht +N1l0IyYcxDsdY1dua9N4KowMW5r0lU=
X-Google-Smtp-Source: APXvYqxMdcnjWSjvXXTgMthK+Phc3/zhIv369iqGiJ+tf/FlNWhOFP4DYrhi8F10NvHBNkJUlnHC1g==
X-Received: by 2002:a17:90a:348c:: with SMTP id p12mr2719853pjb.105.1572916409769; Mon, 04 Nov 2019 17:13:29 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id r185sm17691096pfr.68.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 17:13:28 -0800 (PST)
References: <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Tue, 5 Nov 2019 14:13:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [arch-d] I-D Action: draft-iab-protocol-maintenance-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2019 01:13:38 -0000


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.

   Brian Carpenter

On 04-Nov-19 19:36, 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> I-D-Announce mailing list
> Internet-Draft directories:
> or