Re: assumption about number of octets encoding PENs

Hi Dan,

On 23 May 2012, at 16:05, "Romascanu, Dan (Dan)" <[email protected]> wrote:

> 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. 

Not necessarily, see below.
> 
> Questions: 
> 
> - is there any place where a limit is defined? 

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.

> - should we advice new documents to cautiously define 32 bits (at least)
> for Vendor-Id fields? 

I think that would be a good idea, yes.

> - should we say something on this respect in draft-liang-iana-pen?

I think so.

> What will happen to RFC 2865 implementations (and maybe other protocols)
> that assumed Vendor-Id is limited to three octets

Probably sufficient in medium term.

> - this will probably
> need to be dealt by the RADEXT WG. 
> 
> Regards,
> 
> Dan