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

Brian E Carpenter <> Thu, 29 January 2015 20:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 839BB1A6FFF for <>; Thu, 29 Jan 2015 12:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hnbt0XHJaWRc for <>; Thu, 29 Jan 2015 12:39:17 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 696B61A1A2C for <>; Thu, 29 Jan 2015 12:39:17 -0800 (PST)
Received: by with SMTP id rd3so43223449pab.3 for <>; Thu, 29 Jan 2015 12:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RKpbKYygLtwYax8ZjzzNtUyR7O5jmfjxzDYh+2IQ6uY=; b=qmny/6TyTyn7b4Bm9uN2NStwrJfuudBuSar8kDb7Srho4sBcUC9vSTT3XxHwBhJEl2 8J/HmlJD1KG8UNhGJfX2VBg+zDQR3ETK6xyI/J0OL3MRx+9Egt6dyy8U9B3vWywIbbIj sxRmyL6o9pkXJdTzRIckxqIuQFCqpBKGBLnsmx8GZRaQ6V3MXUcV5MiN5xo+siTqsXjW O0Othq6Ns2j/04ehgObPIeMYuVsR1kmnzQe1UNyaygq0FA5iVHbxEZUYSLNCz8MrEObF q56Y7OJztNl9MFa37X4qpzxbSBaViAH51hu4RMMpkqG98r+jFV4Dcve7ZZvblEZuKP1q 9dcg==
X-Received: by with SMTP id n4mr3406781pdg.85.1422563956701; Thu, 29 Jan 2015 12:39:16 -0800 (PST)
Received: from ?IPv6:2401:c80:3:0:28cc:dc4c:9703:6781? ([2401:c80:3:0:28cc:dc4c:9703:6781]) by with ESMTPSA id di10sm8721311pad.41.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 12:39:15 -0800 (PST)
Message-ID: <>
Date: Fri, 30 Jan 2015 09:39:19 +1300
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Lorenzo Colitti <>, "Fred Baker (fred)" <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
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: Thu, 29 Jan 2015 20:39:19 -0000

To be honest I stopped tracking this draft a long time ago,
so didn't speak up during the first WGLC. But I think I'm
in the rough with Lorenzo. The document reads like somebody's
procurement spec, not like a set of recommendations for
generic interoperability. And the devil is in the details.
For example, I noticed a point where I have a little skin
in the game:

   APP_REC#3:  Applications provided by the mobile device vendor that
               use Uniform Resource Identifiers (URIs) must follow
               [RFC3986].  For example, SIP applications must follow the
               correction defined in [RFC5954].

So, does that requirement include the updates to RFC 3986 (i.e. RFC 6874
and 7320)? And how is applying a correction to RFC 3261 an "example"
of following RFC 3986? And anyway, shouldn't this be in a SIP profile,
not here?

That's an illustration of why this document positioned as an IETF work
product makes me uncomfortable. I imagine there are many other similar
hidden issues.


On 30/01/2015 00:53, Lorenzo Colitti wrote:
> On Thu, Jan 29, 2015 at 1:57 AM, Fred Baker (fred) <> 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?
> 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.
> 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.,
> - 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.
> 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.
> Regards,
> Lorenzo
> _______________________________________________
> v6ops mailing list