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

[<[e-mail]>]

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

> -----Message d'origine-----
> De : v6ops [mailto:[e-mail]] De la part de Alexandru
> Petrescu
> Envoyé : mardi 3 mars 2015 10:57
> À : [e-mail]
> Objet : Re: [v6ops] comments on draft-ietf-v6ops-mobile-device-profile-19
> - M2M
> 
> Le 02/03/2015 10:35, [e-mail] 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."
> >
> > I lost the context why this sentence was removed from the draft.
> 
> 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:
> >
> > 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
> >>
> >
> > _______________________________________________ v6ops mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops