Hi Jari, I do think that general security analysis on running multiple EAP conversations between peer and authenticator is quite beneficial for designers of EAP lower layers. I agree that it makes sense for IETF to have an RFC on usage of IETF technology <X> in environment <Y> as long as environment <Y> is defined by other SDO. However, the draft is also defining part of environment <Y> where Y=3GPP2 and GEE is part of 3GPP2. Even if this "experiment" succeeds, I don't think IETF can recommend this specific GEE format to other lower layers, because there are multiple different ways of transporting EAP messages, depending on the characteristics of each lower layer. How to support multiple EAP conversations between peer and authenticator, including encoding format, is just part of EAP transport design (except general security analysis as I mentioned above). Having said that, I still think that ideally 3GPP2 should take the ownership of the GEE format and its processing rule within their specification unless there is a particular situation that prevents 3GPP2 from doing that. Regards, Yoshihiro Ohba On Wed, Dec 27, 2006 at 03:37:03PM +0200, Jari Arkko wrote: > Yoshihiro, > > If we agree that EAP GEE is part of a 3GPP2 EAP lower layer, wouldn't > > it be more appropriate to standarize EAP GEE within 3GPP2, with > > utilizing this EAP WG review as peer review as we have done for IEEE > > 802.16e and 802.1aa? > > > I fully agree with Bernard that the work needs to be tied > to the specific lower layer and specific use of EAP in that. > If this was a general mechanism for all EAP uses, it > would require a different IETF process, consideration > of a broad set of requirements from different > usage scenarios, etc. As Bernard points out, merely > turning this on in other link layers would break them. > (We need to work on what the details are for > the sufficient tie-in to the link layer is, however. > The current document is already tied to 3GPP2 link > layer, though based on Bernard's review, in an > inadequate manner.) > > However, I believe that submitting specifications > developed outside the IETF as non-standard RFCs > is sometimes useful, as long as the situation > and status is clearly indicated. Typical cases where > such publication can be useful are "Using IETF > technology <X> in environment <Y>" documents > where it is felt that significant IETF review is > warranted (such as in this case), and where > the community might benefit from availability > of an RFC. > > Jari > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf