Re: Review of draft-murdock-nato-nid

Barry Leiba <barryleiba@computer.org> Tue, 14 October 2014 17:32 UTC

Return-Path: <barryleiba@gmail.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 8A2C31A90D9 for <urn-nid@ietfa.amsl.com>; Tue, 14 Oct 2014 10:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] 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 dRDs76xXbTib for <urn-nid@ietfa.amsl.com>; Tue, 14 Oct 2014 10:32:27 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B371A90C4 for <urn-nid@ietf.org>; Tue, 14 Oct 2014 10:32:27 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id b6so8654520lbj.31 for <urn-nid@ietf.org>; Tue, 14 Oct 2014 10:32:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2h3zRqyMUGUWZLbREASt/tjs3UG6VdE7lM2GjowBVWw=; b=nQm5H4ErNo+fe7TjVRAhgRC0q337n09+ij7kv9tlFJlcM5+F84aQWHyFke/wAe4REF sGbztrm1yvkYJpTAe0xe5tS6wQJMiCFW5E/P2VjkPzChqYEz6r8u+BbUj32o34CFagel UucKVQLvclNN8jBSqCfuo0lESSKtlqPsnF4QTMPgr55VTPiy8zrDWtAU6vOML93pSGB0 ekDhrS8+IFHAGbDBbWYSsMKN4tt4QhCDZPr27j7jfmnaG2JkiFmjlbBuVxwbOYHKNIQ/ JiOQ0PAJChPy1P2Zmk3MzD2iS9kKt6Dcqv1pminLDVGPXguwDqEhG7kh34M45Al6oh67 a6qg==
MIME-Version: 1.0
X-Received: by 10.152.87.66 with SMTP id v2mr6903851laz.28.1413307945439; Tue, 14 Oct 2014 10:32:25 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.152.8.103 with HTTP; Tue, 14 Oct 2014 10:32:25 -0700 (PDT)
In-Reply-To: <201409301920.s8UJKPuc005775@hobgoblin.ariadne.com>
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> <201409301920.s8UJKPuc005775@hobgoblin.ariadne.com>
Date: Tue, 14 Oct 2014 13:32:25 -0400
X-Google-Sender-Auth: tL_SQe4MmB9xT2iE4eHanJhYfhs
Message-ID: <CALaySJJr02Uw10VdOK9Nw=UUZTb-ep-Q4u5EAUOV=-bXnqev1A@mail.gmail.com>
Subject: Re: Review of draft-murdock-nato-nid
From: Barry Leiba <barryleiba@computer.org>
To: Murdock Aidan <Aidan.Murdock@ncia.nato.int>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/1_hAAq6Nd9J1o4A3nkaxNTC6unQ
Cc: "urn-nid@ietf.org" <urn-nid@ietf.org>, "draft-murdock-nato-nid@tools.ietf.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, 14 Oct 2014 17:32:29 -0000

Aidan, I didn't see a reply from you to this last review from Dale,
but I see that the draft was updated a couple of weeks after it.  Did
you address Dale's comments?

Barry

On Tue, Sep 30, 2014 at 3:20 PM, Dale R. Worley <worley@ariadne.com> wrote:
>> 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