Re: Review of draft-murdock-nato-nid

worley@ariadne.com (Dale R. Worley) Tue, 30 September 2014 19:20 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145B21A87CD for <urn-nid@ietfa.amsl.com>; Tue, 30 Sep 2014 12:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuQ83mV0Z_Ia for <urn-nid@ietfa.amsl.com>; Tue, 30 Sep 2014 12:20:32 -0700 (PDT)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29351A87C8 for <urn-nid@ietf.org>; Tue, 30 Sep 2014 12:20:28 -0700 (PDT)
Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-12v.sys.comcast.net with comcast id xXKJ1o0024zp9eg01XLUcy; Tue, 30 Sep 2014 19:20:28 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-07v.sys.comcast.net with comcast id xXLS1o0011KKtkw01XLSED; Tue, 30 Sep 2014 19:20:27 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s8UJKPPA005776; Tue, 30 Sep 2014 15:20:25 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s8UJKPuc005775; Tue, 30 Sep 2014 15:20:25 -0400
Date: Tue, 30 Sep 2014 15:20:25 -0400
Message-Id: <201409301920.s8UJKPuc005775@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Murdock Aidan <Aidan.Murdock@ncia.nato.int>
In-reply-to: <1aee5729c960477ca03b9f974478abd4@NRNCIEX4003.NR.NC3A> (Aidan.Murdock@ncia.nato.int)
Subject: Re: Review of draft-murdock-nato-nid
References: <CALaySJLOy61aOHBqb390+B_ciBDh3ZxRYqJ_nY1PSAD=hi0Uig@mail.gmail.com> <201409251751.s8PHpkLX016851@hobgoblin.ariadne.com> <f1b2fb63a9cc4b51848dddfa0aba0628@NRNCIEX4003.NR.NC3A> <CALaySJLRy2B_gU0z0o94b8_KC9G8aH2GjKhYFX6fOQyoP2MQ2g@mail.gmail.com> <1aee5729c960477ca03b9f974478abd4@NRNCIEX4003.NR.NC3A>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412104828; bh=v6SX6BvrnI/CUpBqtpeqoRo+MUPloBZJ1AleUbDNklY=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=GK39cDWHGH0I71AUH9cxPTaYkjTjh/MSFiS0WzgSb+MU4eH5NUEic+Ma1JEDIqxqw SZGpxVWt4nngRGQjsIyvcr9UzP2nrxzUoIJJ8vSHJ+eEjB66Wn+ghGXD022g4aY+2T /yXHU+HJIEP9V5+rPj+x5Y6ZuJKgKN+R26/EtETtTcU/YOEGg3z47YDEH05KEOTQXx 7ePp+tj8aeV9RIkUnesVb9sdswEXIdMuxEoW2OP1PHlXZ8DLpgIIc5rWVEufBrmMjb wGOKw7bmtQ9rXhBs69Ibxkb2jyNCDf3A/D/iN36520h3NvDX+62fsg+jjH9veslNtq 3YbzTz31vRMiA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/7C5sNMeoy4srv2520emTvyoBaBk
Cc: urn-nid@ietf.org, barryleiba@computer.org, draft-murdock-nato-nid@tools.ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 30 Sep 2014 19:20:35 -0000

> From: Murdock Aidan <Aidan.Murdock@ncia.nato.int>

> 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