[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.
- [apps-discuss] APPSDIR review of draft-montemurro… Martin J. Dürst
- Re: [apps-discuss] APPSDIR review of draft-montem… Andrew Allen