Vidya, > ... do the responsible thing, which would be to clearly define the > applicability, along with providing an interoperable means of defining > the key hierarchy for those usages that want to/can use it. This is all I'm suggesting we do. I think we should add text to the document that gives guidance on the types of usages for which a USRK would be appropriate. Usages should be for functions related to the access network to which you are connecting, and for functions where it is reasonable for your access network to have an interest in authorization. For example, consider using a USRK to secure HTTP. If your access provider did this to deliver firmware updates to your handset, this might be reasonable, but if amazon.com required it for authentication, this would be unreasonable. Even if amazon.com had an agreement with your provider to obtain a USRK for your session, that's not the kind of thing for which your provider should be the authorization authority. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf