Let me forward my response with reducing quotes since it got bounced. ----- Forwarded message from Yoshihiro Ohba <[EMAIL PROTECTED]> -----
From: Yoshihiro Ohba <[EMAIL PROTECTED]> Subject: Re: IETF last call on draft-barany-eap-gee-04.txt To: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> Cc: Yoshihiro Ohba <[EMAIL PROTECTED]>, "Narayanan, Vidya" <[EMAIL PROTECTED]>, "Barany, Pete" <[EMAIL PROTECTED]>, Bernard Aboba <[EMAIL PROTECTED]>, Jari Arkko <[EMAIL PROTECTED]>, ietf@ietf.org User-Agent: Mutt/1.5.13 (2006-08-11) X-UIDL: `*T"!3ga"!Eh'#!<h>"! Hi Joe, Your comment would be valid if GEE were defined just as a function not as a protocol. As long as GEE is defined as a protocol, I do not agree with the statement that GEE is not an EAP lower layer, because in RFC 3748, EAP lower layer sits immediately below EAP layer and there is no shim layer. That is why the only way for GEE to comply with RFC 3748 is to view GEE as part of EAP lower layer. Yoshihiro Ohba On Thu, Jan 04, 2007 at 04:17:58PM -0800, Joseph Salowey (jsalowey) wrote: > > <snip> > > > * EAP lower layer and GEE - Bernard's review pointed out > > that the EAP > > > lower layer transport requirements are not discussed in the > > GEE draft. > > > GEE is not an EAP lower layer. GEE is a protocol that the EAP lower > > > layer can use to allow multiple parallel authentications. > > > > As I already commented, GEE is part of EAP lower layer in > > term of RFC 3748. This fact does not change even if the > > lower layer of GEE negotiates the use of GEE between the peer > > and authenticator. > > > [Joe] GEE is not an EAP lower layer, it is intended to be transparent to > the EAP method layer. GEE does not provide lower layer functionality by > itself, rather it relies upon the processing of a lower layer that meets > the RFC 3748 requirements. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf