Larry, > Paul Hoffman wrote: > > Which SDOs that you participate in want to see other SDOs publishing > > *incompatible* versions of their protocols? > > Hi Paul, > > Of course none of the SDOs that I work with want to see incompatible > versions. But this turns the issue on its head. Open source and open > standards deal with the freedom to do things, even though we might > discourage people to take us up on that offer of freedom. > > So with respect to IETF specifications, the open source and open standards > objective is that the world is *free* to make compatible or incompatible > versions of our specifications. (This is the philosophy that neither IETF > nor Microsoft nor IBM, nor anyone else, is going to be the absolute God of > acceptable software.) I'm sure that good people everywhere will cooperate to > ensure that all good versions of our specifications are compatible, and > cooperative people will be encouraged to remain compatible by virtue of the > quality of our work. > > But if anyone, anywhere, for any reason, wants to take an IETF specification > and modify it, open source requires that he be free to do so. I think "requires" is a stretch. There are a large number of non-IETF standards implemented in open source for which copyright does not permit arbitrary modifications, so I think "requires" is incorrect. Copyright provisions that do not grant derivative works rights and have distribution terms far less permissive than IETF's are common in other standards bodies, some of whom rely on charging money for copies of standards to fund their budgets. IETF has chosen not to charge for standards for many good reasons. Encouraging people who want to modify standards to talk to the people who developed the standards is a "good idea", and to the extent that copyright terms encourage people to do so, that's beneficial. An example of the benefits of this sort of discussion is RFC 4595 "Use of IKEv2 in the Fibre Channel Security Association Management Protocol" (I'm an author). When I started working on this, my initial belief was that an IETF RFC and use of IANA-allocated values was highly unlikely (e.g., IKEv2 for FC does not run over IP) and I was pleasantly surprised that the IETF Security Area wanted to see the FC values and usage documented in an RFC. OTOH, of the various arguments made for use of RFC text, the one I'm most sympathetic to is documentation - code comments, manuals, online help, etc., where the ability to selectively quote from the RFC that is implemented can be very useful. This would need to be controlled, as blanket permission for arbitrary selective quoting can be dangerous - it's fairly easy to change a standard to be non-interoperable via selective quoting. For an (amusing) extreme example from another domain, see: http://www.legis.state.wi.us/senate/sen10/news/FrankensteinVeto.pdf While I doubt that anyone would ever resort to something that bizarre in quoting from an RFC, I hope the underlying concern is clear. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@xxxxxxx Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf