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

[Ca By <[e-mail]>]

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, <[e-mail]> wrote:

>  Hi Nick,
>
>
>
> I fully agree.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* v6ops [mailto:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>] *De la part de*
> Heatley, Nick
> *Envoyé :* mercredi 18 février 2015 10:35
> *À :* Lorenzo Colitti
> *Cc :* IPv6 Ops WG ([e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>)
> *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:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>]
> *Sent:* 18 February 2015 07:26
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG ([e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>)
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> On Tue, Feb 17, 2015 at 8:31 PM, Heatley, Nick <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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 <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>]
> *Sent:* 17 February 2015 02:41
> *To:* Heatley, Nick
> *Cc:* Ross Chandler; IPv6 Ops WG ([e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>)
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call-
> "harmfully broad"?
>
>
>
> On Tue, Feb 17, 2015 at 10:57 AM, Lorenzo Colitti <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> 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
>
>
>