On Tue, Apr 19, 2016 at 12:37 PM, Martin Bjorklund <m...@tail-f.com> wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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... > > > I do not think the standard mechanisms are good enough to assume YANG module names will be globally unique. The RDNS format needs to include the naming authority somehow. The namespace URI gives the author more control to make naming collisions less likely. > /martin > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
