On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> Andy Bierman <a...@yumaworks.com> writes: > > > On Thu, Jan 14, 2016 at 9:32 AM, t.petch <ie...@btconnect.com> wrote: > > > >> ----- Original Message ----- > >> From: "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de> > >> To: "Martin Bjorklund" <m...@tail-f.com> > >> Cc: <netmod@ietf.org> > >> Sent: Monday, January 11, 2016 10:48 AM > >> > >> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote: > >> > > Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> wrote: > >> > > > On Mon, Jan 11, 2016 at 10:15:26AM +0100, Martin Bjorklund wrote: > >> > >> <snip> > >> > > > > 2. There was some discussion about recommending a different > >> URN > >> > > > > prefix for unpublished modules (i.e., modules in Internet > >> > > > > Drafts). > >> > > > > > >> > > > > Should 6087bis recommend some special urn prefix for > >> drafts, > >> > > > > with a note to the RFC editor to change the namespace once > >> it > >> > > > > has been registered with IANA? > >> > > > > >> > > > Do we have evidence that having such a rule makes the Internet > >> work > >> > > > better? > >> > > > >> > > I don't know, but apparently there can be confusion when an > >> extracted > >> > > module from a draft is passed around. > >> > > > >> > > What can we learn from the SNMP experience where the OID assignement > >> > > is done by IANA - good or bad? > >> > > >> > With MIB modules, the module OID is assigned by IANA and we usually > >> > have a placeholder (which makes the module not compile). With SNMP, we > >> > converged to register the majority of modules below mib-2 and hence if > >> > people pick numbers, they have a high potential for collision. With > >> > NETCONF namespaces, the collision probability is rather low. The other > >> > aspect is that an official assignment happens late during the process, > >> > e.g., as part of the RFC publication process and there might be early > >> > implementations that use a 'speculative' namespace value. In a perfect > >> > world, we should likely use a different prefix while the module is > >> > under development and then let IANA have the final say on the official > >> > prefix. And if Lada is really concerned about problems caused if I-D > >> > implementations, we could do lets say a series of > >> > > >> > urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-00 > >> > ... > >> > urn:ietf:params:xml:ns:yang:draft-ietf-netmod-routing-cfg-20 > >> > > >> > in I-Ds and then the RFC editor finally changes things to > >> > > >> > urn:ietf:params:xml:ns:yang:ietf-routing > >> > > >> > if IANA agrees to allocate this URN to the module. Of course, this > >> > means more work for the editors involved and so far our lax handling > >> > of this issue seems to have worked. (But so it did for MIB modules > >> > until problems started to show up.) > >> > >> I think that, as has already been said, the much larger namespace for > >> urn compared to mib-2 makes collisions less likely. > >> > >> I have seen collisions in SMI and they were costly to fix, one > >> manufacturer or the other had to agree to back off and rework their > >> product. > >> > >> What SMI did get superbly right was setting up a branch of the tree > >> (.private.enterprises.), for organisations that wanted to get involved, > >> to register for a number, FCFS (and a process that did not involve the > >> costs of the IEEE equivalent:-) under which they could create their own > >> modules. On a typical network box, the amount of data under that branch > >> would exceed, sometimes by an order of magnitude, the amount of data > >> under mib-2. > >> > >> Originally, the intention with SMI was that development would take place > >> under a different branch and be converted to the allocated number at the > >> end, but making changes when everything was tested and working was not > >> too popular so that fell by the wayside. > >> > >> Finally, the fashion with YANG seems to be to carve up a piece of work > >> into a number of (sub)modules, so there are a number of related names > >> which again may reflect the convenience of developers rather than > >> users; and the relationship may or may not be apparent from the chosen > >> names. We could offer guidance here > >> > >> > > I like the idea of adding DRAFT to the end of the namespace identifier > > I would prefer not to put revision identifiers in the namespace. > > > > Internet-Draft publication: > > > > urn:ietf:params:xml:ns:yang:ietf-routing:DRAFT > > > > RFC publication > > > > urn:ietf:params:xml:ns:yang:ietf-routing > > > > Does this solve any practical problem? Modules are imported based on > the module name and revision. On the other hand, it does create new > problems: > namespace URIs and their mappings to prefixes may be spread in many > places in the code, and these would have to be manually edited after an > I-D -> RFC transition. > > This is an implementation detail. Our code uses a namespace registry and does not spread out hard-wired string comparisons in the code. But it is OK it we do nothing about this issue other than make sure the RFC version has a different revision date than any of the I-D versions. Andy > It would IMO be much better to use revision numbers rather than dates, > and adopt a convention, e.g., that modules in the I-D stage have > revisions 0.x that get bumped with each new revision of the I-D. > > Lada > > > > > > > > > I never liked the SMIv2 practice of putting XXX in the MIB module. > > It means that no MIB module extracted from an I-D can be compiled without > > editing it. There was never any guidance offered (over 25 years) what > number > > somebody should pick when changing XXX so the module will compile. > > This is what led to all the problems. > > > > > > > > > > Tom Petch > >> > >> > > Andy > > > > > >> > /js > >> > > >> > PS: Note that JSON encoding uses the module name and not the namespace > >> > and hence even if we do the above, module names in JSON won't > >> > signal the difference between I-D and published RFC versions of a > >> > module. So to be really fool proof one would have to change the > >> > module name also with every posted I-D. The question is at which > >> > point in time bureaucracy hampers productivity and perhaps what we > >> > do today is not perfect but a reasonable trade-off. > >> > > >> > PS: Another option could be a YANG keyword that declares the status of > >> > a module, 'draft', 'published', 'experimental', 'example', > >> > 'obsolete' and then the RFC editor would only have to toggle this > >> > value and tools could still distinguish the different kinds of > >> > YANG modules. > >> > > >> > -- > >> > 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 > >> > >> _______________________________________________ > >> 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
