Re: [netmod] 6087bis namespace recommendations
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 11 January 2016 10:49 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 6739E1A88FA for <netmod@ietfa.amsl.com>; Mon, 11 Jan 2016 02:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 q-RGOTLTHusf for <netmod@ietfa.amsl.com>; Mon, 11 Jan 2016 02:49:02 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719BD1A88F9 for <netmod@ietf.org>; Mon, 11 Jan 2016 02:49:02 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3A1DC74A; Mon, 11 Jan 2016 11:49:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6ucseR7xdVKS; Mon, 11 Jan 2016 11:49:00 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Jan 2016 11:49:00 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18C222002B; Mon, 11 Jan 2016 11:49:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9P0j41I3VIjl; Mon, 11 Jan 2016 11:48:58 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 622E820013; Mon, 11 Jan 2016 11:48:58 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8212B39812B0; Mon, 11 Jan 2016 11:48:56 +0100 (CET)
Date: Mon, 11 Jan 2016 11:48:55 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Message-ID: <20160111104855.GA41658@elstar.local>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <20160111.101526.1720014765007751699.mbj@tail-f.com> <20160111092831.GA41568@elstar.local> <20160111.112143.1731089672764861015.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160111.112143.1731089672764861015.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/bE7ZyxVkY3Dn2_8PtOf1ZjCjIzI>
Cc: netmod@ietf.org
Subject: Re: [netmod] 6087bis namespace recommendations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: Mon, 11 Jan 2016 10:49:04 -0000
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: > > > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
- [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