Re: [netmod] 6087bis namespace recommendations

[Juergen Schoenwaelder <[e-mail]>]

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:
> > > Hi,
> > > 
> > > Currently, 6087bis says that standards-track, published and
> > > unpublished modules SHOULD use the URN prefix
> > > "urn:ietf:params:xml:ns:yang:".
> > > 
> > > There are two issues with this:
> > > 
> > >   1.  We already publish experimental modules w/ this prefix.
> > >       (ietf-netconf-time and ietf-complex-types).
> > > 
> > >       So 6087bis should remove "standards track" from this
> > >       recommendation.
> > 
> > Well, the current text is silent about non-standards-track modules
> 
> No, it says:
> 
>   Note that a different URN prefix string SHOULD be used for
>   non-Standards-Track modules.

Well, yes, this is likely in need of a fix then.
 
> > so
> > there is not really a conflict. While searching through 6087, I think
> > it is more important to clarify the usage of 'publish'. One solution
> > would be to use 'publishing' when we talk about the publication of
> > RFCs and to use 'posting' when we talk about the posting of an
> > Internet-Draft. But yes, this is a different can of worms.
> > 
> > >   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.)

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