[v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19

"STARK, BARBARA H" <bs7652@att.com> Sat, 28 February 2015 18:44 UTC

Return-Path: <bs7652@att.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626DE1A7D81 for <v6ops@ietfa.amsl.com>; Sat, 28 Feb 2015 10:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7fF_40MbIPb for <v6ops@ietfa.amsl.com>; Sat, 28 Feb 2015 10:44:11 -0800 (PST)
Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBDA1A026F for <v6ops@ietf.org>; Sat, 28 Feb 2015 10:44:10 -0800 (PST)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id a7c02f45.0.257173.00-2353.709459.nbfkord-smmo07.seg.att.com (envelope-from <bs7652@att.com>); Sat, 28 Feb 2015 18:44:10 +0000 (UTC)
X-MXL-Hash: 54f20c7a3a1300f6-02e87d213563a542c1348fa3af16870dbd236f90
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1SIi9m5023325 for <v6ops@ietf.org>; Sat, 28 Feb 2015 13:44:09 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t1SIi38S023303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <v6ops@ietf.org>; Sat, 28 Feb 2015 13:44:06 -0500
Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (GAALPA1MSGHUBAH.itservices.sbc.com [130.8.218.157]) by alpi132.aldc.att.com (RSA Interceptor) for <v6ops@ietf.org>; Sat, 28 Feb 2015 18:43:48 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.149]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0224.002; Sat, 28 Feb 2015 13:43:48 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: comments on draft-ietf-v6ops-mobile-device-profile-19
Thread-Index: AdBTanJNvJBbZ0pnRLOCo1ESaXFM+A==
Date: Sat, 28 Feb 2015 18:43:46 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E61130F42835@GAALPA1MSGUSRBF.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.115.187]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=EvxlW1gA c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=zhobYCeBVNkA:10 a=yy6f1W50eQUA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=0HtSIViG9]
X-AnalysisOut: [nkA:10 a=8pif782wAAAA:8 a=-tGrwHRrAAAA:8 a=l37wT53hQxIhjg_]
X-AnalysisOut: [qZiwA:9 a=CjuIK1q_8ugA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <bs7652@att.com>
X-SOURCE-IP: [144.160.229.23]
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/SU0xI2xyBlg4bJP2yhA5JGsHeQU>
Subject: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Feb 2015 18:44:13 -0000

I've read through this draft and have some comments. I focused mostly on "must" requirements, because it's always easy to justify not doing a "should". The authors are free to change nothing as a result of my comments. I'm not voicing opposition. I'm simply expressing in more detail why I would not recommend to my employer (or any other service provider) that they use this draft as an RFC reference without very careful thought as to the desirability of each requirement.
Barbara

---------
Note that the term "[3GPP] cellular host" includes a wide variety of devices, including those which are considered "IoT" or "M2M" (such as tracking/locating devices, health monitors, eReaders, automobiles, etc.). Some of these devices are intended (by the service provider who procures them) to be used with a service that does not support roaming to other providers'  networks. Some are single function devices, where the function is fully specified at time of procurement. These devices are generally intended to be as low-complexity and energy-efficient as possible. If a service provider is creating an RFP for such a device, that service provider would be best advised to figure out their IPv6 architecture before sending out an RFP with any of the requirements in this draft. For a service provider to say "I have no clue what my IPv6 architecture is going to be, so I want to require even the simplest and lowest complexity cellular hosts to have support for all possible IPv6 architectures" is not an approach I would recommend. 

But that is exactly what this draft recommends:
   C_REC#1:  In order to allow each operator to select their own
             strategy regarding IPv6 introduction, the cellular host
             must support both IPv6 and IPv4v6 PDP-Contexts [TS.23060].

There are also other requirements which appear to impose complexity on low-end non-roaming/single-purpose cellular hosts in order to allow the service provider maximum flexibility in ultimately deciding on an IPv6 architecture. I'm not enough of a cellular expert to be able to properly identify all of these.

As for cellular hosts that do roam, I think the service provider needs to put some thought into how important it is for such devices to support all IPv6 architectures. I'm not fully convinced that it won't be acceptable to users of low-end cellular hosts that do roam to just do IPv4 on networks with unsupported IPv6 architectures. 

---------

CPE (Customer Premises Equipment): The draft does provide the acronym expansion of CPE, but does not define the term. Given the context in which the draft uses the term, I suspect that the authors are not intending a definition consistent with that at, for example, [1] and [2]. The first of these references includes the sentence "CPE generally refers to devices such as telephones, routers, switches, residential gateways (RG), set-top boxes, fixed mobile convergence products, home networking adapters and Internet access gateways that enable consumers to access communications service providers' services and distribute them around their house via a local area network (LAN)." The second includes the sentence "Today, almost any end-user equipment can be called customer premise [sic] equipment and it can be owned by the customer or by the provider." But the set of CPE that could also reasonably be expected to include a 3GPP interface are, of course, much smaller than this broad definition. One such piece of CPE, though, is a home automation/security gateway that interfaces with various monitoring, automation, and security devices. Such CPE have both an Ethernet WAN interface (that allows them to be behind the CE router) and a 3GPP interface (for backup and perhaps some other management purposes). Since these are "CPE" and "cellular" and they provide LAN connectivity to various home automation devices, they would appear to fall under the requirements of Section 3, and specifically those that apply to "cellular CPE". I would not recommend applying RFC 7084 to such CPE. If "CE router" is intended, instead of all devices that can be classified as "CPE", then I suggest using the term "CE router". 

[1] http://en.wikipedia.org/wiki/Customer-premises_equipment 
[2] http://searchnetworking.techtarget.com/definition/customer-premises-equipment 

--------

Discussion as to which device requirements the authors are really trying to drive seems to be largely focused on smartphones. Given there has been no input from most smartphone OS providers and opposition from people associated with one smartphone OS, IMO this draft will not be a useful mechanism for driving these requirements into smartphone OSs.