Alfred Hönes <ah@TR-Sys.de> Mon, 26 October 2009 21:25 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: urn-nid@core3.amsl.com
Delivered-To: urn-nid@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 8FF713A62C1 for <urn-nid@core3.amsl.com>; Mon, 26 Oct 2009 14:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.962
X-Spam-Level: *
X-Spam-Status: No, score=1.962 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id KRq1KdsjOMvc for <urn-nid@core3.amsl.com>; Mon, 26 Oct 2009 14:25:35 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de []) by core3.amsl.com (Postfix) with ESMTP id 14EBE3A67CC for <urn-nid@ietf.org>; Mon, 26 Oct 2009 14:25:33 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: $/16.3.2) id AA014432299; Mon, 26 Oct 2009 22:24:59 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA27234 for urn-nid@ietf.org; Mon, 26 Oct 2009 22:24:58 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200910262124.WAA27234@TR-Sys.de>
Subject: draft-reed-urn-dgiwg-00
To: urn-nid@ietf.org
Date: Mon, 26 Oct 2009 22:24:58 +0100
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2009 21:25:36 -0000

I have taken a detailed look a your recent I-D,
and have a few comments, one fundamental and a bunch of mostly
 editorial topics (presented roughly in textual order).

(0)  Fundamental:  Namespace consideration

Could this namespace not reasonably be implemented as a delegation
branch within the OGC URN namespace, to which the target subject
of the draft seems to be very closely related?
[ Question triggered by draft author's affiliation! ]

(1)  General

I suggest to consistently place the definite article in front of

(2)  Section 2

(2.1)  general

I suggest (for enhanced readability) that you make use of consistent
indentation steps and levels for all clauses of the template in this
section.  The RFC Editor prefers a consistent indentation stepwidth
of 3 character positions.

(2.2)  Leading clause

I believe that this can be simplified instantaneously to say:

|  Namespace ID: dgiwg

Anything other will not really satisfy your request, isn't it? -- and
 it would be contrary to the section headline and Section 7 as well!

(2.3)  "Declared registrant ..."

Perhaps adding "Postal:"  to parallel the "Name:" already present,
and adding more line breaks would improve the clarity and readability
of the clause.

(2.4)  "Declaration of syntactic structure:"

1st para:

|   The Namespace Specific String (NSS) of all URNs that use the "nena"
    NID will have the following structure:

Ooops!   "nena" NID  ??  --  caught in copy-edit trap !?!

2nd para:

o  To disambiguate the NSS syntax, you need to specify that the
   {DGIWGresource}  part does not contain the colon (":") character,
   isn't it?.

3rd para (and other places):

o  "NRS" -- what the heck does the "N" stand for ?
   Could you please give a precise acronym expansion on first use?
   In case it simply is a not-so-meaningful name of the system
   you could say somewhere:

   ... the DGIWG Registration System (called "NRS") ...   [or similar].

o  'DGIWGresources"' -- unmatched double-quotes !

(2.5)  "Relevant ancillary documentation:"

o  The trailing period is missing after the 2nd sentence in this clause,
   "These are maintained by the DGIWG"

o  Suggested language improvement:

   More information about NRS and the registration activities and
|  procedures to be followed are defined in document on the "Concept of
   Operations for Registration", which provides the procedures for the
|  DGIWG registration of geographical items.
---                      vvvvv
|  More information about the NRS and the registration activities and
|  procedures to be followed can be found in the document, "Concept of
                             ^^^^^^^^^^^^   ^^^^^        ^
   Operations for Registration", which provides the procedures for the
|  DGIWG registration of geographical items; URL:

o  Is the URI presented a sufficiently stable URL ?
   AFAICT, the RFC Editor and IANA prefer more mnemonic URLs;
   in fact, experience has shown that URLs containing apparent
   implementation details (here: question part "?artifact_id=3526")
   frequently are less stable; be prepared for this URI being
   challenged by the RFC Editor!

(2.6)  "Identifier uniqueness considerations:"

"and subsequent strings associated."   seems to be truncated.

You have previously introduced the terms "class of resource type"
for the  DGIWGresource  component of the NSS.
In retrospect, it might be even better to more simply say "class
of resources" or "resource type" only.   I would appreciate
if you could use consistently the same term (of your preference),
since that would make the presentation much more clear and precise.
So perhaps the first sentence of this clause should become:

   The NRS will manage resources using the "dgiwg" NID and will be the
|  authority for managing the resource type identifiers and subsequent
|  strings associated with them.  [...]

(2.7)  "Process for identifier resolution:"

The acronym "RDS" is neiter expanded here nor does it appear anywhere
else in the draft; I's suggest to avoid the acronym and use the
exoanded form only in such case(s).

(3)  IANA Considerations

This section should point to Section 2 as containing the
registration template and specify the origin of the template
and the procedures followed (RFC 3406).

For instance:

|  This document registers with IANA a new Formal URN Namespace ID,
|  "dgiwg", following the procedures in RFC 3406 [RFC3406]; the
|  completed registration template is in Section 2 of this document.
|  The affected IANA registry is currently located at
|  http://www.iana.org/assignments/urn-namespaces.

Text in this style has the outstanding property that the RFC Editor
does not have to change much for temporal consistency after the
IANA registration actually has been performed, thus reducing the
potential for clerical errors introduced in final stages of the
publication process.   (In this case, the RFC Editor will most
likely simply remove the last sentence that only serves as an
assistance and counter-check for IANA during pre-publication

(4)  References

The first 3 entries in Section 8 are doubtlessly Normative!

(The guides on the RFC Editor web site explain the term
"Normative Reference" as 'needed to understand the document'.)

I refrain from arguing about the kind of the final one, but
that lacks the proper bracketed reference tag, and it lacks
quotation of the title and more details (as does the 3rd entry).

Please compare with (ISO or similar) "3rd party" references
in contemporary RFCs for examples of how these should better
appear for bibliographic precision (minimum IPR requirements
for citations).

Kind regards,
  Alfred Hönes.


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |