Hi Yoshi,
Thanks for your followup comments. I understand that your opinion is
that each lower layer should do it on its own and perhaps some lower
layers will follow that track. In the 3GPP2 case, it was deemed a
good idea to do it in a "generic" sense for some degree of
genericness. As Jari also notes that is being documented by
draft-barany-eap-gee-04 as a 3GPP2 experiment.
On your comment about whether or not a 1 octet field is necessary, my
opinion is that it is the most optimal design (cannot be any smaller
:)). I don't think ethertype will work in a generic sense to
distinguish multiple parallel EAP conversations (we are not talking
about multiple "types" of conversations, but instead multiple conversations).
thanks,
Lakshminath
At 06:37 AM 12/28/2006, Yoshihiro Ohba wrote:
Hi Lakshminath,
On Wed, Dec 27, 2006 at 11:43:34PM -0800, Lakshminath Dondeti wrote:
> Hi Bernard, Yoshi,
>
> Many thanks for your reviews and notes. I am going to try and
> address the overarching issues. Once we settle on those, we can take
> care of the details.
>
> * On the use of the term "generic":
> At the beginning of the GEE standardization effort, the idea was to
> specify the protocol and allow use of it by any EAP lower layer,
> irrespective of which standards body develops the lower layer. Upon
> Jari's suggestion, we introduces the term 3GPP2 so as it stands now,
> GEE is only applicable to EAP lower layers defined by 3GPP2. Please
> note that *multiple* lower layers specified by 3GPP2 may use
> it. Furthermore, the intended status is "experimental." The idea is
> to try it out and if all goes well, allow the protocol to be used by
> any lower layer. Finally, the mechanism over the period of 1 year or
> so has been known as GEE, so we would like to continue to use that term.
The functionality to run multiple EAP conversations between peer and
authenticator is part of EAP lower layer design that is specific to
each lower layer. Hence, I am concerned if the intent is to allow GEE
to be used not only for 3GPP2 but also for other SDOs. In fact, the 1
octet GEE field is not even needed if different frame types (e.g.,
Ether Types) or equivalent are used for identifying multiple EAP
conversations between peer and authenticator, where usually one frame
type or equivalent is allocated for EAP.
>
> * On correctly parsing the GEE header:
> Indeed EAP lower layers (would have to) specify how a peer and an
> authenticator can negotiate whether to use EAP or GEE (and versions
> within GEE etc); after that though, there would not be any incorrect
> parsing of a GEE header as an EAP header.
>
> Perhaps it is best to specify that this is expected of the EAP lower
> layer in the GEE I-D. Would that resolve this concern?
>
> * On specifying GEE at the IETF:
> Surely, GEE could have been specified as part of the EAP lower layer,
> but that would mean each lower layer would have to specify it
> independently and as with most things, those sort of exercises tend
> to end up with results slightly (or vastly, take your pick) different
> from each other.
But there is nothing wrong that each EAP lower layer is designed in
different ways including support for multiple EAP conversations
between peer and authenticator.
Yoshihiro Ohba
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf