Re: [apps-discuss] APPSDIR review of draft-montemurro-gsma-imei-urn-16

[Andrew Allen <[e-mail]>]

Martin

Thank you for the review and I hope you enjoyed your vacation.

My responses are inline prepended with [AA]. I also have a couple of questions for guidance and would welcome your feedback on these.

Andrew 

-----Original Message-----
From: "Martin J. Dürst" [mailto:[e-mail]] 
Sent: Friday, August 16, 2013 10:54 AM
To: [e-mail]
Cc: IESG; [e-mail]
Subject: APPSDIR review of draft-montemurro-gsma-imei-urn-16

I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-montemurro-gsma-imei-urn-16
Title: A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)
Reviewer: Martin Dürst
Review Date: August 16, 2013
IETF Last Call Date: August 16, 2013

Note: I'm on vacation, so the review and in particular the writeup is rather cursory.

Summary: This document is nearly ready for publication as a Proposed Standard.

Major issues:

The document registers both the 'gsma' URN Namespace ID as well as a single subspace therein. It would be overkill to write two separate documents for this, but it would clearly make the document more readable (and make future addditions easier) if the 'gsma' Namespace ID and the subnamespace were clearly separated. This would also simplify/untangle the grammar.

The syntax after the subnamespace ID
(gsma-specifier) is too specific. It is geared towards the current needs only, and may be too restrictive. I'd change the overall syntax to something like the following:

         gsma-urn = "urn:gsma:" gsma-specifier
                    *(":" gsma-specifier-defined-substring)

         gsma-specifier  = gsma-specifier-defined-string
         gsma-specifier-defined-string  = gsma-approved-nonempty-string
         gsma-specifier-defined-substring  = ; allow any URN character
         gsma-approved-nonempty-string = 1*unreserved ; needs to be
                                                      ; approved by GSMA
         unreserved  = ALPHA / DIGIT / "-" / "." / "_"

The 'vers' parameter is overkill. I'm not a GSMA expert, but my feeling is that such a basic identifier is changed extremely rarely. If that happens, it's much easier to just create 'imei2'. 
That would also eliminate the need to define that the absence of this parameter is the same as "vers=0".
Likewise, I'd remove the 'svn' parameter, and either use 'imeisv' or just make the IDs with software versions a few digits longer (they can easily be distinguished by length). [One could then completely get rid of the parameter syntax.]

[AA]  With regard to the general ABNF comments. Cullen Jennings has been very clear that he wants all uses of the sub namespaces under the GSMA namespace to be documented in RFCs. Therefore in the draft we need to document the currently defined usage and it makes sense to me that the ABNF for that is also documented here. The draft is already referenced by 3GPP specifications and these rely on the ABNF defined here. I think unreserved  = ALPHA / DIGIT / "-" / "." / "_" covers all the unreserved characters except the "~" character (which I cannot see any valid use for within the GSMA namespace)  and the % character which as you suggest ought to be added so that percent-encoded UTF-8 strings can be used . 

[AA] With regard to defining parameters. Early versions of this draft did define IMEISV as a separate sub namespace but Cullen Jennings provided feedback that since the IMEISV always contains as a subset the IMEI that it made sense to  define the software version as a parameter. The version number could have been defined as a separate sub namespace IMEI2, however keeping the namespace as IMEI with a "vers"  parameter allows for some backward compatibility as many entities will not need to decode the IMEI value just perform string compares on the IMEI value and so many IMEI version 0 compliant entities will still be able to understand that they have received an IMEI and be able to perform equality comparisons on the IMEI even if the format of the IMEI value is changed to for example hexadecimal or the number of digits is changed in a future version. 

[AA] My proposal is therefore to only include in the revision the % character (to allow percent-encoded UTF-8 strings) and the  gsma-approved-nonempty-string = 1*unreserved ; needs to be approved by GSMA

I don't understand why the check digit (spare) is set to '0'. URIs in general and URNs in particular are often used by humans, and in that context, a check digit is valuable (although I understand that imeis shouldn't be passed among humans too often for privacy reasons).

[AA] When transmitted the spare digit is always set to zero. The spare digit is only non-zero when displayed on the equipment and is used as a check digit to make sure that when a human being communicates an IMEI that the communicated digits transmitted (e.g. orally) and received (e.g. heard) correctly. The intention is that the URN is used within communication protocol messages and so as is stated in the draft the value of the spare digit is set to "0".

The draft says:
       Any identifier in GSMA namespaces can be compared using the normal
       mechanisms for percent-encoded UTF-8 strings.
The syntax currently doesn't allow
percent-encoded UTF-8 strings, but it should.

[AA] See above comments regarding ABNF.

In sections 4.1.4 and 4.2.4, things are rather unclear. 4.1.4 has least to most, 4.2.4 has most to most as a correspondence. Given the text, I'd have no confidence at all to get this right. 

