Re: [YANG] [sub]module name uniqueness

Phil Shafer <phil@juniper.net> Sat, 05 April 2008 03:53 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 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 <yang@core3.amsl.com>; 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 <yang@core3.amsl.com>; 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 <yang@ietf.org>; 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 <ietf@andybierman.com>
In-reply-to: <47F6A7F2.9050006@andybierman.com>
Date: Fri, 04 Apr 2008 23:52:22 -0400
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 05 Apr 2008 03:53:40.0673 (UTC) FILETIME=[A2ADEB10:01C896D0]
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>
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 <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.

>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