On Tue, Apr 19, 2016 at 04:23:51PM +0000, Ing-Wher (Helen) Chen wrote: > I'm not an expert on XML namespaces and I'm a little confused by some of > the questions, so I apologize if my response below does not quite answer the > questions. I'd like to point out that the request for "rdns" URN is not to > prevent > the use of URLs. The request for "rdns" URN is to allow an enterprise to > easily > create a URN namespace, if the enterprise happens to prefer to use URN as a > YANG module namespace. I also think that the problems that arise when a > YANG module uses a URN based on an enterprise's domain name are the same > problems that arise when a YANG module uses a URL based on an enterprise's > domain name. (Of course, this is not an excuse to fix the problems that > should > be fixed.)
You write "happen to prefer to use URN" - why? > > 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'd like to flesh out this example to illustrate what I had in mind when I > wrote > that YANG model namespaces are only used to uniquely identify a model within > a device. [...] I think a management application likely has a problem is a URI value can mean different things on different devices unless it always fetches the model from the devices. Anyway, this problem exists for URNs that contain domain names in the same way as for URLs that contain domain names. In practice, I think this scenario is rare - it is likely more common that people rename modules and namespaces, e.g. when a company acquires a different company. This is strictly speaking not a problem since YANG treats such a renamed module as a new module. > > [...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>). > > This approach would require registering "yang" URN and also would place > constraints on <modulename>. These constraints might result in the same > questions that we're struggling with now, with URN/URL based on domain > names that can come and go. The namespace definition is used by the XML encoding, the JSON encoding uses the YANG module name to identify a 'namespace'. The module name generally is assumed to be unique since tools (e.g., YANG compilers) import via module names. A urn:yang:<modulename> would have the advantage to integrate things. In fact, the namespace statement in YANG could become optional, if one does not define a namespace, then the default namespace is urn:yang:<modulename> (and this would enable round-trip conversion of namespaces between XML and JSON encoding, something I always found a valuable property.) Anyway, it would be good to hear opinions of other people. /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
