Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid submitted

From: Andrew Allen <[email-masked]>
Date: Sat, 23 Feb 2013 23:32:17 +0000

New versions of draft-montemurro-gsma-imei-urn and draft-allen-dispatch-imei-urn-as-instanceid submitted have recently been submitted

They can be found at:

http://www.ietf.org/id/draft-montemurro-gsma-imei-urn-13.txt

http://www.ietf.org/id/draft-allen-dispatch-imei-urn-as-instanceid-08.txt

These replace the 12 and 07 versions of these drafts submitted earlier in February and contain only minor corrections over the 12 and 07 versions with draft-montemurro-gsma-imei-urn-13 only correcting some additional incorrect information about the check digit and draft-allen-dispatch-imei-urn-as-instanceid-08 only correcting the references to draft-montemurro-gsma-imei-urn-13. The main significant changes to these draft were included previously in the 12 and 07 versions to address Dale Worley's comments below (see inline comments prepended with [AA]).

Thanks to Dale for working through these with me during downtime after the recent RTCweb/MMUSIC interim.

I believe these changes now address all Dale's comments. Cullen made some additional comments back in January which I responded as did Dale too but no response back to us has been received.

I would like to see us move forward towards publication of these drafts which are required by 3GPP.

Thanks
Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Tuesday, November 27, 2012 4:53 PM
To: [email-masked]
Subject: Re: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted

In regard to the privacy issue, I agree with the authors that privacy has been addressed more vigorously than it is in regular SIP networks (where it is often handled very sloppily), and that (as regarding standards), and that is sufficient.

Below I have noted some specific comments, only two of which have technical content:  (1) What is the permitted character set of the "gsma-*" symbols in the generic syntax?  (2) What is the intended lexical equivalence algorithm?

Resolving these comments should be straightforward, after which I think these documents should progress to RFCs.

Good work!

Dale

*** Comments on draft-montemurro-gsma-imei-urn-11

Technical issues:

   3.1.  GSMA

      The <gsma-specifier>, <gsma-specifier-defined-string>, <gsma-
      specifier-defined-substring>, <gsma-specifier-defined-param-name>
      and <gsma-specifier-defined-param-val> can comprise any ASCII
      characters compliant with URN syntax and must not contain the ":"
      character or ";" character or "=" character(see STD 66, RFC 2141
      [5]).

This contradicts the ABNF in the same section, as there are quite a number of "unreserved" characters for URNs (see RFC 2141, section 2.2, symbol <other>) that are not included in this document's <unreserved>.
What is the intended generic syntax of these symbols?

Within this text, "can comprise any ASCII characters ... and must not ..." would be better phrased "can comprise any ASCII characters except/but it must not ...".

[AA] Done. This passage has been rewritten as follows:
	      The <gsma-specifier>, <gsma-specifier-defined-string>, <gsma-
	      specifier-defined-substring>, <gsma-specifier-defined-param-name>
	      and <gsma-specifier-defined-param-val> can comprise any ASCII
	      characters compliant with the above ABNF.  

   Rules for Lexical Equivalence:
      Consider each field of the IMEI gsma-defined substring to be a
      sequence of decimial digits.  Then, to compare a pair of IMEIs,
      arithmetically compare the corresponding fields of the gsma-
      defined substring 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.

      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.

I think this passage has not been updated to match the symbols in the ABNF.  For instance, there isn't a "gsma-defined substring" in the grammar.  But it's not clear to me what the comparison process is.
E.g., how are parameters compared?  What is a "field"?

(What is the informal description of the equality test?  I assume we've already agreed on that and it's just a matter of specifying it formally.  draft-allen-dispatch-imei-urn-as-instanceid-06 section 5 gives "any optional or variable components of the URN (e.g., the "vers" parameter) MUST be presented with the same values and in the same order)".  Is that correct?)

[AA] Done. The rules for Lexical equivalence has been re-written as follows:
	   Rules for Lexical Equivalence:
	      Two IMEI URNs are equivalent if the single gsma-defined-substrings
	      in the two URNs are the same, and the sequences of gsma-specifier-
	      params are the same and in the same order, with the exception that
	      the gsma-specifier-param "vers=0" is to be ignored for purposes of
	      comparison.  All of these comparisons are to be case-insensitive.

	      Any identifier in GSMA namespaces can be compared using the normal
	      mechanisms for percent-encoded UTF-8 strings.

Editorial:

   1.  Introduction

   GSMA is an identifier for a namespace for identities used by Mobile
   ^^^^

