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

[Ballot comment]

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.

[Ballot discuss]


I do recall but didn't have a chance to review the IETF
LC discussion of this so feel free to point me at
relevant bits of that. FWIW, I appreciate that the
authors were responsive to the privacy issues raised in
that discussion, but I also think there's maybe a bit
more work to be done.

(1) I accept that there are valid uses for these URNs at
least within mobile operator networks, but, like others,
am concerned that we're defining a pretty invasive form
of PII that can be perhaps too easily dropped into
protocols that don't properly protect such information or
that are typically not deployed with such protection
enabled. I'm not sure how best to address this in general
and would like to discuss that with the IESG and authors
in general as well as the more specific discuss points
below.

(2) cleared

(3) cleared

(4) "care SHOULD be taken" seems meaningless to me and
"MUST NOT be delivered to devices that are not trusted"
is definitely meaningless in my universe (though perhaps
it seems less so in GSM). I think you need to say when
these URNs can be safely used, and then say that other
uses are NOT RECOMMENDED. Is there a way to characterise
that crisply? If there's not, then how is this safe
really?

(5) cleared

(6) cleared

[Ballot comment]

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

[Ballot comment]
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.

[Ballot discuss]
UPDATED after some discussion...

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

I propose the following changes to this document, which should give full
control of the gsma: URN namespace to GSMA, where it belongs, while
highlighting that only the gsma:imei: URNs are applicable to the SIP
instance ID.  I've discussed this with Cullen, and he's OK with it.

In Section 3:
OLD
          future-specifier = gsma-defined-nonempty ;GSMA defined and
                                                  ;IETF consensus
                                                  ;required
NEW
          future-specifier = gsma-defined-nonempty ;GSMA defined
END


OLD
      The GSMA will take responsibility for the NSS 'imei'.

      Additional NSS may be added for future identifiers needed by the
      GSMA using the procedure for URN NSS changes and additions
      (currently through the publication of future Informational RFCs
      approved by IETF consensus).
NEW
      The GSMA will take responsibility for the "gsma" namespace,
      including the "imei" NSS.

      Additional NSS may be added for future identifiers needed by the
      GSMA, at their discretion.  Only URNs with the "imei" NSS are
      considered to be "GSMA IMEI URNs", and use in IETF protocols of
      other NSS that might be defined in the future will require
      IETF consensus.
END


In Section 4.1:
OLD
  Any change to the format specified here requires the use of the
  procedure for URN NSS changes and additions (currently the
  publication of a future Informational RFCs approved by IETF
  consensus).
NEW
 
  Any change to the format of the "imei" NSS requires the use of
  the procedure for URN NSS changes and additions (currently the
  publication of a future Informational RFCs approved by IETF
  consensus).
END

[Ballot comment]
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?

[Ballot discuss]


I do recall but didn't have a chance to review the IETF
LC discussion of this so feel free to point me at
relevant bits of that. FWIW, I appreciate that the
authors were responsive to the privacy issues raised in
that discussion, but I also think there's maybe a bit
more work to be done.

(1) I accept that there are valid uses for these URNs at
least within mobile operator networks, but, like others,
am concerned that we're defining a pretty invasive form
of PII that can be perhaps too easily dropped into
protocols that don't properly protect such information or
that are typically not deployed with such protection
enabled. I'm not sure how best to address this in general
and would like to discuss that with the IESG and authors
in general as well as the more specific discuss points
below.

(2) I think the abstract should have a brief mention of
the privacy issue, e.g. something like "URNs from this
namespace almost always contain Personally Identifying
Information and need to be treated accordingly." If doing
this, then a slightly longer paragraph along the same
lines in the intro would probably also make sense.

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

(4) "care SHOULD be taken" seems meaningless to me and
"MUST NOT be delivered to devices that are not trusted"
is definitely meaningless in my universe (though perhaps
it seems less so in GSM). I think you need to say when
these URNs can be safely used, and then say that other
uses are NOT RECOMMENDED. Is there a way to characterise
that crisply? If there's not, then how is this safe
really?

(5) "loosely correlated to a user" seems like its trying
to hide that IMEIs are PII. And "messages intended to
convey any level on anonymity" is not meaningful - what
does that really mean when you look at it? (I suspect
that might just be unfortunate phrasing from IETF LC
discussion.) I suggest you simply state that "almost all
IMEIs are almost always PII and so these URNs MUST be
treated as PII in all cases."

(6) I personally think you should state that protocols
carrying these URNs MUST or SHOULD do so over strongly
hop-by-hop encrypted channels at least, and ideally
encrypted end-to-end.  I can imagine that might not fit
with some real planned uses though, but I'd like to
discuss it a bit to see. The "if sent in clear" paragraph
is just too weak I think.

[Ballot comment]

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

[Ballot discuss]
This document's been around for a long time, and we should get it through already.

That said, there's an issue I want to talk about:

