Comments on emu-eap-tunnel-method-02

1.  After the first exchange of messages, if the version does not match the
agreed on version - what happens?

2.  Section 3.2 says that one should be able to do a renegotiate for getting
the peers identity certificate.  Do the following points need to be made?
a) If you are doing a re-negotiation - then you SHOULD not be using an
anonymous cipher suite
b) Once you have started phase 2, re-negotiation MUST NOT be done.

3. in section 3.3.1 - did you miss changing and EAP-TLS to a TEAP? "For
example, EAP-TLS..."  If not, then I would suggest changing to a std track
protocol.

4.  In section 3.4 - I want to make sure that what I read is what you
intend.
 == If I do multiple (one or more) inner EAP methods, the authenticated peer
identity is the set of all of these identities.
 == If I do zero inner EAP methods and I do a client auth TLS, the
authenticated peer identity comes from the certificate.
 == If I do zero inner EAP methods and do not do a client auth TLS, then I
have no authenticated peer identity.

 -- specifically - should the client auth TLS identity be excluded if I run
an inner EAP method
 -- Specifically - should the all non EAP methods be excluded -- include the
TEAP defined user name/password
 -- Specifically - should any EAP server name established in an EAP method
be excluded from its name set?

5.  In section 3.8 - potentially ambiguous statement:  "The request MAY be