Subject: Re: Review of draft-murdock-nato-nid

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Oct 2014 13:32:25 -0400

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 <[email-masked]> wrote:
>> 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

---

From: Murdock Aidan <[email-masked]>
Date: Mon, 20 Oct 2014 09:39:51 +0000

Barry,

Yes, see the attached.  It looks like a ";" was replaced by a "." in the cc line, so likely only Dale received.

Regards,

Aidan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: 14 October 2014 19:32
To: Murdock Aidan
Cc: Dale R. Worley; [email-masked]; [email-masked]
Subject: Re: Review of draft-murdock-nato-nid

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

>    Names (URN) Namespaces".  The registration template is given in

Subject: RE: Review of draft-murdock-nato-nid
From: Murdock Aidan <[email-masked]>
To: "Dale R. Worley" <[email-masked]>
Cc: "[email-masked]@ietf.org" <[email-masked]@ietf.org>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Oct 2014 14:58:04 +0000

Dale,

Thank you again for your great review.  I accept all your findings, have made the corrections, and have submitted the revision here:    http://www.ietf.org/internet-drafts/draft-murdock-nato-nid-02.txt

The only outstanding item is:  "The indenting of the BNF is irregular, but the RFC Editor will fix that."
I am counting on the Editor doing just that.

I hope the latest version is more clear.  However, for any further enhancements/clarifications, please do not hesitate to provide them - your comments have been most appreciated.

Best Regards,

Aidan

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: 30 September 2014 21:20
To: Murdock Aidan
Cc: [email-masked]@ietf.org; [email-masked]
Subject: Re: Review of draft-murdock-nato-nid

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

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

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"?)

Better to phrase it

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.

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.

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

I think you mean

section 2.8

   At this

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

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:

section 5

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

Dale