Re: [netmod] 6087bis namespace recommendations

[t.petch <[e-mail]>]

----- 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

Tom Petch

> /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