Re: Some additional obscure questions...

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi Mike -

The value of the MODULE-IDENTITY macro is *not* the same
thing as the object identifier that names an ASN.1 module.
See RFC 2578 clause 5:

|   Note that reference in an IMPORTS clause or in clauses of SMIv2
|   macros to an information module is NOT through the use of the
|   'descriptor' of a MODULE-IDENTITY macro; rather, an information
|   module is referenced through specifying its module name.

Randy

----- Original Message -----
From: "Michael Kirkham" <mikek@muonics.com>
To: "David T. Perkins" <dperkins@dsperkins.com>
Cc: <mibs@ops.ietf.org>
Sent: Wednesday, January 29, 2003 7:51 PM
Subject: Re: Some additional obscure questions...


> On Wed, 29 Jan 2003, David T. Perkins wrote:
>
> > As an "old-timer" on the SMI, I appreciate your "searching for the truth".
> > But, on the other hand, it appears to me (and maybe to others), that in
> > your zeal to find the truth, you are being more concerned with legalistic
> > aspects of parsing small pieces of the SMI and ASN.1 definitions than
> > understanding the intent of the documents.
>
> Close.  I am (at this time) being more concerned with legalistic aspects
> than the intent; not with understanding the intent.  I understand, the
> intent fine, and for the most part I believe my parser/compiler is very
> good at following the intent and providing warnings/errors where a module
> doesn't follow it.  So my current focus is on legalistic aspects and
> deciding just how bad a module can get and still be legal so that my tools
> can both be as flexible AND compliant as possible.  It's no good if my
> compiler accepts as valid something that isn't; but it's also no good if
> it can't handle something that is technically legal, however obscure and
> outside current practices it is.  Such limitations in a lot of tools are
> among the reasons I undertook this project.
>
> > Please note, and I'm sorry if it sounds like a broken record,
> > that the MACRO definitions in the SMI are NOT valid ASN.1. Once
> > you understand this, then I believe that it makes understanding
> > the SMI easier.
>
> I understand this fine.  This issue has nothing to do with the SMI MACRO
> definitions, but with the SMI is defined as a delta from the ASN.1 specs;
> in this case, specifically with regard to the IMPORTS clause.  The SMI
> dosn't fully define the notation, but only says what's different from
> ASN.1.  Thus if something isn't mentioned by one of those deltas,
> presumably the ASN.1 rules apply, because it's not possible to intuit the
> complete notation and semantics solely by reading RFC 2578.
>
> > versions. However, there are still problems with the text of the
> > current SMI. Where those problems are identified, it would
> > most benefit the community of users of the SMI to document
> > the problems and provide alternative fixes with the consequences
> > of those fixes.
>
> Certainly.  But it would help to be clear what the different accepted
> interpretations are first, which is what I am looking for here.  I'm not
> attached to any particular interpretation.  I see three possibilities,
> none of which are definitively spelled out:
>
> 1. One interpretation might be that only absolute OIDs are allowed when
> specifying a MODULE-IDENTITY to disambiguate the imports.  This
> interpretation doesn't seem to be supported if the IMPORTS rules are taken
> to be the same as in ASN.1 except for those areas that are specifically
> mentioned.  This is probably the easiest for parser implementors, or
> implementors of tools that resolve references at runtime, to deal with;
> but also adds an extra chore (manually resolving to an absolute OID) for
> the module author.
>
> 2. Another might be that absolute and relative OIDs are allowed, but there
> must be at least two components (ie., no disambiguating imports via the
> descriptors of the MODULE-IDENTITYs in question).  This would seem to be
> the appropriate interpretation if you take the IMPORTS rules in the same
> light as 1, since 'DefinedValue' is not one of the forms listed in the
> 'ObjectIdentifierValue' production in the ASN.1 specs.  This is probably
> the easiest for a module author to work with, but more difficult for tools
> that resolve references at runtime (whether a compiler or an NMS) to
> implement, though still possible.
>
> 3. Another interpretation might be that any item whose value resolves to
> an 'ObjectIdentifierValue' can be used in places where the
> 'ObjectIdentifierValue' production is used.  This is probably the easiest
> for module authors to work with, but the most difficult to resolve at
> runtime.  The problem of resolving references is likely equivalent to 2,
> but there is added complexity in the need to refactor several of the
> productions in order to resolve conflicts in an LALR(1) type parser.
>
> Personally, I subscribe to #2 but support #3 (mostly) for flexibility.
>
> --
> Michael Kirkham
> www.muonics.com
>
>