Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?

Lorenzo Colitti <lorenzo@google.com> Wed, 18 February 2015 07:26 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475961A8743 for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 23:26:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 weWCm6EW7VLu for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 23:26:04 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2381A033B for <v6ops@ietf.org>; Tue, 17 Feb 2015 23:26:04 -0800 (PST)
Received: by iecvy18 with SMTP id vy18so46635036iec.13 for <v6ops@ietf.org>; Tue, 17 Feb 2015 23:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JX7RY+6XuUZyDvGCiww7gqJaK+gwM+8SGQ1pUmuHuKA=; b=WLtQR5Z/62ZcULunOhhIOmCpeGjCQC83s/tHFaOq1h2H6BZ7s/728aH5l4QGijqFLQ sSLA8TsSFzUYSBBDzY1WEstloHjP6F9ZWnPY8H4cVyx3s49r/fnbbhOpsBCX04GHS5ic qQ8kq0I6vWfnI4wl8VoPmrFCZPbQoa40nP9S69v2Bm5OVpjfyLqmwM8l3D/BBWewMydr sJ8q37QzJ2qnJ95w/Ny9bGiBUXn7DfRgIwIcfvoXJatU2ccqP7WwVbEnBiqqZW+Eqv2H /XtdQAckRdctogVJ9Nxl16C1mpGxGO3qQi0ZHOohrGg9WGSc4XhtCDZVtit6ok6EE3Nz c3aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JX7RY+6XuUZyDvGCiww7gqJaK+gwM+8SGQ1pUmuHuKA=; b=GgxEzsaDINht50Ehq+TOqcoa2mjU09lzhRLMVbteU8uSH9lqo+02X1JMBm2w/66VZv 23fd/32Okq5/FtEJ1IBB7YPqCJPWjg1C1+d8b7OiIQzY0UBpEtN+fe/64fOtmWTJfruF cADQrBk/iaNJznOAuJxDsz1YNaBhWwe/4i51gUuUbT32wuYaaWWdKWneF9Iek5CIO+3n dbXR6GWqMEbmthyv55KjLo2pmii5JRpBW1kUmkcmG6Fr0IblJdaiy2ZIfIomqXFPB5nL dmgRSItJqhDOWQxJJ745NRp5CSSQpVyEAYIWOCJXv2QqfyiaRlFIqiHlj3E+Q0GdpHkM qpTQ==
X-Gm-Message-State: ALoCoQnjLkVUeovjdHvKNjUlLyO3WU/bVM42B4ye9Nm77q8JdtaXe0o+Vf97bvl8uEl8BlUmisK2
X-Received: by 10.42.58.139 with SMTP id i11mr1926940ich.68.1424244363693; Tue, 17 Feb 2015 23:26:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 23:25:43 -0800 (PST)
In-Reply-To: <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <787AE7BB302AE849A7480A190F8B9330049091C2@OPEXCLILM23.corporate.adroot.infra.ftgroup> <CAKD1Yr2yDnwPDHgsq3Wi3UOzKY7KrqSpBMbBttJ5qAAu6ijOAw@mail.gmail.com> <54DDF02C.8020903@gmail.com> <2D09D61DDFA73D4C884805CC7865E61130F231B4@GAALPA1MSGUSRBF.ITServices.sbc.com> <6536E263028723489CCD5B6821D4B21303DEA706@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0j23E-UMdL2Ujv5nrpbbUa9rgPE_6AhbHLn0JeOZ9Edg@mail.gmail.com> <355A1FFC-9F92-4D61-985D-4C5FC6EC69EC@eircom.net> <CAKD1Yr2PX81czTwUZzaMtgPc9vhvP=oL++UZByGzxmkq_B=DMA@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E07EE2@UK30S005EXS06.EEAD.EEINT.CO.UK> <CAKD1Yr0Zkic6-ydV-u==xjDGdY9GYWb8KwciBPnfk8zO=6FFqQ@mail.gmail.com> <CAKD1Yr0qS-Vg-XB7mNWwephkkL5rCG+NJO7uDJg_4W3LT+Q9Ew@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E088AE@UK30S005EXS06.EEAD.EEINT.CO.UK>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 18 Feb 2015 16:25:43 +0900
Message-ID: <CAKD1Yr00Ri8hQMsJcSqMAw+g_T-mU8GxG1G8rTHgo=McaKdW8Q@mail.gmail.com>
To: "Heatley, Nick" <nick.heatley@ee.co.uk>
Content-Type: multipart/alternative; boundary="20cf30334b6f5f4f3d050f57bb91"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/6PUyCja6_6ObLbq3jBEZ2bvaVcU>
Cc: "IPv6 Ops WG (v6ops@ietf.org)" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call- "harmfully broad"?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2015 07:26:07 -0000

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <nick.heatley@ee.co.uk>
wrote:

