Dan, As editor, I thoroughly endorse splitting off parts of the draft into separate documents. The base/SIP split that was done recently was simply the lowest hanging fruit. I think there should be at least two more splits into separate documents.
However, security is not one of these. Two reasons for this: - security is so intertwined with the base protocol that it would probably be impossible to split it out and have the result make any sense. Signatures are used not only over the entire message, but also used (and stored) over particular resources. If we remove security from the base draft then we wind up with something bizarre that says "when using security, put the signature here, see rfcYYYY for how to do it." - if we remove security (or even TLS) from the base draft, then we wind up with a draft specifying an "internet protocol" that has a security section stating "this protocol cannot be run on the internet without extensions specified in rfcYYYY." Do we want to do that? Bruce On Thu, Nov 6, 2008 at 9:38 AM, Dan York <[EMAIL PROTECTED]> wrote: > David, > > On Nov 6, 2008, at 8:53 AM, David A. Bryan wrote: > >> 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. > > DY> Well, yes, draft explosion definitely IS a problem. We need only look at > the fact that we need a Hitchhiker's Guide or Henry's simple SIP draft to > know that there is a problem. On the other hand, we're all just in this wee > minor little process of rearchitecting the entire communications > infrastructure of the planet... :-) > > DY> As much as we don't want an explosion of a zillion drafts, do we really > want giant documents that are complicated to implement? > > DY> Comparing to software development models, are we trying to do the > monolithic approach of building big giant programs that do everything?? Or > are we trying to do the UNIX approach of making many small utilities and > stringing them together? >> >> 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... > > > DY> Right. So we can make the spec allow them to negotiate... but that does > nothing to help with whether or not two P2PSIP implementations can > interoperate. A vendor can't take the RELOAD spec, implement it, and know > that they have a prayer of FULL interoperability with someone else... > because there are optional parts to it. > > DY> You've already defined two very clear use cases for where P2PSIP would > be implemented WITHOUT "security" aspects to the protocol. So why not > simplify the main spec and carve those off as separate RFCs? > > DY> Let's look at a case where this has worked well - RTP. If you want to > implement basic RTP, you implement RFC 3550. If you want to implement > Secure RTP, you implement RFC 3711. Ta da... you're done. It's very easy > for vendors to specify whether or not they support "secure" use of RTP > because they can point to their use of "SRTP" as defined in RFC 3711. > > DY> Now, yes, I'm a "security guy" arguing to REMOVE security provisions > from the main draft, but that's primarily because I realize that if they are > left in there as (wink, wink) "options", then NOBODY WILL IMPLEMENT THEM. > They text is in the RFC and so someone can say that they have appeased > whomever is doing a security review, but in practice no one will implement > them and the result is that protocols will wind up being LESS secure. > > DY> I've also been a product manager responsible for trying to ensure proper > implementations of various RFCs and in that role I can assure you that large > RFCs containing SHOULDs are horrible. I would vastly prefer multiple RFCs > (where the division makes sense) that *only* contain MUSTs. > > DY> Why don't we put this on the P2PSIP agenda for IETF 73? (the idea of > breaking out security aspects into a separate draft) > > My 2 cents, > Dan > > P.S. And realizing that I'm advocating making MORE work for the WG and we > just had a long thread on the RAI list about the lack of people to *do* > things, I'll put my actions behind my mouth and say that if the group agrees > with this path, I will volunteer to write one of the companion drafts. > > -- > 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 > > > > > > _______________________________________________ > P2PSIP mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2psip
