Gene, I don't think anyone would find an EMU reality show entertaining. The only comic relief would be one crazy guy who, once every 4 months, pokes his head in the window and says "I do not approve" to people sitting around watching paint dry.
You are restating Stephen's comment from Philly that I'm more interested in the cage match than in the coronation of the winner. That is not true but it is also irrelevant. I actually don't care who wins or how much blood is let, I just want it to be over. It would really be an abuse of process to hold up all other work while each side crunches numbers and pays analysts to run surveys so that someone can claim to have reached an arbitrary 10M mark. And it would not be a service to anybody. So what we have is argument over the wording of "requirements" so that they will subtly favor one side over the other. Then we create a "requirements" document that captures all the carefully constructed verbage. And while that's getting advanced we then argue over which candidate best matches the customized wording of the "requirements". And then we finally get down to the work of actually changing one of the specifications to add channel binding. And this must all be done serially. Sigh. Both FAST and TTLS are equally amenable to modification and their differences are not so great or we'd have had a clear "winner" already. No matter which one gets selected we will not end up with a weak solution. You don't see my sense of urgency because what you view as interesting work is not being held up. Dan. On Mon, April 28, 2008 11:26 am, Gene Chang (genchang) wrote: > Dan, > > I think we can all appreciate the entertainment value of bringing a > reality show to the IETF. Imagine replacing the IETF social with an > arena full of hyped up Internet engineers enjoying a night fellowship > with beer and trash talk. > > Unfortunately, all we are doing is dressing up a down select with two > 4-5 year old protocols that do not completely meet the requirements > document that is being assembled. We aren't doing the industry a favor > freezing the protocol choice to technology ca. 2004. > > If you are in such a rush, why not simply declare victory and have a > tie. That enshrines the status quo. Picking one over the other won't > change the status quo and thus won't change the deployment preference > already established. > > Better for the industry would be a foot race where the candidate > protocol that meets the requirements document and gains 10 million > devices protected would win the standards title. This would advance the > technology to cover the missing requirements and significantly grow > adoption. > > Let's focus our efforts on moving the technology forward instead > searching for an entertaining down select. > > I really don't see your sense of urgency. I don't see an adoption window > that we are going to miss with the current effort. Yet, I can be really > excited pushing to meet the needs of a critical adoption window. > > I would like to see things progress faster but not at the expense of a > weak technical outcome. > > Gene > > ------------------------------------------------------------------------ > ---- > Eugene Chang (genchang) > Cisco Systems > Office: 603-559-2978 > Mobile: 781-799-0233 > Skype: gene02421 > > > >> -----Original Message----- >> From: Dan Harkins [mailto:[EMAIL PROTECTED] >> Sent: Monday, April 28, 2008 12:05 PM >> To: Gene Chang (genchang) >> Cc: Dan Harkins; Stephen Hanna; emu@ietf.org >> Subject: RE: [Emu] EMU charter revision >> >> >> Hi Gene, >> >> I'm not pushing a tunneled method. We have enough of those and their >> differences are not so great. >> >> Yes, I was using "snail race" as a pejorative. As I said at the last >> IETF we should have a cage-match-cum-beauty-contest between TTLS and >> FAST, turn the last RFC text of the winner into a -00 EMU draft, add > the >> channel bindings stuff that was discussed back in Vancouver and then >> publish. Apparently this working group can work on nothing except >> a tunneled method. And that work is being done at a snail's pace. >> >> I'm glad to hear that you're open to a discussion of adding a non- >> tunneled method "if there is sufficient demand", but you see we have > this >> long-standing consensus and the mere mention of anything that remotely >> sounds like a non-tunneled method gets stifled with "consensus!" So >> apparently we're not allowed to have that discussion. At least until > we >> finish work on a tunneled method. >> >> Dan. >> >> On Mon, April 28, 2008 3:35 am, Gene Chang (genchang) wrote: >> > Dan, >> > I am not sure I am able to clearly understand the end result you > seek. >> > It seems there is a clear consensus for a tunneled method. Are you >> > pushing for the addition of a tunneled method? >> > >> > Ok... I am easily baited. What would you like to see to achieve more >> > than a snail race? I am assuming we both believe the term "snail > race" >> > is a pejorative. Thus I ask you, how do we do better? >> > >> > I clearly hear your comment that there have been a paucity of > comments, >> > if nothing else, simply to affirm we are on track. I agree with the >> > proposed charter. I am open to a discussion to add a non-tunneled > method >> > if there is sufficient demand. A non-tunneled method does not seem > to >> > promise enough features for the use cases that interest me. >> > >> > Gene >> > >> > > ------------------------------------------------------------------------ >> > ---- >> > Eugene Chang (genchang) >> > Cisco Systems >> > Office: 603-559-2978 >> > Mobile: 781-799-0233 >> > Skype: gene02421 >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of >> > Dan >> >> Harkins >> >> Sent: Monday, April 28, 2008 2:12 AM >> >> To: Stephen Hanna >> >> Cc: emu@ietf.org >> >> Subject: Re: [Emu] EMU charter revision >> >> >> >> >> >> That's true. One person's opinion does not negate consensus, >> >> even if that one person is the only one who is able to opine >> >> in the alloted time given for opinions (twice now). But so what? >> >> If someone asks then I'll give an honest opinion, especially >> >> since no one else seems to be able to. >> >> >> >> But maybe you're right. Any additional work taken on by this >> >> group would distract from the fantastic progress we've made in the >> >> past 9 months on the tunneled method. It would be a shame to lose >> >> all that. Yes, let's just focus on the snail race.... >> >> >> >> Dan. >> >> >> >> On Sun, April 27, 2008 6:10 pm, Stephen Hanna wrote: >> >> > I apologize for my tardy response. I have been on vacation. >> >> > >> >> > I agree with and support the proposed charter below. As for >> >> > Dan's suggestion that we not require the password based >> >> > method to be based on the tunnel method, the WG already >> >> > went through a long discussion and consensus check last >> >> > fall on this matter. There was clear consensus that we >> >> > should NOT work on a new password based method designed >> >> > to function without the tunnel method. One person's >> >> > opinion to the contrary does not negate that consensus. >> >> > I think that the reason we are not seeing much email on >> >> > this charter is that the issues and language have been >> >> > hashed through many times. >> >> > >> >> > Thanks, >> >> > >> >> > Steve >> >> > >> >> > -----Original Message----- >> >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf >> > Of >> >> > Dan Harkins >> >> > Sent: Friday, April 25, 2008 5:43 PM >> >> > To: Joseph Salowey (jsalowey) >> >> > Cc: emu@ietf.org >> >> > Subject: Re: [Emu] EMU charter revision >> >> > >> >> > >> >> > Hi Joe, >> >> > >> >> > Once again, a call for comments and I'm the only one to > comment. >> >> > >> >> > Whether removing that line achieves "my goals" or not I still >> > think >> >> > it should be removed. And that really seems to be the only > comment >> >> > on the charter you get when you ask. >> >> > >> >> > regards, >> >> > >> >> > Dan. >> >> > >> >> > On Fri, April 11, 2008 2:49 pm, Joseph Salowey (jsalowey) wrote: >> >> >> >> >> >> >> >> >>> -----Original Message----- >> >> >>> From: Dan Harkins [mailto:[EMAIL PROTECTED] >> >> >>> Sent: Friday, April 11, 2008 10:38 AM >> >> >>> To: Joseph Salowey (jsalowey) >> >> >>> Cc: emu@ietf.org >> >> >>> Subject: Re: [Emu] EMU charter revision >> >> >>> >> >> >>> >> >> >>> Hi Joe, >> >> >>> >> >> >>> Thank you for giving me the opportunity to object, once >> >> >>> again, to the last sentence in the last item in the charter. >> >> >>> If you were to run the following sed filter on the charter I >> >> >>> would approve: >> >> >>> >> >> >>> s/This item will be based on the above tunnel method.// >> >> >>> >> >> >> >> >> >> [Joe] I do not think that removing this line would achieve the > goal >> >> > you >> >> >> wish. With this line removed EAP-PWD is still out of scope of > the >> >> >> charter as it does not meet the requirements of supporting > legacy >> >> >> password databases. The message from the ADs in the last > meeting >> > was >> >> >> pretty clear in that EAP-PWD style mechanisms is not something > for >> > the >> >> >> group to take on right now. This does not mean that we cannot > take >> > on >> >> >> an EAP-PWD style mechanism once we have made progress on the >> > current >> >> >> charter items. >> >> >> >> >> >>> What is the process here? This looks the same as the >> >> >>> charter revision you made a consensus call on back in >> >> >>> January. I was the only one to opine before your cutoff last >> >> >>> time and my comment was the same as above. Now we're doing this >> >> > again. >> >> >>> >> >> >> [Joe] There have been several revisions posted to the list and >> >> > feedback >> >> >> from several working group members that have been worked into > the >> > new >> >> >> proposal along with input from the discussion in the last > meeting. >> > If >> >> >> enough people respond positively, such that we have rough >> > consensus, >> >> >> then we can move forward. >> >> >> >> >> >> >> >> >>> Dan. >> >> >>> >> >> >>> On Thu, April 10, 2008 7:26 pm, Joseph Salowey (jsalowey) > wrote: >> >> >>> > Below is a revision to the EMU charter that is intended to >> >> >>> reflect the >> >> >>> > discussions in the Philadelphia meeting. Please respond to >> >> >>> the list >> >> >>> > if you approve of the charter or if you have any comments >> >> >>> on the charter. >> >> >>> > I would like to have responses by 4/24. >> >> >>> > >> >> >>> > Thanks, >> >> >>> >f >> >> >>> > Joe >> >> >>> > >> >> >>> > Description of Working Group: >> >> >>> > The Extensible Authentication Protocol (EAP) [RFC 3748] is >> >> >>> a network >> >> >>> > access authentication framework used in the PPP, 802.11, >> >> >>> 802.16, VPN, >> >> >>> > PANA, and in some functions in 3G networks. EAP itself is a >> > simple >> >> >>> > protocol and actual authentication happens in EAP methods. >> >> >>> > >> >> >>> > Over 40 different EAP methods exist. Most of these methods > are >> >> >>> > proprietary methods, but some are documented in >> >> >>> informational RFCs. In >> >> >>> > the past the lack of documented, open specifications has been > a >> >> >>> > deployment and interoperability problem. There are >> >> >>> currently only two >> >> >>> > EAP methods in the standards track that implement features >> >> >>> such as key >> >> >>> > derivation that are required for many modern applications. >> >> >>> > Authentication types and credentials continue to evolve as do >> >> >>> > requirements for EAP methods. >> >> >>> > >> >> >>> > This group is chartered to work on the following types of >> >> >>> mechanisms >> >> >>> > to meet RFC 3748, RFC 4017, RFC 4962 and EAP Keying >> > requirements: >> >> >>> > >> >> >>> > - An update to RFC 2716 to bring EAP-TLS into standards >> >> >>> track, clarify >> >> >>> > specification, interoperability, and implementation issues >> > gathered >> >> >>> > over the years, and update the document to meet the > requirements >> > of >> >> >>> > RFC 3748, RFC 4017, and EAP keying framework documents. >> > Backwards >> >> >>> > compatibility with RFC 2716 is a requirement. >> >> >>> > >> >> >>> > - A mechanism based on strong shared secrets. This mechanism >> > should >> >> >>> > strive to be simple and compact for implementation in > resource >> >> >>> > constrained environments. >> >> >>> > >> >> >>> > - A document that defines EAP channel bindings and provides >> >> >>> guidance >> >> >>> > for establishing EAP channel bindings within EAP methods. >> >> >>> > >> >> >>> > - A mechanism to support extensible communication within a > TLS >> >> >>> > protected tunnel. This mechanism must support channel > bindings >> > in >> >> >>> > order to meet RFC 4962 requirements. This mechanism will > support >> >> >>> > meeting the requirements of an enhanced TLS mechanism, a >> > password >> >> >>> > based authentication mechanism, and additional inner >> > authentication >> >> >>> > mechanisms. >> >> >>> > >> >> >>> > - Enable a TLS-based EAP method to support channel >> >> >>> bindings. This item >> >> >>> > will not generate a new method, rather it will extend >> >> >>> EAP-TLS and/or >> >> >>> > the above tunnel method. >> >> >>> > >> >> >>> > - A mechanism that makes use of existing password databases > such >> > as >> >> >>> > AAA databases. This item will be based on the above tunnel >> > method. >> >> >>> > >> >> >>> > Goals and Milestones: >> >> >>> > Done Form design team to work on strong shared secret >> >> >>> > mechanism >> >> >>> > Done Submit 2716bis I-D >> >> >>> > Done Submit first draft of shared secret >> >> >>> mechanism I-D >> >> >>> > Done Form password based mechanism design team >> >> >>> > Done Submit 2716bis draft to IESG for >> >> >>> Proposed Standard >> >> >>> > Apr 2008 Submit Strong Shared Secret Mechanism to IESG >> >> >>> > May 2008 Submit Tunnel and Password Method requirements >> > first >> >> >>> > Draft >> >> >>> > Sep 2008 Submit EAP Channel Bindings First Draft >> >> >>> > Sep 2008 Submit Tunnel Method first draft >> >> >>> > Oct 2008 Submit TLS based method channel binding first >> > draft >> >> >>> > Oct 2008 Submit Password Method first draft >> >> >>> > Jan 2009 Send EAP Channel Bindings to IESG >> >> >>> > Mar 2009 Send Tunnel Method to IESG >> >> >>> > Apr 2009 Send TLS based method channel binding to IESG >> >> >>> > Apr 2009 Send Password based method to IESG >> >> >>> > _______________________________________________ >> >> >>> > Emu mailing list >> >> >>> > Emu@ietf.org >> >> >>> > https://www.ietf.org/mailman/listinfo/emu >> >> >>> > >> >> >>> >> >> >>> >> >> >>> >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Emu mailing list >> >> > Emu@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/emu >> >> > >> >> >> >> >> >> _______________________________________________ >> >> Emu mailing list >> >> Emu@ietf.org >> >> https://www.ietf.org/mailman/listinfo/emu >> > >> > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
