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
- Review of draft-murdock-nato-nid Barry Leiba
- Re: Review of draft-murdock-nato-nid Dale R. Worley
- Re: Review of draft-murdock-nato-nid Barry Leiba
- RE: Review of draft-murdock-nato-nid Murdock Aidan
- Re: Review of draft-murdock-nato-nid Dale R. Worley
- Re: Review of draft-murdock-nato-nid Barry Leiba
- RE: Review of draft-murdock-nato-nid Murdock Aidan