On Tue, Apr 19, 2016 at 01:51:32PM -0700, Andy Bierman wrote: > > > 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. >
Are you saying that (a) YANG imports are broken (since they assume unique module names) and that (b) JSON encoding is broken (since it uses module names to define 'namespaces'? I believe module authors will have to make sure module names are unique; if not they will learn it the hard way. Yes, I know the wording in 6020bis is Within a server, all module names MUST be unique. since this is obviously decidable and thus enforceable but RFC 6087 should clearly advice to create module names that have a larger scope of uniqueness. In fact, -06 still says: All published module names MUST be unique. [...] /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
