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

Lorenzo Colitti <lorenzo@google.com> Wed, 18 February 2015 07:20 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 CE34D1A902E for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 23:20:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 i-kGWdIJ1U6K for <v6ops@ietfa.amsl.com>; Tue, 17 Feb 2015 23:20:14 -0800 (PST)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 558C01A8FD6 for <v6ops@ietf.org>; Tue, 17 Feb 2015 23:20:14 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id b16so50491igk.1 for <v6ops@ietf.org>; Tue, 17 Feb 2015 23:20:13 -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=rZdZVzvEdq7lfUx6FrwYae1WOK4t5u5ow1AC7tu0f1o=; b=KTkBAioZOb3txcH0N+iN40Oyg0X9qmuv+VMIWUrEfvbKzfYtzcTz0l3WSJ5CBHUazC 6OlPJ0ZyzY5uaPiB0+yp9sCROITbv1yiaNIGpZnoq7K0Fv3P5tZOHYYW5sllpdSf84S7 fWnWCwF389AbB3ulUJbOowNEQ+iOyUpJKKjQDoJ8x2fSVZ66X9ReYu01B/IvD2LmXP5z /5kRTmnXT03aLmD1pJV3/1ySqrarVXFo2Mqm/P4LvtIKe7CyKlIwApWVv9P9ONX1bQLZ 0amDfYoc9ZFaWCWb7uGg69aQZIFQpSK2uzWUYm9tS2KsdNf/S83var8NPPRhUeCiPiTi FL9w==
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=rZdZVzvEdq7lfUx6FrwYae1WOK4t5u5ow1AC7tu0f1o=; b=ksyOmIPZ9QMree+9h5X5DA74UUSYhSb/qxWFMpliHO2CWKv3LBJ3043zr23Vb71fiK ZlrtDV107BlWy1kZWohMjMa2k+f7ki2FviBMf0mzppYRhNJp0/CraVRMJifggf26byJy h0G+ODzLSq8EL4Dp8ykf1CnoGZ13xGSHjckuXLZvcNroPN6AL8XwCW7jWKIENld+yCGB kAlweRDCRjn4fcy4BqgFX1etim1rV/TtDgHyrhW2errGdbtNBx4yVLba0jOmzntC/wO6 jhhVnI6GVz3xQHiW3IgQMfKwFr+CiLvDwoFunRfki3XxBNVwFBWx0twIjk3YxYx7d0Lk 0Z4Q==
X-Gm-Message-State: ALoCoQl89a0llo3VG5OGmJWtMs7BHk/VtbX3CdVAxrSwZAW2d1NN/Xyjvf4ERyeNT2cHRM9Juytz
X-Received: by 10.107.25.72 with SMTP id 69mr3858826ioz.44.1424244013403; Tue, 17 Feb 2015 23:20:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.33.104 with HTTP; Tue, 17 Feb 2015 23:19:53 -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:19:53 +0900
Message-ID: <CAKD1Yr3Kbdm30sXNuf0suiCJrzPv_-ZC5NC_POAKLz+5_=Vb_Q@mail.gmail.com>
To: "Heatley, Nick" <nick.heatley@ee.co.uk>
Content-Type: multipart/alternative; boundary=001a113fef7a7e35e5050f57a66d
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/P3GP5E2qQueQhw_NHJWlEwd8WTw>
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:20:17 -0000

I don't understand why you say this is a game of chicken.

All the major device vendors (except Apple, if you need 464xlat) support
IPv6 today - Verizon and T-Mobile have fixed that problem for you. Asking
them to set the APN configuration for your network to IPv6 (or IPv4v6) is
simple, and they are running that code already on other networks. It's not
an unreasonable request. It's not like you're asking them to write off the
national debt or give you all their phones for free or something. It seems
that you are dismissing that approach as unrealistic. Fine.

But what you *are* doing, though, is writing a profile document listing 30+
features, many of which those vendors don't implement today, and some of
which will require substantial work. Then you're asking a technical
standards organization - which is not an operator organization, and which
is not in the business of publishing profile documents or influencing
deployments, but only of defining standards - to publish that document with
"this is not a standard, and compliance is not required" written on the
first page.

To me that sounds a lot less realistic than just asking the vendors to turn
on the code they already have.

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
>
>
>