> -----Original Message----- > From: Henry Sinnreich [mailto:[EMAIL PROTECTED] > Sent: Monday, July 16, 2007 3:38 PM > To: [EMAIL PROTECTED]; [email protected] > Cc: Cullen Jennings; [EMAIL PROTECTED] > Subject: [MMUSIC] ICE deployment data before LC for RFC > > The work on ICE is truly impressive and so are the numerous > I-Ds associated with ICE. > > > > However, before sending the <ice-17> I-D for LC to the IESG, > it would be prudent and responsible to the industry (that > spends considerable resources on ICE in good faith) > implementing ICE, to either (1) make it an informational RFC > or
To my knowledge, IETF only requires such deployment details and analysis when promoting a Proposed Standard to Draft Standard, and promoting Draft Standard to Internet Standard. Many Internet Drafts don't have deployment results, because they aren't yet deployed nor deployable until they achieve RFC status. As was well witnessed by the many substantive changes to ICE during its development, it is unreasonable to create interoperable implementations with an Internet Draft while that Internet Draft is undergoing substantial and substantive revision. I don't see the value to the community to deny ICE as a standards-track document. Making ICE an Informational document, as you suggest, will only further delay interoperation and deployment of ICE. If ICE had a competing, incrementally- deployable NAT traversal technique, I could see a desire to make one of those techniques a standards track document and the other an informational document; however, there is no such competing, incrementally-deployable NAT traversal technique. ICE should be a standards-track document. > (2) publish some deployment data showing such items as: > > > > * NAT scenarios that have been tested, > * The % of success, > * Performance, such as call setup delay using SIP. > > > > I have not seen any such public data on ICE deployment, for > example with SIP. A private report has raised my concern > about the performance of ICE. I do agree that publishing information, such as what you requested in (2), would be very useful. But publishing such information is not necessary for ICE to be published as a standard-track RFC. > In the best IETF tradition, it would also help to have open > source code available for ICE, before declaring it a standard. I see that already there have been two followups to your request for publicly-available code, pointing at three implementations (NICE, PJSIP, and oRTP/mediastreamer2). > ICE is too important for the IETF (good work Jonathan and > other authors!) not to publish (1) deployment results and (2) > publish open source code as well. > > The various nits discussed on the lists are only of secondary > importance to the LC compared to the above and would get > resolved with such a process anyway. -d > > > > These are my personal two cents. > > Henry Sinnreich > > > > > > > _______________________________________________ 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
