Re: Review of draft-murdock-nato-nid

[[e-mail] (Dale R. Worley)]

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
<Type>s.

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

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

Dale