Subject: [eap] Issue 112: Rewrite of IANA Considerations

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 14:43:54 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 6.2
Rationale/Explanation of issue:

It is desirable to require a published RFC for EAP methods,
if possible. Rewrite Section 6.2 to the following:

"For registration requests where a Designated Expert should be consulted,
the responsible IESG area director should appoint the Designated Expert.
The intention is that any allocation will be accompanied by a published
RFC. But in order to allow for the allocation of values prior to the
RFC being approved for publication, the Designated Expert can approve
allocations once it seems clear that an RFC will be published. The
Designated expert will post a request to the EAP WG mailing list (or a
successor designated by the Area Director) for comment and review,
including an Internet-Draft. Before a period of 30 days has passed, the
Designated Expert will either approve or deny the registration request
and publish a notice of the decision to the EAP WG mailing list or its
successor, as well as informing IANA. A denial notice must be justified
by an explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable.

Packet Codes have a range from 1 to 255, of which 1-4 have been
allocated. Because a new Packet Code has considerable impact on
interoperability, a new Packet Code requires Standards Action, and
should be allocated starting at 5.

The original EAP Method Type space has a range from 1 to 255, and is
the scarcest resource in EAP, and thus must be allocated with care.
Method Types 1-41 have been allocated, with 20 available for re-use.
Method Types 42-191 may be allocated on the advice of a Designated
Expert, with Specification Required.

Allocation of blocks of Method Types (more than one for a given
purpose) should require IETF Consensus. EAP Type Values 192-253 are
reserved and allocation requires Standards Action.

Method Type 254 is allocated for the Expanded Type. Where the
Vendor-Id field is non-zero, the Expanded Type is used for functions
specific only to one vendor's implementation of EAP, where no
interoperability is deemed useful. When used with a Vendor-Id of
zero, Method Type 254 can also be used to provide for an expanded
IETF Method Type space. Method Type values 256-4294967295 may be
allocated after Type values 1-191 have been allocated.

Method Type 255 is allocated for Experimental use, such as testing of
new EAP methods before a permanent Type code is allocated."