On Jul 18, 2007, at 3:10 AM, Magnus Westerlund wrote:
Henry Sinnreich skrev:
Following some discussions and soul searching, the best approach for
ICE-17 for LC would be to _go ahead and make it an experimental RFC_.
This would support the development of interoperable
implementations, the
collection of deployment data and also hopefully open source code.
Though I have full faith in ICE, following the practices that made
the
IETF successful take precedent here, I believe.
This is a change from the attached that I wrote on 7/16/2007.
Note: We can only hope the proliferation of SBC in VoIP service
provider
networks will not make these concerns and ICE for SIP a moot
issue, but
this is another topic.
Henry,
I don't quite understand why you are requesting a status change of
ICE? To me it appears that ICE is almost finished spec. It has been
implemented, used and feedback has been influencing the protocol.
It is definitly one of the better examples of current IETF work
that actually has running code. Sure, the implementations may not
be fully updated yet to the latest draft version. But I think it is
safe to say that ICE works in the intended core cases. If there are
some corner cases where it fails, that may be. But that is not
information we will have until really large scale deployement or
someone makes very extensive tests.
Henry has, I believe, been very consistent in urging the IETF to have
more "running code" experience on every specification (not just ICE)
than our process requires. He has, IIRC, also advocated changing the
process to require running code before publishing an RFC. He's even
suggested at times that one should have running code before
submitting a protocol draft.
Another point to consider -- I've known Henry to bark at a tree with
no squirrel in it occasionally, but most of the time he's pretty
reliable, more so than most technology predictors. If he's worried
about ICE, it's probably because he's been talking to people who are
trying to implement it and they're telling him it is difficult or
that they're having performance or reliability issues. I imagine that
there are plenty of internal development teams in various companies
that are working on this and not necessarily bringing their results
back to the IETF. After all, if everybody sees the emperor as fully
clothed, they'd be embarrassed to proclaim otherwise. Of course, I
wish all of these developers were tied into the IETF, but then I'm
sure I don't want to see every ice-implementor's question on the SIP
list. That is why we have a sip-implementors mailing list, right?
Personally, I think ICE is the best solution we have. We KNOW of
cases where hole-punching doesn't work, and I think ICE will produce
usable results in most of those cases. But that's just my personal
opinion from reading the specs. I haven't implemented ICE, and I
haven't used anybody else's implementation. Sure, it's complex, but
that's because the underlying problem is complex -- there are just
too many different behaviors out there in "NAT and firewall land". Of
course, I could be wrong, too. It's happened before, once or
twice ;-). Just how sure are we that we're right about this?
Are we designing a "spruce goose" or a practical system? Only
experience will tell us. But some good flight reports from the
prototypes could go a long way towards reassuring us of the design's
utility.
So far we've had a couple of people report hearsay evidence -- that
somebody else has an ICE implementation and it works. Any of you
folks have personal experience you can share? Have there been
prototypes exercised at the interop events?
--
Dean
_______________________________________________
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
