idnits 2.17.1 draft-montemurro-gsma-imei-urn-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Additional security considerations are specified in 3GPP TS 22.016 [7]. Specifically the IMEI is to be incorporated in a module which is contained within the terminal. The IMEI SHALL not be changed after the terminal's production process. It SHALL resist tampering, i.e. manipulation and change, by any means (e.g. physical, electrical and software). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 2009) is 5498 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-16 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Montemurro, Ed. 3 Internet-Draft A. Allen 4 Intended status: Informational Research in Motion (RIM) 5 Expires: October 2, 2009 D. McDonald 6 unaffiliated 7 P. Gosden 8 GSM Association 9 March 31, 2009 11 A Uniform Resource Name Namespace For The GSM Association (GSMA) and the 12 International Mobile station Equipment Identity(IMEI) 13 draft-montemurro-gsma-imei-urn-04 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on October 2, 2009. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This specification defines a Uniform Resource Name namespace for the 61 GSMA and sub namespaces for the IMEI (International Mobile station 62 Equipment Identity), and for the IMEISV (International Mobile station 63 Equipment Identity and Software Version number). The IMEI is 15 64 decimal digits long and the IMEISV is 16 decimal digits long and both 65 are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV 66 were introduced as part of the specification for Global System for 67 Mobile (GSM) and are also now incorporated by the 3rd Generation 68 Partnership Project (3GPP) as part of the 3GPP specification for GSM, 69 and the Universal Mobile Telecommunications System (UMTS). The IMEI 70 and IMEISV are used to uniquely identify Mobile Equipment within 71 these systems and are managed by the GSMA (GSM Association). 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 3. Namespace Registration Template . . . . . . . . . . . . . . . 5 80 3.1. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 8 83 4.1. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.1.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 9 85 4.1.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 9 86 4.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 9 88 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 10 89 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 10 90 4.2.3. Software Version Number (SVN) . . . . . . . . . . . . 10 92 5. Community considerations . . . . . . . . . . . . . . . . . . . 10 94 6. Use as an Instance ID . . . . . . . . . . . . . . . . . . . . 10 96 7. Namespace considerations . . . . . . . . . . . . . . . . . . . 10 98 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 100 9. Security considerations . . . . . . . . . . . . . . . . . . . 11 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 105 11.1. Normative references . . . . . . . . . . . . . . . . . . . 11 106 11.2. Informative references . . . . . . . . . . . . . . . . . . 12 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 110 1. Introduction 112 This specification defines a Uniform Resource Name namespace for the 113 GSMA (GSM Association) and sub namespaces for the IMEI (International 114 Mobile station Equipment Identity), and for the IMEISV (International 115 Mobile station Equipment Identity and Software Version number as per 116 the namespace registration requirement found in [1]. GSMA is an 117 identifier for a namespace for identities used by Mobile Equipment 118 used in GSM and UMTS networks. The IMEI and the IMEISV are managed 119 by the GSMA, so this namespace would be managed by the GSMA. Whilst 120 this specification currently specifies only the IMEI and IMEISV sub 121 namespaces under the GSMA URN namespace additional sub namespaces 122 under the GSMA namespace may be specified in the future by the GSMA 123 through the publication of future informational RFCs. 125 The IMEI is 15 decimal digits long and includes a Type Allocation 126 Code (TAC) of 8 decimal digits and the Serial Number (SNR) of 6 127 decimal digits plus a Spare decimal digit. The TAC identifies the 128 type of the Mobile Equipment and is chosen from a range of values 129 allocated to the Mobile Equipment manufacturer in order to uniquely 130 identify the model of the Mobile Equipment. The SNR is an individual 131 serial number that uniquely identifies each Mobile Equipment within 132 the TAC. The Spare digit is used as a security check to combat 133 potential spoofing and is always set to the value 0 when transmitted 134 by the Mobile Equipment. 136 The IMEISV is 16 decimal digits long and includes the TAC and SNR 137 same as for the IMEI but also a 2 decimal digit Software Version 138 Number (SVN) which is allocated by the Mobile Equipment manufacturer 139 to identify the software version of the Mobile Equipment. 141 The IMEI is specified to be stored in a tamper proof fashion so that 142 it cannot be overwritten or otherwise reprogrammed by software. 144 The information here is meant to be a concise guide for those wishing 145 to use the IMEI and IMEISV as URNs. Nothing in this document should 146 be construed to override 3GPP TS 23.003 [2] that defines the IMEI and 147 IMEISV. 149 The GSM Association (GSMA) is a global trade association representing 150 more than 750 GSM mobile phone operators across 218 territories and 151 countries of the world. The primary goals of the GSMA are to ensure 152 mobile phones and wireless services work globally and are easily 153 accessible. Further details about the GSMA role in allocating the 154 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 155 be found in GSMA PRD DG.06 [3] 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [4]. 163 3. Namespace Registration Template 165 3.1. GSMA 167 Namespace ID: "gsma" requested 169 Registration Information: 171 Registration version number: 1 173 Registration date: 2006-10-11 175 Declared registrant of the namespace: GSM Association, 1st Floor, 176 Mid City Place, 71 High Holborn, London, England 178 Declaration of syntactic structure: 179 The identifier is expressed in ASCII (UTF-8) characters and has a 180 hierarchical structure as follows: 182 urn:gsma:[:]+ 183 where 184 = "imei" | "imeisv" 185 = GSMA-approved string 186 + = one or more occurences of "gsma-specifier-defined-string" 188 The GSMA namespace includes two predefined namespaces IMEI and 189 IMEISV and may be in the future extended to include other 190 identifiers used by Mobile Equipment used in GSM and UMTS networks 191 or future networks deployed by members of the GSMA. 193 A IMEI is an identifier under the GSMA namespace that uniquely 194 identifies Mobile Equipment used in GSM and UMTS networks. 196 The internal representation of a IMEI is a specific sequence of 197 bits in memory, as described in 3GPP TS 23.003 [2]. To accurately 198 represent a IMEI as a URN, it is necessary to convert the BCD bit 199 sequence to a string representation. Each field BCD bit sequence 200 has its value printed as a decimal digit string with the most 201 significant digit first. 203 The following augmented Backus-Naur Form (ABNF) includes the set 204 of core rules in RFC 5234 [8], and are not repeated here. 206 The formal definition of the IMEI string representation is 207 provided by the following ABNF [8]: 209 IMEI = tac "-" snr "-" spare 210 tac = 8DIGIT 211 snr = 6DIGIT 212 spare = 1DIGIT 213 For example: 214 urn:gsma:imei:90420156-025763-0 216 A IMEISV is an identifier under the GSMA namespace that uniquely 217 identifies Mobile Equipment and associated software versions used 218 in GSM and UMTS networks. The internal representation of a IMEISV 219 is a specific sequence of bits in memory, as described in 3GPP TS 220 23.003 [2]. To accurately represent a IMEISV as a URN, it is 221 necessary to convert the BCD bit sequence to a string 222 representation. Each field BCD bit sequence has its value printed 223 as a decimal digit string with the most significant digit first. 225 The formal definition of the IMEISV string representation is 226 provided by the following ABNF [8]: 228 IMEISV = tac "-" snr "-" svn 229 tac = 8DIGIT 230 snr = 6DIGIT 231 svn = 2DIGIT 232 For example: 233 urn:gsma:imeisv:90420156-025763-42 235 The and can 236 comprise any ASCII characters compliant with URI syntax and must 237 not contain the ":" character (see STD 66, RFC 3986 [5]). The 238 exclusion of the colon from the list of other characters means 239 that the colon can only occur as a delimiter between string 240 values. 242 The GSMA will take responsibility for the gsma-specifier "imei" 243 and "imeisv" and manage the sub level. 245 Additional gsma-specifiers may be added in the future through 246 informational RFCs. 248 Relevant ancillary documentation: 249 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 250 [2]. 252 Identifier uniqueness considerations: 253 Identifiers in the "gsma" namespace are defined and assigned in 254 the requested namespace by the GSMA after ensuring that the URNs 255 to be assigned are unique. Uniqueness is achieved by checking 256 against the registry of previously assigned names. 258 Procedures are in place to ensure that each IMEI is uniquely 259 assigned by the Mobile Equipment manufacturer so that it is 260 guaranteed to uniquely identify that particular Mobile Equipment. 261 IMEIs are stored in the Mobile Equipment in a tamper proof non 262 modifiable fashion so they remain persistent. 263 Procedures are in place to ensure that each IMEISV is uniquely 264 assigned by the Mobile Equipment manufacturer so that it is 265 guaranteed to uniquely identify that particular Mobile Equipment 266 and the specific software version installed. 268 Identifier persistence considerations: 269 The GSMA is committed to maintaining uniqueness and persistence of 270 all resources identified by assigned URNs. 272 As the NID sought is "gsma" and GSMA is the long standing acronym 273 for the trade association that represents the mobile phone 274 operators the URN should also persist indefinitely (at least as 275 long as there is a need for its use). The assignment process 276 guarantees that names are not reassigned. The binding between the 277 name and its resource is permanent. 279 IMEIs are stored in Mobile Equipment in a tamper proof non- 280 modifiable fashion so they remain persistent 281 The TAC and SNR portions of IMEISVs are stored in the Mobile 282 Equipment in a tamper proof non modifiable fashion so they remain 283 persistent. The SVN may be modified by software when new versions 284 are installed but should be persistent for the duration of the 285 installation of that specific version of software. 287 Process of identifier assignment: 288 GSMA will manage the and 289 including "imei" and "imeisv" identifier resources to maintain 290 uniqueness. 292 The process for IMEI and IMEISV assignment is documented in GSMA 293 PRD DG.06[3] 295 Process for identifier resolution: 296 Since the GSMA namespace is not globally resolvable, this is not 297 applicable. 299 Rules for Lexical Equivalence: 300 Consider each field of the IMEI or IMEISV to be a sequence of 301 decimial digits. Then, to compare a pair of IMEIs or IMEISVs, 302 arithmetically compare the corresponding fields from each IMEI or 303 IMEISV in order of significance and according to their data type. 304 Two IMEIs or IMEISVs are equal if and only if all the 305 corresponding fields are equal. 307 The lexical equivalence of the GSMA namespace-specific strings 308 (NSSs) is defined as an exact, but not case-sensitive, string 309 match. 311 Any identifier in GSMA namespaces can be compared using the normal 312 mechanisms for percent-encoded UTF-8 strings. 314 Conformance with URN Syntax: 315 The string representation of the GSMA URN and of the IMEI and 316 IMEISV subnamespaces is fully compatible with the URN syntax. 318 Validation Mechanism: 319 The IMEI can be validated using the mechanism defined in Annex B 320 of 3GPP TS 23.003 [2]. The TAC and SNR fields of the IMEISV can 321 be validated using the mechanism defined in Annex B of 3GPP TS 322 23.003 [2]. There is no mechanism defined to validate the SVN 323 field of the IMEISV. 325 Scope: GSMA URN is global in scope. 327 4. Specification 329 4.1. IMEI Format 331 The IMEI format is 15 decimal digits encoded in 8 octets using BCD as 332 defined in 3GPP TS 24.008 [6]. The most significant digit is coded 333 in the most significant bits of octet 1. The least significant digit 334 is coded in the least significant bits of octet 8. 336 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 337 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 338 | | | S| 339 | T | S | p| 340 | A | N | a| 341 | C | R | r| 342 | | | e| 343 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 344 1 2 3 4 5 6 7 8 Octets 346 4.1.1. Type Allocation Code (TAC) 348 The TAC is a 8 decimal digit value. The TAC identifies the type of 349 the Mobile Equipment and is chosen from a range of values allocated 350 to the Mobile Equipment manufacturer in order to uniquely identify 351 the model of the Mobile Equipment. 353 4.1.2. Serial Number (SNR) 355 The SNR is a 6 decimal digit value. The SNR is an individual serial 356 number that uniquely identifies each Mobile Equipment within the TAC. 358 4.1.3. Spare 360 The Spare is a single decimal digit that is used as a security check 361 digit to combat potential spoofing. The Spare is always set to zero 362 when transmitted by the Mobile Equipment. Annex B of 3GPP TS 23.003 363 [2] defines a mechanism for computing the actual check digit in order 364 to validate the TAC and SNR. 366 4.2. IMEISV Format 368 The IMEISV format is 16 decimal digits encoded in 8 octets using BCD 369 as defined in 3GPP TS 24.008 [6]. The most significant digit is 370 coded in the most significant bits of octet 1. The least significant 371 digit is coded in the least significant bits of octet 8. 373 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 374 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 375 | | | | 376 | T | S | S | 377 | A | N | V | 378 | C | R | N | 379 | | | | 380 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 381 1 2 3 4 5 6 7 8 Octets 383 4.2.1. Type Allocation Code (TAC) 385 The TAC is the same as for the IMEI in Section 5.1.1. 387 4.2.2. Serial Number (SNR) 389 The SNR is the same as for the IMEI in Section 5.1.2. 391 4.2.3. Software Version Number (SVN) 393 The Software Version Number is allocated by the Mobile Equipment 394 manufacturer to identify the software version of the Mobile 395 Equipment. 397 5. Community considerations 399 GSM and UMTS mobile devices will be interoperating with Internet 400 devices for a variety of voice and data services. To do this, they 401 need to make use of Internet protocols that will operate end to end 402 between devices in GSM/UMTS networks and those in the general 403 internet. Many of these protocols require the use of URN's as 404 identifiers. Within the GSM/UMTS networks, mobile devices are 405 identified by their IMEI and IMEISV. Internet users will need to be 406 able to receive and include the GSMA URN in various Internet protocol 407 elements to facilitate communication between pure internet based 408 devices and GSM and UMTS mobile devices. Thus the existence and 409 syntax of these namespaces needs to be available to the general 410 internet community and the namespace needs to be reserved with IANA 411 in order to guarantee uniqueness and prevent potential namespace 412 conflicts both within the internet and within GSM/UMTS networks. 414 6. Use as an Instance ID 416 The IMEI and IMEISV URNs MAY be used as an Instance ID and included 417 in the sip.instance parameter of a Contact header field of a SIP 418 Register request as specified in draft-ietf-sip-outbound [9]. 420 7. Namespace considerations 422 A URN was considered the most appropriate URI to represent the IMEI 423 and IMEISV as these identifiers may be used and transported similarly 424 to the Universally Unique Identifier (UUID)which is defined as a URN 425 in [10]. Since specifications for protocols that are used to 426 transport device identifiers often require the device identifier to 427 be globally unique and in the URN format it is necessary that the 428 IMEI and IMEISV URN formats are defined. 430 8. IANA considerations 432 In accordance with BCP 66 [1], IANA is asked to register the Formal 433 URN Namespace 'GSMA' in the Registry of URN Namespaces, using the 434 registration template presented in Section 3 of this document. 436 9. Security considerations 438 IMEIs (with the Spare value set to zero) are displayable on most 439 Mobile Equipment; therefore, they must not be used as security 440 capabilities (identifiers whose mere possession grants access), for 441 example. 443 Revealing the specific software version of the terminal might make 444 the terminal more vulnerable to attacks against software that is 445 known to contain security holes. This is a similar concern to the 446 use of the User-Agent header in SIP as specified in RFC 3261 [11]. 447 It is therefore RECOMMENDED that the IMEISV is not delivered to 448 devices that are not trusted. Care should be taken regarding use of 449 the IMEISV as it could help a malicious device identify Mobile 450 Equipment running software that is known to be vulnerable to certain 451 attacks. 453 Additional security considerations are specified in 3GPP TS 22.016 454 [7]. Specifically the IMEI is to be incorporated in a module which 455 is contained within the terminal. The IMEI SHALL not be changed 456 after the terminal's production process. It SHALL resist tampering, 457 i.e. manipulation and change, by any means (e.g. physical, electrical 458 and software). 460 10. Acknowledgements 462 This document draws heavily on the 3GPP work on Numbering, Addressing 463 and Identification in 3GPP TS 23.003 [2] and also on the style and 464 structure used in RFC 4122 [10]. 466 11. References 468 11.1. Normative references 470 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 471 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 472 BCP 66, RFC 3406, October 2002. 474 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 475 (Release 8)", 3GPP 23.003, September 2008, 476 . 478 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 479 PRD DG.06 version 3.6, February 2008, 480 . 482 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 483 Levels", BCP 14, RFC 2119, March 1997. 485 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 486 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 487 January 2005. 489 [6] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 490 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 491 September 2008, 492 . 494 [7] 3GPP, "TS 22.016: International Mobile station Equipment 495 Identities (IMEI)(Release 7)", 3GPP 22.016, May 2007, 496 . 498 11.2. Informative references 500 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax 501 Specifications: ABNF", STD 68, RFC 5234, January 2008. 503 [9] Jennings, C. and R. Mahy, "Managing Client Initiated 504 Connections in the Session Initiation Protocol (SIP)", 505 draft-ietf-sip-outbound-16 (work in progress), October 2008. 507 [10] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 508 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 510 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 511 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 512 Session Initiation Protocol", RFC 3261, June 2002. 514 Authors' Addresses 516 Michael Montemurro (editor) 517 Research in Motion (RIM) 518 4701 Tahoe Dr 519 Mississauga, Ontario L4W 0B4 520 Canada 522 Phone: unlisted 523 Fax: unlisted 524 Email: mmontemurro@rim.com 526 Andrew Allen 527 Research in Motion (RIM) 528 300 Knightsbridge Parkway, Suite 360 529 Lincolnshire, Illinois 60069 530 USA 532 Phone: unlisted 533 Fax: unlisted 534 Email: aallen@rim.com 536 David McDonald 537 unaffiliated 539 Phone: unlisted 540 Fax: unlisted 541 Email: mcdonalddm@hotmail.com 543 Paul Gosden 544 GSM Association 545 1st Floor, Mid City Place, 71 High Holborn, 546 London 547 England 549 Phone: unlisted 550 Fax: unlisted 551 Email: pgosden@gsm.org