Re: [OPS-AREA] assumption about number of octets encoding PENs

Well, with all due respect to SNMP, it is yet another protocol using
PENs, isn't it? J

From: mark@ellisonsoftware.com [mailto:mark@ellisonsoftware.com] On
Behalf Of Mark Ellison
Sent: Wednesday, May 23, 2012 6:14 PM
To: Romascanu, Dan (Dan)
Cc: ops-area@ietf.org; Alexey Melnikov; Alan DeKok;
pearl.liang@icann.org
Subject: Re: [OPS-AREA] 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)
<dromasca@avaya.com> 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
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area