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

Re: Some additional obscure questions...



HI,

on the below....

At 08:43 PM 1/30/2003 -0800, Michael Kirkham wrote:
>On Thu, 30 Jan 2003, David T. Perkins wrote:
>
>Right.  Dave's got the correct interpretation of what I'm talking about.
>Thanks for providing more detailed examples.
I think you have got it not quite correct with "Dave's got the correct
interpretation...". I think you meant to say, "My (mk's) interpretation
matches the example that David Perkins provided. Thank you very much
David for providing such an efficient example."

>Taking this "in MIB modules" example, the original question posed was on
>the allowed forms for the OIDs specified in the above two lines from the
>IMPORTS section.  That is, whether the above IMPORTS could (legally) be
>specified as:
>
>   AnotherModule DEFINITIONS ::=
>   BEGIN
>      IMPORTS
>         parentOfA FROM NON-AMBIGUOUS-MIB
>         a FROM M1 { parentOfA 1 }
>         a FROM M2 { parentOfA 2 }
       ...
    END

or better yet...
   AnotherModule DEFINITIONS ::=
   BEGIN
      IMPORTS
         a FROM M1 { parentOfA 1 }  -- a forward reference
         a FROM M2 { parentOfA 2 }
         parentOfA FROM NON-AMBIGUOUS-MIB
       ...
   END

>...given...
>
>   NON-AMBIGUOUS-MIB DEFINITIONS ::=
>   BEGIN
>     ...
>     parentOfA OBJECT IDENTIFIER ::= { 0 0 99999 }
>     ...
>   END
>
>...or if only the "absolute" form (NameAndNumber or Number forms for every
>component of those two OIDs) are allowed.
By the way, only the first item in the "{ ... }" can ever be a "name"
in a MIB module. So, when you say "for every component", it sort of seems
like you are implying that items after the first can be a "name". But
they cannot!

>My ASN.1-based assumption is that the 'parentOfA' form is quite legal, and
>I believe that question as been sufficiently answered (that yes it is
>legal), unless Randy's implication was that neither the form provided in
>Dave's example nor the 'parentOfA' form above are legal.
To provide confirmation with respect to ASN.1, I would have to re-read
the ASN.1 docs and consult the appropriate ASN.1 experts. But, I'm not,
and I'll provide only a guess, which is that since ASN.1 allows forward
references, most likely the 'parentOfA' is probably legal, but I don't
have high confidence. And even if it was, probably most SNMP MIB compilers
would not support it (and most do not support an OID value in
an IMPORTS, or support <module>.<imported-item>.) As suggested by
C.M. Heard, the "absolute" form must be supported, other forms
are only conveniences for MIB writers.

>>           INCLUDES { g } -- note: no qualification with module ID
>>           INCLUDES { g } -- note: no qualification with module ID
>>           MANDATORY-GROUPS { g } -- note: no qualification with module ID
>>           MANDATORY-GROUPS { g } -- note: no qualification with module ID
>
>This is interesting.  I was under the impression that
>'value(OBJECT IDENTIFIER)' meant that any form allowed by ASN.1's
>ObjectIdentifierValue or any DefinedValue that resolves to such a value
>was permitted (albeit pointless to qualify with a module ID here
>since the module ID is already specified in the MODULE/SUPPORTS clauses
>and the referenced group/etc. MUST be defined in that module).
Think about all of the places that a "descriptor" can be specified.
For example in an INDEX clause. Do you think it would be legal to
have an INDEX clause look like
    INDEX { { 0 0 99999 1 1} { 0 0 200000 1} }
May the reason that the AC and MC macros use 
    Group ::= value(OBJECT IDENTIFIER)
instead of 
    Group ::= value(GroupName)
be a "mistake" of not cloning convention of ObjectName usage?
And do you think that in ASN.1, that specifying
    GroupName ::= OBJECT IDENTIFIER
    Group ::= value(GroupName)
vs
    Group ::= value(OBJECT IDENTIFIER)
are different?

Remember, the ASN.1 MACROs in the SMI are not valid, and the desired
syntax of constructs in MIB modules is not supported by the ASN.1
macros. The macros are just an illusion to make people that think
that they know how to understand syntax specifications for programming
languages happy. Are you happy?

Regards,
/david t. perkins