Thank you. Comment following your clarification. Joel Lakshminath Dondeti wrote: ... >> The one thing that bothers me a little is the intended status of >> this document. Given that the EMSK is entirely inside a system, and >> that therefore the actual generation process is internal to that >> system, I am not sure that a registry tied to the specifics of the >> generation mechanism, is appropriate. A lot of this document is of >> the form "if you don't define it some other way, do this." While very >> useful text, it actually doesn't seem to affect on-the-wire >> interoperability. So I wonder if this whole document is more >> informational than "proposed standard?" I'm not sure on this, but the >> containment property did strike me reading the document. > > The peer and the server need to arrive at the same derivations. The > keynames derived as specified in this document would be used in > protocols specified elsewhere to refer to the keys derived independently > at both ends. So, whereas there are no "on the wire" packet formats in > this document, other documents will put information derived as specified > in this document in their packets. That does make for a good reason for PS. I am however then confused by the description that the EMSK never leaves the server. I presume that this relates to other aspects of EAP that I am not familiar with. You may want to see if there is a way to phrase it that makes it a bit clearer. But given what you say, this is another minor issue, not a big deal. _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf