Hi Joel, Thank you for spending your time reading the framework document and sending your feedback. Please see my response below. On Fri, May 26, 2006 at 08:27:29AM -0400, Joel M. Halpern wrote: > In reading the PANA Framework document, what I read seemed to me to > be more of a "system" or "solution" document than a clean IETF > protocol framework. I think your reading is correct. The document describes how different types of access network deployments are enabled by PANA. > > I saw efforts to address three different problems: > 1) Securing an otherwise unsecured link, when the access node is not > known to the client in advance. > 2) Selecting an authorization (charging, possibly packet handling) service Just to make sure, do you mean by 2) network selection that is described in Section 8 of pana-framework draft? > 3) Authenticating the user > > EAP over IP (or UDP, or link) is about authenticating the user. If a > media independent technique better than just using a browser is > needed, then solve that problem. This is surely one problem PANA is trying to solve, and has been clarified from the beginning of the work and more in this dicussion, I believe. > Personally, I would find the work > far more persuasive if it did not also try to solve the problem of > creating an IPSec association to the access device, nor of the > authorization selection problem. Bootstrapping lower-layer ciphering (IPsec and link-layer ciphering) from EAP-based network access authentication is another problem. When a lower-layer does not provide EAP service, it is clear that PANA is a standard way to solve the problem. Perhaps the main confusion is coming from the fact, as a side effect of solving this bootstrapping problem, that it is possible to use PANA to bootstrap lower-layer ciphering *even if the lower-layer supports EAP*. While I understand the confusion but let me explain several reasons for why I think this is still viable for lower-layers that support EAP. - Use of PANA for bootstrapping IKEv2. I explained several reasons for why doing this while IKEv2 can carry EAP, in my response to Vidya: http://www1.ietf.org/mail-archive/web/ietf/current/msg42002.html. - Use of PANA for bootstrapping IEEE 802.11i PSK mode. This makes APs and non-AP STAs that support 802.11i but do not support 802.11r can transit from one AP to another without necessarily perform EAP for every AP transition as long as the APs are acting as EPs of the same PAA. One may argue that this usage becomes useless when all APs and non-AP STAs are migrated to 802.11r, but it is still possible to use PANA for inter-ESS transition which is not covered by 802.11r. > > And spell out in clear English what use case needs that problem > solved. I can read between the lines and start to guess. But the > document is quite unclear. The appendix about DSL is not helpful in > that regard. One of the reasons for this may be that the problem statement and requirements are described in a separate RFC (i.e., RFC 4058) not in the pana-framework draft. Of course another reason may be that I, the editor of the draft, am not a native English speaker. BTW, there is no appendix in pana-dramework draft. So you may refer to Section 10.1 about DSL. Is this correct? I hope this sheds some light on the discussion. Yoshihiro Ohba > > Yours, > Joel M. Halpern > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf