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

t.petch <> Wed, 11 February 2015 17:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB38D1A1ABF for <>; Wed, 11 Feb 2015 09:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.654
X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_PROFILE1=2.555, SPF_HELO_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7c5dtClnHP8 for <>; Wed, 11 Feb 2015 09:59:55 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70F961A1AC1 for <>; Wed, 11 Feb 2015 09:59:47 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 11 Feb 2015 17:54:41 +0000
Received: from pc6 ( by ( with Microsoft SMTP Server (TLS) id; Wed, 11 Feb 2015 17:54:40 +0000
Message-ID: <041b01d04623$939416e0$>
From: t.petch <>
To: Mark ZZZ Smith <>, Lorenzo Colitti <>, <>
References: <> <>
Date: Wed, 11 Feb 2015 17:46:03 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Authentication-Results:; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062;
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DBXPR07MB062;
X-Forefront-PRVS: 0484063412
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(51444003)(66654002)(122386002)(14496001)(50226001)(50466002)(44736004)(86362001)(1456003)(40100003)(15975445007)(77096005)(81816999)(50986999)(81686999)(76176999)(62966003)(61296003)(42186005)(77156002)(116806002)(47776003)(87976001)(23676002)(92566002)(19580395003)(19580405001)(84392001)(62236002)(44716002)(66066001)(33646002)(2521001)(230783001)(46102003)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB062; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en;
X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB062;
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Feb 2015 17:54:40.4383 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB062
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB207;
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: Wed, 11 Feb 2015 17:59:59 -0000

----- Original Message -----
From: "Mark ZZZ Smith" <>
Sent: Wednesday, February 11, 2015 10:08 AM

I agree with Lorenzo and others, and this has made me wonder about
perhaps what might be different philosophies between e.g. the ITU and
the IETF regarding how to handle devices that have different versions or
feature revisions of protocols.

In the IETF, major and very significant differences are handled by using
a different protocol version, where as for less significant differences,
mandatory absolute minimums and supported option negotiation is used to
cope with those differences. This allows different versions or feature
revisions of different protocols to co-exist on a IPv6 node, to the
point where an individual node may have a unique combination of protocol
versions and protocol feature revisions that no other node has.

Reading through this draft and having looked a bit at the telephone
standards world, it seems the traditional telephony world has more of an
approach of 'profiles', which specify a snapshot of features across many
protocols at a particular time. This draft is stating them as
recommendations, perhaps to be more in line with the less prescriptive
approach of the IETF. In effect, I think profiles are like having major
version numbers, and therefore mandatory maximums, with no or very
little option negotiation.

The concern I have about this 'profiles' approach is that I think it
probably slows down deployment of new capabilities in the protocols to a
device, because doing so now stops it being "Profile XYZ.ABC" compliant.
Perhaps it stops a phone vendor from deploying new capabilities because
they have to wait until there is a profile that allows it. Perhaps they
can't deploy some more limited new capabilities because doing so would
cause them to have to try to comply with a later and newer profile, and
that then creates an obligation to support all of the newer profile's
capabilities, and the phone's hardware just can't support all of them.


I think that you make a good point but that there is another one
alongside it, that ITU-T Recommendations, at least in aggregate, are
much, much more complex than IETF RFC and so the idea of profiling them,
to produce something that can be implemented and interwork, is
desirable, if not necessary.

IETF RFC are, for the most part, much simpler and do not require such an
action.  MPLS-TP, perhaps not surprisingly, has a strong flavour of
ITU-T about it and does include profiles - it needed them.

IPv6?  Probably the most complex protocol, or family thereof, that the
IETF has produced, which, for me, is why the take up is so poor
(nonexistent around me, on a small offshore island:-).  So the idea of a
profile seems to be not just right, quite likely essential, to make IPv6
get deployed.

Tom Petch

The other thing I wonder about is what is so special about telephones
(anymore)? 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, 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.


 From: Lorenzo Colitti <>
 Sent: Wednesday, 11 February 2015, 19:09

On Tue, Feb 10, 2015 at 11:31 PM, <> wrote:

In case you missed the latest version (see the
file-15&url2=draft-ietf-v6ops-mobile-device-profile-16), 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
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.