[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NGO] external module properties



>>>>> On Tue, 29 Apr 2008 08:52:47 -0700, Andy Bierman <ietf at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/ngo