Subject: Re: [v6ops] Review of draft-ietf-v6ops-mobile-device-profile-01

From: <[email-masked]>
Date: Tue, 23 Apr 2013 08:08:05 +0200

Hi Jouni,

Many thanks for the review.

My answers inline.
Cheers,
Med

>-----Message d'origine-----
>De : Jouni Korhonen [mailto:[email-masked]]
>Envoyé : vendredi 19 avril 2013 10:08
>À : [email-masked] Operations; draft-ietf-v6ops-mobile-device-
>[email-masked]
>Objet : Review of draft-ietf-v6ops-mobile-device-profile-01
>
>Hi,
>
>I did a review of draft-ietf-v6ops-mobile-device-profile-01. Below are
>my comments. They are rather long, sorry about that ;)
>
>- JOuni
>
>---------------------------------------------------------------------
>
>1) General notes
>
>o The I-D mixes (throughout) PDP context, PDP Context, PDP-Context.
> suggest to use PDP-Context. (I have not noted any of those in
> the comments below)
[Med] Fixed.

>o The I-D mixes (throughout) dual-stack and dual stack. Suggest
> to choose one style; like dual-stack. (I have not noted any of
[Med] Fixed.

> those in the comments below)
>o The I-D uses both RFC3316 and draft-ietf-v6ops-rfc3316bis. Suggest
> to use only the latter one.
[Med] The text will be tweaked.

>o The I-D uses a "mobile device" in places where it should really say
> a "cellular device". Use consistent wording.
[Med] Will check the text.

>o The I-D uses a "mobile network" where it should really use "cellular
> network". In places where the network can be cellular or some other
> wireless technology, I would use "wireless network" as a generic
> term.
[Med] The text twill be checked.

>o The use of GGSN and PDN-GW should have more consistency. For example
> using GGSN/PGW throughout..
[Med] OK.

>
>2) Abstract
>
>  This document specifies an IPv6 profile for mobile devices.  It lists
>                                              ^^^^^^^^^^^^^^
>  the set of features a mobile device is to be compliant with to
>                        ^^^^^^^^^^^^^

[Med] changed to "This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network)."

>
>o The document really is more about cellular devices than arbitrary
> mobile device. Suggest to reword "cellular devices".

[Med] As suggested by Teemu, "3GPP mobile devices" is used instead.

>
>  connect to an IPv6-only or dual-stack mobile network.
>                                        ^^^^^^^^^^^^^^
>o Since both cellular and Wi-Fi network are in scope, maybe
> saying "wireless networks" would be more appropriate?

[Med] See the proposed change above.

>
>  This document defines a different profile than the one for general
>  connection to IPv6 mobile networks defined in [RFC3316].  In
>                     ^^^^^^^^^^^^^^^            ^^^^^^^^^
>o RFC3316 is about cellular network. Even the RFC title says that.
>o Use RFC3316bis reference rather than RFC3316.

[Med] Will check the text and update when appropriate.

>
>  particular, this document identifies also features to ensure IPv4
>  service continuity over an IPv6-only transport.
>  ^^^^^^^^^^^^^^^^^^
>o Service continuity is IMHO overloaded in IPv6 space with
> Mobile IPv6 and similar. Suggest to use "service availability".

[Med] changed the wording to "deliver IPv4 connectivity service".

>
>3) Section 1 - Introduction
>
>  IPv6 deployment in mobile networks is the only perennial solution to
>                     ^^^^^^^^^^^^^^^
>o Suggest to use wireless networks.

[Med] OK.

>
>  operators already deployed IPv6 or are in the pre-deployment phase.
>        ^^^^^^^^
>o "..have already deployed.."

[Med] Fixed.

>
>  Some vendors are already proposing some mobile devices with a set of
>                                          ^^^^^^^^^^^^^^
>o Suggest using cellular devices.
>
>  Some vendors are already proposing some mobile devices with a set of
>  IPv6 features, but the majority of devices are still lacking IPv6
>  support.
>
>o For a profile or requirements, I would remove text like this
> since in few years time it will be outdated. Rather reword it
> stating the fact that cellular devices plain need to have IPv6
> enabled if they don't already have it.

[Med] Makes sense. Removed.

