eap Mailing List: Review of EAP MAKE Type Allocation Request

[Bernard Aboba (bernard_aboba]

I have reviewed the EAP MAKE Type Code Allocation request.  My 
recommendation is that the request be DENIED.

A specification for EAP MAKE was first posted to the IETF archive on
September 17, 2001 by Romain Berrendonner and Herve Chabanne of SAGEM SA. 
This specification describes two exchanges, one known as MAKE1 and another 
one, described as MAKE2:
http://www.watersprings.org/pub/id/draft-berrendo-chabanne-pppext-eapmake-00.txt

The EAP MAKE Specification was subsequently revised:
http://www.watersprings.org/pub/id/draft-berrendo-chabanne-pppext-eapmake-01.txt

Subsequently, IANA allocated EAP Type Code 27 for EAP MAKE on the request of 
Mr. Romain Berrendonner:
http://www.iana.org/assignments/eap-numbers

Given that a Type Code has already been allocated to EAP MAKE, a request for 
an additional Type Code allocation for the same protocol would represent a 
"block allocation" as described in RFC 3748,
Section 6.2:

   Allocation of blocks of method Types (more than one for a given
   purpose) should require IETF Consensus.

Given that EAP MAKE has not gone through an IETF consensus determination, 
this requirement has not been met, and the recommendation is that the 
request be DENIED.

Note:  Requesting allocation of IANA parameters for a protocol with the same 
name as one with a completed or outstanding IANA request is inherently 
problematic.  Such a request, if granted, is likely to cause confusion among 
implementers and users, and so such requests are to be discouraged.  
Possible points of confusion include:

a. Confusion about which protocol parameters are to be used for 
implementation with which protocol version.  The IANA allocation web page 
for EAP Type Codes does not reference the protocol specification, only the 
protocol name, the Type Code and the name of the requester.

b. Confusion with respect to application of IANA allocation policies.  If 
the protcols in question are on different tracks (Informational vs. 
Experimental or Standards Track) it is possible that a request may receive 
an allocation originally intended for another protocol using the same name, 
but attaining a different status.  This would enable a non-standards track 
protocol to steal the name and protocol allocation of a standards track 
protocol.

c. Confusion with respect to implementations.  In addition to referring to 
RFCs, users often refer to protocols by name.  Allowing two protocols to 
utilize the same name creates the potential for confusion about which 
protocol is being implemented, potentially resulting in confusion between 
vendors and customers, as well as interoperability problems in the field.