[urn] ONF UNR Namespace

Scott Mansfield <scott.mansfield@ericsson.com> Tue, 29 May 2018 20:02 UTC

Return-Path: <scott.mansfield@ericsson.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA4612ECC6 for <urn@ietfa.amsl.com>; Tue, 29 May 2018 13:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 c1gWnZd9Wwqd for <urn@ietfa.amsl.com>; Tue, 29 May 2018 13:02:03 -0700 (PDT)
Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7EB12EB6B for <urn@ietf.org>; Tue, 29 May 2018 13:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527624114; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OwYTq70+e7g6aktQUJfG5MqJ71sa5dyWayE+ALEM2Fc=; b=dUGTnbGehBnzJ9HpPnROe9kV+SczMkgOQnix6h2rcThKFYYMn1/QRlYNNKELLYSq ZZgTvwSl/2qKim9hRH2Jzc+W6vZmj7qUlL16x/on9dR0o+F+CGs/IAuRT0rYUxEb qDE6MGJeoIwk6CZIGEFIMDmo8OGqIbFgJyiTUzrOMe0=;
X-AuditID: c618062d-a69ff70000001885-94-5b0db1b1b000
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 34.A1.06277.1B1BD0B5; Tue, 29 May 2018 22:01:54 +0200 (CEST)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0382.000; Tue, 29 May 2018 16:01:53 -0400
From: Scott Mansfield <scott.mansfield@ericsson.com>
To: "urn@ietf.org" <urn@ietf.org>
CC: "timon@opennetworking.org" <timon@opennetworking.org>, =?utf-8?B?5p6X5bqG5rem?= <kamlam@fiberhome.com>, "Davis, Nigel (ndavis@ciena.com)" <ndavis@ciena.com>
Thread-Topic: ONF UNR Namespace
Thread-Index: AdP3h0658SnDol3bT+efPGnqgXmtxw==
Date: Tue, 29 May 2018 20:01:53 +0000
Message-ID: <EF35EE4B92789843B1DECBC0E24558646BDED6D7@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/mixed; boundary="_004_EF35EE4B92789843B1DECBC0E24558646BDED6D7eusaamb107erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUyuXSPn+6mjbzRBpd/iVvcereB3eLpbRmL 1adbWS2mNn9gcmDxOHvzH4vHpt6DzB5Llvxk8ng01TCAJYrLJiU1J7MstUjfLoEr48jPc4wF XxYyV3R2/WRuYLw/jbmLkZNDQsBE4uDtqYxdjFwcQgJHGSU2dH9kg3CWM0o8edDNCFLFBlS1 ddd0MFtEQFFi37MmdpAiZoEljBLTNh4ESnBwCAtISZxrzgExRQTkJY5PCYMo15N40zSDHcRm EVCVeHRpFxNICa+Ar8SK7aUgYUYBMYnvp9YwgdjMAuISt57MZ4K4TUTi4cXTbBC2qMTLx/9Y IWwliUlLz7FC1GdKbLvWAXYZr4CgxMmZT1gmMArNQjJqFpKyWUjKIOL5EgcmrGObBXQRs4Cm xPpd+hBhRYkp3Q/ZIWwNidY5c9kxxY0kHpzsYYOw1STur1rPOgscJusZJVZfuc6ErGEBI88q Ro7S4oKc3HQjg02MwFg9JsGmu4Px/nTPQ4wCHIxKPLynFvNGC7EmlhVX5h5iVAFqfbRh9QVG KZa8/LxUJRHe0r080UK8KYmVValF+fFFpTmpxYcYpTlYlMR5z3jyRgkJpCeWpGanphakFsFk mTg4pRoYBYwsjh77Vfh0vsdKu517Y0VPMiY6Om2fyD7r443oYyFnQ9YdOrf1R8SqOZsKzMp8 n6ZX+jxpb05oTGCs/vNcT3L7efE//Aern96cKZq7iPt53C5Gdvn9T5quOFTpxB63MjpUtJMt 4vGWDa5b/0mn2m2X1VIPnO4xZcOEt0VR8x56/bN5yPJARImlOCPRUIu5qDgRACAF5k7dAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/tEZR4fGju3UOnhV7VfA5T9dc_RA>
Subject: [urn] ONF UNR Namespace
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2018 20:02:20 -0000

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:L.Svensson@dnb.de]

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

To: Scott Mansfield <scott.mansfield@ericsson.com<mailto:scott.mansfield@ericsson.com>>; urn@ietf.org<mailto:urn@ietf.org>

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:worley@ariadne.com]

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

To: Scott Mansfield <scott.mansfield@ericsson.com<mailto:scott.mansfield@ericsson.com>>; timon@opennetworking.org<mailto:timon@opennetworking.org>

Cc: urn@ietf.org<mailto:urn@ietf.org>

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: kam.lam@fiberhome.com<mailto:kam.lam@fiberhome.com>



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.
+1 724 931 9316