Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC

From: "Jonathan Rosenberg \(jdrosen\)" <[email-masked]>
Date: Sat, 21 Jul 2007 16:43:24 -0400

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-masked]]
Sent:	Saturday, July 21, 2007 01:11 PM Eastern Standard Time
To:	Jiri Kuthan; David Barrett; Jan Janak; Juha Heinanen
Cc:	[email-masked]; [email-masked]
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-masked]] 
Sent: Saturday, July 21, 2007 9:48 AM
To: David Barrett; 'Jan Janak'; 'Juha Heinanen'
Cc: [email-masked]; [email-masked]
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-masked]]
>> 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-masked] for questions on current sip
Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip