Re: 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: [email protected] [mailto:[email protected]] On
Behalf Of Mark Ellison
Sent: Wednesday, May 23, 2012 6:14 PM
To: Romascanu, Dan (Dan)
Cc: [email protected]; Alexey Melnikov; Alan DeKok;
[email protected]
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)
<[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