Re: assumption about number of octets encoding PENs

Dan,

Here is one reference point:

The SnmpEngineID TC as defined in RFC3411 reserves 4 octets for the PEN,
but then takes the high order bit for a different purpose.  This
essentially leaves 31 usable bits for a PEN within the SnmpEngineID.

Regards,

Mark

On Wed, May 23, 2012 at 11:05 AM, 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.
>
> 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
>
>
>
>
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area