>
>  connection to IPv6 mobile networks defined in [RFC3316]; in
>                     ^^^^^^                      ^^^^^^^^
>  ...
>     implement basic IPv6 features in a mobile context.
>                                        ^^^^^^^
>o s/mobile/cellular. And reference to RFC3316bis

[Med] Fixed.

>
>  o  It identifies also features to ensure IPv4 service continuity over
>                                                ^^^^^^^^^^^^^^^^^^
>o Suggest using "service availability" to make a clear distinction
> to IP mobility..

[Med] Changed to "IPv4 service delivery"

>
>  required specifications produced by various SDOs (in particular 3GPP
>                                              ^^^^
>o Expand SDO on the first occurrence.

[Med] Fixed.

>
>      IPv6 connectivity and IPv4 service continuity (over an IPv6- only
>                                                             ^^^^^^^^^^
>o s/IPv6- only/IPv6-only

[Med] Fixed.

>
>4) Section 1.1 - Scope
>
>  user equipment such as a mobile telephone, a CPE or a machine-to-
>                                               ^^^^
>o Expand CPE on the first occurrence.

[Med] Fixed.

>
>  The requirements listed below are valid for both 3GPP GPRS and 3GPP
>  EPS access.  For EPS, "PDN type" terminology is used instead of "PDP
>  ^^^                    ^^^^^^^^
>  context".
>
>o Expand EPS on the first use and give a reference.
>o I assume this is supposed to be "PDN-Connection" not "PDN Type" ??
>o Expand GPRS on the first use.

[Med] Fixed. I didn't cited any ref as the document already points to RFC6459.

>
>5) Section 2 - Connectivity Requirements
>
>  REQ#2:  The cellular host MUST support both IPv6 and IPv4v6 PDP
>       Contexts.
>
>o for a MUST requirement I would like to see the 3GPP release to
> which this applies.

[Med] Like for other requirements, we avoided to mention the release as suggested by Mickael (check the v6ops ml archives).

>o there are also cases where IPv6-only cellular host is justified,
> thus I would point back here in the text to e.g. Section 1.1
> M2M scope clarification/narration.
>
>  REQ#3:  The cellular host MUST comply with the behavior defined in
>       [TS.23060] [TS.23401] [TS.24008] for requesting a PDP context
>
>o The list of references neglect non-3GPP accesses (TS.23402). I am fine
> with that but you should state it in e.g. Section 1.1 scoping that
> non-3GPP accesses except for some exceptions (Wi-Fi without 3GPP
> flavour) are out of scope.

Med: Section 1.1 states explicitly both 3GPP accesses and WLAN are in scope. No need to have an explicit reference to TS.23402.

>
>       the cellular host is not aware of connectivity types requested
>       by devices connected to it (e.g., cellular host with LAN
>       capabilities):
>
>o I would clarify this part of the text a bit more. The text in 3GPP
> standards are mostly coming from the Split-UE background where MT and
> TE are separate, not from tethering. Therefore, some rewording is
> needed here. As such the current text is not acceptable.

Med: I added an explicit reference to Section 4 in the example listed in the text you quoted.

>
>          cellular host will be configured with an IPv4 address and/or
>                        ^^^^^^^
>o s/will be/MAY be. There is no guarantee that an UE would always open
> two PDPs.

[Med] As suggested by Teemu "and/or" was changed to "or". As such, "will be" is accurate.

>
>          an IPv6 prefix by the network.  It MAY initiate another PDP
>                                                                  ^^^
>          request in addition to the one already activated for a given
>          APN.
>          ^^^^
>o "PDP request" I would use different wording like "PDP-Context activation"
>o Expand APN on the first occurrence.

[Med] Fixed.

>
>          Traffic Flow Templates are employing a Packet Filter to
>                                                 ^^^^^^^^^^^^^
>o "packet filter" ?
>
>          PDP-Context and radio resources can be provided by the mobile
>          network for certain IP traffic.                        ^^^^^^
>
>o s/mobile network/cellular network

[Med] Fixed.

>
>          This is a stronger form compared to what is specified in
>          Section 12.2 of [RFC6434].  The support of Neighbor Discovery
>          ^^^^^^^^^^^^
>o Section 5.2 should also be referenced here since e.g. RFC5942 is
>mentioned
> in there rather than in Section 12.2.

