Re: the race to the bottom problem

Mark Andrews <marka@isc.org> Mon, 09 November 2020 00:32 UTC

Return-Path: <marka@isc.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D7A3A104B for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 16:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h34bt3HBV3lQ for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 16:32:50 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA283A1049 for <ipv6@ietf.org>; Sun, 8 Nov 2020 16:32:50 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 46DDE3AB0D2; Mon, 9 Nov 2020 00:32:50 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 36E99160081; Mon, 9 Nov 2020 00:32:50 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 21F40160082; Mon, 9 Nov 2020 00:32:50 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JVDJX2DoHcXV; Mon, 9 Nov 2020 00:32:50 +0000 (UTC)
Received: from [1.0.0.3] (n114-75-120-99.bla3.nsw.optusnet.com.au [114.75.120.99]) by zmx1.isc.org (Postfix) with ESMTPSA id C040D160081; Mon, 9 Nov 2020 00:32:48 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: the race to the bottom problem
From: Mark Andrews <marka@isc.org>
In-Reply-To: <190c5cf3-9034-4e38-235c-620ecd916750@foobar.org>
Date: Mon, 09 Nov 2020 11:32:46 +1100
Cc: Ted Lemon <mellon@fugue.com>, IPv6 List <ipv6@ietf.org>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Bob Hinden <bob.hinden@gmail.com>, "Mudric, Dusan" <dmudric=40ciena.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <73CA579B-8877-45F7-9BF5-8FCE7EEF17B5@isc.org>
References: <60a15726-ff04-a202-4df9-79a6c6f33540@foobar.org> <99B762B0-0370-4B5B-9075-F688284D614A@fugue.com> <190c5cf3-9034-4e38-235c-620ecd916750@foobar.org>
To: Nick Hilliard <nick@foobar.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/SrFK-uYOPWN88Qi2W-pCH7KmAcg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 00:32:52 -0000


> On 8 Nov 2020, at 10:24, Nick Hilliard <nick@foobar.org> wrote:
> 
> Ted Lemon wrote on 07/11/2020 23:16:
>> Read the whole thread, please, Nick.
> 
> this is the problem: I did read it, just like I've read through all the other threads on this topic over the last several years. There was a repeat of the usual speculation, generalisation and echo-chamber mechanics which have characterised this discussion at the ietf since more-or-less forever.
> 
> You said: "we’ve already seen clear pressure to race to the bottom".
> 
> So I politely ask you again: please provide citations to data.  Then we can have a discussion.

Telcos only supplying /64 despite 3GPP supporting shorter than /64.  Every Telco that only supplies /64 has raced to the bottom.  There was reasons for this initially.  Some devices did not work correctly with short than /64 because their developers fail to properly test them before releasing them.  Its now a decade later and many of those Telcos are still doing /64.

DHCP-PD supports STATIC leases.  Whether you get a static of dynamic lease depends on the functionality the DHCP server vendor built in and how the server is configured.

> Nick
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org