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
