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

<mohamed.boucadair@orange.com> Fri, 30 January 2015 07:35 UTC

Return-Path: <mohamed.boucadair@orange.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 893D11A1B28 for <v6ops@ietfa.amsl.com>; Thu, 29 Jan 2015 23:35:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level:
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 GrlHWbX1T7sV for <v6ops@ietfa.amsl.com>; Thu, 29 Jan 2015 23:35:20 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2F01A898F for <v6ops@ietf.org>; Thu, 29 Jan 2015 23:35:20 -0800 (PST)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A17933744C8; Fri, 30 Jan 2015 08:35:18 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 6662A15804E; Fri, 30 Jan 2015 08:35:18 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Fri, 30 Jan 2015 08:35:18 +0100
From: <mohamed.boucadair@orange.com>
To: Lorenzo Colitti <lorenzo@google.com>, "Fred Baker (fred)" <fred@cisco.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQOxuJv5W9vu3skUKiVKZnDa9kKZzW7VoAgAFTUoA=
Date: Fri, 30 Jan 2015 07:35:17 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330049024FB@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <CAKD1Yr2jO9Lc8e4GXxcTWgEudotbTVsgsgW7uspYZ82UqK-1sA@mail.gmail.com>
In-Reply-To: <CAKD1Yr2jO9Lc8e4GXxcTWgEudotbTVsgsgW7uspYZ82UqK-1sA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049024FBOPEXCLILM23corp_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/eydNtWenNoDDIvqzZA0l0RsSccA>
Cc: "draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org" <draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org>, V6 Ops List <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
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: Fri, 30 Jan 2015 07:35:23 -0000

Hi Lorenzo,

Please see inline.

Cheers,
Med

De : Lorenzo Colitti [mailto:lorenzo@google.com]
Envoyé : jeudi 29 janvier 2015 12:53
À : Fred Baker (fred)
Cc : V6 Ops List; draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org
Objet : Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <fred@cisco.com<mailto:fred@cisco.com>> wrote:
draft-ietf-v6ops-mobile-device-profile has been through Quite a bit of change in the IESG. The ADs would like to see the working group read it again and comment - working group last call - before they proceed.

Ok, off we go again then.

I have objected to this document already, and was found to be in the rough. Therefore, I must assume that rough WG consensus is that we need a document that looks something like this, and I will accordingly refrain from making any general statements on the scope, utility, and general content of the document, with which I continue to disagree.

However, I would be remiss if I did not at least draw attention to the following factual errors and/or inappropriate statements.


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













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


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.


At the risk of sounding like a broken record, I am going yet again to say that that operational documents should be based on operational experience. 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. 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.


Regards,
Lorenzo