Re: [YANG] [sub]module name uniqueness

Andy Bierman <ietf@andybierman.com> Sat, 05 April 2008 05:20 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 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 <yang@core3.amsl.com>; 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 <yang@core3.amsl.com>; 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 <yang@ietf.org>; 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 <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
References: <200804050352.m353qNds094370@idle.juniper.net>
In-Reply-To: <200804050352.m353qNds094370@idle.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

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.


> Thanks,
>  Phil
> 
> 
> 

Andy

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www.ietf.org/mailman/listinfo/yang