> Yikes. That's not a circus -- that's a abattoir. It's a very careful > analysis of why carriers want all of SIP except for the SIP part. > > It looks like it boils down to: > > 4.1.1(a) - Some SIP products are broken by either design or > implementation > > 4.1.1(b) - Inter-service provider federation is being rolled out > without any of the tools the IETF has defined for that > kind of thing > > 4.2 - Service providers won't deploy DNS, despite it > being integral > to SIP and the Internet at large > > 4.3 - (Mostly a symptom of 4.2) People are deploying security > theater without any of the tools the IETF has defined for > that kind > of thing, and tel: URLs aren't apparently supported, even > when E.164 > is the only useful identifier in use. (If you can change > the domain > of a URI and still have it mean anything at all, it > should have been > a tel: URL anyway) > > 4.4 - This isn't a stand-alone issue; it's a symptom of 4.1.1(b) > > In short -- if we ignore the software bugs, it looks like the > problems all boil down the service providers choosing to ignore > various IETF-defined solutions (mostly as they relate to security).
By IETF-defined security solutions, are you referring to Speermint, which is all about SBE and DBEs? Speermint has not created an RFC yet. Hadriel's document explains in detail what he has seen in existing, real-world deployments. I agree the reality is depressing. I have thrown up my hands many times, too. > Why do we think we can come up with a new security mechanism > in the IETF and have it make half a whit of difference to > organizations who are clearly hostile to IETF-developed > security mechanisms? By developing protocols that meet their needs and work in their networks -- the same as every protocol that someone will use. Right now, 4474 doesn't work. Right now, service providers are abusing P-A-I in a way we know will cause harm. We could sit back and let them figure out a solution. Or we could step up and define the best solution that meets their needs and works in their networks, and which works best with the academic view of SIP. There are similarities between the 'Service Providers are destroying SIP' argument and the 'NATs are destroying the end-to-end Internet' arguments popular in the IETF during the 1990's. NATs were (and are) deployed because they met a need. The abuse of SIP is being done to meet a need -- it is not being done to upset the digerati. -d _______________________________________________ Sip mailing list https://www.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
