Re: [YANG] [sub]module name uniqueness

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Sun, 06 April 2008 10:33 UTC

Return-Path: <yang-bounces@ietf.org>
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 <yang@core3.amsl.com>; 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 <yang@core3.amsl.com>; 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 <yang@ietf.org>; 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, 06 Apr 2008 12:34:01 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04ACF137@307622ANEX5.global.avaya.com>
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)" <dromasca@avaya.com>
To: Andy Bierman <ietf@andybierman.com>, Phil Shafer <phil@juniper.net>
Cc: yang <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 <yang.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/yang>
List-Post: <mailto:yang@ietf.org>
List-Help: <mailto:yang-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=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 <foo.h>'
> > 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