Also, sometimes half of an octet isn't used; this should be explained and shown in the drawings. 
Also, if an octet spans two decimal digits, there should be no 'tic' in the middle of the octet value. I.e., like this:
       +-----+-----+-----+-----+-----+-----+-----+---
          1     2     3     4     5     6     7     8  Octets
and not like this:
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
          1     2     3     4     5     6     7     8  Octets

[AA] The text and figures regarding the binary representation of the IMEI are only meant to be informative. The key concepts that were trying to be conveyed are the when used in cellular signaling messages the IMEI is BCD encoded, that the IMEI and IMEISV are encoded in 8 octets, and that the most significant digit of the TAC is in the 1st Octet. The actual alignment of the digits to octets when used as an identity element in a cellular signaling message depends on the alignment of the identity element within the coding of the cellular signaling message. I can certainly remove the 'tic" or '+' between the nibbles of each octet and explain the half octet better.

Wording addressing the issue brought up by Tim Bray on [e-mail] is still missing.

[AA] this version is the same version that Tim Bray commented on. Tim's comments will also be taken into account in the next revision.

Minor issues:

The draft says:
       A sub-namespace for the IMEI is defined under the GSMA namespace.
       Other sub-namespaces may be defined in the future to include other
       identifiers in the GSM, UMTS or LTE networks or future networks
       deployed by members of the GSMA.
This seems needlessly restricted to networks. 
Just saying something like "for future identifiers needed by the GSMA".

[AA] This comment will be taken on board in the next revision.

The draft says:
                                                               Each field
       has its value printed as a decimal digit string with the most
       significant digit first.
"printed" is too narrow. Change to 'visual 
representation', or better yet, change to 
'representation for humans' (which includes 
auditory and tactile representations).

[AA] This can be changed to use the proposed 'representation for humans' text.

The draft says:
    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.
Does the GSMA indeed plan to set up a registry? 
Or is this just implicit, i.e., check all the 
relevant RFCs? In the later case, please don't 
use the term 'registry'. In the former case, 
please be more explicit about location,...

[AA] as the draft states: additional sub-namespaces under the GSMA namespace may be specified in the future by the GSMA through the publication of future Informational RFCs. Therefore it is expected that the IANA registry will be updated if any sub namespaces are registered in the future.

The draft says:
    Identifier persistence considerations:
       The GSMA is committed to maintaining uniqueness and persistence of
       all resources identified by assigned URNs.
IMEIs identify devices, but the GMSA can't 
guarantee the persistence of a device (I can shred and burn my cell phone).


The draft says:
       As the NID sought is "gsma" and GSMA is the long standing acronym
       for 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.
I don't think this paragraph is necessary. The 
parsistence consideratios are abuout persistence 
in the namespace, not of the namespace ID itself.


[AA] it seems we have misunderstood what persistence meant in the registration template. We have interpreted this as meaning that the GSMA has defined storage requirements such that the IMEI is not easily modified and once assigned persists as long as the device exists. What persistence property is being sought by the template here?

RFC 5234 needs to be normative.

[AA] This will be made into a normative reference.



Editorial:

There are many abbreviations, many of them not 
very familiar with IETF people, and some of them 
not or not consistently expanded. E.g. GSM 
appears in the second line of the abstract, but 
is only expanded at the end of the abstract.

[AA] This will be fixed and another scrub done for others

There's no need for section 3.1, because it's the 
only subsection in section 3. On the other hand, 
it would be good if it could have subsections. 
Because this is a template, that may be 
impossible. As an alternative, I suggest 
shortening the template by moving descriptive 
materail out of the template into separate subsections.

[AA] OK will look at doing that

Intro (and maybe elswhhere): Please put the 
namespace name into quotes, like this: 'gsma'.

[AA] OK

References: if possible, please replace numeric 
reference ids (e.g. [8]) with something like 
[RFC5234]. That reduces manual lookups.

[AA] This is done automatically by XML2RFC. What I can do is also insert the document ID e.g RFC 5234 [8]

Intro: "so this namespace would be managed by the 
GSMA": When the document is published, this is no 
longer a conditional, so please change "would" to "is".

[AA] OK

There are inconsistencies with punctuation. E.g. 
"TS" (an acronym that's not expanded) is spelled 
"TS" as we0ll as "TS.". Also, there should always 
be spaces outside parentheses.

[AA] OK will check for these

(if parameters are kept)
    means that the "=" character can only occur as an operator for
=>
    means that the "=" character can only occur as a separator ...

[AA] OK will revise as proposed

The security sectiion needs a careful grammar check (singular/plural,...)

[AA] OK will check

"Phone: unlisted": Just remove these useless fields.

[AA] OK

Regards,   Martin.

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