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

"Heatley, Nick" <> Mon, 09 February 2015 09:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D0BBD1A0102 for <>; Mon, 9 Feb 2015 01:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3oyFH2MkOmg1 for <>; Mon, 9 Feb 2015 01:14:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D003B1A00E5 for <>; Mon, 9 Feb 2015 01:14:53 -0800 (PST)
Received: from [] by id 9D/44-03165-B8A78D45; Mon, 09 Feb 2015 09:14:51 +0000
X-Originating-IP: []
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4991 invoked from network); 9 Feb 2015 09:14:51 -0000
Received: from unknown (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 9 Feb 2015 09:14:51 -0000
Received: from EEUKWV0941.EEAD.EEINT.CO.UK (Not Verified[]) by with MailMarshal (v7, 2, 3, 6978) (using TLS: SSLv23) id <B54d87a890002>; Mon, 09 Feb 2015 09:14:49 +0000
Received: from UK30S005EXS02.EEAD.EEINT.CO.UK (Not Verified[]) by EEUKWV0941.EEAD.EEINT.CO.UK with MailMarshal (v7, 2, 3, 6978) id <B54d87a8a0002>; Mon, 09 Feb 2015 09:14:50 +0000
Received: from UK30S005EXS06.EEAD.EEINT.CO.UK ([fe80::314c:b96c:4a9a:8a79]) by UK30S005EXS02.EEAD.EEINT.CO.UK ([2002:62c:2a4f::62c:2a4f]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 09:14:50 +0000
From: "Heatley, Nick" <>
To: "Fred Baker (fred)" <>, "" <>
Thread-Topic: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
Date: Mon, 9 Feb 2015 09:14:50 +0000
Message-ID: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK>
References: <> <> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, V6 Ops List <>
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Feb 2015 09:14:57 -0000

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.

-----Original Message-----
From: v6ops [] On Behalf Of Fred Baker (fred)
Sent: 03 February 2015 19:18
Cc:; V6 Ops List
Subject: Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last call

> On Jan 30, 2015, at 4:21 AM, 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.

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

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.