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

Ca By <cb.list6@gmail.com> Wed, 18 February 2015 15:08 UTC

Return-Path: <cb.list6@gmail.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 3AE271A1B34 for <v6ops@ietfa.amsl.com>; Wed, 18 Feb 2015 07:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 7mUHHCdcDYjf for <v6ops@ietfa.amsl.com>; Wed, 18 Feb 2015 07:08:24 -0800 (PST)
Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (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 E98DB1A924B for <v6ops@ietf.org>; Wed, 18 Feb 2015 07:08:21 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id k14so1737263wgh.4 for <v6ops@ietf.org>; Wed, 18 Feb 2015 07:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XE0fM+oPGJ2Fxjgi1bgxCExme3G97l8ZTiUQUVxEKdo=; b=zQ6Y9K+z1U/4pBTBpwJKScnnFA9yO425weMnVSCOB4PQQZehZjGs4Dk+fgr2EDNm6s 53nfPOU0IQypoLWhKvXqUfWBoDbBAMfHYqdILLO6so5uajimJdEjZ9kLQ8EdZ2fs2VRM X3DKTTYUXi/Gbv3NwjnZQYhQsW4ugqe8IwKYi9WfOWJ98h8bT1o1Fgk9KV/UPLxHaTRP 4D6kEpGMV9mqbttPmzehuE6pujyOt4UWbTg+xdVBTej3SL9hjlHSyl8vCrAn+CGO2x3a L6Q0Esi3/uCFsxow9AjcCPlV1kRqmdmIqJJDZ51qiEQn0uzlk3SYOiy+dkNz/sBHy6N5 G7uA==
MIME-Version: 1.0
X-Received: by 10.181.13.4 with SMTP id eu4mr901475wid.41.1424272099117; Wed, 18 Feb 2015 07:08:19 -0800 (PST)
Received: by 10.194.127.102 with HTTP; Wed, 18 Feb 2015 07:08:18 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup>
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> <CAKD1Yr00Ri8hQMsJcSqMAw+g_T-mU8GxG1G8rTHgo=McaKdW8Q@mail.gmail.com> <6536E263028723489CCD5B6821D4B21303E08E9C@UK30S005EXS06.EEAD.EEINT.CO.UK> <787AE7BB302AE849A7480A190F8B93300490D690@OPEXCLILM23.corporate.adroot.infra.ftgroup>
Date: Wed, 18 Feb 2015 07:08:18 -0800
Message-ID: <CAD6AjGQ_K2kJCfFbhUxHK4p_5UXAsRpgoeYNtcbg4D+dOq5_4Q@mail.gmail.com>
From: Ca By <cb.list6@gmail.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Content-Type: multipart/alternative; boundary=f46d043be152881222050f5e30a6
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/z6SvQ02QWFa-c9hPMM6Hnl_3L-U>
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 15:08:27 -0000

Authors,

I know you said the 3gpp is not interested in this work, what about GSMA ?
They write profiles for mobile networks , right?

CB

On Wednesday, February 18, 2015, <mohamed.boucadair@orange.com> wrote:

>  Hi Nick,
>
>
>
> I fully agree.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* v6ops [mailto:v6ops-bounces@ietf.org
> <javascript:_e(%7B%7D,'cvml','v6ops-bounces@ietf.org');>] *De la part de*
> Heatley, Nick
> *Envoyé :* mercredi 18 février 2015 10:35
> *À :* Lorenzo Colitti
> *Cc :* IPv6 Ops WG (v6ops@ietf.org
> <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>)
> *Objet :* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> Yes, I agree with you, that is a sensible approach.
>
> Working with each vendor in turn.
>
> (You know each vendor who claims IPv6 readiness for their terminal, will
> never say whether the device will work on the operators IPv6 network.
>
> So it needs to be collaborative.)
>
>
>
> So all this document is doing is setting a collective roadmap, rather than
> expect vendors to do their own thing. Given we agree on the above, this is
> not harmful.
>
>
>
> I think the real disagreement comes from your opinion that this is not
> IETF.
>
> (By the way, mobile operators have had discussions with the sister org of
> the Internet Society about what would help mobile operators introduce IPv6.
>
> One of the major major themes has been terminals.)
>
>
>
>
>
> *From:* Lorenzo Colitti [mailto:lorenzo@google.com
> <javascript:_e(%7B%7D,'cvml','lorenzo@google.com');>]
> *Sent:* 18 February 2015 07:26
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org
> <javascript:_e(%7B%7D,'cvml','v6ops@ietf.org');>)
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <nick.heatley@ee.co.uk
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','lorenzo@google.com');>]
> *Sent:* 17 February 2015 02:41
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG (v6ops@ietf.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>
>
>
>
>
> 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
>
>
>