Re: assumption about number of octets encoding PENs

So this is an indirect answer. As PENs where originally designed to be
part of an OID, what results is that the upper limit is 2**32-1. Should
we say this explicitly in the future RFC? 

Dan


> -----Original Message-----
> From: Randy Presuhn [mailto:[email protected]]
> Sent: Wednesday, May 23, 2012 8:49 PM
> To: Alexey Melnikov; Romascanu, Dan (Dan)
> Cc: [email protected]; Alan DeKok; [email protected]
> Subject: Re: [OPS-AREA] assumption about number of octets encoding
PENs
> 
> Hi -
> 
> > From: "Alexey Melnikov" <[email protected]>
> > To: "Romascanu, Dan (Dan)" <[email protected]>
> > Cc: <[email protected]>; "Alan DeKok"
> <[email protected]>; <[email protected]>
> > Sent: Wednesday, May 23, 2012 9:48 AM
> > Subject: Re: [OPS-AREA] assumption about number of octets encoding
> PENs
> ...
> > I believe that OID definition explicitly don't have an upper
boundary
> on integers.
> > I don't know if any IETF RFC specifies additional constraints.
> 
> RFC 2578 (SMIv2) imposes additional constraints beyond those in ASN.1:
> 
> | 3.5.  OBJECT IDENTIFIER values
> |
> |    An OBJECT IDENTIFIER value is an ordered list of non-negative
> |    numbers.  For the SMIv2, each number in the list is referred to
as
> a
> |    sub-identifier, there are at most 128 sub-identifiers in a value,
> and
> |    each sub-identifier has a maximum value of 2^32-1 (4294967295
> |    decimal).
> 
> Randy