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

[Lorenzo Colitti <[e-mail]>]

On Fri, Jan 30, 2015 at 4:35 PM, <[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.


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.


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


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

The IETF should not document matters of opinion. It should make technical
statements that are supported by evidence. 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.


>   I am not aware of any of the authors' employers having a substantial
> IPv6 deployment (though I would be happy to see any data that the authors
> could provide to the contrary). On the other hand, the IPv6 lead on one of
> the operators that *has* deployed IPv6 no longer appears in the list of
> authors.
>
> [Med] I can give you the example of Orange in Poland, for one.
>
http://www.worldipv6launch.org/measurements/ says 1.81% , yes. What about
the others?

> You can also check the Orange Groud Device requirements (IPv6 Chapter):
> https://www.ogdr-online.com/ogdr/index.php/component/extendedreg/login. I
> hope we can focus on technical comment rather than diverting. Thanks.
>
The problem with that is that there is very little technical content in
this document. Most of the document is just a laundry list of desired
features.

Regards,
Lorenzo