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

Ted Hardie <> Wed, 06 November 2019 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E49D4120100 for <>; Wed, 6 Nov 2019 14:26:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 3TqNQN-CstL0 for <>; Wed, 6 Nov 2019 14:26:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0943712002F for <>; Wed, 6 Nov 2019 14:26:22 -0800 (PST)
Received: by with SMTP id z12so11250473ilp.2 for <>; Wed, 06 Nov 2019 14:26:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8OYLnJPdOfB0u5jLEuVo4J0IS76hn+D96zMze4E5A2Y=; b=NTOTLE6MY2fNjhUCpe7OP8Z6pCgWVCvrbioDAtikz5OY0saAmOvzIZhPyVIzMarbuP 4RRgk8nDpVMJFjxPPcZiWsaVy+tCTy76B+XWEabyPlZZbkVxdF7ERkhDWzGDN9l6PLk/ MZ5sZurTTZAx+zFstlFHJ3ySsvq1JhVIbUMJvA26uzAdMZhXqylAwmwkDh3s6PY1OjOi GXlNurrH61hn2KrD7p0vgpAd2SQFcSzVdDESxtuSuHc6WgYIMJdnZ2ezgHGNbAqXZ1Nw zo7t6/aaJNRYpYkZ4wBysBOFDOAfANVRFS9ua7QzEdO5VhWZSfuzGshycyDUqgpU7JQF aVrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8OYLnJPdOfB0u5jLEuVo4J0IS76hn+D96zMze4E5A2Y=; b=HeYXxdJ6foJfXwWEtcILElUAjF13hnylg+v95TH5l3zlJbhHWElptoJkNVEqAYQmRn rPXfoLflPbo6ehQoA66MJNYQqFVyXQGSiA7DQT1iS9bHkqmaAxpdZHy9+LPm1Ha24HfL GUPvER2rzDVO0axg1RkmwhBxikE0IpCz4wX5FBW0kIBUSGkR4XNXG3th529GzazcICVC hT2mxYi1YEweAxyQfKAvZ8B/jON7EAMtmWhuudAZwrUKQhgmAYkIkGhyKQDLPCp4J5K8 BR205W3I3NHUCT2ugtfbLGxyflYnLfIdHDMPR3mc9EFNIMPJweRtH+kDeCGe0RQqtmsn JKLA==
X-Gm-Message-State: APjAAAUfXGOs8DMsinHG/6sDIx37Vbu8/SIHnatCirWXL0b90FfpeYZa inG1Ls63caJzzHlR6k+Dzphym0l0vDh6VpuVZUk=
X-Google-Smtp-Source: APXvYqywIWHfasIOhePbQQz+grMM0alweF9G1hoiMKtSIdwv/N1YYPWlIlP8eBxheaSZ8G9LauC7y7bzlRUXlDjiMoA=
X-Received: by 2002:a05:6e02:cc1:: with SMTP id c1mr122721ilj.139.1573079180741; Wed, 06 Nov 2019 14:26:20 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Wed, 6 Nov 2019 14:25:50 -0800
Message-ID: <>
Cc: Brian E Carpenter <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000c594ce0596b5097a"
Archived-At: <>
Subject: Re: [arch-d] [IAB] 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: Wed, 06 Nov 2019 22:26:24 -0000

Hi Deborah,

On Wed, Nov 6, 2019 at 1:15 PM BRUNGARD, DEBORAH A <> wrote:

> For me, the robustness principle has nothing to do with preventing new
> extensions on a protocol, it has everything to do with protecting existing
> deployments. The document's proposal "Choosing to generate fatal errors for
> unspecified conditions" may be appropriate for some protocols, it would
> cause a melt down of the network for other protocols. One of my working
> groups currently is doing a "fix" - and only because of the robustness
> principle, there have been no issues with current deployments.
> As Carsten says downthread, some of the applications of the robustness
principle are obviously good.  Some, not so much.  I think we all agree,
though, that maintaining points of extension is both good and, ultimately,
necessary if the Internet is going to continue to change and grow.  One
issue is that some of the points of extension get eaten up by poor
applications of the robustness principle.  If you reserve a code point but
ignore its use in deployments because it has no meaning, it can really
never have a meaning until a forklift upgrade arrives, as you can't tell
which bits ignore it and which use it.  Given our current rate of
ossification, that is a problem.

I don't know the situation you allude to above, and it may not apply
there.  If you can send text on how to distinguish the situation you see
and the doc describes, we'd be grateful.