Hi Bernard, Comments inline below:
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Bernard Aboba > Sent: Thursday, February 21, 2008 11:54 AM > To: [email protected] > Subject: Re: [Emu] EMU Charter revision > > I also do NOT approve of the current charter revision, for > several reasons: > > a. The Charter text contains statements that are no longer > true. For example: > > "Most of these methods are proprietary methods and only a few > methods are documented in RFCs." > > The following EAP methods are now documented in RFCs: > > EAP-TLS (RFC 2716) > EAP-SIM (RFC 4186) > EAP-AKA (RFC 4187) > EAP-PAX (RFC 4746) > EAP-SAKE (RFC 4763) > EAP-PSK (RFC 4764) > EAP-POTP (RFC 4793) > EAP-FAST (RFC 4851) > EAP-IKEv2 (RFC 5106) > > 9 methods claiming to satify RFC 4017 critieria is more than a "few". > [Joe] In addition there is at least one more, EAP-TTLS that is in the process. We can revise the section of the charter. Do you have any suggested text? > b. The Charter requires support for Channel Bindings without > doing the preparatory work to define how Channel Bindings > works. Either the requirement should be removed, or a work > item should be added to better define the approach to Channel > Bindings. > [Joe] There is time set on the agenda in Philadelphia to discuss channel bindings. > c. The text on tunnel methods does not provide enough > guidance to avoid potentially fruitless arguments. So far, > the EMU WG has not been able to come to consensus on > selection of one of the existing tunneling protocols, and > efforts to design "yet another" tunneling protocol haven't > gotten very far either. I'd like to see more specific > language that would make it clear that work on improving > existing tunneling protocols is within scope, and also that > the EMU WG, if it cannot come to consensus on a single > protocol, can proceed to work on one or more protocols with > significant support. > [Joe] OK, do you have some recommended text in this area. I'm not sure how one would write this into the charter. I think this will need some discussion. > d. Password-based methods. While I can understand the desire > to limit the number of charter items, I do agree with Dan > that work on weak-password methods is important. With some > of the IPR obstacles likely to fall by the wayside in coming > years, it is time for the IETF to re-visit its policy on > inclusion of "zero knowledge" algorithms within standards > track documents. [Joe] This will be a topic for discussion as well. We can see what the level of interest is. > Dan Harkins said: > > " Hi Joe, > > > I do NOT approve of the current charter revision, > specifically the change that says the password-based method > can only be via the tunneled method. I do approve of the > inclusion of tunneled methods in the charter though and would > be willing to contribute as a reviewer. > > regards, > > Dan." > On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote: > > The response to the charter revision has been > underwhelming. I am a > > bit concerned that we do not have enough participation to > complete the > > tunnel method work (most of the recent discussion has been > about other > > methods). > > > > I would like to get an idea of the number working group > members that > > approve of working on the tunnel method items and are able to > > participate in the development of requirements and > specifications as > > contributors and/or reviewers. > > > > Please respond to this message and state whether you approve of the > > current charter revision and what capacity you would be willing to > > contribute towards tunneled method development: > contributor, reviewer > > or not able to contribute. > > > > I have submitted an internet draft attempt at an outline of > > requirements for tunneled methods > > > (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunn > el-req-00. > > txt) that I hope can provided a starting point for > discussions on the > > list and in the Philadelphia meeting. > > > > Thanks, > > > > Joe > > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
