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

[<[e-mail]>]

Hi Barbara,

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[e-mail]] De la part de STARK, BARBARA H
> Envoyé : samedi 28 février 2015 19:44
> À : [e-mail]
> Objet : [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19
> 
> 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.

[Med] Why is this unique to this draft? Your statement applies for every document of this kind.

> 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.

[Med] M2M-specific considerations are out of scope of this I-D. We had this sentence in the draft (http://tools.ietf.org/html/draft-ietf-v6ops-mobile-device-profile-00): "M2M devices profile is out of scope."

I lost the context why this sentence was removed from the draft. 

 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 archit
>  ectures"
>   is not an approach I would recommend.

[Med] That exercise is needed anyway (including identifying which parts from RFC6434 and RFC7066 are to be included in the list) . The question is whether this I-D helps in simplifying that exercise or not. This draft positions itself as follows:

   This profile is a superset of that of the IPv6 profile for 3GPP
   Cellular Hosts [RFC7066], which is in turn a superset of IPv6 Node
   Requirements [RFC6434].

The service provider you are referring to needs to figure out which parts from RFC6434, RFC7066, and this I-D are to be included in his list. This I-D completes RFC6434 and RFC7066 with IPv6-related features lists functions that are not captured in existing RFCs (e.g., PDP part, TFT support, VoLTE profile, etc.). 

This I-D is a "helper" for SPs to customize their list. This is explicitly called out in the I-D:

   2.  Help Operators with the detailed device requirement list
       preparation (to be exchanged with device suppliers).  This is
       also a contribution to harmonize Operators' requirements towards
       device vendors.

> 
> 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].
> 

[Med] What's the problem with this recommendation?

> 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.

[Med] As said above, this kind of devices is not the target of this I-D. We can make this more clearer.

> 
> 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.

[Med] I don't understand this point.

> 
> ---------
> 
> 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]. 

[Med] The I-D includes this sentence: 

                There are several deployments, particularly in emerging
                countries, that relies on mobile networks to provide
                broadband services (e.g., customers are provided with
                mobile CPEs).


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 def
>  inition.
>   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.

[Med] Can you elaborate why L_REC#2 is not recommended for those?

FWIW, the I-D includes this text:

                This recommendation does not apply to handsets with
                tethering capabilities; it is specific to cellular CPEs
                in order to ensure the same IPv6 functional parity for
                both fixed and cellular CPEs.  Note, modern CPEs are
                designed with advanced functions such as link
                aggregation that consists in optimizing the network
                usage by aggregating the connectivity resources offered
                via various interfaces (e.g., DSL, LTE, WLAN, etc.) or
                offloading the traffic via a subset of interfaces.
                Mutualizing IPv6 features among these interface types is
                important for the sake of specification efficiency,
                service design simplification and validation effort
                optimization.

 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
>