Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:[e-mail]]
Envoyé : vendredi 30 janvier 2015 09:27
À : BOUCADAIR Mohamed IMT/OLN
Cc : Fred Baker (fred); V6 Ops List; [e-mail]; [e-mail]; joel jaeggli
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Fri, Jan 30, 2015 at 4:35 PM, <[e-mail]<mailto:[e-mail]>> wrote:
1. The wording "required features to connect 3GPP mobile devices to an IPv6-only or dual-stack wireless network" is factually incorrect. The vast majority of these recommendations are not required to connect to such networks, and are many are not even implemented by many popular mobile operating systems - which manage to connect just fine. After long discussions, that text was removed in -06. Why was it readded?

[Med] This text was redited as a side effect of implementing the request from the IESG to position this document as a superset of existing RFCs.  The recommendations are not only about IPv6 but also, as indicated in the same sentence you quoted, “features to deliver IPv4 connectivity service over an IPv6-only transport”.


But that doesn't change the fact that the statement is incorrect. The vast majority of those features are not "required to connect". As for the feature required to deliver IPv4 connectivity service over IPv6-only transport, only one feature (out of the dozes in this draft) is required for that - 464xlat.

If you want to turn this into a document of features that are required to connect, I support that... but that would mean that the majority of recommendations should be removed, because they're not required.

[Med] We already discussed this point several times. No need to repeat this discussion once again.

Also - this document passed WG and IETF last call with the understanding that it explicitly did *not* define an IETF-approved device profile, but only a profile "that a number of operators recommend". That text was in the document as recently as -14, but it was removed.

Making this documean IETF-approved device profile is a substantial change and has much broader implications than what the WG and IETF had consensus on. Adding that text was essential to overcome the objections of those in the WG that felt that it is not the place of an operational WG, or indeed of the IETF, to place the RFC seal of approval on a device profile document (or, as Brian puts it, "on somebody's procurement spec").

That text should be restored.

[Med] Your point about the process is fair. I have no problem to restore that text if this is what the WG wants. This is really the kind fo feedback I’m looking for.  Unless I heard any objection from the WG, that text will be restored.


2. Previous versions of the document, including the version that passed IETF last call, contained the text:

   This document is not a standard, and conformance with it is not
   required in order to claim conformance with IETF standards for IPv6.
   The support of the full set of features may not be required in some
   deployment contexts.  The authors believe that the support of a
   subset of the features included in this protocol may lead to degraded
   level of service in some deployment contexts.

That text remains accurate and that statement is still necessary. Why was it removed? It has been in the document since -06, and the words "this document is not a standard" have been in this document since -01.

[Med] It was removed as per a request from the IESG (A. Farrel).

Adrian, why did you request that this text be removed?

The text that passed last call went out of its way to state it was not a standard, and that compliance with it was not required.  This text helped defuse substantial objections within the WG and the IETF that pointed out that only a fraction of these features are actually necessary to deploy, and called attention to the harm to IPv6 deployment that would occur if mobile operators and device manufacturers believed that all these features needed to be implemented before deployment could occur.

[Med] Lorenzo, the document does not states ALL features MUST be implemented. Just like any other recommendation document, there are several support levels. As far as I’m concerned, I have no objection to include that text if the IESG is OK with it.

3. I object to the statement "One of the major hurdles encountered by mobile operators is the availability of non-broken IPv6 implementation in mobile devices." I submit that if it were true, then we would observe no IPv6 deployment in mobile networks... but publicly-available data - e.g., http://www.worldipv6launch.org/measurements/ - shows that multiple operators have deployed IPv6 to up to 30-65% of their footprint, using the same commercially-available devices that are used by customers of other operators. So claiming that "broken IPv6 implementations in mobile devices" are a major hurdle is at best incomplete and at worst incorrect.

[Med] That sentence was there since we edited the individual version of the document. Of course, current implementations perform better that when we edited the -00 of the document. Still, the feedback we had from our device team is that there are still a lot to be done.

But you see, the problem with that is that it's just the opinion of your device team. For example, if instead you asked the device teams of Verizon Wireless and T-Mobile, they might well say that the features that are necessary to deploy IPv6 are already supported just fine (with the possible exception of 464xlat on iOS) - and that's why they deployed IPv6 to 30-65% of their devices.
[Med] This is US-centric, but anyway you already raised this point several times: some answers are provided here https://www.ietf.org/mail-archive/web/v6ops/current/msg14769.html or https://www.ietf.org/mail-archive/web/v6ops/current/msg20086.html. I can add that in the Europe for instance, operators do not control the device used by  the customer, hence the need to have a profile.

The IETF should not document matters of opinion.
[Med] Agree.

It should make technical statements that are supported by evidence.
[Med] ISOC organized several IPv6 mobile workshops that revealed that operators participated a those workshop agree devices are a hurdle for their IPv6 deployments. I don’t have public pointers for the prez mad during the workshop but you can get in touch with ISOC if you need so.

The available evidence does not support the statement that "IPv6 deployment is blocked because mobile device implementations are broken"; in fact, the existence of large mobile deployments proves that statement wrong.
[Med] Not sure to understand the causality effect here.