I think this would be more clearly written as '"gsma"', that is, lower-case (as the actual namespace ID is), and in quotes (as the subject of the sentence is the name of the namespace, not the GSMA.

[AA] Done

Perhaps a less syntactically awkward way to write it would be "The namespace "gsma" is a namespace for ...".

[AA] Done

"sub namespace" should probably be hyphenated, as "sub" is not generally used as a separate word.

[AA] Done

      3.1.  GSMA

      A IMEI is an identifier under the GSMA namespace that uniquely
      ^

This should be "An".

[AA] Done

      The formal definition of the IMEI string representation for the
      gsma-specifier-defined-substring for the "imei" gsma-specifier is
      provided by the following ABNF [8]:

The BNF and text do not explicitly state that URNs in the "imei"
sub-namespace use exactly one gsma-specifier-defined-substring, whereas that requirement is intended but the generic syntax allows zero or more gsma-specifier-defined-substrings.  This wording would correct that:

      A URN with the "imei" gsma-specifier contains exactly one
      gsma-specifier-defined-substring, and its formal definition is
      provided by the following ABNF [8]:

[AA] Done

      The GSMA will take responsibility for the gsma-specifier "imei"
      and manage the sub level.
                     ^^^^^^^^^

This seems awkward, as "sub-level" is not commonly a word.  Perhaps this expresses the intended meaning:

      The GSMA will take responsibility for the gsma-specifier "imei"
      and will manage the URNs in its sub-namespace.

[AA] Done

   4.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. 

There are repeated uses of the phrase "the spare is always set to zero when transmitted by the mobile equipment".  I suspect this also means that "spare" is always "0" in IMEI URNs, but the text doesn't say that directly.  Since other forms of "transmission by the Mobile Equipment"
are out of scope for this document, perhaps the second sentence could be changed to:

   The Spare is always set to zero in an IMEI URN.

Is there a security concern if the "actual" check digit is accidentally used as the "spare" field in an IMEI URN?  If so, a sentence to that effect should be added to "Security considerations".

   8.  Security considerations

   It is therefore RECOMMENDED that the IMEISV is not delivered to
   devices that are not trusted.

[AA] The text regarding the spare digit was inaccurate and has been corrected to reflect its actual purpose. It is not in fact a security feature but a is used as a check digit to ensure valid entry and verbal communication of the actual IMEI value. The text has been updated to correctly reflect this.

In the document, there is no explicit statement that IMEISV is logically interchangeable with "IMEI URN with svn parameter", which might cause an implementer to overlook the implications of the above sentence.  So I would suggest augmenting it:

   It is therefore RECOMMENDED that the IMEISV (that is, the IMEI URN
   with svn parameter) is not delivered to devices that are not
   trusted.

[AA] Done

Similarly, for thoroughness:

   In particular, the IMEI URN MUST NOT be included in messages
   intended to convey any level of anonymity.

[AA] After discussion with Dale he agrees this was an incorrect comment (probably IMEI vs IMEISV confusion)

*** Comments on draft-allen-dispatch-imei-urn-as-instanceid-06

Editorial:

   Abstract

   This specification defines how the Uniform Resource Name namespace
   reserved for GSMA (Global Sstandard for Mobiles Association) ...

The expansion of the acronym GSMA provided here is different from the one in draft-montemurro-gsma-imei-urn-11, and does not agree with the expansion of "GSM" provided by Wikipedia ("Global System for Mobile Communications, originally Groupe SpC)cial Mobile").

[AA] Done

   ... identities and its sub namespace for the IMEI (International Mobile

"sub namespace" should probably be hyphenated or made one word.

   station Equipment Identity) can be used as an instance-id as
   specified in RFC 5626 [1] and also as used by RFC 5627 [2].

[AA] Done sub-namespace hyphenated

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  User Agent Client Procedures  . . . . . . . . . . . . . . . . . 5
   6.  User Agent Server Procedures  . . . . . . . . . . . . . . . . . 6
   7.  3GPP Registrar Procedures . . . . . . . . . . . . . . . . . . . 7
   8.  Security considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1.  Normative references . . . . . . . . . . . . . . . . . . . 8
     10.2.  Informative references . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

The capitalization of the section titles is inconsistent.  (But you can probably leave fixing that to the RFC Editor.)

[AA] Done

   1.  Introduction

   meets this requirement by specifying how the GSMA IEMEI URN is used
                                                     ^^^^^

Should be "IMEI".

[AA] Done

   3.  Background

   Amongst other things in some
   regulatory jurisdictions the IMEI is used to identify a stolen mobile
                                                        ^ Adding "that" here makes this easier to read.  Otherwise, one tends to read "identify a stolen mobile".
   is being used and help to identify the subscription that is using it
                ^^^^

[AA] Done

There are three clauses here, so there should be only one "and", and the second clause should start "to help".

[AA] Done

   and to prevent its use.  Whilst GSM was originally a circuit switched
   system enhancements such as GPRS (General Packet Radio Service) and
         ^
Adding a comma makes this easier to read.  Otherwise, one tends to read "a circuit switched system enhancements".

[AA] Done

   UMTS have added IP data capabilities which along with the definition
   of the IP Multimedia Subsystem (IMS) has made SIP based calls and IP
   multimedia sessions from mobile devices possible.

   Center) server enhanced for ICS which controls mobile voice call
   setup over the circuit switched radio access while establishing the
   corresponding voice session in the core network using SIP/IMS.  To
   enable this the MSC server enhanced for ICS (IMS centralized
   services) performs SIP registration on behalf of the mobile device

Move the expansion of "ICS" to its first use.

[AA] Done

The phrase "MSC server enhanced for ICS" is used several times.  I assume that this is a specific technical term.  Is there a shorter form?

[AA] Yes this is a term used in 3GPP specifications and there is no abbreviation

   Additionally in order to meet the regulatory requirements to use the
   IMEI to identify a stolen mobile is being used and help to identify
   the subscription that is using it and to prevent its use the same
   IMEI that is obtained from the circuit switched signaling needs to be
   obtainable from SIP signaling.

Much of this duplicates the first sentences of the section.  Perhaps it could be shortened to:

   Additionally, in order to meet the above regulatory requirements,
   the IMEI that is obtained from the circuit switched signaling needs
   to be obtainable from SIP signaling.

[AA] Done

   4.  3GPP Use Cases

   call as from the same mobile device that was in the emergency session
        ^^

This probably should be "is".

[AA] Done

   5.  User Agent Client Procedures

   When registering with a non 3GPP IMS network ...

There are a number of instances where "non" is presented as a stand-alone word.

[AA] Done hyphenated form is used

[END]
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.