[Med] Done, thanks.

>
>          In particular, MTU communication via Router Advertisement
>                         ^^^^
>o Expand MTU on the first occurrence.

[Med] Fixed

>
>          standard MTU setting due to inconsistencies in GTP [RFC3314]
>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Expand GTP on the first occurrence.
>o It is unclear what the "inconsistencies in GTP" are. The RFC3314
> definitely does not tell a thing about that. Also give a reference
> to a proper GTP specification(s).

[Med] re-used the same pointers as in RFC6459.

>
>  REQ#8:  The cellular host MUST support IPv6 Stateless Address
>       Autoconfiguration ([RFC4862]) apart from the exceptions noted in
>       [TS.23060] (3G) and [TS.23401] (LTE):        ^^^^^^^^^^^
>                  ^^^^                 ^^^^
>o What are the exceptions? If you mean the restrictions in 3GPP SLAAC
> point to other documents like RFC6459 or RFC3316bis that detail those
> out.
>o s/3G/GPRS
>o s/LTE/EPS
[Med] Fixed.

>
>          The cellular host MUST use the interface identifier sent in
>                                         ^         ^
>o s/interface identifier/Interface Identifier. For the consistency..
[Med] OK.

>
>          PDP Context Accept message to configure its link local
>          ^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Suddenly referencing to specific 3GPP signaling messages seems odd
> here. I suggest to reword "3GPP PDP-Context setup signaling from
> a GGSN/PGW to the cellular host" or something to that direction.
[Med] changed to "To configure its link local address, the cellular host MUST use the Interface Identifier conveyed in 3GPP PDP-Context setup signaling received from a GGSN/PGW."

>
>  REQ#9:  The cellular host must comply with Section 7.3 of [RFC6434].
>                            ^^^^
>o s/must/MUST
[Med] Fixed.

>o Generally about the "Req#9". The motivational text following the
> requirement title is not imho needed. The MUST for Section 7.3 of
> RFC6434 is quite clear.
[Med] No problem to remove it from my side.

>
>  REQ#10:  The cellular host must comply with Section 7.2.1 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed.

>
>          1.  PCP
>          ^^^^^^^
>o I assume PCO is meant here?
[Med] Yes, this was a typo.

>
>       Translator (CLAT, [I-D.ietf-v6ops-464xlat]) function which is
>                          ^^^^^^^^^^^^^^^^^^^^^^^
>o RFC6877 yay!
[Med] Done.

>
>          application and IPv4-referals to work on an IPv6-only PDP.
>                                                      ^^^^^^^^^^^^^
>o I suggest replacing PDP with "network" or "access network" or
> "PDP-Context".
[Med] changed to "connectivity"

>
>          DNSSEC.  Means to configure or discover a PREFIX64 is also
>          ^^^^^^^                                            ^^^^^^^
>          required on the cellular device.
>          ^^^^^^^^
>
>o Add a reference to DNSSEC.
[Med] Add pointers to RFC4033, 4034 and 4035.

>o Pref64 discovery is already SHOULDed in Req11. Mentioning it here
> again seems unnecessary repetition.
[Med] As suggested by Teemu a reference to REQ#11 was added to the text.

>
>          The support of PCP is seen as a driver to save battery
>                                          ^^^^^^^^^^^^^^^^^^^^^^
>          consumption exacerbated by keepalive messages.  PCP also
>
>o This is a strong statement. Do we have documented proof of that?
> PCP itself does not solve or even help that much the battery
> savings since the host side applications still need to coordinate
> among themselves and it is a different issue & problem.

[Med] The text only says "is seen as a driver to save battery. This text is basically restating what is included on the base PCP spec: " This helps reduce bandwidth on the subscriber's
   access network, traffic to the server, and battery consumption on
   mobile devices. "

>
>  REQ#15:  When the cellular host is dual stack connected, it SHOULD
>                                     ^^^^^^^^^^^^^^^^^^^^^
>o Using what mechanisms? Two PDPs? IPv4v6 PDP or XLAT? Or should we
> actually not care? Some clarification would be nice here, though.

[Med] i.e., configured with an IPv4 address and IPv6 prefix. Text is updated now.

