Subject: Re: Request for GSMA IMEI urn draft review

From: Leslie Daigle <[email-masked]>
Date: Thu, 09 Nov 2006 02:30:07 -0500

> 4.  Namespace Registration Templates
> 
> 4.1.  GSMA
> 
>    Namespace ID:  "urn:gsma" requested

Nit:  the requested NID is "GSMA", not "URN:GSMA".

> 
>    The identifier has a hierarchical structure as follows:
>    urn:gsma:imei/imeisv/ <gsma-specifier>[: <gsma-specifier defined
>    string>]+
>       + denotes one or more occurrences of gsma-specifier defined
>       strings all delimited by a colon."

The formatting in the section above is broken; it's very hard
to interpret with any precision.  Please fix the formatting,
and allow for re-review.

WRT grammar syntaxes -- please be clear what the characters
are intended to mean.  is "[ ]" optional, are "<   >" productions,
etc.

> 
>    The GSMA namespace includes two predefined namespaces IMEI and IMEISV
>    and may be in the future extended to include other identifiers used
>    by Mobile Equipment used in GSM and UMTS networks or future networks
>    deployed by members of the GSMA.
> 
>    For example:
>    urn:gsma:imei:90420156-025763-0
>    urn:gsma:imeisv:90420156-025763-42
> 
>    The <gsma-specifier> and <gsma-specifier> defined string can comprise
>    any UTF-8 characters compliant with URI syntax and must not contain

Note that the UTF-8 characters that are complient with URI syntax
are, in fact, ASCII characters.  Probably best to rephrase this so
as not to give the illusion that the URN supports UTF-8 8-bit
characters without encoding.

>    the ":" character (see STD 66, RFC 3986 [xref target="RFC3986"]).

NIT:  Failed reference citationin the xml.

>    The exclusion of the colon from the list of other characters means
>    that the colon can only occur as a delimiter between string values.
> 
>    The GSMA will take responsibility for the gsma-specifier "imei" and
>    "imeisv".
> 
>    The GSMA will take responsibility to assign other gsma-specifiers and
>    manage the sub level and its applicable gsma-specifier defined
>    string(s).
> 
>    Relevant ancillary documentation:  None.
> 
>    Identifier uniqueness considerations:  Identifiers in the "gsma"
>       namespace are defined and assigned in the requested namespace by
>       the GSMA after ensuring that the URNs to be assigned are unique.
>       Uniqueness is achieved by checking against the registry of
>       previously assigned names.
> 
>    Identifier persistence considerations:
> 
> 
>    The GSMA is committed to maintaining uniqueness and persistence of
>    all resources identified by assigned URNs.
> 
>    As the URN sought is "gsma" and GSMA is the long standing acronym for

s/URN sought/NID sought/

>    the trade association that represents the mobile phone operators the
>    URN should also persist indefinitely, (at least as long as there is a
>    need for its use).The assignment process guarantees that names are
>    not reassigned.  The binding between the name and its resource is
>    permanent.
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                 [Page 6]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>    Process of identifier assignment:
> 
> 
>    GSMA will manage the <gsma-specifier> and <gsma-defined string>
>    including "imei" and "imeisv" identifier resources to maintain
>    uniqueness.
> 
>    The process of assigning additional URNs at the <gsma-specifier> sub-
>    level will be managed by the GSMA.
> 
>    Process for identifier resolution:   Since the GSMA namespace is not
>       globally resolvable, this is not applicable.
> 
>    Rules for Lexical Equivalence:
> 
> 
>    The lexical equivalence of the GSMA namespace-specific strings (NSSs)
>    is defined as an exact, but not case-sensitive, string match.
> 
>    Any identifier in GSMA namespaces can be compared using the normal
>    mechanisms for percent-encoded UTF-8 strings.
> 
>    Conformance with URN Syntax:  The string representation of a IMEI is
>       fully compatible with the URN syntax.
> 
>    Validation Mechanism:  None
> 
>    Scope:  GSMA URN is global in scope.
> 
> 
> 4.2.  IMEI
> 
>    Namespace ID:  "urn:gsma:imei" requested.