>  I can see why you argue for lowest common denominator of v6 requirements.
>
> I think your stance that this can work across the board is “harmfully
> restrictive”.
>
> The other approach is understanding the differences and trying to set a
> slightly higher bar that highlights conditional requirements of the
> collective; what you call  “harmfully broad”.
>

What I'm saying is that if your goal is IPv6 deployment in a reasonable
timeframe, then the right strategy is *not* to make a list of all the
features under the sun, wait until they have all been implemented, and
deploy them. A better strategy is to start from the features that are
required, test and deploy those, and then iterate. As the industry evolves
and IPv6 becomes more common, IPv6 features will become higher priority for
vendors and they will get implemented.

On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <nick.heatley@ee.co.uk>
wrote:

>  This is the game of chicken approach, I have no doubt it works, but is
> it inclusive to all mobile operators?
>
> For me, it has some limitations:
>
> -          The operator must have top down backing for a terminal policy
> of “IPv6 or you are out” (now that is a wildcard condition in itself); it
> may compromise relationships in a valuable ecosystem
>
> -          Where the operator has high major market power helps. Where
> markets have a number of players ready to play the IPv6 game, there is an
> advantage. Otherwise the operator is very exposed to divide and conquer
>
> -          Currently it tends to play out as a the simplest set of
> requirements. Which also means simplest set of network capabilities.
> Sometimes these simplest set of network capabilities are at odds with the
> business priorities of the operator (clear examples are: APN strategy,
> tethering approach, roaming approach, subsidised handset vs “SIM-only”)
>
> (Not having an IPv6 capable network is a myth you are promoting to
> discredit operator views, it is a red herring – any operator specifying *
> *any** IPv6 requirements will very quickly need this capability to
> validate terminals whatever the path they choose.)
>
>
>
> I can see why you argue for lowest common denominator of v6 requirements.
>
> I think your stance that this can work across the board is “harmfully
> restrictive”.
>
> The other approach is understanding the differences and trying to set a
> slightly higher bar that highlights conditional requirements of the
> collective; what you call  “harmfully broad”.
>
>
>
>
>
> *From:* Lorenzo Colitti [mailto:lorenzo@google.com]
> *Sent:* 17 February 2015 02:41
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org)
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <lorenzo@google.com>
> wrote:
>
> Yes. Make IPv6* (see below) a requirement for carrier-branded devices, and
> give the OEMs a credible signal that from date X onwards, you *will* fail
> TA on every device that doesn't implement IPv6, and you *will not* waive
> the requirement. That's what Verizon and T-Mobile did, and it worked for
> them.
>
>
>
> Also: if you think that this strategy is not feasible because you do not
> have an IPv6 network yet, then yes, that's true - you can't make IPv6 a
> device requirement until you have an IPv6 network.
>
>
>
> But I think the key point here is that apart from the lack of 464xlat on
> iOS, the mobile operating systems are a lot more ready for IPv6 than you
> might think they are. Once the network is complete, I think turning on IPv6
> in the devices does work. Orange Poland, Telenor, and SK Telecom should be
> able to confirm.
>
> NOTICE AND DISCLAIMER
> This e-mail (including any attachments) is intended for the above-named
> person(s).  If you are not the intended recipient, notify the sender
> immediately, delete this email from your system and do not disclose or use
> for any purpose.
>
> We may monitor all incoming and outgoing emails in line with current
> legislation. We have taken steps to ensure that this email and attachments
> are free from any virus, but it remains your responsibility to ensure that
> viruses do not adversely affect you.
>
> EE Limited
> Registered in England and Wales
> Company Registered Number: 02382161
> Registered Office Address: Trident Place, Mosquito Way, Hatfield,
> Hertfordshire, AL10 9BW
>
>
>