eap Mailing List: Re: Issue 196: Peer SM Issues

[Nick Petroni (npetroni]

> In Figure 3, it is not clear from the diagrams that SUCCESS and FAILURE
This is stylistic I think. If there is a special notation for final states
in Figure 3, there should be in all of them. I am open to other
discussion, but I think the text descibing them as final is sufficient.
Other votes?

> are terminal states; perhaps a function call is necessary to cause
> the packet to be sent.
There are no packets to send- the Peer does not respond to success or
failure.


> Suggest adding a getIdentity() call in the IDENTITY state,
> which can take into account the information that the peer
> has available, in order to determine the appropriate
> identity to put into the EAP-Response/Identity. This
> could include, for example, "hints" in the EAP-Request/Identity,
> default settings in the peer, etc.
I think this is abstracted away in buildIdentity(). We could add
information about these considerations in the function definition if the
group thinks it is necessary.

The remainder of this issue seems to be about tunnels, so I propose to
reject the issue. We can make the style changes above as other issues or
just as editiorial liberties if the group thinks they are good ideas.