Hmm... You do not need to ask IANA for a sub-NID assignment.  From the
documentation above, I understood GSMA was managing the sub-NID
assignments.  This does not belong in this document.

Or, in the registration of GSMA as a NID, you are welcome
to specify further sub-NIDs, such as imei, without making
them "requests".

> 
>    Registration Information:
> 
>    Registration date:  2006-10-11
> 
>    Declared registrant of the namespace:  GSMA.
> 
>    Declaration of syntactic structure:  .
> 
> 
>    A IMEI is an identifier under the GSMA namespace that uniquely
>    identifies Mobile Equipment used in GSM and UMTS networks.
> 
>    The internal representation of a IMEI is a specific sequence of bits
>    in memory, as described in 3GPP TS 23.003 [1].  To accurately
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                 [Page 7]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>    represent a IMEI as a URN, it is necessary to convert the BCD bit
>    sequence to a string representation.
> 
>    Each field BCD bit sequence has its value printed as a decimal digit
>    string with the most significant digit first.
> 
>    The formal definition of the IMEISV string representation is provided
>    by the following ABNF [4]
> 
>    IMEI =  tac "-" snr "-" svn
>    tac      = 8decDigit
>    snr      = 6decDigit
>    spare    = 1decDigit
>    decDigit =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
> 
>    The following is an example of the string representation of a IMEI as
>    a URN:
> 
>    urn:gsma:imei:90420156-025763-0
> 
>    Relevant ancillary documentation:  3GPP TS 23.003 [1] and GSMA PRD
>       TW.06 [2]
> 
>    Identifier uniqueness considerations:  Procedures are in place to
>       ensure that each IMEI is uniquely assigned by the Mobile Equipment
>       manufacturer so that it is guaranteed to uniquely identify that
>       particular Mobile Equipment.
> 
>    Identifier persistence considerations:  IMEIs are stored in the
>       Mobile Equipment in a tamper proof non modifiable fashion so they
>       remain persistent
> 
>    Process of identifier assignment:  The process for IMEI assignment is
>       documented in GSMA PRD TW.06 [2].
> 
>    Process for identifier resolution:  Since IMEIs are not globally
>       resolvable, this is not applicable.
> 
>    Rules for Lexical Equivalence:  Consider each field of the IMEISV to
>       be a sequence of decimal digits.  Then, to compare a pair of
>       IMEIs, arithmetically compare the corresponding fields from each
>       IMEI in order of significance and according to their data type.
>       Two IMEIs are equal if and only if all the corresponding fields
>       are equal
> 
> 
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                 [Page 8]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>    Conformance with URN Syntax:  The string representation of a IMEI is
>       fully compatible with the URN syntax.
> 
>    Validation mechanism:  The IMEI can be validated using the mechanism
>       defined in Annex B of 3GPP TS 23.003 [1]
> 
>    Scope:  IMEIs are global in scope.

The conditions above could/should be expressed more generally
in terms of the overall namespace ID request for GSMA.

> 
> 
> 4.3.  IMEISV
> 
>    Namespace ID:  "urn:gsma:imeisv" requested

Same comment as above.

