Re: [netmod] 6087bis namespace recommendations
Andy Bierman <andy@yumaworks.com> Fri, 15 January 2016 14:16 UTC
Return-Path: <andy@yumaworks.com>
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 6D2591B2D6C for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 06:16:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.678
X-Spam-Level:
X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] 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 9RhLxVC4it7W for <netmod@ietfa.amsl.com>; Fri, 15 Jan 2016 06:16:04 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041991ACE4B for <netmod@ietf.org>; Fri, 15 Jan 2016 06:16:04 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id x4so59044232lbm.0 for <netmod@ietf.org>; Fri, 15 Jan 2016 06:16:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KQbVWVDBulpfUxoaz8SbtsA0BSHZv+8Vj74hf8lswug=; b=eroAegVTIQiN3iJGrS9SNn4xIdnLvnCFF/xpWVvMSsDXcw6+1UDFPP43qm1vUlQZ4P s+/+AnbyNYlfDrvPGXhZarhTpcun9uYCrUPVwNWiuIT87E3qvh8U2siFDZDfV22bvdIg LbF1QvLp9iY+Xjca9g6eakdOouEiTJA1H1O3Qq/aDGPxXMYgXJRbT794D8eWkurk1uoM Undan9rJz3D+fkaP6gxbZ/Y2Vb0fVXITi0VatKbzZcGKTaiiYCIGyr/jIosV2C6/0Tpc 0snUMGPKd9O96kEwilDrTLVa3gdWq3DrzIEyLHRfswl9Uvn6YbovEU0KXPq/uOI2iyUC EEAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KQbVWVDBulpfUxoaz8SbtsA0BSHZv+8Vj74hf8lswug=; b=FCg1uQT5nMz80meY3U3MDrpSfNjHo/vqrUDjgpS+VKXWvzRr5Stk65PUlYXf37qI1J qIM7S4fuYcwHSwEWph7mSK+5FzrlSga6ZD3lqnVs80AKsPhCPA4EEbx8UXgPUrIhmsQw 1ID4AgW2rhHq3cjnE64vETYL61bNAJUZ60+zPE59qqfuU7e2UFokgqfzuMi2m7E+cNwt AGk7CGtXfiYT/rqn4HeDq+d6GME+N1PboaCHQ2KweNMXJ2htIaJ8cCFQNqUvDAhk60yL JpYdJFolZ1jYjprkFrXCPtAKGKSkKfTzxX+9VBw7evnaTN7HSZY6fZCSsQpEHzL+RI2X JJcQ==
X-Gm-Message-State: AG10YOQuW4LoWX2yQiDXhbDR2fF0H4Hz8eM954KeH75IPPi63fUk6YDIyfGpskWS2M6LDaFujqzkH5iAP1977A==
MIME-Version: 1.0
X-Received: by 10.112.180.7 with SMTP id dk7mr2795114lbc.65.1452867362156; Fri, 15 Jan 2016 06:16:02 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 15 Jan 2016 06:16:02 -0800 (PST)
In-Reply-To: <m2oacnnkbf.fsf@birdie.labs.nic.cz>
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> <m2oacnnkbf.fsf@birdie.labs.nic.cz>
Date: Fri, 15 Jan 2016 06:16:02 -0800
Message-ID: <CABCOCHQy7JKReSLzXE9D+Bca-Xd2Cftb=sVrnciduWwcYTD0xw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary="089e0112cad0070cb10529600b9d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/MA-ZPe1RlpwNRQJmrrN6cmCui1I>
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 14:16:07 -0000
On Fri, Jan 15, 2016 at 3:39 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > 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. > > This is an implementation detail. Our code uses a namespace registry and does not spread out hard-wired string comparisons in the code. But it is OK it we do nothing about this issue other than make sure the RFC version has a different revision date than any of the I-D versions. Andy > 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