Re: [**EXTERNAL**] Re: the race to the bottom problem

Nick Hilliard <nick@foobar.org> Sun, 08 November 2020 22:35 UTC

Return-Path: <nick@foobar.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 01B303A0EB4 for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 14:35:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UeqoPJVJh05V for <ipv6@ietfa.amsl.com>; Sun, 8 Nov 2020 14:35:10 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [46.182.8.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3763A0EA9 for <ipv6@ietf.org>; Sun, 8 Nov 2020 14:35:09 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.16.1/8.16.1) with ESMTPSA id 0A8MZ6IM016658 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Nov 2020 22:35:06 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Subject: Re: [**EXTERNAL**] Re: the race to the bottom problem
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 'IPv6 List' <ipv6@ietf.org>
References: <160409741426.1448.16934303750885888002@ietfa.amsl.com> <CABNhwV3L7kz=cWu8s3X=djVf4MCwewzbEgx09TWaKzCULCjYUQ@mail.gmail.com> <9A9CE8E7-3552-4FD8-A50E-1BDCA2CB813F@employees.org> <CABNhwV0LxM7EuKo2wNtVacjewsVqdhrmSiVBmB_EL-mqJYdU3A@mail.gmail.com> <CD9F9F09-2CBC-4A72-99C0-4A9A470357ED@employees.org> <9e787ed0-a221-e413-e030-ac2553dffc8e@gmail.com> <a21c9447-730b-e2c0-81f6-46deda57f507@gmail.com> <f4635fa9-45ca-f7ec-40a2-41764e1ca74f@si6networks.com> <905bcc26-a223-53d0-6675-c35579b9a8be@gmail.com> <AAE75F7F-F8DF-4B7F-9C50-3D6C91544997@ciena.com> <2b59b2de-3597-8d35-374d-75e9b10d4d83@gmail.com> <21BC970D-8708-4090-A984-02E6E1305B94@gmail.com> <25099A60-8685-4226-8328-AA87376B62D2@ciena.com> <SN6PR02MB4512023A8418FA3BFA79F412C3EB0@SN6PR02MB4512.namprd02.prod.outlook.com> <8bc14b7a-9b4c-6f03-4e11-4fe02947fd31@gmail.com> <321718b8-41c4-8b85-6c0e-7d7cfeea6784@foobar.org> <e1b7bce4-7361-1e81-3496-ea47453d8285@gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <6c161f5b-1780-50e4-b008-321591908f6c@foobar.org>
Date: Sun, 08 Nov 2020 22:35:05 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.36
MIME-Version: 1.0
In-Reply-To: <e1b7bce4-7361-1e81-3496-ea47453d8285@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/9Zexvebaf4S8AF7ylfnraGGQq2g>
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: Sun, 08 Nov 2020 22:35:13 -0000

Brian E Carpenter wrote on 08/11/2020 22:05:
> That's the wrong question. It's 3GPP that created a problem. We are
> stuck with it, but that doesn't mean we should quietly concede.

it's ok to ask a question like this, and to question both the question 
and the answer.  Obviously the question was loaded in the "have you 
stopped beating your wife yet" sense, but there is a grain of truth to it?

The real question was: to what extent is the IETF going to restrain 
itself from making ipv6 protocol behaviour decisions because a different 
SDO made a move in a particular direction and stayed there?

If the IETF can't make changes to ipv6 protocol behaviour decisions 
relating to access technologies other than 3GPP, then does 6man feel it 
has any mandate for ongoing ipv6 protocol management relating to other 
generic access technologies and not just service provider access products?

I.e. is the tail wagging the dog here?  And if so, where does this end?

Nick