> 
>    Registration Information:
> 
>    Registration date:  2006-10-11
> 
>    Declared registrant of the namespace:  GSMA.
> 
>    Declaration of syntactic structure:
> 
> 
>    A IMEISV is an identifier under the GSMA namespace that uniquely
>    identifies Mobile Equipment and associated software versions used in
>    GSM and UMTS networks.
> 
>    The internal representation of a IMEISV is a specific sequence of
>    bits in memory, as described in 3GPP TS 23.003 [1].  To accurately
>    represent a IMEISV as a URN, it is necessary to convert the BCD bit
>    sequence to a string representation.
> 
>    Each field BCD bit sequence has its value printed as a decimal digit
>    string with the most significant digit first.
> 
>    The formal definition of the IMEISV string representation is provided
>    by the following ABNF [4]
> 
>    IMEISV =  tac "-" snr "-" svn
>    tac      = 8decDigit
>    snr      = 6decDigit
>    svn      = 2decDigit
>    decDigit =  "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
> 
>    The following is an example of the string representation of a IMEISV
>    as a URN:
> 
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                 [Page 9]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>    urn:gsma:imeisv:90420156-025763-42
> 
>    Relevant ancillary documentation:  3GPP TS 23.003 [1] and GSMA PRD
>       TW.06 [2]
> 
>    Identifier uniqueness considerations:  Procedures are in place to
>       ensure that each IMEISV is uniquely assigned by the Mobile
>       Equipment manufacturer so that it is guaranteed to uniquely
>       identify that particular Mobile Equipment and the specific
>       software version installed.
> 
>    Identifier persistence considerations:  The TAC and SNR portions of
>       IMEISVs are stored in the Mobile Equipment in a tamper proof non
>       modifiable fashion so they remain persistent.  The SVN may be
>       modified by software when new versions are installed but should be
>       persistent for the duration of the installation of that specific
>       version of software.
> 
>    Process of identifier assignment:  The process for IMEISV assignment
>       is documented in GSMA PRD TW.06 [2].
> 
>    Process for identifier resolution:  Since IMEISVs are not globally
>       resolvable, this is not applicable.
> 
>    Rules for Lexical Equivalence:  Consider each field of the IMEISV to
>       be a sequence of decimal digits.  Then, to compare a pair of
>       IMEISVs, arithmetically compare the corresponding fields from each
>       IMEISV in order of significance and according to their data type.
>       Two IMEISVs are equal if and only if all the corresponding fields
>       are equal
> 
>    Conformance with URN Syntax:  The string representation of a IMEISV
>       is fully compatible with the URN syntax.
> 
>    Validation mechanism:  The TAC and SNR fields of the IMEISV can be
>       validated using the mechanism defined in Annex B of 3GPP TS 23.003
>       [1].  There is no mechanism defined to validate the SVN field of
>       the IMEISV.
> 
>    Scope:  IMEISVs are global in scope.
> 

Same comments as above.

> 
> 
> 5.  Specification
> 
> 
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 10]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
> 5.1.  IMEI Format
> 
>    The IMEI format is 15 decimal digits encoded in 8 octets using BCD as
>    defined in 3GPP TS 24.008 [5].  The least significant digit is coded
>    in the 1st 3 bits of octet 1.  The most significant digit is coded in
>    the least significant bits of octet 8.  Last 4 digits of octet 8 are
>    all 1's.
> 
>        1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  Decimal Digits
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |               |           |S|
>       |        T      |      S    |p|
>       |        A      |      N    |a|
>       |        C      |      R    |r|
>       |               |           |e|
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         1   2   3   4   5   6   7   8  Octets
> 
> 
> 5.1.1.  Type Allocation Code (TAC)
> 
>    The TAC is a 8 decimal digit value.  The TAC identifies the type of
>    the Mobile Equipment and is chosen from a range of values allocated
>    to the Mobile Equipment manufacturer in order to uniquely identify
>    the model of the Mobile Equipment.
> 
> 5.1.2.  Serial Number (SNR)
> 
>    The SNR is a 6 decimal digit value.  The SNR is an individual serial
>    number that uniquely identifies each Mobile Equipment within the TAC
> 
> 5.1.3.  Spare
> 
>    The Spare is a single decimal digit that is used as a security check
>    digit to combat potential spoofing.  The Spare is always set to zero
>    when transmitted by the Mobile Equipment.  Annex B of 3GPP TS 23.003
>    [1] defines a mechanism for computing the actual check digit in order
>    to validate the TAC and SNR.
> 
> 5.2.  IMEISV Format
> 
>    The IMEISV format is 16 decimal digits encoded in 8 octets using BCD
>    as defined in 3GPP TS 24.008 [5].  The least significant digit is
>    coded in the 1st 3 bits of octet 1.  The most significant digit is
>    coded in the least significant bits of octet 8.
> 
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 11]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>        1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6  Decimal Digits
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |               |           |   |
>       |        T      |      S    | S |
>       |        A      |      N    | V |
>       |        C      |      R    | N |
>       |               |           |   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>         1   2   3   4   5   6   7   8   Octets
> 
> 
> 5.2.1.  Type Allocation Code (TAC)
> 
>    The TAC is the same as for the IMEI in Section 5.1.1.
> 
> 5.2.2.  Serial Number (SNR)
> 
>    The SNR is the same as for the IMEI in Section 5.1.2.
> 
> 5.2.3.  Software Version Number (SVN)
> 
>    The Software Version Number is allocated by the Mobile Equipment
>    manufacturer to identify the software version of the Mobile
>    Equipment.
> 
> 
> 6.  Security considerations
> 
>    IMEIs (with the Spare value set to zero) are displayable on most
>    Mobile Equipment therefore they must not be used as security
>    capabilities (identifiers whose mere possession grants access), for
>    example.
> 
>    Care should be taken regarding use of the IMEISV as it could help a
>    malicious device identify Mobile Equipment running software that is
>    known to be vulnerable to certain attacks.  This is a similar concern
>    to the use of the User-Agent header in SIP as specified in RFC 3261
>    [6].
> 
>    Additional security considerations are specified in 3GPP TS 22.016
>    [7].
> 
> 
> 7.  Acknowledgements
> 
>    This document draws heavily on the 3GPP work on Numbering, Addressing
>    and Identification in 3GPP TS 23.003 [1] and also on the style and
>    structure used in RFC 4122 [8].
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 12]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
> 8.  References
> 
> 8.1.  Normative references
> 
>    [1]  3GPP, "TS 23.003: Numbering, addressing and identification
>         (Release 7)", 3GPP 23.003, June 2006,
>         <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
> 
>    [2]  GSMA Assocaition, "IMEI Allocation and Approval Guidelines",
>         PRD TW.06 version 3.3.0, December 2004,
>         <http://www.gsmworld.com/documents/twg/tw06.pdf>.
> 
>    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>         Levels", BCP 14, RFC 2119, March 1997.
> 
>    [4]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
>         Specifications: ABNF", RFC 4234, October 2005.
> 
>    [5]  3GPP, "TS 24.008: Mobile radio interface Layer 3 specification;
>         Core network protocols; Stage 3 (Release 7)", 3GPP 24.008,
>         June 2006, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.008/>.

