Re: Review of draft-murdock-nato-nid (Dale R. Worley) Thu, 25 September 2014 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C222D1A871F for <>; Thu, 25 Sep 2014 10:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0Slwfi4UBmko for <>; Thu, 25 Sep 2014 10:52:07 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 564461A873A for <>; Thu, 25 Sep 2014 10:51:49 -0700 (PDT)
Received: from ([]) by with comcast id vV3s1o0020mv7h001VroLM; Thu, 25 Sep 2014 17:51:48 +0000
Received: from ([]) by with comcast id vVrn1o00J1KKtkw3XVrnle; Thu, 25 Sep 2014 17:51:48 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s8PHpl9O016854; Thu, 25 Sep 2014 13:51:47 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s8PHpkLX016851; Thu, 25 Sep 2014 13:51:46 -0400
Date: Thu, 25 Sep 2014 13:51:46 -0400
Message-Id: <>
To: Barry Leiba <>
In-reply-to: <> (
Subject: Re: Review of draft-murdock-nato-nid
References: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1411667508; bh=4XRjB0IORFiWhDbv6w/JyxHMEWeWd7sSobUr7sKuyS4=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=dGL4zsgJUuMH2leQnu4rpP1mCM3x5fpdoCQAY74k7t/O0eCh0tLl0+JWZvWKR9Ntc jBHsT/TelSw3MbT+PdvVSJJka5ZBt9iRBtdGcJ2UdyGuOxRo+AI5JAEBR8CqFaUTCW PnL2t2YJ4o3sZ4I2BcGlMhDpqxFfSFt04tnJIu4uOATFuyb68ouN37CeqR1A+WIHb9 lNkUdTJaBsBzUCreJcDEEUdZVpQWOjWUlCkdsqbwa5SUU+CojS8PYXG1nQ4NDp0cGE Xx0w2Nz/hpuhIligRc33EJtzjrFvcB5p9tRc13dlE5di0UoPqvtPGJ1wqf7zpRlsv+ HG8JoC9WKv9+g==
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Sep 2014 17:52:09 -0000

The concept of the document is fine, but there are some details that
need to be cleaned up.

Technical items:

section 2.4

What is the intended syntax?

Note that the syntax of RFC 2141 allows the NSS to be a sequence of
one or more <URN chars>, among which is ":".  In particular, there is
no requirement for ":" to be present, nor that there be any other
characters between two successive ":"s.  But very few URN definitions
desire to allow such generality.  In most cases, the syntax is a
subset of:

   <NSS>         ::= <segment> *( ":" <segment> )

   <segment>     ::= 1*<non-colon chars>

   <non-colon chars> ::= <non-colon trans> | "%" <hex> <hex>

   <non-colon trans> ::= <upper> | <lower> | <number> | <non-colon other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <non-colon other> ::= "(" | ")" | "+" | "," | "-" | "." |
                     "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

I suspect you desire the syntax to be of this form, with <Type> and
<Source> being <segment>s, and if the optional <Source> is omitted,
then the ":" preceding it will also be omitted.  And also if
sub-trees below the level of Source are defined, that they involve
further <segment>s.

The problems with the current wording include:

There is no syntactic restriction on <Type> that it not include a
colon, nor that it have at least one character.  (The term "string" is
ambiguous; in some usages there can be a string with zero length.)  If
<Type> is permitted to contain colons, a URN cannot be unambiguously
parsed into <Type> and <Source> unless one has a complete list of

There is no syntactic restriction on <Source> that it not include a

If <Source> is omitted, there is no statement that the preceding colon
is to be omitted.  (Though of course, you could define that it is not
to be omitted, that would be unusual.)

There is no definition of how the syntax is to be extended to
sub-trees under <Source>.

I suspect you want a syntax definition like this:

   <NSS>         ::= <Type> | <Type> ":" <Source> |
   		     <Type> ":" <Source> *( ":" <segment> )

where <segment> is defined as above.

Editorial items:

section 2

Remove the ":" at the end of the titles of the subsections of section 2.

section 2.4

Two paragraphs in this section do not end with ".".

section 2.8

Currently, "The urn is then registered with ...".  Better usage would
be to use "URN".

section 2.9

This section currently reads:

   The namespace is not currently listed with a Resolution Discovery
   System (RDS) [3]. In the future, URNs from this namespace may be                                                          rd        resolved using a NATO listing in an RDS, using a 3  party listed
   resolver, using an unlisted, private resolver, or some combination of
   these.  The resolution method for each sub-tree will be registered
   with the NRA Registrar.

I believe the text is intended to run "... may be resolved using a
NATO listing in an RDS, using a 3rd party listed resolver ...".  The
"3rd" seems to have been originally specified with superscripting,
which subsequent processing mutilated.  I suggest writing it as