>
>          [I-D.ietf-mif-happy-eyeballs-extension] for MIFed devices.
>                                                      ^^^^^
>o Care to expand..
[Med] Teemu suggested to remove the MIF reference...which I accepted.

>
>  REQ#17:  The cellular host SHOULD NOT perform Duplicate Address
>       Detection (DAD) for these Global IPv6 addresses (as the GGSN or
>       PDN-GW must not configure any IPv6 addresses using the prefix
>       allocated to the cellular host).  Refer to Section 4 for DAD
>       considerations on the LAN interface when the 3GPP connection is
>       shared.
>
>o This is already in RFC6459 and RFC 3316(bis). No need to repeat the
> requirement here again and Section 4 deals with the specific case
> that is not in the previously mentioned RFCs. I suggest removing
> the Req17.

Med: Done.

>
>6) Section 2.1 - Wi-Fi Connectivity
>
>2.1.  WiFi Connectivity
>                       ^^^^^^^^
>o Why not adding "Requirements" here as well?
[Med] Done.

>
>  REQ#19:  IPv6 MUST be supported on the Wi-Fi interface.  In
>         particular, IPv6-only connectivity MUST be supported over the
>         Wi-Fi interface.
>
>o Suggest rewording "..Wi-Fi interface without configuring IPv4
> on the interface."
>
>            Recent tests revealed that IPv4 configuration is required
>            to enable IPv6-only connectivity.  Indeed, some cellular
>            handsets can access a Wi-Fi IPv6-only network by
>            configuring first a static IPv4 address.  Once the device
>            is connected to the network and the wlan0 interface got an
>            IPv6 global address, the IPv4 address can be deleted from
>            the configuration.  This avoids the device to ask
>            automatically for a DHCPv4 server, and allows to connect to
>            IPv6-only networks.
>
>o I would delete this and just state that "Failing to configure an
> IPv4 address on the interface MUST NOT prohibit using IPv6 on the
> same interface."
[Med] "Recent test.." is now changed to " Some tests..".  I didn't removed that text as it provides the context. I added the explicit sentence you proposed.

>
>
>7) Section 3 - Advanced Requirements
>
>  REQ#22:  The cellular host must comply with Section 5.6.1 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed

>
>  REQ#23:  The cellular host must comply with Section 5.9.3 of
>                             ^^^^
>o s/must/MUST
[Med] Fixed.

>
>            permanent interface identifier.  [RFC4941] does not require
>            any DAD mechanism to be activated as the GGSN (or PDN-GW)
>            MUST NOT configure any global address based on the prefix
>            allocated to the cellular host.
>
>  REQ#24:  The cellular host SHOULD support ROHC for IPv6 ([RFC5795]).
>
>o I would say which ROHC profiles SHOULD be supported. It makes no sense
> to require all, since IMHO ROHC has limited benefit in 3G/LTE. I would
> strongly recommend aligning this requirement to GSMA PRD.92.

Med: Profile 1 and 2 are explicitly included in the REQ now.

>
>o IMHO no need to repeat the DAD behaviour. I strongly suggest removing
> the last sentence.
>
>            This is a stronger form compared to what is specified in
>            [RFC6434].  The justification is some flags are used by the
>            GGSN (or PDN-GW) to inform cellular hosts about the
>            autoconfiguration process.
>            ^^^^^^^^^^^^^^^^^^^^^^^^^^
>o Care to reveal the flags that do the justification? What are told now
> by GGSNs/PGWs more in extended flags? I am OK with the requirement as
> such but the justification text is just confusing. I suggest removing
> it.
>
>  REQ#26:  The cellular host must comply with Section 5.3 of [RFC6434]
>                             ^^^^
>o s/must/MUST
[Med] Done.

>
>8) Section 4 - Cellular Devices with LAN Capabilities
>
>4.  Cellular Devices with LAN Capabilities
>                         ^^^
>o So this is strongly about LAN, not WLAN?
>
>  are sharing the same GPRS, UMTS or EPS connection.  In addition to
>                       ^^^^  ^^^^    ^^^
>o s/GPRS/2G
>o s/UMTS/3G
>o s/EPS/LTE
[Med] OK, done.

>
>            WAN and the Delegated Prefix to be aggregatable, so the
>            ^^^
>o Expand WAN on the first occurrence.
[Med] Done.

