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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> (by way of S Moonesamy <sm+ietf@elandsys.com>) Fri, 16 August 2013 14:54 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EB211E8286; Fri, 16 Aug 2013 07:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level:
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMoGXw4N1pUp; Fri, 16 Aug 2013 07:54:29 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B1B11E828E; Fri, 16 Aug 2013 07:54:26 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.232.196]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7GEs6Ax012626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 07:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376664860; bh=jcO/tHy+h6rNaYdQjNN/qS0I4Mr3oTI+HHtP1No37DI=; h=Date:To:From:Subject:Cc; b=bFG0O0nu3A/xsg11BiudoHCXDJ1OJJhCyqYFh+VFSeqfDN5Rqio+vRefu/gy5KpRr KSJwKNKTLhTmI+PdXIVf8tiydXkF4V8niJ4meYuO+oiG7ZnfvJZefgg11d/AFjguoK OsovyCh2kKqqUWEon8ejL7Q9ZIrN7p4KfVjSIqQI=
Message-Id: <6.2.5.6.2.20130816075127.0d5b05b0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 16 Aug 2013 07:53:41 -0700
To: apps-discuss@ietf.org
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: draft-montemurro-gsma-imei-urn@tools.ietf.org, IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-montemurro-gsma-imei-urn-16
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2013 14:54:30 -0000

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

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

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.

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

Wording addressing the issue brought up by Tim 
Bray on ietf@ietf.org is still missing.


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

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

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

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.

RFC 5234 needs to be normative.



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.

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.

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

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

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

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.

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

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

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


Regards,   Martin.