-- Section 3 --

  future-specifier = gsma-defined-nonempty ;GSMA defined and
                                            ;IETF consensus
                                            ;required
...
  Additional NSS may be added for future identifiers needed by the
  GSMA using the procedure for URN NSS changes and additions
  (currently through the publication of future Informational RFCs
  approved by IETF consensus).

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.

If you really want to have it be through IETF consensus, I'll clear my DISCUSS forthwith.  But let's please talk about what the right path here is.

[Ballot comment]
Two other, non-blocking points:

1. There are two unused normative references, [8] (UTF-8) and [9] URN syntax.  They should be anchored.  I gather that [9] was put in to resolve Magnus's DISCUSS from 2009, but it's not sufficient just to stick in a reference -- the appropriate spot in the text needs to refer to it.

2. A very, very minor suggestion: This sentence is at a level of detail that's out of place in the Abstract, and I suggest removing it:

  The IMEI is 15 decimal digits long and the IMEISV
  is 16 decimal digits long and both are encoded using Binary Encoded
  Decimal (BCD).

That information is correctly provided in the Introduction.

IESG/Authors/WG Chairs:

IANA has reviewed draft-montemurro-gsma-imei-urn-18.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Formal URN Namespaces subregistry of the Uniform Resource Names (URN) Namespaces registry at

http://www.iana.org/assignments/urn-namespaces/

a single new URN Namespace will be registered as follows:

URN Namespace: gsma
Reference: [ RFC-to-be ]

IANA understands that this action is the only one required upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Uniform Resource Name Namespace for the Global System for Mobile communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A Uniform Resource Name Namespace for the Global System for Mobile
  communications Association (GSMA) and the International Mobile
  station Equipment Identity (IMEI)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Note that this draft was already IETF Last Called in July. The current revision
of the draft is supposed to have addressed all the comments received during
the previous IETF Last Call.


Abstract


  This specification specifies a Uniform Resource Name namespace for
  the GSMA (Global System for Mobile communications Association) and a
  Namespace Specific String (NSS) for the IMEI (International Mobile
  station Equipment Identity), and an associated parameter for the
  IMEISV (International Mobile station Equipment Identity and Software
  Version number).  The IMEI is 15 decimal digits long and the IMEISV
  is 16 decimal digits long and both are encoded using Binary Encoded
  Decimal (BCD).  The IMEI and IMEISV were introduced as part of the
  specification for Global System for Mobile communications (GSM) and
  are also now incorporated by the 3rd Generation Partnership Project
  (3GPP) as part of the 3GPP specification for GSM, the Universal
  Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term
  Evolution).  The IMEI and IMEISV are used to uniquely identify Mobile
  Equipment within these systems and are managed by the GSMA.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1224/
  http://datatracker.ietf.org/ipr/2090/
  http://datatracker.ietf.org/ipr/2095/
  http://datatracker.ietf.org/ipr/1213/
  http://datatracker.ietf.org/ipr/1471/

IESG/Authors/WG Chairs:

IANA has reviewed draft-montemurro-gsma-imei-urn-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

This document requests adding a new, formal URN namespace registration to the Formal URN Namespaces located at:

http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

The namespace to be added is:

URN Namespace: gsma
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed upon approval of this document.

---
Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'A Uniform Resource Name Namespace for the GSM Association (GSMA) and
  the International Mobile station Equipment Identity (IMEI)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This specification defines a Uniform Resource Name namespace for the
  GSMA (GSM Association)and a sub-namespace for the IMEI (International
  Mobile station Equipment Identity), and an associated parameter for
  the IMEISV (International Mobile station Equipment Identity and
  Software Version number).  The IMEI is 15 decimal digits long and the
  IMEISV is 16 decimal digits long and both are encoded using Binary
  Encoded Decimal (BCD).  The IMEI and IMEISV were introduced as part
  of the specification for Global System for Mobile communications(GSM)
  and are also now incorporated by the 3rd Generation Partnership
  Project (3GPP) as part of the 3GPP specification for GSM, the
  Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long
  Term Evolution).  The IMEI and IMEISV are used to uniquely identify
  Mobile Equipment within these systems and are managed by the GSMA.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1224/
  http://datatracker.ietf.org/ipr/2090/
  http://datatracker.ietf.org/ipr/2095/
  http://datatracker.ietf.org/ipr/1213/
  http://datatracker.ietf.org/ipr/1471/

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot discuss]
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).

[Ballot discuss]
I want to understand why this request is coming from GSM not 3GPP and be sure that IETF is not being used as a tool in some politics between two other SDOs.

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.

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

The IANA consideration make no sense.

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.

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.

[Ballot discuss]
Just updating this based on having learned more about URNs. I have removed objects about allocating a subdeligated space.

There is nothing experimental about how this URN will be used (Just a few billion end hosts :-) - I am fine with informational. It also seems that an experimental may not imply the long term stability one is looking for in defining a new registry for URNs.

