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(_at_)emc(_dot_)com Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf