Re: [arch-d] Centralization or diversity Wed, 08 January 2020 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5532712089D for <>; Wed, 8 Jan 2020 12:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 10hIPVRgML8e for <>; Wed, 8 Jan 2020 12:58:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 346BB12083C for <>; Wed, 8 Jan 2020 12:58:16 -0800 (PST)
Received: by with SMTP id l9so3952530oii.5 for <>; Wed, 08 Jan 2020 12:58:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=anOUw0MtoTyGeMNWhUMoFNWuPc+WBWYJMpTnvLVo1r4=; b=fz71ZxQgoaelifUlwsbuWzHNAOWWljtSP6xCmJ+CDDv3h59O8PJSSXP/XnV7YuVoko xZ/Me2jIasBh5PNXYZaNllNYsU7UR4BplBH4xQPMHpNdGBCgauR/omfQNZRcquEkgxZ1 Z/qQsRtB1RewhyR0yUU5HB6Jme26/lA5PQxk3LBOvdKZWMhj1vf5KUqzbPL4pVblTKvL b90IzMelehVHC/nv3YxYfzYm8Z/j6NiuEo0Kh+UdA8PRLyu9kbs8yEFeFUVfMfq9vBZJ 37+8ssAjCmEhAB24uDss52kG10HUF/S2RRsHf8WWDbLMJvxF7tz2hUgM9bml1VsGqXvf jxXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=anOUw0MtoTyGeMNWhUMoFNWuPc+WBWYJMpTnvLVo1r4=; b=RzW1FqgjYPQucQEQVdWzGJoVm4tbcds79o+dQgxI7wWgfSdHiLozk4CZZfqQ8HzHPt S7o7F3j8fL8Qme34MNPmEZgHao4T2aBaP/AopGerw+HUi9G995Csj4n1wQT5rvTixqXt fra8mc3ogaeJuY9K+50j7miUIgZxojOcNyh8rzI23zFWMnw0tXgi+FrMKiBXnxOc7Bw1 hf5xqNXkHvQxo5Rv/4j0q5AmUHkGsGfA3nMigVpn1zUNq2SYnun6/11jNaIfj/df54yu sItHqDTFXS8UX8hBSHXOm4eWO8lNkG8DaEMv0pUbjiMNH3KwxC+k6qm7WETRHGdYT+mN I3VA==
X-Gm-Message-State: APjAAAU/6DyqqHd2N354H3N/Y8UT5XTO2BGXfLrlKk/F8mrd+mglRyGf p5uWapbxvTvEhTkxgpNFxI8=
X-Google-Smtp-Source: APXvYqyfQc7pSsjGs8H/6bbDVTmPCvZ4JOvIb2BxVL9grPmLZBsHQFInVMXjL4sYqvHNNqR3ccqNVw==
X-Received: by 2002:aca:1012:: with SMTP id 18mr395658oiq.151.1578517095378; Wed, 08 Jan 2020 12:58:15 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id a24sm1457923oic.10.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jan 2020 12:58:14 -0800 (PST)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
In-Reply-To: <>
Date: Wed, 8 Jan 2020 12:58:13 -0800
Cc: Brian E Carpenter <>, Andrew Campling <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <> <> <>
To: Toerless Eckert <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Wed, 08 Jan 2020 20:58:24 -0000

> Yes, i was thinking of ISO PICS. But i lost track of those ISO standards
> since the 90th. I guess i would have to see a successfull and still
> currently used standard and how its PICS do or do not help. Just
> not alot of those ISO specs left in wide deployments, right.
> X.500 ? Maybe i can get more insight from the security community.

You need not go that far.  Remember IS-IS?  Still thriving.  

And yes, my experience with PICs and test suites comes from that.

>> What it does do is to encourage people to write ???conformance test suites???.  These then get sold to unsuspecting customers and end-users.  Unfortunately, the quality of such suites is so low that you spend way, way, way more time debugging the test suite and you never find bugs in your implementation.
> This is just the worst possible outcome, and i am sure one can learn
> from those bad experiences. Just think of taking a more organized
> step towards being able to collect protocol implementation information
> from the industry. Right now every WG who wants to raise the level of
> an IETF protocol, e.g.: to(wards) full standard is coming up with a
> questionaire in an ad-hoc fashion (we're just doing this in Multicast
> for IGMP/MLD). 

You can do that if you like, but the one proven, effective method is interoperability testing.

Running code trumps questionaires, conformance test suites, theory, and mandate.

> My point was: If the only murphy you have is competitive pressure, it works not
> it there is only limited competition, such as a total of maybe no
> more than 3 competing national infrastructures. 

And countries that stifle competition inflict vendor lock on themselves.

> See above. The best i think we (IETF) can do is to educate better about
> this by appropriate documents. Certainly some additional protocol work
> will result from that. I for once had simple slides 10 years ago how to fixup
> non-dual plane networks to be dual-plane. And maybe we can come up with
> questionaires to get better numbers from actual deployments (the
> PICS discussion).

The IETF’s job is not education. It does not work as the education is not requested
and not welcome. The IETF’s job is standards and it needs to focus on that.

> Figuring out ideas for a complete ecosystem of monetization and
> deployment between competition and regulation is better left for
> an ongoing bar-bof with emphasis on bar.

I concur. Let’s stop fooling ourselves into thinking that anything that the IAB/IETF writes has any impact
on regulation or economics.

> Actually one of the interesting conclusions was that dual-plane in
> many cases is really free but deployments often just don't fully
> utilize it.

I’d agree that it’s close to free.  If you accept that you need a dual-plane approach for resiliency, then
adding a second vendor to the mix is relatively easy. There’s additional cost because of decreased 
purchasing volume. There’s additional costs in management and operations.

However, as compared to the costs of an unnecessary outage, it’s still trivial.