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

<mohamed.boucadair@orange.com> Wed, 11 February 2015 07:00 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 184AD1A7D80 for <v6ops@ietfa.amsl.com>; Tue, 10 Feb 2015 23:00:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level:
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=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 pKfcTf6iSNN5 for <v6ops@ietfa.amsl.com>; Tue, 10 Feb 2015 23:00:19 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9712C1A710D for <v6ops@ietf.org>; Tue, 10 Feb 2015 23:00:18 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3F71D2AC7B7; Wed, 11 Feb 2015 08:00:17 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 197CB1800C8; Wed, 11 Feb 2015 08:00:17 +0100 (CET)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Wed, 11 Feb 2015 08:00:16 +0100
From: <mohamed.boucadair@orange.com>
To: "Heatley, Nick" <nick.heatley@ee.co.uk>, "Fred Baker (fred)" <fred@cisco.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Thread-Index: AQHQOxuJ94KoZb5URc+rHGKXMO3E0JzXBDUAgACFfoCAANnEAIAAGFgAgAAcc4CABr3FgIAA+7oAgArF1tA=
Date: Wed, 11 Feb 2015 07:00:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933004908DF9@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <8B808F0C-1AA8-4ABE-A06E-80652B9C1498@cisco.com> <B7D61F30-BAC4-4BE0-A5FD-1D4BD4652E55@employees.org> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <BF1BDC61-D8BD-4FB3-A111-070D9FF51F60@cisco.com> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.11.30323
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/tykwPk-nhxbVDWed_vKf8MIcU-E>
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: Wed, 11 Feb 2015 07:00:22 -0000

Hi Nick,

Thank you for sharing your thoughts. 

This is exactly the motivations for which we edited the first version of the cellular requirements draft. We wanted a document that gathers features shared by a group of operators. This scope and objectives have been explicitly called out since the initial version of the draft. The draft was adopted with that scope unchanged. 

As an editor of the draft, I'm open to address technical comments that would enhance the document. We already released an updated version that integrated the changes requested during this ongoing call. (BTW, I would like to publically thank F. Baker for his effort and guidance to solve one of the key issues raised during the IESG review.)

If there are other technical concerns or clarifications that need to be added to the draft, we are open to discuss how to address those.

Cheers,
Med

-----Message d'origine-----
De : Heatley, Nick [mailto:nick.heatley@ee.co.uk] 
Envoyé : lundi 9 février 2015 10:15
À : Fred Baker (fred); BOUCADAIR Mohamed IMT/OLN
Cc : draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops List; Ross Chandler (ross@eircom.net)
Objet : RE: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

Just a reminder on why I, as an operator, have a need of a document from the IETF. 
I desire:
- an IP profile from IETF - IETF is the home of IP and Internet Engineering (but happy to tie up with 3GPP etc.)
- a profile for mobile devices when the network offers them IPv6-only (dualstack will not get us beyond IPv4 exhaustion)
- a single recommended profile covering all mobile use cases  - handset cellular data, handset tethering, mobile broadband; an informational standard will suffice
- I will use this as a NORM in further discussions with terminal vendors. Yes, many operators will have further discussions with many terminal vendors, terminal software/configuration on the whole is fragmented.

Contrary to some of the views expressed ("that some IPv6 is out there in mobile land, therefore by induction all mobile issues are resolved") there are still some issues and grey areas.
As far as I know there are only a few open market device model "families", that may work IPv6-only with full backwards compatibility with IPv4, and provides stable tethering, and implement APN roaming controls.
For all other vendor models that are badged as IPv6, you need to request a per operator build. Will the relevant features in the build be the same for all operators, in all regions? How can one operator really say without some global norm to compare this to?
If the Google guy says it is all fine, that is great news. 
I'd feel better if the LG guy, Samsung guy, Apple guy, HTC guy etc. etc. all came on the V6Ops list with the same message.
Our devices teams do not normally get involved with such low level requirements as IP protocol versions. We have vendors that we haven’t even started talking to yet about IPv6.

Similarly, find me a mobile network where all IPv6-enabled terminal models are in IPv6-only mode for all use cases (c.f. cellular data, tethering, mobile broadband) using standards build.
Those are hard to find; as an industry we are not there yet. (No disrespect, this is due to business reasons: some operators have gone dualstack APN, some have another APN for tethering, some have chosen hardcoding of prefix64, some need a common APN for all  IP connectivity modes....). It is important to recognise the operator differences.

As one of the authors, we were advised by the WG that normative language was not appropriate for this document as it was a feature list /buffet of options/list document rather than a standard.
Fine, it is not a standard, it is not a problem to accept that and make that perfectly clear in the paper. 
But equally I would suspect that as it is not a standard this is why the document has expanded with all the best buffet of features available mandatory/optional/required for certain use cases. 
Now the document appears to be being blasted for exactly this extensive list of non-mandatory features. Is that fair? Has a steer been given here, and is everyone agreed on the steer?

The question in my mind is this, if we produce a document that focuses only on features for IPv6-only mode of operation (which I may support, not sure of other authors' positions), can we use normative language and produce an informational standard? Will that be more agreeable to the detractors?
If it could be done without resetting the process too far back and it turned opposition into support, then I'd support it.
I think the IPv6-only profile is more urgent than the equivalent IPv4v6 dual stack profile, based on my viewpoint, again I cannot speak for all authors.

Not having a NORM document, leaves the industry in a hole in my opinion. 
I hope we can find a timely way forward.
Regards,
Nick


-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred)
Sent: 03 February 2015 19:18
To: mohamed.boucadair@orange.com
Cc: draft-ietf-v6ops-mobile-device-profile.all@tools.ietf.org; V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call


> On Jan 30, 2015, at 4:21 AM, mohamed.boucadair@orange.com wrote:
> 
> With all due respect, I'm afraid we are not discussing whether the document is needed or not but (as I see it) whether the new version does not break the WG consensus that was declared for the version sent to the IESG. I recall that both the WG and IETF consensus were declared for the version sent to the IESG.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/history/

That’s not quite the way I recall it. In the WG, consensus has always been rough. I sent it out when the number of people stating a dissenting position dwindled. In the IETF LC in September 2013, James, Lorenzo, and Owen made comments that caused Joel to withdraw it from the IESG. In the IETF LC in September 2014 and subsequent IESG discussion, comments were raised by several in the IESG and summarized by Brian Haberman to the effect that the document has serious issues. https://datatracker.ietf.org/doc/draft-ietf-v6ops-mobile-device-profile/ballot/. In this round, you have tried to address the issues raised.

Before I bother the IESG with it a third time, I’d really like to hear a clear consensus, not a rough one. Where it stands right now, that’s not at all obvious.

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.