Subject: [eap] Review of EAP MAKE Type Allocation Request

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Jan 2006 19:23:38 -0800

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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Jan 2006 17:51:10 +0200

Bernard Aboba wrote

> 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,

I agree that this is confusing. We can't have the same know, or we'll
never figure out later what is going on. From a quick review of 
draft-berrendo
and draft-vanderveen, however, it seems that these are different protocols.
If Michaela submitted her draft and request under a different name (say,
EAP Flarion MAKE), would that remove this particular problem?

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 11 Jan 2006 09:38:12 -0800

>EAP Flarion MAKE), would that remove this particular problem?

I'm told that the authors have chose to rename the protocol EAP-SAKE.  That 
does take care of this issue (although the renamed document would still need 
to go through Expert Review).