Re: [netmod] 6087bis namespace recommendations
Ladislav Lhotka <lhotka@nic.cz> Fri, 15 January 2016 11:39 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9BD1B2B78 for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 03:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYYJkR6eh8jC for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 03:39:18 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 641DA1B2B77 for <netmod@ietf.org>; Fri, 15 Jan 2016 03:39:17 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 065D21CC0147; Fri, 15 Jan 2016 12:39:20 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "t.petch" <ietfc@btconnect.com>
In-Reply-To: <CABCOCHTXa-XTkY73QhM3gzFbx0zQ_a24hijCz2HOaOQ9odL9DA@mail.gmail.com>
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com> <20160111104855.GA41658@elstar.local> <01d301d14ef1$814dcee0$4001a8c0@gateway.2wire.net> <CABCOCHTXa-XTkY73QhM3gzFbx0zQ_a24hijCz2HOaOQ9odL9DA@mail.gmail.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 15 Jan 2016 12:39:16 +0100
Message-ID: <m2oacnnkbf.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/1Yg0WduQV0C93aiMyp5YGJJhznQ>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2016 11:39:21 -0000
Andy Bierman <andy@yumaworks.com> writes: > On Thu, Jan 14, 2016 at 9:32 AM, t.petch <ietfc@btconnect.com> wrote: > >> ----- Original Message ----- >> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de> >> To: "Martin Bjorklund" <mbj@tail-f.com> >> Cc: <netmod@ietf.org> >> Sent: Monday, January 11, 2016 10:48 AM >> >> > On Mon, Jan 11, 2016 at 11:21:43AM +0100, Martin Bjorklund wrote: >> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [netmod] 6087bis namespace recommendations Martin Bjorklund
- Re: [netmod] 6087bis namespace recommendations Juergen Schoenwaelder
- Re: [netmod] 6087bis namespace recommendations Martin Bjorklund
- Re: [netmod] 6087bis namespace recommendations Juergen Schoenwaelder
- Re: [netmod] 6087bis namespace recommendations Mahesh Jethanandani
- Re: [netmod] 6087bis namespace recommendations t.petch
- Re: [netmod] 6087bis namespace recommendations Andy Bierman
- Re: [netmod] 6087bis namespace recommendations Ladislav Lhotka
- Re: [netmod] 6087bis namespace recommendations Juergen Schoenwaelder
- Re: [netmod] 6087bis namespace recommendations Ladislav Lhotka
- Re: [netmod] 6087bis namespace recommendations Andy Bierman
- Re: [netmod] 6087bis namespace recommendations Andy Bierman
- Re: [netmod] 6087bis namespace recommendations Ladislav Lhotka
- Re: [netmod] 6087bis namespace recommendations Ladislav Lhotka
- Re: [netmod] 6087bis namespace recommendations Andy Bierman
- Re: [netmod] 6087bis namespace recommendations Ladislav Lhotka
- Re: [netmod] 6087bis namespace recommendations Robert Wilton
- Re: [netmod] 6087bis namespace recommendations Andy Bierman
- Re: [netmod] 6087bis namespace recommendations Juergen Schoenwaelder
- Re: [netmod] 6087bis namespace recommendations Robert Wilton
- Re: [netmod] 6087bis namespace recommendations t.petch