Re: [netmod] 6087bis namespace recommendations

[Ladislav Lhotka <[e-mail]>]

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.

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