Re: [netmod] 6087bis namespace recommendations

[Andy Bierman <[e-mail]>]

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




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
>