Re: [netmod] 6087bis namespace recommendations

[Ladislav Lhotka <[e-mail]>]

> On 15 Jan 2016, at 15:16, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka <[e-mail]> wrote:
> Andy Bierman <[e-mail]> writes:
> 
> > On Thu, Jan 14, 2016 at 9:32 AM, t.petch <[e-mail]> wrote:
> >
> >> ----- Original Message -----
> >> From: "Juergen Schoenwaelder" <[e-mail]>
> >> To: "Martin Bjorklund" <[e-mail]>
> >> Cc: <[e-mail]>
> >> Sent: Monday, January 11, 2016 10:48 AM
> >>
> >> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote:
> >> > > Juergen Schoenwaelder <[e-mail]> 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.

Agreed, and also each I-D revision should bump the revision date of all its modules. If YANG modules are verified as a part of idnits, then this should also be checked.

Lada

> 
> 
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> > Fax:   [phone]         <http://www.jacobs-university.de/>
> >> >
> >> > _______________________________________________
> >> > netmod mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C