Subject: [urn] Formal URN request for ONF

From: Scott Mansfield <[email-masked]>
Date: Tue, 22 May 2018 19:51:21 +0000

Thanks for the feedback received so far, here is an update of the request form.

Regards,
-scott.

Scott Mansfield
Ericsson Inc.
+1 724 931 9316

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2018 13:53:40 -0600

Scott: thanks again for the quick fixes.

Reviewers: it would be great if the rest of you could take a look at
this, too.

Thanks!

Peter

On 5/22/18 1:51 PM, Scott Mansfield wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn
>

---

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 25 May 2018 14:50:20 +0000

Hi Scott,

Your draft is well written. Some minor points, though:

[[
2.5.  Purpose

   Namespace needed for YANG RFC 6020 [2] RFC 7950 [3] modules.
]]

It would be helpful to have some text about what exactly the identifiers are supposed to do in those modules resp. what they identify.

[[
2.7.  Assignment

   ONF manages resources that utilize this URN identification model.
]]

Does ONF manage *all* resources that use this URN namespace or just *some* resources? If it's *all* resources it would help if you say so explicitly so that it's clear that no other organisation can mint URNs in that namespace and that you have full control over the assignment.

And finally you need a section on lexical equivalence saying how an agent can determine if two character sequences denote "the same" URN. Points to consider are use normalising of upper/lower case and use of characters outside of the ASCII range, particularly how to handle  percent-encoding.

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49 69 1525-1752
Telefax: +49 69 1525-1799
mailto:[email-masked] 
http://www.dnb.de

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Scott Mansfield
> Sent: Tuesday, May 22, 2018 9:51 PM
> To: [email-masked]
> Subject: [Marketing Mail] [Caution: Message contains Redirect URL content] [urn]
> Formal URN request for ONF
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 25 May 2018 23:27:32 -0400

Comments on draft-onf-urn, dated 22 May 2018:

The draft is quite straightforward and well-conceived.  It does need
some improvements in how the namespace is explained.

I was going to complain that the document does not specify any rules for
lexical equivalence, but RFC 8141 seems to have eliminated the
requirement to specify lexical equivalence rules, and to have provided
default rules.

2.5.  Purpose

It seems like it would be wise to allow other uses of the URN
namespace.  Perhaps:

   Namespace needed for identifiers defined by ONF, including those of
   YANG modules [2][3].

2.6.  Syntax

   urn:onf:{ResourceSpecificString}

   "ResourceSpecificString" identifies the information about the
   resource.

You want to add "It must conform to the syntax NSS in [1]." so as to
have an unambiguous statement of the syntax.

urn:{ONF-NamespaceId}:{ONF-Project}:{ONF-SubProject}:{Protocol}:{ModuleName}

   o  ONF-NamespaceId: onf

The following four component descriptions present the four components in
four distinct ways.  I suggest you make them consistent and clearly
separate (1) the name of the component, (2) the example value of the
component, and (3) the meaning of the example value, for each of the
four components.  E.g.,

   o  The ONF-Project: Example: "otcc" (Open Transport Configuration & Control)

etc.

2.7.  Assignment

More to the point, ONF manages the *identifiers* in this URN model.
Perhaps phrase this as

   ONF manages this URN identification model and the assignment of
   identifiers within it to resources.

2.11.  Documentation

   The ONF maintains a Uniform Resource Names (URN) document that
   provides the mechanism to ensure the resource identifiers are unique.

Is there any (public) reference to this document describing the
mechanism?

4.  Revision Information

   o  v1: Initial Version

   o  v2: Aligned with template in Appendix A RFC 8141 [1]

   o  v3: Moved example to the syntax system.  Removed reference to
      RFC1737, and moved RFC8141 to normative.

It took me a moment to realize that this section described revisions of
this document, and not revisions of the URN registration.
Document-revision information is usually removed upon publication, so
you want to add a note:

    [Note to RFC Editor:  Please remove this section before publication.]

5.  Acknowledgements

   Technical contact person:
      Kam Lam
      Role: Co-Chair of Open Information Modeling and Tooling Project
      Email: [email-masked]

Is this an acknowledgment (in which case the heading line is not really
correct), or does it provide a technical contact (which should be added
to section 2.4)?  Or perhaps it is both?

Dale