Lakshminath, > Why would we force the hotel to provide multiple sets of credentials > for each additional service/application that they want to provide? Credentials can still be the same. We're not really arguing against that. It would indeed be silly if you had to have more credentials. In some deployments the cost of this would be astronomical. But I note that the same credentials can often be used. E.g., 802.1X and IKEv2 can use the same credentials. HTTP digest can use credentials from cellular networks via RFC 4169. And so on. > Perhaps your argument is to use IKEv2-EAP in that case. Sure, we can > use that. But, why not use the optimization when it is available? > Why force IKEv2 again? Please see below for additional notes. The argument is that the optimization provides minor benefits (we're talking about few roundtrips or even less) and even this can in many cases be amortized across the whole life of an a connection to a server. This, taken together with the costs involved in the optimization (tying yourself to a particular network, limiting deployment, additional protocol work etc) IMHO makes it very clear that we should avoid using EAP keys for applications other than those relating to network access. In any case, I don't think the HOKEY WG is doing applications, they are working on network access improvements. Why are we even discussing this topic? I don't see any (active) proposal on the my table that would suggest doing something like this. Tighten up the language in the hokey spec to not allow application keying, and we're done. Jari _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf