> On 20 Apr 2016, at 13:34, 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'? > > 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. [...]
[I know we already had this discussion but …] It is unclear what "published" means - not so much in 6087bis whose scope is restricted to Standard Track RFCs. However, 6020bis provides no definition but nonetheless uses "published" in connection with 2119 keywords, e.g. For any published change, a new "revision" statement (Section 7.1.9) MUST be included in front of the existing "revision" statements. I think this is quite problematic. Lada > > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
