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

Alexandru Petrescu <> Wed, 11 February 2015 10:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 820641A87F2 for <>; Wed, 11 Feb 2015 02:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.983
X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UUeNkfROUgOT for <>; Wed, 11 Feb 2015 02:51:48 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 956F71A87E7 for <>; Wed, 11 Feb 2015 02:51:39 -0800 (PST)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t1BApbaR016136 for <>; Wed, 11 Feb 2015 11:51:37 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 20C80202CA7 for <>; Wed, 11 Feb 2015 11:52:30 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 192312007F6 for <>; Wed, 11 Feb 2015 11:52:30 +0100 (CET)
Received: from [] ( []) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t1BApYCI014482 for <>; Wed, 11 Feb 2015 11:51:37 +0100
Message-ID: <>
Date: Wed, 11 Feb 2015 11:51:34 +0100
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
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: Wed, 11 Feb 2015 10:51:50 -0000

Le 11/02/2015 11:08, Mark ZZZ Smith a écrit :

> The other thing I wonder about is what is so special about
> telephones (anymore)?

In principle yes - a smartphone is now as open as an IBM PC on a desk.
The end-user independently makes any software that s/he wants to run,
provided enough skill is present.

> They're fundamentally now nothing more than portable portable
> computers that just happen to also be used to make phone calls, as
> well as running many other types of applications. Their 3GPP
> link-layer interface is the only thing that makes them specifically
> different from any other portable computer, and I think the only
> real need to make IPv6 run on them would have been to prepare and
> update any 3GPP link characteristic specific IPv6 RFCs,

This draft is more than just making IPv6 work on it.  IPv6 already works
on many cell links and there are a couple IPv6-over-cellular RFCs present.

This draft makes some new requirements about additional matters of this
"IPv6" to work on these links.  These requirements are not so clear in
the older IPv6-over-cellular RFCs, although they are assumed true by
much protocol design happening in IETF.  They're just not stated anywhere.

And, regardless of these new requirements being clear in this draft,
there are still unknowns happening on 3GPP links - they are are maybe
left for future specifications (if ever the 3GPP links become open

> that in particular didn't invent new ways of doing what existing
> non-link specific IPv6 protocols could already do (e.g., PCOs for DNS
> instead of originally just stateless/stateful DHCPv6 and now
> (although mostly, in my opinion, unfortunately) RAs).
> It seems to me that if smartphone vendors need or needed guidance on
> what they should implement to support IPv6, they should be or should
> have been provided with the IPv6 Node Requirements RFC, and an RFC
> that specifies how to bootstrap IPv6 over an 3GPP link to the point
> where the non-link type specific standard IPv6 methods could be
> used, as all of the other IPv6 over Foo-link RFCs do. As major
> computer companies are now in charge of smartphone
> development/advancement, that is probably in effect what is mostly
> happening anyway.

Mark - there is a host of kinds of smartphone vendors: operators selling 
them, but also hw manufacturers and B2B resellers, integrators; their 
interests vary from pure IETF stds to pure 3GPP stds.

Even if this draft is titled "mobile device profile",
its reqs may well apply to a Machine which is not mobile at all (home 
automation) or provides mobility for others (trains).  Or apply to LTE 
USB keys connecting specialized platforms, very different than smartphones.

For me the important aspect, among its other contents, is that it puts 
DHCPv6 PD forward - I hope it will lead operators to support it.


> Regards, Mark.
> ------------------------------------------------------------------------
*From:* Lorenzo Colitti <>
> *To:* "<>" <>
> *Cc:* ""
> <>rg>; V6 Ops
> List <> *Sent:* Wednesday, 11 February 2015, 19:09
> *Subject:* Re: [v6ops] draft-ietf-v6ops-mobile-device-profile last
> call
> On Tue, Feb 10, 2015 at 11:31 PM, <
> <>> wrote:
> In case you missed the latest version (see the diff:
we addressed the changes YOU asked for and also those from James and
> Barbara (many thanks to them). __ __ What additional changes you
> would like to see added?
> I don't think minor changes to the document would cause me to
> support it.
> I have expressed my concerns about this document in the past. For
> example, I think the document is too broad (in fact, harmfully
> broad); places too much focus on what features to support and not
> enough focus on why; reads like a procurement spec and not a
> technical document. Pretty much what I said already at IETF last
> call -
> -
> and what I have been saying since we started discussing this
> document.
> The good news for this document is that it does not need my support
> to advance - one objection is not sufficient. IIRC the chairs/ADs
> have stated that they want to see "clear consensus" to support it,
> and if I were the only one objecting, then I suppose that would be
> clear consensus. After all, clear consensus does not mean unanimity.
> My observation of this thread, however, is that it's not just me
> objecting. Most clearly, Brian wrote that this reads like a
> procurement spec and not an IETF document. Gert wrote that he
> doesn't see a need for this document. James said he shares my
> general objections. And so on. You can't address that sort of
> objection with minor edits. And there doesn't seem to be lots of
> support for this document, either. I see one statement of support
> from someone who is not an author, and very little else from the rest
> of the WG.
> _______________________________________________ v6ops mailing list
> <>
> _______________________________________________ v6ops mailing list