Juergen Schoenwaelder <[email protected]> wrote: > 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.
I can see the value in a urn:rdns: URN. Using 'http://' for YANG module namespace is a bit weird. Why not 'https://'? Or 'gopher://'? But I like urn:yang:<module-name> even more - and if we had this, we wouldn't have to use the "namespace" statement. Unfortunately that would require a new version of YANG... /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
