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

From: <[email-masked]>
Date: Mon, 2 Mar 2015 09:35:09 +0000

Hi Barbara,

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de STARK, BARBARA H
> Envoyé : samedi 28 février 2015 19:44
> À : [email-masked]
> 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
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2015 10:56:46 +0100

Le 02/03/2015 10:35, [email-masked] a écrit :
[...]
>> 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."
>

Med, I dont know either.  But I think we may have a more important
problem here that we try to overlook somehow by putting M2M devices out
of scope.

The problem is that these M2M devices connect to the same cellular
network, and practically in almost the same way, as the smartphones do.
  The main differences are in the way of billing, and the data rates
afforded.

Another problem lies in an apparent difficulty we have in defining what
an M2M device is with respect to IP networking, although we do know they
are full IP (as opposed to other IoT devices which are hardly IP or not
IP at all).

I think it would be advantageous to include M2M devices in this device
profile draft.

If so, we can start by conceptualizing in the text the fact that 3GPP is
just an interface, not a computer per se.  This interface can be added
to computers like a smartphone, larger computers like a laptop, or
smaller computers like the Sierra Wireless Air Prime (one notable
M2M-class device in wide use with open source; there are others).

It would be necessary also to describe how on the market M2M devices are
only IPv4, and only smartphones are IPv6, today.

Alex

>
> 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:
>
> 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.).
>
> 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].
>>
>
>> 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].
>
> 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.
>
> 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.
>
>> [1] http://en.wikipedia.org/wiki/Customer-premises_equipment [2]
>> http://searchnetworking.techtarget.com/definition/customer-premises-
>>
>>
>>
>>
equipment
>>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: <[email-masked]>
Date: Tue, 3 Mar 2015 10:11:38 +0000

Hi Alex, 

I'm all with you about the importance of having a profile for M2M devices but I'm also hearing what is expressed by some WG participants who are asking to restrict the scope of this I-D. Their comments is fair, too.

IMHO, incorporating M2M specificities should be conducted in coordination with other WGs covering M2M-related matters. That will require more work. 

I'm afraid reconciling both positions in the same profile I-D is unlikely.

A way to proceed is to edit a dedicate M2M profile document that can rely on this one (tag which recommendations from the RFC6434, RFC7066, and mobile-profile I-D are relevant for a pure M2M context + identify more items that are M2M-specific).

Hope you understand the constraints we have as editors.

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Alexandru
> Petrescu
> Envoyé : mardi 3 mars 2015 10:57
> À : [email-masked]
> Objet : Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19
> - M2M
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops