Re: Some additional obscure questions...

[Michael Kirkham <mikek@muonics.com>]

On Thu, 30 Jan 2003, David T. Perkins wrote:

> 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!

Not what I was implying at all.  Sorry to confuse.

> 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} }
                              ^ (comma)

Yes (with comma inserted), though very bad form and most compilers can't
deal with it, I believe this is legal.  I know of at least one
implementation besides mine that can deal with it, based on my poking at
it with various test MIBs.  My implementation can deal with it in some
places (e.g. variation callouts) and I'm right now finishing up the
process of expanding this to be consistently supported across all places
where e.g. ObjectName or NotificationName are used.

> 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?

Probably.

> And do you think that in ASN.1, that specifying
>
>     GroupName ::= OBJECT IDENTIFIER
>     Group ::= value(GroupName)
> vs
>     Group ::= value(OBJECT IDENTIFIER)
> are different?

No, I think these are equivalent, as is value(ObjectName).  I could easily
believe the *intent* was for ObjectName and NotificationName (and, if so,
then in the AC and MC productions too) to mean descriptor-only, but (a) I
don't believe that is what the productions actually say and (b) as you
yourself have noted at times, "name" means "object identifier value" in
SMI terminology as opposed to "name" meaning
"typereference/valuereference/etc." in ASN.1 terminology.

I tend to believe that this must be the case, since there would be no
other way to define a NOTIFICATION-TYPE that includes objects from
different MIBs with the same descriptor.  e.g.

MyModule DEFINITIONS ::= BEGIN
  ...
  moduleID MODULE-IDENTITY ... ::= { 0 0 99999 1 }
  ...
  aa OBJECT-TYPE ... ::= { moduleID.123 }
END

MyModule DEFINITIONS ::= BEGIN
  ...
  moduleID MODULE-IDENTITY ... ::= { 0 0 99999 2 }
  ...
  aa OBJECT-TYPE ... ::= { moduleID.456 }
END

NotificationModule DEFINITIONS ::= BEGIN
IMPORTS
   aa FROM M1 { 0 0 999999 1 }
   aa FROM M2 { 0 0 999999 2 }
   ...

   bb NOTIFICATION-TYPE
      ...
      OBJECTS { M1.aa, M2.aa }
      ...
      ::= { ... }
END

NOTIFICATION-TYPE also uses 'value(ObjectName)', so unless you're saying
that 'value(OBJECT IDENTIFIER)' for some reason allows only descriptors,
or without some text that specifically says only descriptors are allowed
in any of these cases, then I tend to believe what I said about both
'ObjectIdentifierValue' and 'DefinedValue' forms being legal.

> 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?

My happiness isn't at issue.  I'm only concerned with all the different
ways people can write badly designed (but still legal) MIBs and my tool's
ability to still work with them (for that matter, where possible, ability
to work with things that aren't legal well enough that they don't require
manual intervention to load into my tool for correction).  I'm being
overly pedantic on syntax vaguarities on purpose, since this product came
about in part by the desire to leverage my experience in helping people
work out their compiler compatibility issues.

I'm not trying to step on anyone's toes or argue that the SMI is
fundamentally flawed in some way and needs to be changed.  I'm just trying
to figure out the obscure grey areas that a lot of implementations don't
bother getting into.  There wouldn't have been much point in writing a new
parser/compiler from scratch otherwise, since the existing ones would be
sufficient. :)

--
Michael Kirkham
www.muonics.com