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

joel jaeggli <> Mon, 09 February 2015 17:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9AE3C1A1EE8 for <>; Mon, 9 Feb 2015 09:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CrqS-pH1DDQT for <>; Mon, 9 Feb 2015 09:40:32 -0800 (PST)
Received: from ( [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51BC51A6EED for <>; Mon, 9 Feb 2015 09:40:28 -0800 (PST)
Received: from mb-aye.local ( [] (may be forged)) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t19HeLjQ004029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Feb 2015 17:40:21 GMT (envelope-from
Message-ID: <>
Date: Mon, 09 Feb 2015 09:40:14 -0800
From: joel jaeggli <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0
MIME-Version: 1.0
To: "Heatley, Nick" <>, "Fred Baker (fred)" <>, "" <>
References: <> <> <20150129201251.GD34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902668@OPEXCLILM23.corporate.adroot.infra.ftgroup> <20150130103924.GG34798@Space.Net> <787AE7BB302AE849A7480A190F8B933004902889@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK>
In-Reply-To: <6536E263028723489CCD5B6821D4B21303DE865D@UK30S005EXS06.EEAD.EEINT.CO.UK>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mWRkdoDRHjfPD4wwwN62569WoelsNcqhR"
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 17:40:36 -0000

On 2/9/15 1:14 AM, Heatley, Nick wrote:
> 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.

Well it essentially started with this list of features, so I don't
accept that it has ballooned as product of non-normative language. If in
total one didn't it like before and the language change didn't mollify,
you probably still don't.

We have a channel for publishing non-consesus documents but it's not the
working group process. I believed, perhaps mistakenly that we could move
this to a more durable consensus on the basis of text changes to take it
away from requirements.

> 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 
> [] On Behalf Of Fred Baker (fred) Sent:
>  03 February 2015 19:18 To: 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.
> 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. 
> _______________________________________________ v6ops mailing list