>
>            (e.g., halving the Delegated prefix and assigning the WAN
>                              ^^^
>o s/Delegated/delegated
[Med] Fixed.

>
>         requirements specified in [RFC6204].
>                                    ^^^^^^^
>o I would suggest referencing to RFC6204bis since it has some language
> that takes cellular network particularly into considerations.

Med: RFC6204 is sufficient.

>
>            reduced to 1440 bytes.  While a host may generate packets
>                       ^^^^^
>o TS.23060 has specific MTU size recommendations. I would reference to
> that and also "reveal" the number stated in there.
[Med] Done.

>
>9) Section 5 - APIs & Applications
>
>  REQ#33:  Applications MUST be independent of the underlying IP
>         address family.
>
>o I think SHOULD/RECOMMENDED with some stressing would be more
> appropriate. There could be cases where IP version specific
> software is justified, e.g. diagnostic tools and such.. Maybe
> "MUST be independent of the underlying IP address family,
>  unless done purposely address family specific for a specific
>  reasons."

[Med] IMO, adding exceptions will nullify the REQ.

>
>10) Section 6 - Security Considerations
>
>  The security considerations identified in [RFC3316] are to be taken
>                                            ^^^^^^^^^
>o Use RFC3316bis and also reference to RFC6459 that has some additional
> security considerations to RFC3316.

[Med] Ok, done.

---

From: t.petch <[email-masked]>
Date: Tue, 23 Apr 2013 18:04:18 +0100

That's a lot of work and a lot of changes, which makes me think I have
missed the boat but ....

