[urn] ONF UNR Namespace

[Scott Mansfield <[e-mail]>]

I received comments from the list and have created this update.  For background I copied in the responses with the suggested resolutions…


Thanks,
-scott.


From Lars Svensson:

I have included an updated version of the urn document and hopefully addressed your comments.  Please see in-line (<update></update> and <note></note> tags for potential resolutions.



Thanks,

-scott.



-----Original Message-----

From: Svensson, Lars [mailto:[e-mail]]

Sent: Friday, May 25, 2018 10:50 AM

To: Scott Mansfield <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Subject: RE: Formal URN request for ONF



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.



<update>

   Namespace needed for identifiers defined by ONF, including those used

   in YANG modules RFC 6020 [2] RFC 7950 [3].  In YANG, identifiers

   identify different kinds of YANG constructs.  An identifier is a

   valid namespace which provides the scope for YANG modules and the

   leafs, lists, etc.

</update>



[[

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.



<update>

   ONF manages this URN identification model and the assignment of

   identifiers within it to resources.

</update>



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.



<note>

I added a note that The syntax of "ResourceSpecificString" must conform to the Namespace Specific String definition in RFC 7950 [3].  Is that what you mean?

</note>



Best,



Lars

From Dale Worley



Dale,



Thanks for the comments.  I have attached an updated document.



See in-line how I (hopefully) addressed your comments... (in <update></update> or <note></note> tags)



-----Original Message-----

From: Dale R. Worley [mailto:[e-mail]]

Sent: Friday, May 25, 2018 11:28 PM

To: Scott Mansfield <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

Subject: Re: [urn] Formal URN request for ONF



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



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



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



<update>

   Namespace needed for identifiers defined by ONF, including those used

   in YANG modules RFC 6020 [2] RFC 7950 [3].  In YANG, identifiers

   identify different kinds of YANG constructs.  An identifier is a

   valid namespace which provides the scope for YANG modules and the

   leafs, lists, etc.

</update>



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.



<update>

   urn:onf:{ResourceSpecificString}



   "ResourceSpecificString" identifies the information about the

   resource.



   ONF will manage the assignment of "ResourceSpecificString" and the

   specific registration values assigned for each resource.  The syntax

   of "ResourceSpecificString" must conform to the Namespace Specific

   String definition in RFC 7950 [3].  The ONF process is found in the

   ONF URN Management [4] document.

</update>



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.



<update>

For clarity, examples of how the ONF plans to manage the IANA

   provisioned NamespaceId and the ResourceSpecificString follows:



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



   o  ONF-NamespaceId: "onf" (Open Networking Foundation)



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

      Control



   o  ONF-SubProject: Example: "tapi" (Transport API)



   o  Protocol: Example: "yang"



   o  ModuleName: Example "connectivity"



   So a complete example that provides the URI for the connectivity yang

   model for the tapi sub-project of the otcc project for the ONF would

   be:



   urn:onf:otcc:tapi:yang:connectivity

</update>





2.7.  Assignment



   ONF manages resources that utilize this URN identification model.



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.



<update>

   ONF manages this URN identification model and the assignment of

   identifiers within it to resources.

</update>



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?



<note>

The ONF URN Management document reference in the text is a public document.

</note>



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



<note>

I fixed my understanding and only have a v1 to indicate that the revision is for the URN assignment.

</note>



5.  Acknowledgements



   Technical contact person:

      Kam Lam

      Role: Co-Chair of Open Information Modeling and Tooling Project

      Email: [e-mail]<mailto:[e-mail]>



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?



<note>

I removed the Technical contact person: line and added two more people in this section.

</note>



Dale


Scott Mansfield
Ericsson Inc.
[phone]