Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?

Sander Steffann <> Wed, 27 May 2020 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9C153A0C00; Wed, 27 May 2020 13:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FiHTcEMVdGyC; Wed, 27 May 2020 13:59:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FB893A0BEB; Wed, 27 May 2020 13:59:25 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D3724B; Wed, 27 May 2020 22:59:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1590613158; bh=GMh6oUKQIVvfVAkzW0v KQM/ZNOLeDafnPkyBxB8kiKY=; b=K/Npf4O5lkWLCCNrht9s0O2LRpOKXuo7gLy F8ozD+mteDsqtWyzIIDlDrEjVntzNG2NWSFSSkEi6soDrRVGRBX4b7rtuiKRzk5A F0bmgy2WzzGCxv06M4waDNwOSmsfu4sElZIFU/8LMo9T2d6Z+310fSAqsDJtb/rF ApZbJR3I=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id EkZcqZDefR8O; Wed, 27 May 2020 22:59:18 +0200 (CEST)
Received: from [IPv6:2a02:a213:a300:ce80:7c8d:b931:f677:6a46] (unknown [IPv6:2a02:a213:a300:ce80:7c8d:b931:f677:6a46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 6408C49; Wed, 27 May 2020 22:59:17 +0200 (CEST)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_757EFE35-0F96-4023-85F8-6FF5A20001AA"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: [spring] Long-standing practice of due-diligence is expected - Re: CRH is not needed - Re: How CRH support SFC/Segment Endpoint option?
Date: Wed, 27 May 2020 22:59:12 +0200
In-Reply-To: <>
Cc: "" <>, 6man <>, Alissa Cooper <>
To: Andrew Alston <>
References: <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 May 2020 20:59:38 -0000

Hi Andrew,

> What I find so bizarre is –
> You have an multiple operators – who have clearly said – we want this – we see advantage of this.  Yet still the obstructionism and denialism continues.  The “not invented here” syndrome seems to run deep – and email after email is patently ignored from the very people who have to buy the hardware.  Reference is made to Montreal – yet the emails that stated the use cases after it went by with no response.  No technical objections ever show up – other than – we don’t want this and you haven’t given us this mythical architecture document – which was yet another non-technical response that seems so clearly designed to stall any innovation that doesn’t come from one source.

This makes me think back to the days of telcos. You know, the world where telcos defined the protocols and the users just had to accept their choices... The world where TCP/IP flourished because it allowed permissionless innovation (which is the very thing that the IETF says it's all about to their supporters on

And look where we are today. The IETF as the place where innovation is shot down because it might compete with "IETF sanctioned" standards. The IETF has turned IP into ISO's OSI stack of today.

> Yet again – I support crh – I’ve deployed CRH – CRH works for us – and we still continue to support it.  And irrespective of if it is adopted – the development of it will continue – and it will exist – the only question is – do we end up with something that the market wants outside of the auspices of the IETF – or do we end up with something that is properly standardized, because this level of obstructionism will not prevent the development.

Yep. That's what happens to those standing in the way of permissionless innovation: at some point the users (operators) have had enough and will fight what they believe in, ignoring the outdated standards bodies that hold them back.

If the IETF can't provide permissionless innovation anymore it has no reason to exist.