You do want to refer to the document defining URN NID registration
requirements, RFC3406.

And, in reviewing that, note the requirement for sections on

	. Community Considerations
	. Namespace Considerations

Thanks,
Leslie.

> 
> 8.2.  Informative references
> 
>    [6]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
>         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
>         Session Initiation Protocol", RFC 3261, June 2002.
> 
>    [7]  3GPP, "TS 22.016: International Mobile station Equipment
>         Identities (IMEI)(Release 6)", 3GPP 22.016, January 2005,
>         <ftp://ftp.3gpp.org/Specs/archive/22_series/22.016/>.
> 
>    [8]  Leach, P., Mealling, M., and R. Salz, "A Universally Unique
>         IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
> 
> 
> Authors' Addresses
> 
>    Michael Montemurro (editor)
>    Research in Motion (RIM)
>    5090 Commerce Blvd
>    Mississauga, Ontario  L4W 5W4
>    Canada
> 
>    Phone: unlisted
>    Fax:   unlisted
>    Email: [email-masked]
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 13]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
>    Andrew Allen
>    Research in Motion (RIM)
>    102 Decker Court, Suite 100
>    Irving, Texas  75062
>    USA
> 
>    Phone: unlisted
>    Fax:   unlisted
>    Email: [email-masked]
> 
> 
>    David McDonald
>    GSM Association
>    Block 2, Deansgrange Business Park
>    Deansgrange, Co. Dublin
>    Ireland
> 
>    Phone: unlisted
>    Fax:   unlisted
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 14]
> 
> Internet-Draft          The IMEI and IMEISV URNs            October 2006
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2006).
> 
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
> 
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
>    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
>    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
>    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Intellectual Property
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    [email-masked].
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
> 
> 
> 
> 
> 
> Montemurro, et al.       Expires April 16, 2007                [Page 15]
> 
> 

Michael Montemurro wrote:
> We would like to solicit a review of the IMEI and  IMEISV URN draft. 
> This work is
> needed for equipment tracking in GSM systems and would be managed by the 
> GSM Association. You can find the draft at:
> http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-00.txt
> 
> Thanks,
> 
> Mike
>