[tkined] scotty (2.1.8) has problems parsing ATOMMIB drafts - upcoming MIBs for ATM

Peder Chr. Norgaard (pcn@tbit.dk)
Thu, 26 Feb 1998 13:16:32 +0100 (MET)

Hello,
I have attempted to use scotty to test an implementation of the
workings of the IETF ATOMMIB group. The SNMP parser, unfortunately, fails
to parse the textual convention MIB of the ATOMMIB suite, in the file
draft-ietf-atommib-atm2TC-06.txt.

The problem is that this draft contains two ASN.1 OID values
with more than one numeric sub-identifier:

atmTCMIB MODULE-IDENTITY .... ::= { mib-2 37 3 }
and
atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1}

The logic in tnm/snmp/tnmMibParser.c that parses such values - the
function ReadSubID with identical code fragments surrounding the
call of ReadSubID in 9 places - and perhaps the entire reading logic
seem to be built on the assumption that OID values consists
of the named form of sub-identifiers, except in the last position.
So parsing the original form results in error messages caused by the
fact that the two symbols are not registered properly for use in
other OID values.

When I change the definitions to

atmTCMIB MODULE-IDENTITY .... ::= { mib-2 atmMIB(37) 3 }
and
atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 atmMIB(37) atmMIBObjects(1) 1}

(stealing the name forms used from the companion
draft-ietf-atommib-atn1ng-03.txt) everything works fine.

I am pretty certain that the construction used in the textual
convention ATOMMIB is valid. It *is* valid with respect to the ASN.1
standard, and I cannot find anything in the SNMP SMI that prohibits
it's use. The construction is not used in any current standard SNMP
MIBs, and is as such somewhat unconventional. The reason for the use
of the construction is probably that the textual convention stuff is
split out from the RFC 1695, with most of the other stuff going to
other drafts - which scotty needs to parse *after* parsing the textual
conventions.

Unfortunately, I do not have a code fix for the problem; I can
see what causes the problem, but fixing it calls for detailed knowledge
of the data structures used during parsing.

best regards
--peder chr.

Peder Chr. Nørgaard System Developer, M. Sc.
Telebit Communications A/S tel: +45 86 28 81 77 - 49
Fabrikvej 11 fax: +45 86 28 81 86
DK-8260 Viby J Denmark e-mail: pcn@tbit.dk

--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.