Re: [YANG] [sub]module name uniqueness

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