Chris Hessing wrote: > Then I must ask a stupid question. Who is the group that decides what > should and shouldn't be allowed?
The chairs determine the focus of the group, guided by the WG charter. > While I understand that the changes > EAP-FAST makes to existing EAP methods are already published and have > many implementations, it seems that allowing future EAP methods to make > random changes is something that will ultimately lead to > interoperability problems. It is just a bad precedent to allow to > continue. I would be happy to raise this issue on a different list if > there is one more appropriate. But where this is an EAP related issue > this seemed to be the right list. While this is the currently the only EAP WG in the IETF (IIRC), it has a charter that specifies WG work items. Re-visiting EAP-FAST is not a work item. That being said, a discussion of EAP related issues *is* welcome on this list, so long as it does not distract from work items. In relation to EAP-FAST, the RFC was not a WG work item (from any WG). It did not follow the normal WG review process, and may have issues caught by additional reviewers. >... For EAP-FAST provisioning anonymous provisioning is clearly > spelled out as a possible mode of operation. i.e. A "possible" mode of operation. Provisioning is not part of the scope of this WG (see the charter). If EAP-FAST is chosen as the tunneled method, it would be appropriate to forbid anonymous provisioning in the EMU document describing the tunneled method. > Further it bothers me more when > I see a NIST document that indicates that EAP-FAST is the best choice > for a secure, but easy to deploy, EAP method. Do the NIST documents permit anonymous provisioning? > However, again, if I am trying to get this discussion going in the wrong > forum, please point me to a better one. Discussions as to how EAP-FAST meets (or does not) the tunneled method requirements are needed on this list. However, discussions of the tunneled method requirements document are a higher priority right now, because that document is unfinished. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
