Re: assumption about number of octets encoding PENs

On Wed, May 23, 2012 at 09:37:29PM -0700, Randy Presuhn wrote:
> Hi -
> 
> > From: "David Harrington" <[email protected]>
> > To: "Romascanu, Dan (Dan)" <[email protected]>; "Mark Ellison" <[email protected]>
> > Cc: "Alan DeKok" <[email protected]>; <[email protected]>; <[email protected]>
> > Sent: Wednesday, May 23, 2012 8:06 PM
> > Subject: Re: [OPS-AREA] assumption about number of octets encoding PENs
> ...
> > A PEN is defined as being an OBJECT IDENTIFIER (a sub-oid if I read
> > RFC1157 correctly).
> > I think that means the number range is constrained by the adapted subset
> > of 1988 ASN.1 that defines an INTEGER sub-oid.
> > But I don't have time right now to research that limit.
> 
> In ASN.1 the range for sub-oids isn't tied to the definition of the
> INTEGER type.  In ASN.1 no upper bound is mandated for sub-ids, other
> than in the first position and in the second position if the first is a 0 or 1,
> due to the way BER mashes them together.
> 
> RFC 1157 also didn't specify limits for sub-identifiers.  Some early
> SNMP implementers responded to this by writing their code to 
> handle well-formed subidentifiers larger than 0xFFFFFFFF.
> I ran into one very early SNMP implementation that had problems
> handling subidenfiers greater than a measly 0xFFFF. 

And because of this, sub-identifiers were restricted to 32 bits in
SMIv2. In other words, assuming PENs can be larger than 32 bits will
surely not work with SNMP. And as has been pointed out before, the
SnmpEngineID format kind of restricts this further to 31 bits. I think
documenting that the number space is de facto limited to 32 bits is a
good idea. Are we anywhere close to this limit? If not, I suggest to
postpone the discussion what to do if we run out of numbers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>