A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)
RFC 7254

Note: This ballot was opened for revision 09 and is now closed.

(Cullen Jennings) Discuss

Discuss (2009-04-24 for -** No value found for 'p.get_dochistory.rev' **)
The most resent version did not seem to address my comments not have I received any email on them that I can find. If I'm missing some email, please let me know. 

The text 

   The IMEI and IMEISV URNs MAY be used as an Instance ID and included
   in the sip.instance parameter of a Contact header field of a SIP
   Register request as specified in draft-ietf-sip-outbound [8].

requires an IETF RFC that updates SIP outbound to define this.

This use of IMEISV in outbound would directly contradict the text in the security section of this draft.

I view overriding the 3GPP specs on tamper residence of IMEI in an IETF spec as a really bad plan. This is not within the scope of IETF.n As it stands the advice in the draft does not seem to be implementable. 

One of the key normative references [3], does not exist leading me to seriously question the stability of such things. 

I don't understand what usage would require the software version in the URN other than the whole malware prevention proposal from RIM. It seemed everyone thought that there were much better ways to deal with this than using the URN so I don't understand the need for the SV version and see no IETF discussion, much less consensus, about why it is needed. For the reason stated in the security consideration, this seems like an inappropriate type of information in the URN for a device. 

This draft does address the reasons for IMEI but URN but not a namespace delegation. 

The idea that the IMEISV has to be tamper resistant and can be changed by malware software, but that an over the air software upgrade has to change exactly IMEISV sounds to me as something that has a lot of wishful thinking involved with it. I'd like to know how to implement this. 

The requirements of this draft make it difficult for a soft phone running on a PC to ever use one of these. While this would be great for manufactures of hardware phones to lock out other types of phones, I doubt it has IETF consensus.

This draft does far more than register the IMEI as a URN. I have no problems with the IMEI as an URN part of the draft.

Magnus Westerlund (was No Objection, Discuss) Discuss

Discuss (2009-04-02 for -** No value found for 'p.get_dochistory.rev' **)
1. The reference to the syntax is to the general URI spec. However, to my understanding the URN syntax is more restricted than the URI syntax. Thus changing the reference for the syntax to the URN (RFC 2141).
Comment (2009-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The document uses text to describe the allowed syntax for the URN subspaces. I wish for a syntax declaration that are complete and declares both sub-spaces and the syntax that all future extensions needs to stay within.

(Richard Barnes) Yes

Comment (2014-02-19 for -19)
No email
send info
I agree with Barry that the IETF probably doesn't need control over the internals of the namespace.

(Gonzalo Camarillo) Yes

(Lisa Dusseault) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2014-02-18 for -19)
No email
send info
I re-iterate the position of my ancestors.

(Ross Callon) No Objection

(Spencer Dawkins) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-03-05)
No email
send info
Thanks for addressing my discuss points.

-- this used to be a discuss point, I'd still like to chat about
it but its non-blocking

(3) Given that IMEIs are PII, and that devices may then
emit those, would there not be value in defining an "I'm
not telling" URN value that could be used by devices
(whose users) would (sometimes) prefer privacy over
convienence? As-is, when a protocol uses one of these
URNs, then the only option is to not run the protocol or
to expose the PII. Wouldn't the existence of such a URN
value help there, e.g. perhaps "urn:gsma:imei:anon" or it
could of course use the existing syntax but just some
numbers never allocated to a real device as an IMEI, and
I'm sure there are such values that could be added here
as a special case. 

-- original comments, below didn't check if they are addressed

- On Barry's discuss. I think there would be value in
IETF review if e.g. the GSMA wanted to define other
urn:gsma: namespaces that were likely to contain PII, for
example a putative urn:gsma:imsi perhaps. Given the
cross-over nature of these kinds of identifier, I think
such review would be valuable.

- Section 5: I'm not gettng the intent of this section.
Can you explain why its there?

- Section 8: This would be better named "Security and
Privacy Considerations" for this document I think.

- Section 8, para 1: suggest s/proof/"proof"/ in the 2nd
last sentence - scare quotes seem appropriate there:-)

- S8, 2nd para: The IMEI and s/w version definitely will
identify the set of known vulnerabilities (whether zero
day or not). Saying that's a "possibility" is a
significant understatement.

(Russ Housley) (was Discuss) No Objection

Comment (2007-05-07 for -10)
No email
send info
  From Gen-ART Review by Pasi Eronen:

  ABNF for IMEI:
   - The preceeding text should say "IMEI" instead of "IMEISV"
   - the IMEI rule has "svn" element, should be "spare" instead
   - I'd suggest using the pre-defined DIGIT core rule instead 
     of decDigit; i.e. change "tac = 8decDigit" to "tac = 8DIGIT"
     and remove decDigit rule.

  ABNF for IMEISV:
   - Again, suggest using DIGIT core rule

  "Relevant ancillary documentation" section should probably 
  have pointers to the relevant 3GPP specs and GSMA rules (PRD TW.06).

  The title for section "Rules for Lexical Equivalence" is in
  the wrong place (the preceeding paragraph also talks about
  lexical equivalence).

  Sections 5.1 and 5.2: "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." (and similar
  text in Section 5.2).  I think this is wrong; the most
  significant digit is somewhere in octet 1, right?

  Nits from idnits-2.04.07:
   - The document seems to lack an IANA Considerations section.  
   - There are 4 instances of too long lines in the document, 
     the longest one being 29 characters in excess of 72.
   - The document doesn't use any RFC 2119 keywords, yet seems
     to have RFC 2119 boilerplate text.

(Joel Jaeggli) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2014-03-03)
No email
send info
UPDATED, retaining part of my DISCUSS for documentation:

Having registered your "gsma" namespace and defined a "urn:gsma:imei:"
sub-namespace, do you really want to require IETF consensus to create
other sub-namespaces under "urn:gsma:"?  That seems odd.  I should think
you'd want to have the authority to register things under "urn:gsma:" go
to some GSMA management entity instead of to the IETF.

I discussed this with Cullen, and I understand the issue: the SIP
community wants to be sure that other sub-namespaces, with different
semantics, can't be used where gsma:imei: URNs can, as an instance ID. 
I think we're already mostly there, because the other document,
draft-allen-dispatch-imei-urn-as-instanceid, is already full of
references to "GSMA IMEI URN".

In my DISCUSS, I made a change proposal that resolves the issue.
Gonzalo has put that into an RFC Editor note, and I think the document
is ready to go.  Thanks, everyone, for having the discussion.

(Ted Lemon) No Objection

Comment (2014-02-20 for -19)
No email
send info
It's a bit weird to hard-code a contact person into an RFC:

   Designated contact person:
   Name:  Paul Gosden
   Coordinates:  pgosden@gsma.com

Wouldn't it make more sense to have a role address @gsma.com and give the role a name, like "Designated GSMA Contact Person For IMEI/IMEISV URN Registries"?

           imei-specifier = "imei:" ( imeival / ext-imei )
                                            [ ";" sw-version-param ]
                                            [ ";" imei-version-param ]

Are sw-version-param and imei-version-param actually relevant for ext-imei?

(Chris Newman) No Objection

(Tim Polk) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Martin Stiemerling) No Objection

(David Ward) No Objection