From yang-bounces@ietf.org Thu Apr 3 07:59:35 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B3A28C67F; Thu, 3 Apr 2008 07:59:35 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A6228C32D for ; Thu, 3 Apr 2008 07:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.356 X-Spam-Level: X-Spam-Status: No, score=0.356 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaPF0GO3HFxg for ; Thu, 3 Apr 2008 07:59:34 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 96BC03A6C61 for ; Thu, 3 Apr 2008 07:59:34 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 18ECFD800C4 for ; Thu, 3 Apr 2008 16:59:27 +0200 (CEST) From: Ladislav Lhotka To: yang@ietf.org In-Reply-To: <20080328.145304.181904621.mbj@tail-f.com> References: <1206701898.25594.48.camel@missotis> <20080328.145304.181904621.mbj@tail-f.com> Organization: CESNET Date: Thu, 03 Apr 2008 16:59:27 +0200 Message-Id: <1207234767.6348.163.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Subject: Re: [YANG] YANG syntax X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org SGkgTWFydGluLAoKTWFydGluIEJqb3JrbHVuZCBww63FoWUgdiBQw6EgMjguIDAzLiAyMDA4IHYg MTQ6NTMgKzAxMDA6Cgo+ID4gLSBXaGF0IGlzIHRoZSByb2xlIG9mIHVua25vd24tc3RhdGVtZW50 IGluIHN0bXRzZXAgYW5kIHN0bXRlbmQ/Cj4gCj4gSXQgY292ZXJzIGV4dGVuc2lvbiBzdGF0ZW1l bnRzLiAgVGhlIGdyYW1tYXIgbXVzdCBhbGxvdyBlLmcuOgo+IAo+ICAgZGVzY3JpcHRpb24gImJs YSBibGEiIHsKPiAgICAgbXktZXh0OnR5cGUgImNsaS1oZWxwIjsKPiAgIH0KPiAKCkhvdyBkb2Vz IHRoaXMgdHJhbnNsYXRlIHRvIFlJTj8gRS5nLiwKCjxkZXNjcmlwdGlvbj4KICA8dGV4dD5ibGEg YmxhPC90ZXh0PgogIDxteWV4dDp0eXBlIHZhbHVlPSJjbGktaGVscCIvPgo8L2Rlc2NyaXB0aW9u PgoKQ2FuIHRoZSB0d28gc3ViZWxlbWVudHMgYmUgc3dhcHBlZD8gV2hlcmUgY2FuL3Nob3VsZCB0 aGUgbXlleHQgcHJlZml4IGJlCmRlY2xhcmVkPwoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwg Q0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpZQU5HIG1haWxpbmcgbGlzdApZQU5HQGlldGYub3JnCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veWFuZwo= From yang-bounces@ietf.org Fri Apr 4 15:13:58 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170C93A6A00; Fri, 4 Apr 2008 15:13:58 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A57A3A6CF4 for ; Fri, 4 Apr 2008 15:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh8y0RuQTzjY for ; Fri, 4 Apr 2008 15:13:56 -0700 (PDT) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id C2D9B3A68AA for ; Fri, 4 Apr 2008 15:13:56 -0700 (PDT) Received: (qmail 95505 invoked from network); 4 Apr 2008 22:14:03 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.158.234 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 4 Apr 2008 22:14:02 -0000 X-YMail-OSG: _eEjaU8VM1lx7HVBZCE1dm_bYN2luBryZg0s.CrVwuhEjVwY X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F6A7F2.9050006@andybierman.com> Date: Fri, 04 Apr 2008 15:13:06 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: yang Subject: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Hi, Sec 4.2.1 is silent on the requirement for module and sub-module names to be unique, across some naming scope. This is needed for interoperability. There are 3 options for processing import or include statements: 1) modules and sub-module names are globally unique, and there can only 1 file that corresponds to a given import or include statement. 2) there is some proprietary mechanism to determine which file is requested when more than 1 corresponds to the import or include statement value. 3) there is some standard mechanism to determine which file is requested when more than 1 corresponds to the import or include statement value. IMO, modules and submodules need to share the same naming scope, and be globally unique. All SMIv2 module names should also be considered part of this naming scope, so that SMIv2 modules translated to YANG do not conflict with new modules written in YANG. Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Apr 4 20:53:46 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A4B28C10D; Fri, 4 Apr 2008 20:53:46 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EB9B28C103 for ; Fri, 4 Apr 2008 20:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmiAQnTXf1vE for ; Fri, 4 Apr 2008 20:53:44 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 4B55728C10D for ; Fri, 4 Apr 2008 20:53:41 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Fri, 04 Apr 2008 20:53:48 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 20:53:40 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m353rdD85945; Fri, 4 Apr 2008 20:53:39 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m353qNds094370; Sat, 5 Apr 2008 03:52:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804050352.m353qNds094370@idle.juniper.net> To: Andy Bierman In-reply-to: <47F6A7F2.9050006@andybierman.com> Date: Fri, 04 Apr 2008 23:52:22 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Apr 2008 03:53:40.0673 (UTC) FILETIME=[A2ADEB10:01C896D0] Cc: yang Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Andy Bierman writes: > 1) modules and sub-module names are globally unique, and there can > only 1 file that corresponds to a given import or include statement. This would lead to scoped names ala java class names, giving us module names like "org.ietf.smi.interface-mib.yang". This is partially elegant, but mostly verbose. > 2) there is some proprietary mechanism to determine which file > is requested when more than 1 corresponds to the import or include > statement value. This could be done with simple rules like: - Imported modules must be found in a directory given via the -I option. - Multiple -I options may be listed. - They are searched in the order they appear on the command line. - Included submodules must be found in the same directory as their module. This makes "import" behave similarly to '#include ' and "include" behave similarly to '#include "foo.h"'. (Yes, not exactly, but similar.) > 3) there is some standard mechanism to determine which file > is requested when more than 1 corresponds to the import or include > statement value. The standard doesn't need to talk about files, since your YANG IDE may keep all your modules in a database. It's all implementation specific. >IMO, modules and submodules need to share the >same naming scope, and be globally unique. Are we wiling to live with module names like "org.ietf.foo.bar.yang"? Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Apr 4 22:20:49 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136513A68D8; Fri, 4 Apr 2008 22:20:49 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 702163A68D8 for ; Fri, 4 Apr 2008 22:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aetnb1HvZKy5 for ; Fri, 4 Apr 2008 22:20:47 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 8892A3A697C for ; Fri, 4 Apr 2008 22:20:33 -0700 (PDT) Received: (qmail 47869 invoked from network); 5 Apr 2008 05:20:40 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.158.234 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 5 Apr 2008 05:20:39 -0000 X-YMail-OSG: pxZPVykVM1n2OUG_wdCJxdgqf6Eh4PKZshYwJeXdTrF8o1HS X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F70BE9.7090109@andybierman.com> Date: Fri, 04 Apr 2008 22:19:37 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200804050352.m353qNds094370@idle.juniper.net> In-Reply-To: <200804050352.m353qNds094370@idle.juniper.net> Cc: yang Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> 1) modules and sub-module names are globally unique, and there can >> only 1 file that corresponds to a given import or include statement. > > This would lead to scoped names ala java class names, giving us > module names like "org.ietf.smi.interface-mib.yang". This is > partially elegant, but mostly verbose. > >> 2) there is some proprietary mechanism to determine which file >> is requested when more than 1 corresponds to the import or include >> statement value. > > This could be done with simple rules like: > > - Imported modules must be found in a directory given via the > -I option. > - Multiple -I options may be listed. > - They are searched in the order they appear on the command > line. > - Included submodules must be found in the same directory > as their module. > > This makes "import" behave similarly to '#include ' > and "include" behave similarly to '#include "foo.h"'. > (Yes, not exactly, but similar.) > >> 3) there is some standard mechanism to determine which file >> is requested when more than 1 corresponds to the import or include >> statement value. > > The standard doesn't need to talk about files, since your YANG IDE > may keep all your modules in a database. It's all implementation > specific. I don't see how a WG could ever publish an RFC with FOO-MODULE in it if another RFC already has a YANG module using that name. > >> IMO, modules and submodules need to share the >> same naming scope, and be globally unique. > > Are we wiling to live with module names like "org.ietf.foo.bar.yang"? > Why would we name modules like that? There are 1000s of SMI modules and generating a unique name with at most 64 unique characters has not been a real problem in 2 decades. I don't think the problem will be any worse with at least 63 unique characters, as YANG mandates. > Thanks, > Phil > > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Apr 5 13:41:23 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608B53A6C0C; Sat, 5 Apr 2008 13:41:23 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23713A6C85 for ; Sat, 5 Apr 2008 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE2VzlxuWdiv for ; Sat, 5 Apr 2008 13:41:22 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id DC04A3A6BC0 for ; Sat, 5 Apr 2008 13:41:18 -0700 (PDT) Received: from source ([66.129.224.36]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Sat, 05 Apr 2008 13:41:27 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 5 Apr 2008 13:40:41 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m35KeeD78950; Sat, 5 Apr 2008 13:40:40 -0700 (PDT) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m35KdRXW096901; Sat, 5 Apr 2008 20:39:27 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200804052039.m35KdRXW096901@idle.juniper.net> To: Andy Bierman In-reply-to: <47F70BE9.7090109@andybierman.com> Date: Sat, 05 Apr 2008 16:39:27 -0400 From: Phil Shafer X-OriginalArrivalTime: 05 Apr 2008 20:40:41.0456 (UTC) FILETIME=[5045BF00:01C8975D] Cc: yang Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Andy Bierman writes: >There are 1000s of SMI modules and generating a >unique name with at most 64 unique characters has >not been a real problem in 2 decades. I'm no SNMP dude, so I'll take your word for it, but I've seen a number of vendor mibs with names like "foo-mib", which seems to be begging for a collision with something else's foo mib. My guess would have been that this is fairly common. Vendor A invents "foo" technology, names the mib with the obvious "foo-mib". Other vendors follow, naming their mibs with "foo-mib" so they look like they invented "foo". The IETF standardizes the foo mib and ends up calling the standard "foo-mib", because, well, no one else matters ;^) Thanks, Phil _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sat Apr 5 14:40:28 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B703A6D78; Sat, 5 Apr 2008 14:40:28 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445D63A6BD8 for ; Sat, 5 Apr 2008 14:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjWkS+ngup+U for ; Sat, 5 Apr 2008 14:40:27 -0700 (PDT) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by core3.amsl.com (Postfix) with SMTP id 500A728C291 for ; Sat, 5 Apr 2008 14:40:03 -0700 (PDT) Received: (qmail 5549 invoked from network); 5 Apr 2008 21:40:11 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.158.234 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 5 Apr 2008 21:40:10 -0000 X-YMail-OSG: GGk8_4IVM1k8nFXovj.vdJmW.N4eI8tVwx45pdi35xJRgnDB X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F7F1CA.4070204@andybierman.com> Date: Sat, 05 Apr 2008 14:40:26 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Phil Shafer References: <200804052039.m35KdRXW096901@idle.juniper.net> In-Reply-To: <200804052039.m35KdRXW096901@idle.juniper.net> Cc: yang Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Phil Shafer wrote: > Andy Bierman writes: >> There are 1000s of SMI modules and generating a >> unique name with at most 64 unique characters has >> not been a real problem in 2 decades. > > I'm no SNMP dude, so I'll take your word for it, but I've seen a > number of vendor mibs with names like "foo-mib", which seems to be > begging for a collision with something else's foo mib. > It doesn't happen that often, since the odds of both proprietary MIB modules showing up on the same agent are very low. > My guess would have been that this is fairly common. Vendor A > invents "foo" technology, names the mib with the obvious "foo-mib". > Other vendors follow, naming their mibs with "foo-mib" so they look > like they invented "foo". The IETF standardizes the foo mib and > ends up calling the standard "foo-mib", because, well, no one else > matters ;^) > Most vendors use some sort of prefix to prevent naming collisions. Certainly, the IETF does not allow any of its module names to collide. If 2 RFCs have the same SMIv2 module, then they are different versions of the same module. This could be a detail that is part of the conformance for IETF modules. For example, modules with no description clauses, no organization, no contact, etc. may be valid YANG, but they should not be valid IETF YANG modules. If vendors think it's a good idea to allow FOO-MIB to mean totally different modules within the same system, then they should do that. The downside to the 'no-CLR' approach is that the IETF can only manage its own module names, and any collisions with vendor names are irrelevant (to the IETF). Vendors should pick names the IETF would never choose, and therefore avoid any collisions. (Eg. ACME-ROUTING-MIB). My original coding issue is actually related to submodules with the same name. Is module FOO-MIB allowed to include a totally different BAR-TYPES.yang than the one included by GOO-MIB? The belongs-to clause could actually be used to sort it out, but IMO this is a bad idea. Implementations are not likely to keep hunting 'BAR-TYPES.yang' files until it finds the right 'belongs-to' value. First match wins is much more likely. > Thanks, > Phil > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Apr 6 03:33:51 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EB43A6D88; Sun, 6 Apr 2008 03:33:51 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F0928C0DD for ; Sun, 6 Apr 2008 03:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2BsJE96rJV1 for ; Sun, 6 Apr 2008 03:33:48 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 0CE7F3A6D7F for ; Sun, 6 Apr 2008 03:33:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,611,1199682000"; d="scan'208";a="101179980" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Apr 2008 06:33:53 -0400 X-IronPort-AV: E=Sophos;i="4.25,611,1199682000"; d="scan'208";a="185301024" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Apr 2008 06:33:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Apr 2008 12:34:01 +0200 Message-ID: In-Reply-To: <47F70BE9.7090109@andybierman.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [YANG] [sub]module name uniqueness Thread-Index: AciW3NtZoKPWsdPMSPSJn5FU3+c9ywA8zouQ References: <200804050352.m353qNds094370@idle.juniper.net> <47F70BE9.7090109@andybierman.com> From: "Romascanu, Dan (Dan)" To: "Andy Bierman" , "Phil Shafer" Cc: yang Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org > -----Original Message----- > From: yang-bounces@ietf.org [mailto:yang-bounces@ietf.org] On > Behalf Of Andy Bierman > Sent: Saturday, April 05, 2008 8:20 AM > To: Phil Shafer > Cc: yang > Subject: Re: [YANG] [sub]module name uniqueness > > Phil Shafer wrote: > > Andy Bierman writes: > >> 1) modules and sub-module names are globally unique, and there can > >> only 1 file that corresponds to a given import or > include statement. > > > > This would lead to scoped names ala java class names, > giving us module > > names like "org.ietf.smi.interface-mib.yang". This is partially > > elegant, but mostly verbose. > > > >> 2) there is some proprietary mechanism to determine which file > >> is requested when more than 1 corresponds to the > import or include > >> statement value. > > > > This could be done with simple rules like: > > > > - Imported modules must be found in a directory given via the > > -I option. > > - Multiple -I options may be listed. > > - They are searched in the order they appear on the command > > line. > > - Included submodules must be found in the same directory > > as their module. > > > > This makes "import" behave similarly to '#include ' > > and "include" behave similarly to '#include "foo.h"'. > > (Yes, not exactly, but similar.) > > > >> 3) there is some standard mechanism to determine which file > >> is requested when more than 1 corresponds to the > import or include > >> statement value. > > > > The standard doesn't need to talk about files, since your > YANG IDE may > > keep all your modules in a database. It's all implementation > > specific. > > I don't see how a WG could ever publish > an RFC with FOO-MODULE in it if another RFC already has a > YANG module using that name. > > > > > >> IMO, modules and submodules need to share the same naming > scope, and > >> be globally unique. > > > > Are we wiling to live with module names like > "org.ietf.foo.bar.yang"? > > > > Why would we name modules like that? > There are 1000s of SMI modules and generating a unique name > with at most 64 unique characters has not been a real problem > in 2 decades. I don't think the problem will be any worse > with at least 63 unique characters, as YANG mandates. > We can control only the naming in the standard space and recommend rules for proprietary extensions. RFC2578 sets the rules for SMIv2 objects naming and these are mandatory for standard MIB modules, but just a "strong" recommendations for enterprise-specific modules. I am pretty sure there are more than one SMIv2 module out three named ETHERNET-MIB and more than one object named ethernetPortAdminStatus. This did not cause any interoperability problem as long as the MIB modules and objects were rooted under different OIDs, but some tools I encountered ran into trouble when loading simultaneously MIB modules with clashing modules or names. Dan _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Apr 6 06:16:33 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3C13A6B8D; Sun, 6 Apr 2008 06:16:33 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF883A6C77 for ; Sun, 6 Apr 2008 06:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6yvVSqUrP0m for ; Sun, 6 Apr 2008 06:16:31 -0700 (PDT) Received: from mail.tail-f.com (unknown [213.180.94.162]) by core3.amsl.com (Postfix) with ESMTP id 1CB1F3A6B18 for ; Sun, 6 Apr 2008 06:16:31 -0700 (PDT) Received: from localhost (c213-100-166-13.swipnet.se [213.100.166.13]) by mail.tail-f.com (Postfix) with ESMTP id EAB6E1B80C4; Sun, 6 Apr 2008 15:16:40 +0200 (CEST) Date: Sun, 06 Apr 2008 15:14:44 +0200 (CEST) Message-Id: <20080406.151444.236678828.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <47F6A7F2.9050006@andybierman.com> References: <47F6A7F2.9050006@andybierman.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: yang@ietf.org Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > Sec 4.2.1 is silent on the requirement for module and sub-module > names to be unique, across some naming scope. This is needed > for interoperability. Section 7.1 (module) and 7.2 (submodule) have this text: Standard module names will be assigned by IANA. The names of all standard modules MUST be unique (but different revisions of the same module should have the same name). Private module names will be assigned by the organization owning the module without a central registry. It is recommended to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g. by using the enterprise or organization name as a prefix. The idea has always been to make module names work like in SMIv2. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Sun Apr 6 13:05:32 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674123A6872; Sun, 6 Apr 2008 13:05:32 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5E93A6CF8 for ; Sun, 6 Apr 2008 13:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGCymov5RDMo for ; Sun, 6 Apr 2008 13:05:27 -0700 (PDT) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by core3.amsl.com (Postfix) with SMTP id 2049528C13D for ; Sun, 6 Apr 2008 13:04:58 -0700 (PDT) Received: (qmail 40232 invoked from network); 6 Apr 2008 20:05:09 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@67.125.158.234 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 6 Apr 2008 20:05:07 -0000 X-YMail-OSG: I0nBk5IVM1kZ2_lTFeon7p.rXTVLJC1a2Ufz13Aq5zPu86Oq X-Yahoo-Newman-Property: ymail-3 Message-ID: <47F92CEC.6050500@andybierman.com> Date: Sun, 06 Apr 2008 13:05:00 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: yang Subject: [YANG] 2 more naming issues X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Hi, 1) named augment Is there any value in adding user-assigned identifiers to augment-stmt instances? SMIv2 has this feature. The entire issue of augments, including augment of an augment, should be reconsidered, and if so, augment-by-name instead of augment-by-target may work better. 2) named uses Is there any value in adding user-assigned identifiers to uses-stmt instances? This is relevant because a uses-stmt can contain refinements, making it (in effect) a '1-off' grouping definition. It may be useful to refer to specific uses-stmts in normative RFC text, outside the YANG module. An identifier may be easier to read than an Xpath expression. IMO, YANG naming would be a lot cleaner if: 1) all groupings and objects shared the same naming scope 2) all object nodes had a name [object = data, rpc, or notification] Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Apr 7 23:21:37 2008 Return-Path: X-Original-To: yang-archive@optimus.ietf.org Delivered-To: ietfarch-yang-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B290D3A6E8C; Mon, 7 Apr 2008 23:21:37 -0700 (PDT) X-Original-To: yang@core3.amsl.com Delivered-To: yang@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D89E3A6C42 for ; Mon, 7 Apr 2008 23:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.307 X-Spam-Level: X-Spam-Status: No, score=-0.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2fTGoduxVpV for ; Mon, 7 Apr 2008 23:21:32 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C19B43A685F for ; Mon, 7 Apr 2008 23:21:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GxR9tS4GBbId6U7d6cDwPqtI+pVCsK0bjnLVmbypLm8ww2mkWyyftjW+LuCOqxR7; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.35.193] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jj7DH-0000UM-91 for yang@ietf.org; Tue, 08 Apr 2008 02:21:47 -0400 Message-ID: <005701c89938$814bb5a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <47F6A7F2.9050006@andybierman.com> <20080406.151444.236678828.mbj@tail-f.com> Date: Mon, 7 Apr 2008 23:22:13 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891177933603af19ecccfb6e2d1644cb88b15350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.35.193 Subject: Re: [YANG] [sub]module name uniqueness X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: yang-bounces@ietf.org Errors-To: yang-bounces@ietf.org Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Sunday, April 06, 2008 7:14 AM > Subject: Re: [YANG] [sub]module name uniqueness ... > The idea has always been to make module names work like in SMIv2. ... This means it will be a non-issue for most agent environments, and a royal pain for management systems when module names clash. (And without well-thought-out guidelines for module naming, they *will* clash.) (I have no sympathy at all for applications that had trouble with clashing SMI object descriptors, since those are clearly required to be scoped by the module name.) Randy _______________________________________________ YANG mailing list YANG@ietf.org https://www.ietf.org/mailman/listinfo/yang