Very good points...in many ways I'd definitely agree the approach of doing things like this in different drafts, if we could get people to go for that approach. As you point out -- much easier to specify what one does and does not support... Problem would be the draft explosion. Also for this one I think that we could specify a way in the draft for the two sides to negotiate if they have TLS or not, although that solves things at a protocol level, not at a "I support XXXX" level...
David (as individual) On Thu, Nov 6, 2008 at 6:27 AM, Dan York <[EMAIL PROTECTED]> wrote: > David, > > Well said... a couple of points inline prefixed with "DY>": > > On Nov 5, 2008, at 10:47 AM, David A. Bryan wrote: > >> Personally, I think the slippery slope we are risking here is the >> other way...in the RAI in general we keep throwing more and more >> mandatory things into our protocols, and the spec itself becomes more >> and more irrelevant when people ignore parts of the spec that do not >> apply to their application. > > DY> Whoa..... wait, wait... you want to put out a protocol that people > actually *implement*? :-) > > DY> Seriously, your point is well taken, we DO need to put out specs that > people are actually able to implement, but I would argue it from a slightly > different point... > >> The fact that many people do ignore our >> "sage advice" is a symptom of what is wrong with the default approach >> of making everything mandatory. In my mind, this is why SIP >> compatibility is so elusive. Who actually implements everything we say >> is mandatory in the many SIP specs? With no guidance other then "you >> must do it all", we end up with non-compatible implementations. > > DY> ... that part of the reason why we have implementation issues is, in > fact, that we are trying to do too many things in some of the protocols. > However, my experience with non-compatible implementations of many of the > other SIP protocols is that we have too many "SHOULD"s or places where we > have options that people can choose. I mean, look at the fact that we've > needed to spin up a whole new working group, BLISS, primarily because we > have about 4 different ways to do Do Not Disturb inside of SIP! (And a > number of other reasons...) > > DY> In my personal opinion, for solid interop we need fewer SHOULDs and > should have mainly MUSTs... but to your point, the simpler we can make the > protocol, the better. >> >> >> If I am a carrier and am building a P2PSIP system for use exclusively >> inside my network, why implement ICE? > > DY> Agreed. > >> If I am a developer looking to >> use P2PSIP on motes for a small sensor network, I may not want to use >> TLS. I certainly may not want to use it for testing. > > DY> Agreed. > >> I think if >> anything we should just plain support a non-TLS mode. Don't call it a >> "test-mode". Just call it a non-TLS mode. > > DY> So why don't we throw out the TLS mode entirely and just have the base > be NON-TLS and then write a companion document that explains how to do > *secure* P2PSIP? > > DY> That way for an implementor they can say that they support RFCxxxx for > P2PSIP and then also RFCyyyy for secure P2PSIP. This gets around all of the > SHOULDs that cause interop problems. >> >> >> We need to stop assuming that implementors are not able to decide for >> themselves when it is or is not appropriate for something as basic as >> security to be implemented. The IETF is not the only group capable of >> making the decision of whether this is needed -- let the implementors >> who actually understand their particular application make the decision >> -- and just make it optional. If the application needs TLS, the >> implementors will be smart enough to do so and their customers will >> also have strong reasons to demand it be implemented. > > > DY> Sure, but going back to ensuring *interop*... if we just let everyone > decide for themselves which parts of the spec they will implement, how in > the world are we going to be able to do any real interop testing? > > DY> I would argue we should carve out the interoperable pieces into their > simplest forms and then advance those as separate RFCs. That way > implementors can choose among the RFCs, but at the very least they can say > they are "RFCxxxx-compliant" and that will be understood by other vendors - > and can be tested. > > My 2 cents, > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation [EMAIL PROTECTED] > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > -- David A. Bryan [EMAIL PROTECTED] www.SIPeerior.com _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
