Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!oli-stl!asylum!karl
From: karl@asylum.SF.CA.US (Karl Auerbach)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SNMP
Message-ID: <8888@asylum.SF.CA.US>
Date: 5 Dec 89 21:51:47 GMT
References: <237@sparta.UUCP>
Reply-To: karl@asylum.UUCP (Karl Auerbach)
Organization: The Asylum; Belmont, CA
Lines: 31

In article <237@sparta.UUCP> chris@sparta.UUCP (Chris Chiotasso) writes:
>I read the code and found that the object id's are encoded with the
>first 2 subids in a single subid field using (x*40)+y x=1st subid
>and y=2nd subid.
>
>I have also read the RFC's and have not found any reference to this.
>Am I missing something?  Why are the first 2 ids combined?

You have stumbled onto a growing problem -- RFC's which require
knowledge which is not present in the RFC itself or another RFC.  The
answer to your question is in an OSI document, named "ISO 8825
Information Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One
(ASN.1)" You need to look at section 20.

What it says is exactly what you found -- the first two object
identifier components are combined into a single subidentifier.  Why?
I don't know -- probably because they felt they could save a byte.

You'll probably find other things in SNMP that require refernce to ISO
8825 and its companion ISO 8824.  You can get copies (for $$) from a
number of sources.  I tend to use Omnicom in Vienna, Virginia.

You may also find that some SNMP implementations don't do perfect
ASN.1 encoding.  (For example, you may see COUNTERS, GAUGES [i.e.
unsigned types] being mis-encoded as negative signed integers when
high order bit is a 1.  Problems haven't occurred because most of us
tend to use machines that use 32 bit long integers and two's
complement math.)

			--karl--