'Cellular' has always been to me one of those quaint Americanisms that
the rest of us have to put up with because America is, well,
America:-(  Indeed, even Wikipedia, which I would regard as the epitome
of American, goes so far as to reroute 'cellular phone' to 'mobile phone
also known as cellular' so mobile must be understood by some Americans!

So why go for cellular rather than mobile?  And I see a mix of cellular
host and cellular device - are they different?  (I note that in the
rfc-index, usage of 'mobile' vastly outweighs that of 'cellular').

At the very least, I think that s1.2 should be expanded to give a brief
summary of what you mean, what makes a 'cellular host' cellular and (if
not consistent with RFC1122), a host, ditto mobile network, etc etc

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "Jouni Korhonen" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 23, 2013 7:08 AM

Hi Jouni,

My answers inline.
Cheers,
Med

[Med] Fixed.

[Med] Fixed.

[Med] OK.

>  This document specifies an IPv6 profile for mobile devices.  It lists

[Med] changed to "This document specifies an IPv6 profile for 3GPP
mobile devices. It lists the set of features a 3GPP mobile device is to
be compliant with to connect to an IPv6-only or dual-stack wireless
network (including 3GPP cellular network and IEEE 802.11 network)."

<snip>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 23 Apr 2013 10:47:49 -0700

> also known as cellular' so mobile must be understood by some Americans!
Cellular e.g. the 70s, at the time distinguished between VHF  radio 
phone systems, and more geographically limited (e.g. cellular) services 
serviced by more than one transceiver...

Parts of the united states have had radio mobile phone service since 1946.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Apr 2013 11:15:31 -0700

On 04/23/2013 10:04 AM, t.petch wrote:
> America:-(

One could just as easily apply the reverse logic, where us Americans 
have to put up with the fact that Europeans[1] make gratuitous changes 
to simple terms just so that they can avoid having to use the same words 
Americans use to refer to the same things.[2]

Neither perspective is totally accurate, but consider this an FYI that 
your gratuitously anti-American perspective is at least as grating to me 
as you seem to find our use of language.

My point being that rather than concentrating on how annoying Americans 
are, it would be infinitely more useful to phrase your proposal as, "The 
term 'mobile' is used much more commonly than the term 'cellular,' 
perhaps the draft should reflect that usage," which is a perspective I 
think even us annoying 'murricans would agree with.

Doug

[1] I am fully aware that most British don't consider themselves "European"
[2] Add bonus points for all such things actually invented in America

---

From: Teemu Savolainen <[email-masked]>
Date: Tue, 23 Apr 2013 21:33:19 +0300

My comment against simple term of "mobile" stems from the idea that many
kinds of devices can be mobile in sense of moving, but also in the sense of
using some mobile technology (3GPP, 3GPP2, WiMAX...) . This document
applies only to mobiles in the 3GPP domain and hence that should be stated
clearly out (e.g. saying "3GPP mobiles, henceforth referred as mobiles,
need to...").

Teemu
On Apr 23, 2013 9:15 PM, "Doug Barton" <[email-masked]> wrote:

> One could just as easily apply the reverse logic, where us Americans have
> to put up with the fact that Europeans[1] make gratuitous changes to simple
> terms just so that they can avoid having to use the same words Americans
> use to refer to the same things.[2]
>
> your gratuitously anti-American perspective is at least as grating to me as
> you seem to find our use of language.
>
> term 'mobile' is used much more commonly than the term 'cellular,' perhaps
> the draft should reflect that usage," which is a perspective I think even
> us annoying 'murricans would agree with.
>
> Doug
>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 24 Apr 2013 14:48:21 +0300

Hi Med,

Thanks for the response. I have few comments back. I deleted
almost everything that I agreed with. See inline..

- JOuni

> [Med] Like for other requirements, we avoided to mention the release as suggested by Mickael (check the v6ops ml archives).

I would not typically care about the release here. But for this specific
topic the 3GPP release thing is a mess. I would at minimum include a 
note or warning that there is specific 3GPP release related details to
consider. For example a note & reference to Section 6.2 of RFC6459 would
suffice, I guess.

> Med: Section 1.1 states explicitly both 3GPP accesses and WLAN are in scope. No need to have an explicit reference to TS.23402.

Sorry for my sloppy wording but I was more concerned about stuff
like eHRPD. 

> [Med] As suggested by Teemu "and/or" was changed to "or". As such, "will be" is accurate.

'or' is OK with me. The further change in the next sentence from
MAY to MUST is not. I would we ok with SHOULD (since 3GPP specs say
here should, not shall).

> [Med] re-used the same pointers as in RFC6459.

It is still unclear to me what the inconsistencies are.

>   access network, traffic to the server, and battery consumption on

Fine.

> [Med] "Recent test.." is now changed to " Some tests..".  I didn't removed that text as it provides the context. I added the explicit sentence you proposed.

Ok fine.

> Med: Profile 1 and 2 are explicitly included in the REQ now.

And you also added the reference to the GSMA document? I think that
is needed to give the justification for the crude scoping of profiles ;)

> Med: RFC6204 is sufficient.

RFC6204bis has PD Exclude included among other finetuned DHCPv6 text.
That was my reason for updating the reference.

> [Med] IMO, adding exceptions will nullify the REQ.

SHOULD here should be strong enough.

Thanks. That was quite a lot :)

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 25 Apr 2013 05:11:14 +0000

On Apr 23, 2013, at 11:33 AM, Teemu Savolainen <[email-masked]> wrote:

> My comment against simple term of "mobile" stems from the idea that many kinds of devices can be mobile in sense of moving, but also in the sense of using some mobile technology (3GPP, 3GPP2, WiMAX...) . This document applies only to mobiles in the 3GPP domain and hence that should be stated clearly out (e.g. saying "3GPP mobiles, henceforth referred as mobiles, need to...").

I would make a similar comment about 'wireless'. To my small and unimaginative mind, 'wireless' means 'without wires', which is an attribute of 802.11, 802.16, 80.15.1, and 802.15.4...

---

From: t.petch <[email-masked]>
Date: Thu, 25 Apr 2013 10:01:33 +0100

----- Original Message -----
From: "joel jaeggli" <[email-masked]>
To: "t.petch" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 23, 2013 6:47 PM

Parts of the united states have had radio mobile phone service since
1946.

<tp>
Joel

Thanks for that.  I suspected that there was something behind this that
I was ignorant of and so it has proved.  (I was thinking that perhaps
the American use of mobile might include digital cordless, WiFi etc).

As Jouni said, "use consistent wording" and that for me is paramount.
As to what the wording is, then that is less clear - I would prefer
'mobile' with s1.2 spelling out exactly what that means, but using
'cellular' with s1.2 spelling out exactly what that means is an
alternative.  Or, since this is not about mobile
or cellular devices in general, but only about 3GPP, should that be the
word
used?

Either way, I do think that a beefed up s1.2 is needed, whatever term is
used.

Tom Petch