Re: Some additional obscure questions... Forward Refs

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

At 2/3/2003:05:40 PM, Michael Kirkham wrote:

Hi Mike,

Thanks for giving this topic some thought.

>On Mon, 3 Feb 2003, Michael Kirkham wrote:
>
>> There are plenty of ways -- both contrived and not -- to come up with
>> examples of perfectly legal modules that simply cannot be dealt with
>...
>
>Here's another, definitely not contrived:

Well, I think it is...although definitely not in a blatant way
and surely inadvertently.  Why not just pick a real example from
a real MIB (preferably a deployed IETF MIB)...?

>Column2Type TEXTUAL-CONVENTION
>  ...
>  SYNTAX OCTET STRING (SIZE(0..255))

It looks like the T-C here is totally unrelated to the
example (isn't it?) and, therefore, only present an un-
necessary confounding circumstance.

>AbcEntry ::= SEQUENCE
>{
>  abcColumn1   Integer32,
>  abcColumn2   Column2Type
>}

Note that (per RFC2578, p. 25) this is a type definition,
for use in the SYNTAX clauses of the correspondingly
named table and row objects.  So, first, it's not relevant
to the matter of forward references under discussion and,
second, would normally appear following its associated
row object (i.e., after "abcEntry" below).

So, this is already (1) an irrelevant example (the type
definition SEQUENCE does not take an OBJECT-TYPE value)
and (2) somewhat contrived (since it normally follows the
table and row OBJECT-TYPEs...but that's really just a 
matter of readability and good housekeeping...it's clear
that reading (and writing) the definition of a conceptual
table in MIBs requires a logical integration of several
sub-parts and, thus, it is natural to place them in a
coherent and consistent ordering).

>abcTable OBJECT-TYPE
>  SYNTAX SEQUENCE OF AbcEntry
>  ...
>  ::= { experimental 999999 }
>
>abcEntry OBJECT-TYPE
>  SYNTAX AbcEntry
>  ...
>  ::= { abcTable 1 }
>
>abcColumn1 OBJECT-TYPE
>  SYNTAX Integer32
>  ...
>  ::= { abcEntry 1 }
>
>abcColumn2 OBJECT-TYPE
>  SYNTAX Column2Type
>  ...
>  ::= { abcEntry 2 }

Modulo the above feedback, there is nothing troubling (to anyone, I
suspect) about this example that I can see.

>How would one arrange this (or any other) table so-as not to have any
>forward references of any kind?  I don't see that it's possible.  Or is
>the objection only with respect to forward references in OID values, and
>not in type referencess?

Yes, I believe that the discussion is limited to forward references
of OBJECT-TYPE values and their moral equivalents.  Type definition
SEQUENCEs are not of concern; nor are OBJECT-IDENTITYs in and of
themselves (e.g., they might just be used as data values for
OBJECTs of SYNTAX OID).

>What if one of this table's indices was from another table and had a
>greater OID value, with both tables defined under the same branch?

That sounds either contrived or "bass-ackwards" design to me...
but I'll admit that my brain won't let me think that through as
an abstract problem at the moment...can you give me a *concrete*
example from a real MIB that does this...just cut 'n paste and
comment...?

Thanks again, Mike...I'm really just looking for the requirement
in the SMI that forward references must be supported...but I am
happy to do my best to learn as much extra stuff as anyone thinks
I need to know.

Cheers,

BobN