I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or
AD before posting a new version of the draft.
Document: draft-montemurro-gsma-imei-urn-01
Reviewer: Pasi Eronen
Review Date: 04 May 2007
IESG Telechat date: 10 May 2007
Summary: This draft is basically ready for publication, but has
nits that should be fixed before publication.
1) Per RFC 3406, "registration information" section must
include a version number; this is missing.
2) 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.
3) The structure definition ("urn:gsma:<gsma-specifier>...")
should have colon (":") after "<gsma-specifier>".
4) 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.
5) ABNF for IMEISV:
- Again, suggest using DIGIT core rule
6) "Relevant ancillary documentation" section should probably
have pointers to the relevant 3GPP specs and GSMA rules
(PRD TW.06).
7) The title for section "Rules for Lexical Equivalence" is in
the wrong place (the preceeding paragraph also talks about
lexical equivalence).
8) 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?
9) Community considerations section is empty. This section is
required by RFC 3406.
10) 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.
11) I'd strongly suggest using symbolic references (e.g.
[RFC3261] instead of [8]); this is what the RFC editor
also recommends nowadays.
Best regards,
Pasi
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
