On Fri, Apr 15, 2016 at 03:53:04PM +0000, Ing-Wher (Helen) Chen wrote: > Section 4 of the draft > <https://tools.ietf.org/html/draft-chen-rdns-urn-06#section-4> > documents why a URN is better than URL as a namespace. While a URL is > globally > unique, a URL is also a resource locator, providing access information. For > an enterprise > that does not wish to publish the access information of its YANG models, a > URN is a better > choice.
Continuing as devil's advocate... The YANG specifications (both 1.0 and 1.1) has a normative reference to https://www.w3.org/TR/2009/REC-xml-names-20091208/ which states in section 3: [...] The namespace name, to serve its intended purpose, SHOULD have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). Uniform Resource Names [RFC2141] is an example of a syntax that is designed with these goals in mind. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals. Do we have evidence that managing ordinary URLs in such a way as to achieve these same goals (of uniqueness and persistence) is a problem? If so, why does this only apply to YANG modules (only one of many uses of XML namespaces)? > As required by RFC 3406, Section 3 of the draft, at the bottom of page 5 > <https://tools.ietf.org/html/draft-chen-rdns-urn-06#page-5> under "Identifier > Persistence > Considerations", addresses the question of identifier persistence. The main > concern > for "identifier persistence" is in the case where an identifier is used for > global resolution. > Because YANG model namespaces do not provide global resolutions (actually YANG > model namespaces are only used to uniquely identify a model within a device), > the identifier persistence consideration is not as crucial. (Please see RFC > 3406 > top of page 13 <https://tools.ietf.org/html/rfc3406#page-13> for the > identifier > persistence discussion.) I am not sure I agree that the scope of a YANG namespace is limited to a device. There is nothing that prevents some random device to implement some random YANG model. If the org currently owning bar.foo publishes a module using urn:rdns:com:foo:bar as a namespace then other orgs can implement this module as well if they think this is a good idea. I read: In practice, an administrator consciously installs YANG modules in a device. Thus, in the unlikely event that there is a collision due to changing domain names, the administrator can detect the collision and rectify the situation by requesting that the offending organization republish its YANG modules with the correct "rdns" URNs. Who is the 'administrator' that consciously installs YANG modules in a device here? Administrator of what - the namespace or the device? In case you mean the administrator of the namespace then what happens in the case where this role changes because some other org took over the domain name? If a module uses urn:rdns:com:foo:bar and I later buy the domain bar.foo than do I get change control of the YANG module using this particular namespace as a side effect? [...break...] Taking a step back, we do have the tension between XML namespaces (that are identified by URIs and used in the XML encoding) and 'JSON namespaces' identified by module names (and used in the JSON encoding). The former is relying on the uniqueness of a URI while the later is relying on the uniqueness of the YANG module name. So from this perspective, assuming the YANG module name is already sufficiently unique, perhaps the right thing to do is to simply use urn:yang:<modulename> for all XML namespaces and to essentially get rid of the namespace declaration in YANG (which then defaults to urn:yang:<modulename>). Now I need a break to think about this... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
