On Wed, Apr 20, 2016 at 4:34 AM, Juergen Schoenwaelder < [email protected]> wrote:
> 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'? > > No, I didn't say that. > 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. > > This is obviously easy to accomplish since YANG imports cannot possibly work with 2 modules with the same name. 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. [...] > guidelines are not part of YANG. A compiler cannot rely on that. > > /js > Andy > > -- > 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
