Re: Some additional obscure questions...

[Bob Natale <Bob.Natale@AppliedSNMP.com>]

At 2/11/2003:05:00 PM, John Flick wrote:

Hi John,

>... 
>See RFC 2108 or RFC 2668 for real life, standards track
>examples
>...
>Note that these were both originally SMIv1 modules, and
>therefore had no MODULE-IDENTITY.  When converted to
>SMIv2,and the MODULE-IDENTITY clauses were defined, the
>WG chose to register the MODULE-IDENTITY under the original
>OID for the module.  Probably not the best practice, but
>an entirely legal one.

For contexts (like the SMI) in which "entirely legal"
means "not explicitly prohibited", not following best
practices over time leads to quagmires.

Following best practices is essential, IMHO, for SNMP sanity.
Indeed, while I certainly was not present at the creation (so
to speak), I believe that much of the original "simplicity" in
SNMP came from assumptions (reasonable at the time perhaps) that
implementers would naturally follow the best practices which are
implicit in the explicit specs.  In the present context, that
refers to naming hierarchy.

>Note that SMIv2 does not allow any definitions between the
>IMPORTS and MODULE-IDENTITY, so putting y before myMIB is
>not possible.

It is always possible to put y before myMIB in a manner
consistent with the SMI's explicit and implicit naming
hierarchy rules:  Define y in a separate MIB module and
IMPORT it.  It's not hard conceptually or in terms of
resources and it eliminates the need to break the naming
hierarchy.  (And that's how some compilers that don't
support the assumed forward reference "feature" deal with 
it.)

Fortunately, it seems that in practice the SNMP user
base is able to function despite this situation.  The
real issue, I think, has to do with the broader question
of "How do we decide whether practices that are not
explicitly prohibited by a (set of) specification(s) are
compliant with the explicit statements and the implicit
assumptions making up those specifications?"  I don't
really expect us to answer that fully but I do think
that the "Guidelines" document currently in progress
will help.

Cheers,

BobN