Re: [arch-d] Centralization or diversity

Brian E Carpenter <> Tue, 07 January 2020 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 652F4120113 for <>; Tue, 7 Jan 2020 11:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 dOCtx_0J8Vn7 for <>; Tue, 7 Jan 2020 11:46:21 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D678F12010E for <>; Tue, 7 Jan 2020 11:46:21 -0800 (PST)
Received: by with SMTP id bg7so13236pjb.5 for <>; Tue, 07 Jan 2020 11:46:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7o+xTgmC5aKfcOM1gNpzFhCEg0yvagB+ug93/7iEdxY=; b=QqaSHGvDHdePbX5QrESfMNQLHG5ojM82tTYXtSfJt37wD+U2MewW5zBiV5JNKS/LaW xIj+y8TilvAWIjMRfmqhkeI6uStyVLHS8/+V+L20iG94msloB1fgi3/Xo0zkRjIw5x0U advTSbkdZawNnBwnPltry4wA0XycTS26GQbfJScItC1PYqz7QKMCn8qjLFS1EoR/EFzM cA9204/5X30fQM6B7YE09+FT0iGuH+Z6lG8KeaWjavS6uQfmSchBG6Nr73TCU3GaJYJx 8JJ6YB9OcU22CR7patCJsUUsIMuav6NhoMf7wkkTePKoHMDBxYf/A4JVf4JFuGYxfZM0 ZkWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7o+xTgmC5aKfcOM1gNpzFhCEg0yvagB+ug93/7iEdxY=; b=OOQdQU0Ab0dQ2iBvDl/km52af5w/g3WYN+thWeglkQTPA4AMojBfEW9a2hIL7ktEnB 4OUdtOoswLBLAjFPoQjeWXErSMfFxbzj/1MS3tBG5sBplGZwtBCGEthYDqzs+X6MM6ac lim6ZSm33kRtJ3iyoA1D6sq5eKtyuzdbqRo1r3vAR5BuhwWd/HvOOi4hPIP/TZndKmpi uRSbe2Q2wvPUZPUq34lDiIw8ayHdt0Gj9GIIeRPJ5KtIMJUnbHVcOmDLIIp6sjWKmFYo kCc4McFz6hfN7hQwSuXPX/EJB2b1OH7exAsxNaQhrVX/1jipJ7053t2nlqLwfvfMMLQ/ vISw==
X-Gm-Message-State: APjAAAWRtgHYEA2LjAVn2ypaKqm8YqPe61vTiv/YvbiZvlqyVrMt1nj5 ZcIaWnnKzJgOv8N6Qc1q5+YDwude
X-Google-Smtp-Source: APXvYqwjxLOVzCGYJT0AKVlf8f5kz9e0J5kfNH7zEsfIrWAk/ieoD85oIjg8ei2DaXMcjiQZ1Xw4lg==
X-Received: by 2002:a17:902:9882:: with SMTP id s2mr68374plp.156.1578426380986; Tue, 07 Jan 2020 11:46:20 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c17sm355928pfi.104.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jan 2020 11:46:20 -0800 (PST)
To: Spencer Dawkins at IETF <>, Andrew Campling <>
Cc: "" <>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 8 Jan 2020 08:46:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [arch-d] Centralization or diversity
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, 07 Jan 2020 19:46:23 -0000

On 08-Jan-20 05:22, Spencer Dawkins at IETF wrote:
> So, implementation diversity matters, not just decentralization. 

Well yes, and this has been understood in high reliability design for at least 30 years. Triple redundancy with diversity are the buzzwords. This was very familiar to me when I worked in control systems, longer ago than I wish to remember. Google will find you examples from the 1980s in computerised nuclear reactor control systems**, and I think the same technique was used in spacecraft control from a very early stage.

It's not quite clear how to enforce this via the IETF, beyond the multiple interoperable implementations of RFC6410.


** e.g.