assumption about number of octets encoding PENs

This is related to draft-liang-iana-pen-00 and
draft-ietf-radext-radius-extensions-05.txt now in WGLC. The latest
defines new Vendor-Id fields in a way consistent with RFC 2865, which
used three octets. However, in draft-liang-iana-pen-00 we say that a PEN
is a non-negative integer, which I think assumes (0..2**32-1) range. 

Questions: 

- is there any place where a limit is defined? 
- should we advice new documents to cautiously define 32 bits (at least)
for Vendor-Id fields? 
- should we say something on this respect in draft-liang-iana-pen?

What will happen to RFC 2865 implementations (and maybe other protocols)
that assumed Vendor-Id is limited to three octets - this will probably
need to be dealt by the RADEXT WG. 

Regards,

Dan