The motivation section implies this is a solution to problem which I don't think we have IETF consensus that this is a solution too. That said, if GSMA wants a URN for IMEI's, i think it is reasonable to ask for that without getting into how they are used. However, the whole motivation section is something we probably don't have consensus on - this could be fixed by removing it.

I think we need to verify that GSMA will run the allocation and we will not end up with nearly identical URNs from 3GPP and 3GPP2. 

It is not clear to me that IMEI are required to be in tamper proof hardware - particularly in the case of IMS compatible softphones. Could we just remove this.

DISCUSS-clearing call: agreed Informational will be best, and will pursue whether they can simply register two URNs (rather than a whole delegatable namespace of them) and the community considerations section along with other issues.  REMEMBER: Need to do IETF Last Call for Info'l.

[Ballot discuss]
There is nothing experimental about how this URN will be used (Just a few billion end hosts :-) - I am fine with informational

The motivation section implies this is a solution to problem which I don't think we have IETF consensus that this is a solution too. That said, if GSMA wants a URN for IMEI's, i think it is reasonable to ask for that without getting into how they are used. However, the whole motivation section is something we probably don't have consensus on - this could be fixed by removing it.

I think we need to verify that GSMA will run the allocation - this is purely a formality - I'm sure the answer will be yes but this document asserts GSMA will do something and it likely worth checking.  Is there agreement at 3GPP that use this that the syntax is appropriate? (I just wondering about the - separators). To resolve this we just need to consider how we would verify that 3GPP was OK with this.

I think the documents should register two URNs, imei and imeisv and not arbitrary other ones because the arbitrary space does not seem to have an allocation procedure in place that ensure they stay a URN.

It is not clear to me that IMEI are required to be in tamper proof hardware - particularly in the case of IMS compatible softphones. Could we just remove this.

[Ballot discuss]
The syntax definition for the URN is not complete. In addition to the noted issues with the IMEI and IMEISV formats, also there is to much handwaving around the general structure and what can appear in any future extensions. I assume they basically want to allow full RFC 3986 syntax. However that needs to be explicitly said.

[Ballot discuss]
There is nothing experimental about how this URN will be used (Just a few billion end hosts :-) - I think it needs to be standards track.

The motivation section implies this is a solution to problem which I don't think we have IETF consensus that this is a solution too. That said, if GSMA wants a URN for IMEI's, i think it is reasonable to ask for that without getting into how they are used. However, the whole motivation section is something we probably don't have consensus on - this could be fixed by removing it.

I think we need to verify that GSMA will run the allocation - this is purely a formality - I'm sure the answer will be yes but this document asserts GSMA will do something and it likely worth checking.  Is there agreement at 3GPP that use this that the syntax is appropriate? (I just wondering about the - separators). To resolve this we just need to consider how we would verify that 3GPP was OK with this.

I think the documents should register two URNs, imei and imeisv and not arbitrary other ones because the arbitrary space does not seem to have an allocation procedure in place that ensure they stay a URN.

It is not clear to me that IMEI are required to be in tamper proof hardware - particularly in the case of IMS compatible softphones. Could we just remove this.

[Ballot discuss]
From Section 1:

  This specification defines a Uniform Resource Name namespace for the
  GSMA (GSM Association) and sub namespaces for the IMEI (International
  Mobile station Equipment Identity), and for the IMEISV (International
  Mobile station Equipment Identity and Software Version number as per
  the namespace registration requirement found in [1].

[1] is RFC3406. However, the document never makes clear what type of URN space it is requiring as per Section 4 of RFC 3406. If this is targeting Experimental, as the Proposed Status of the document suggests the name should take the form X- as per Section 4.1 in RFC 3406. If this targets Formal, the Community Considerations section cannot be void, and an IANA section should be present, as per Section 4.3 in RFC 3406.

[Ballot comment]
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.

[Ballot discuss]
Why is this document going forward as Experimental?  What happens
  to the URN space of the experiment fails?It seems to me that
  Informational is more appropriate. 

  From Gen-ART Review by Pasi Eronen:
 
  Per RFC 3406, "registration information" section must
  include a version number; this is missing.

  Per RFC 3406, "declared registrant of the namespace"
  must include organization's address, designated contact person,
  and that person's contact information. All of these are missing.

  The structure definition ("urn:gsma:...")
  should have colon (":") after "".

  Community considerations section is empty. This section is
  required by RFC 3406.

IANA Evaluation comments:

No IANA consdierations section.

Upon approval of this document, the IANA will make
the following assignments in the "Uppon approval of
this document" registry located at

http://www.iana.org/assignments/urn-namspaces


Name Value Description
----- ------- ----------------
gsma TBD [RFC-montemurro-gsma-imei-urn-01]

We understand the above to be the only IANA Action
for this document.