Of course they can bring such a thing to ietf. There is a long history of new work improving on the old (ice improving on stun, v6 improving on v4, ospf improving on rip, and so on).
I look forward to your draft suggesting something better. Jonathan R. -----Original Message----- From: Henry Sinnreich [mailto:[EMAIL PROTECTED] Sent: Saturday, July 21, 2007 01:11 PM Eastern Standard Time To: Jiri Kuthan; David Barrett; Jan Janak; Juha Heinanen Cc: [email protected]; [EMAIL PROTECTED] Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC I fully agree with Jiri that this is an IETF problem and not an ICE problem. ICE-17 is a great document, no doubt about it. What happens however of someone finds an innovative approach that may work better? Will it be rejected because it will not be RFC standards compliant? What could an innovator tell customers about a solution that works better but is not IETF ICE RFC standards compliant? Henry -----Original Message----- From: Jiri Kuthan [mailto:[EMAIL PROTECTED] Sent: Saturday, July 21, 2007 9:48 AM To: David Barrett; 'Jan Janak'; 'Juha Heinanen' Cc: [email protected]; [EMAIL PROTECTED] Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC At 20:05 19/07/2007, David Barrett wrote: >> -----Original Message----- >> From: Jiri Kuthan [mailto:[EMAIL PROTECTED] >> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore >> LC for RFC >> >> So I think that the right course of action is that folks doubting ICE >> reliability >> make their case (by that I mean specific arguments rather than emotional >> debates >> about red-colored nails and other hardware). > >Er, my "specific argument" is "until it's been proven to work, it hasn't >been proven to work". It's tautological, but no less true for it. > >Indeed, if you're *not* doubting ICE, why aren't you? Hi David, I'm not entirely sure what is the step you are suggesting? I think ICE is architecturally right answer to the right problem. Notwithstanding that, there are certainly some things I prefer differently (e.g., the infamous debate about proactive hole punching) or may turn out to be bugs. I think though that the key problem at this point is of institutional nature. In the IETF language, "hasn't been proven to work" is adequate to "lacking running code" and this appears to be a phenomen which is indeed occuring in the IETF and is not unique to ICE. The question is how to get this fixed? Some other standardization bodies enjoying the amount of contributions and complexity as the IETF is enjoying now (S in SIP does not really stand for Simple), proceed with 'after-fact filters', in that they produce the initial specs faster and later produce 'profiles' which separate what has proved and what less. Plus -bis versions are produced for whatever appears worth puttting effort in it (i.e., for which there is running code and field evidence of improvement need).This could be an approach which may be more feasible in today's IETF's dimension than trying to get back to historical roots. -jiri _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
