Subject: Review of draft-murdock-nato-nid

From: Barry Leiba <[email-masked]>
Date: Thu, 25 Sep 2014 11:54:19 +0100

Aidan Murdock has requested publication of the subject draft, which
registers the URN NID "nato".  Please review Section 2 of the document
and comment in the next two weeks:

https://datatracker.ietf.org/doc/draft-murdock-nato-nid/

Thanks,
Barry

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Sep 2014 13:51:46 -0400

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 29 Sep 2014 14:24:06 +0100

Just answering the part directed to me:

> I have regenerated the .txt and attached it, though I still have to
> figure out how the IESG would like this re-submitted.

Just go ahead and post a revised I-D, and Dale can re-check it and let us
know.

Barry

---

From: Murdock Aidan <[email-masked]>
Date: Tue, 30 Sep 2014 11:20:16 +0000

Barry,

Ok.  It appears I have done this successfully.

Thanks,

Aidan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: 29 September 2014 15:24
To: Murdock Aidan
Cc: Dale R. Worley; [email-masked]; [email-masked]
Subject: Re: Review of draft-murdock-nato-nid

> figure out how the IESG would like this re-submitted.

Just go ahead and post a revised I-D, and Dale can re-check it and let us know.

Barry

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 30 Sep 2014 15:20:25 -0400

> From: Murdock Aidan <[email-masked]>

> Ok.  It appears I have done this successfully.

The usual method of circulating a new version of a draft is to submit
it as the next version number.  The advantage of that method is that
when someone says "I've looked at the -47 version and ...", it is
unambiguous what text he was looking at.

There are some details I think could be improved:

Abstract

The abstract starts "This document describes a Uniform Resource Name
(URN) namespace primarily for uniquely identifying Extensible Markup
Language (XML) artifacts ...".

I think it would be more informative to say "This document describes a
Uniform Resource (URN) namespace for assignment by NATO.  The current
primary use is for uniquely identifying ...".  That makes it clear
that the overall goal to be served is providing identifiers that NATO
can assign.

section 1

   Almost 400 NATO-defined messages
   that conform to ADatP-3 are contained in an Allied Procedural
   Publication Number 11 (APP-11) message catalogue.

   Since 2008, the APP-11 message catalogue (expresses
   message definitions) also includes XML-MTF definitions for these
   ...

The use of "an" versus "the" before "APP-11 message catalogue" is
inconsistent -- is there one message catalogue or a set of of them?

Also, "expresses" seems to be the wrong form of the word, but I might
be wrong about that.  (Does "the ... catalogue" "express" "message
definitions", or is "expresses" a modifier of "message definitions"?)

   ... giving rise to a need to define and manage a URN namespace
   rooted in the "nato" NID.

Better to phrase it

   ... giving rise to a need to define and manage a URN namespace to
   name the XML namespaces.

because there isn't really a "need" to call it "nato", that is just a
handy mnemonic.

section 2.4

The indenting of the BNF is irregular, but the RFC Editor will fix
that.

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

That "*(" would be better as "1*(".  (Something I was sloppy with in
my e-mail.)  The idea is that for best results you want each
alternative of the <NSS> rule to be exclusive of the others.  In this
case, '<Type> ":"  <Source> *( ":" <segment> )' can also produce what
'<Type> ":"  <Source>' can.  Thus it is better to use "1*", so the
third alternative only produces <NSS>s with three or more segments,
leaving <NSS>s with two segments to the second alternative.

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

You should omit "| <reserved>".  I accidentally copied that from RFC
2141; the intended specification in 2141 is that those characters
might be used in the future but will not be used currently.

section 2.6

   uniqueness of the resulting urn:nato namespace has been validated

I think you mean

   uniqueness of the resulting urn:nato URN has been validated

section 2.8

   At this
   time, the possibility of delegating registration activities for the
   sub-tree is evaluated, subject to supporting agreements. Otherwise,
   such responsibilities remain with the NRA as overarching Registrar.

These sentences aren't clear.  What time does the phrase "At this
time" refer to?  (the publication of the RFC vs. when "the Registrar
checks" as described in the preceding sentence) And is it "... is
being evaluated"?

I suspect that these sentences describe a (potential) modification of
the procedure specified by the rest of the paragraph, and it might be
best to extract them and make them a separate paragraph following this
one.

section 3

   The use of Uniform Resource Names with an appropriate Namespace ID
   will enable the various NATO standards committees and working groups
   [5] to use unique, relevant, reliable, permanent, managed and
   accessible namespace names for its XML products. It also provides
   NATO the opportunity to leverage the use of URNs for persistent
   naming of non-XML resources.

I believe that "its XML products" should be "their XML products"
because the antecedent is "the various NATO standards committees and
working groups".

The final sentence seems to me to be a new topic (i.e., possible
future uses of the namespace), and important enough to separate into
its own paragraph:

   A dedicated namespace also provides
   NATO the opportunity to leverage the use of URNs for persistent
   naming of non-XML resources.

section 5

   Distribution of NATO information in any form is subject to its
   security policies.

You might want to add 'This specification is not "NATO information".'
to reassure the Editor/readers that the RFC is not *itself* subject to
any NATO security policies.  (or that the policy is "unrestricted
distribution")

section 6

   This document defines a URN NID registration of "nato", which is
   requested to be entered into the IANA registry located at
   <http://www.iana.org/assignments/urn-namespaces>.

A more typical way to phrase this is:

   This document defines a URN NID registration of "nato", which is
   requested to be entered into the IANA registry "Uniform Resource
   Names (URN) Namespaces".  The registration template is given in
   section 2.

Dale