A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)
draft-montemurro-gsma-imei-urn-20
Discuss
Yes
(Gonzalo Camarillo)
(Lisa Dusseault)
No Objection
(Adrian Farrel)
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Joel Jaeggli)
(Lars Eggert)
(Martin Stiemerling)
(Pete Resnick)
(Ron Bonica)
(Ross Callon)
(Spencer Dawkins)
(Tim Polk)
Note: This ballot was opened for revision 09 and is now closed.
Cullen Jennings Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2009-04-24)
Unknown
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 Former IESG member
(was No Objection, Discuss)
Discuss
Discuss
[Treat as non-blocking comment]
(2009-04-02)
Unknown
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).
Gonzalo Camarillo Former IESG member
Yes
Yes
(for -19)
Unknown
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Richard Barnes Former IESG member
Yes
Yes
(2014-02-19 for -19)
Unknown
I agree with Barry that the IETF probably doesn't need control over the internals of the namespace.
Adrian Farrel Former IESG member
No Objection
No Objection
(for -19)
Unknown
Barry Leiba Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-03)
Unknown
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.
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(for -10)
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -19)
Unknown
Lars Eggert Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -19)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -19)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-07 for -10)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -19)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-03-05)
Unknown
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.
Stewart Bryant Former IESG member
No Objection
No Objection
(2014-02-18 for -19)
Unknown
I re-iterate the position of my ancestors.
Ted Lemon Former IESG member
No Objection
No Objection
(2014-02-20 for -19)
Unknown
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?
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown