Subject: [eap] RFC 2284bis issues

From: [email-masked] (Simon Josefsson)
Date: Thu, 21 Feb 2002 07:27:03 -0600

Bernard Aboba <[email-masked]> writes:

> 1. IANA considerations. RFC 2284 does not include an IANA considerations
> section, and RFC 2284bis needs one. Some thoughts on what might be in such
> a section:
>
>    a. Reservation of some of the Type space for future use. Should this be
>       a single EAP method (255) or more of the space (e.g. 127-255)?

One value should be enough to extend the protocol syntax in the
future, I don't see an argument for reserving one entire bit, but
maybe I am missing something.

>    b. Statement that IANA should not allocate two Type codes for a single
>       EAP method.

Yes.

>    c. Statement about reclamation of unused Type allocations. It looks
>      like several of the alllocated Type codes have never been used.
>
>    d. Allocation of an EAP Type code for "Vendor Specific". I have in
>       mind something like what RADIUS does with attribute 26. This could
>       take the pressure off the Type space.

I think this is too agressive.  There is 31 EAP Request/Response types
registered, we have 220 left.  Extrapolating linearly tells us we will
run out in 30-40 years.  (Assuming registration started in 1997.)

I think a better approach would be to let IANA continue to register
EAP types, and to reserve 255 to mean that the first 16 bit of the
Data field should be interpreted as a EAP type, where the first 255
values of that 16 bit field is reserved, and leave the control of that
type space to IANA as well.

This would allow you to plug in a multiplexing type 255 EAP mechanism
in an old RFC 2284 implementation if needed.  Of course RFC 2284bis
and later implementations would support EAP type 255 internally.

>    e. Statement on allocation of EAP type codes. Should this be on
>       request? By expert review? (e.g. by sending mail to the WG) By
>       designated expert? Assuming that we have a vendor specific code,
>       the criteria might be different, (e.g. a specification and expert
>       review might be required). 

I think the current procedure (send email to IANA) is fine.  Adding
restrictions on how to register a EAP mechanism makes people just pick
an unused one and not tell anyone.  It also requires human resources
to decide whether a registration is OK or not.  Let's not create
politics.

/Simon

----- End forwarded message -----