Re: [NGO] external module properties

Wes Hardaker <wjhns1@hardakers.net> Tue, 29 April 2008 18:43 UTC

Return-Path: <ngo-bounces@ietf.org>
X-Original-To: ngo-archive@optimus.ietf.org
Delivered-To: ietfarch-ngo-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C683A6AD8; Tue, 29 Apr 2008 11:43:26 -0700 (PDT)
X-Original-To: ngo@core3.amsl.com
Delivered-To: ngo@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE273A6BE7 for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 11:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611]
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 ILSEtwPB5kiU for <ngo@core3.amsl.com>; Tue, 29 Apr 2008 11:43:22 -0700 (PDT)
Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 745E728C257 for <ngo@ietf.org>; Tue, 29 Apr 2008 11:43:22 -0700 (PDT)
Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2B4A2399A86; Tue, 29 Apr 2008 11:42:11 -0700 (PDT)
DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=r9y7hy/lOjqT03wwc80QHa3obLg=; b=oNh1gPtXap5BmZYCFW1i+J6/VfmKKj7z5bkM4W/wldRszjlHbSiu3MXnqUz6yDz+hcjiaOfEdRr0qrQSMj0Zq3UGRJFBYR8vSJTZ2opcVtlHRQj9erMb+ZAnYVOiuM/ZFAJxKZkU439GYsCC1RpivafjfD/7Dr2WUcTexVe8Kqs=
Received: by wes.hardakers.net (Postfix, from userid 274) id EA6B7399B9B; Tue, 29 Apr 2008 11:42:10 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Andy Bierman <ietf@andybierman.com>
Organization: Sparta
References: <200804291540.m3TFeJCa088074@idle.juniper.net> <4817444F.4070302@andybierman.com>
Date: Tue, 29 Apr 2008 11:42:10 -0700
In-Reply-To: <4817444F.4070302@andybierman.com> (Andy Bierman's message of "Tue, 29 Apr 2008 08:52:47 -0700")
Message-ID: <sdfxt4tse5.fsf@wes.hardakers.net>
User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE)
MIME-Version: 1.0
Cc: NETCONF Goes On <ngo@ietf.org>
Subject: Re: [NGO] external module properties
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ngo-bounces@ietf.org
Errors-To: ngo-bounces@ietf.org

>>>>> On Tue, 29 Apr 2008 08:52:47 -0700, Andy Bierman <ietf@andybierman.com> said:

AB> But if module FOO in any NETCONF system imports module X,
AB> and module BAR imports module X, can we say in the YANG spec
AB> that they MUST refer to the same exact module X?

The problem you're trying to dance around is that you don't want to use
import statements that are verbose.

If the SMI used import statements that imported OID instead, there
wouldn't be any naming collusion issues.  But no one wants to write

  IMPORT ifIndex from 1.3.6.1.2.1.2.2.1.1

Nor do we want to write

  <magic-import from="urn:ietf:params:xml:ns:netconf:base:1.0" it="ErrorTag" />

Tools don't actually have a problem actually handling the above.  They
make indexes for lookups or read every file in a search path.  Most
tools already do this for MIB module names since you can't expect the
file name to match the BEGIN statement.

You only have three choices:

1) use fully qualified unique names from the module ID (like
   "namespace") and suffer from the lower readability

2) standardize on some prefix ownership scheme when naming files.  Your
   "module netconf", eg, shouldn't be named that way.  It should be
   "module IETF-netconf" or with some other unique prefix that identifies
   the controlling organization.

   (qualifiers count in this choice too, like

     <magic-import organization="IETF" from "netonf" it="ErrorTag" />

   )

3) be happy when conflicts occur and shrug them off as "not that big of
   a problem".

I'd like to avoid (3).  (2) may or may not require IANA help but I think
is the most reader-and-writer-friendly.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo