Re: [Internet-Drafts@ietf.org: I-D ACTION:draft-bradner-rfc-extracts-00.txt]
On Fri, Feb 11, 2005 at 09:48:52AM +0100, Stephane Bortzmeyer wrote:
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> [-- This text/plain attachment is not included, --]
> [-- and the indicated access-type anon-ftp is unsupported --]
Err. Better to include the actual text, and not a link (especially
not a link that not even Mutt can grok).
--
Glenn Maynard
Network Working Group S. Bradner
Internet-Draft Harvard University
Editor
February 2005
Extracting RFCs
<draft-bradner-rfc-extracts-00.txt>
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 7, 2005.
Abstract
Many people have expressed a desire to extract material from IETF
RFCs for use in documentation, text books, on-line help systems, and
for similar uses. In addition, some IETF RFCs contain MIBs and other
types of program code that could be compiled. This document proposes
an update to RFC 3667 and 3668 to explicitly permit extracting
material for a wide range of uses.
RFC 2026 limited the rights the IETF requires of document authors and
editors. RFC 2026, and its successors, do not require that the
authors permit the creation of derivative works based on their
contribution outside of the IETF process. Some people have expressed
a desire for the IETF to obtain such permission to enable people
outside of the IETF to create derivative works, for example, within
Bradner [Page 1]
Internet-Draft RFC Extracts February 2005
an open source environment. This document tries to spell out the
issues surrounding this desire in order to stimulate discussion
within the IETF community about possibly updating RFC 3667 and RFC
3668 to request such rights from RFC authors.
Copyright Notice
Copyright (C) The Internet Society. (2005)
1. Introduction
Section 3.3(a)(E) of RFC 3667 [RFC 3667] requires that the author(s)
of IETF contributions grant the IETF the right to make and use
certain types of extracts of the contributions for purposes not
limited to the IETF standards process. When I wrote that section I
intended that to mean that anyone could make such extracts but the
wording I used limited the permission to the IETF. This document
tries to fix the words to match my intent.
Historically RFCs have been assumed to be fair game to anyone who
wanted to use text and ideas from an RFC in their own work. The RFC
publication process did not explicitly request that RFC authors
surrender the right for the creation of such derivative works but no
limits to do so were noted in RFCs.
Starting with RFC 1602 [RFC 1602] the IETF stared requesting that RFC
authors agree to grant specific rights to the IETF regarding the text
and ideas in RFCs. These requests were made more explicit in RFC
2026 [RFC 2026] and clarified in RFC 3667. Currently, as defined in
RFC 3667, authors must grant to the IETF the right for derivative
works to be created within the IETF standards process but the IETF
does not request the right for people not working within the IETF
standards process to make derivative works. The author(s) may do
that on their own if they want but its not part of the rights the
IETF requires the author grant as part of RFC publication process.
Note that the RFC Editor requires that authors grant the right for
anyone to make derivative works as a requirement for the publication
of a non-IETF RFC. Note also that authors may explicitly add text to
their submission that prohibits the creation of derivative works at
all. (See RFC 3667 Section 5.2.)
Recently there has been considerable discussion on the IETF IP
working group mailing list about the implications of the IETF not
requiring that authors grant the right for anyone to create
derivative works from RFCs. This document discusses the issue and is
intended to serve as a catalyst for discussion.
2. Extractions from RFCs
I see no reason to limit the ability for people to make and use
extracts from RFCs as long as the extract is not modified and that
Bradner [Page 2]
Internet-Draft RFC Extracts February 2005
proper acknowledgement is given and the ISOC copyright notice is
included. Thus I propose that something like the following be added
to RFC 3667 as Section 3.3(c):
c. To the extent that a Contribution or any portion thereof is
protected by copyright and other rights of authorship, the
Contributor, and each named co-Contributor, and the organization
he or she represents or is sponsored by (if any) grant a
perpetual, irrevocable, non-exclusive, royalty-free, world-wide
right and license to extract, copy, publish, display, distribute,
and incorporate into other works, for any purpose (and not limited
to use within the IETF Standards Process) any portion of the
Contribution as long as the extract is not modified, proper
acknowledgement is given and as long as the ISOC copyright notice
is included. It also being understood that the licenses granted
under this paragraph (c) shall not be deemed to grant any right
under any patent, patent application or other similar intellectual
property right disclosed by the Contributor under [IETF IPR]).
3. Unrestricted derivative works
A number of people have expressed the opinion that it should be
possible for anyone to modify and republish a RFC if they feel that
they can improve on the technology described in the RFC. A number of
messages to the IETF IP working group mailing list asserted that the
open source development process depends on the ability to do this.
As noted above, historically this was possible with RFCs until RFC
2026 changed things so that modifications had to be done within the
IETF standards process unless the author had given specific
permission for modifications to be done elsewhere.
The IETF is not alone in not providing the right to make unrestricted
derivative works. The W3C, the ITU, ANSI, IEEE, etc all restrict the
ability to make derivative works based on their specifications. I
have not found a standards organization that permits it (but I'm sure
that it will be pointed out if there are such standards
organizations.
Disclaimer: I do not think that granting the unrestricted ability to
make derivative works is a good thing for the IETF to do so I expect
the following list of advantages is far from complete.
3.1. Advantages of the unrestricted ability to make derivative works
3.1.1. Support for open source
The assertion was made by a number of posters to the IETF IPR working
group mailing list that the open source community requires the
unrestricted ability to make derivative works.
3.1.2. Speed of technological evolution
Bradner [Page 3]
Internet-Draft RFC Extracts February 2005
It is clear that there would be more rapid evolution of technology
standards if anyone could create their own variation and document it
so that others could implement and support that version.
3.2. Disadvantages of the unrestricted ability to make derivative works
3.2.1. Confusion over what constitutes the standard
It would clearly be confusing if someone could take an IETF standard
such as RFC 3270 (MPLS Support of Differentiated Services), change a
few key words and republish it, maybe in a textbook, as the
definitive standards for MPLS Support of Differentiated Services.
The IETF could, as Larry Rosen suggested create a process whereby the
IETF could create a certification mark and a process to ensure that
the mark was only used on products that implement the IETF version
but that would be adding a lot of extra effort of a type that the
IETF has not shown itself to be very good at.
3.2.2. Architecturally agnostic modifications
IETF working groups undertake a great deal of effort to develop a
common understanding of the underlying architectural assumptions of
the standards they develop. Modifications or extensions to a
standard done without an understanding of those architectural
assumptions may easily introduce significant operational or security
issues. The best place to extend a standard is in the working group
that developed it because they know what the underlying assumptions
are and can properly ascertain if the modification or extension is
something that fills a real need (and not just a local optimization
of something that can already be done) and if its done in a way that
does not break the existing standard.
3.2.2. Cooperation between standards organizations
Many standards development organizations (SDOs) are now working in
the technology areas that were once the nearly exclusive territory of
the IETF. This increased standards activity can be very good for
innovation but frequently other standards organizations have decided
that IETF technologies are almost, but not quite, right for them to
use. If it were perfectly OK for such an SDO to publish a modified
version of an IETF standard as one of their own standards (and most
likely publish it in a way that bans the creation of derivative
works) it would distort the standards playing field. I think that
SDOs working in the same or overlapping areas should cooperate with
each other not try to usurp the other SDO's work. Just as the IEEE
would not like it if the IETF to republish a modified specification
for 802.11 and the ITU-T would not like it if the IETF were to
republish a modified version of the specification of SONET/SDH,
neither of these organizations should assume that they are encouraged
to create modified versions of IETF specifications.
3.2.3. Restricting open source
Bradner [Page 4]
Internet-Draft RFC Extracts February 2005
I do not buy the argument that the open source community requires the
ability to make capricious changes in standards. I fully agree that
the IETF should place no restrictions on the ability of anyone to
implement an IETF standard (some people or companies claiming patent
rights might do so but that is not something the IETF should do). I
do not see that the open source community requires the ability to
create a modified and incompatible version of ATM signaling or of the
Ethernet backoff algorithm. If someone in the open source community
thinks they have a better idea then they should present that idea to
the standards organization that developed the technology to see if
the standards organization agrees.
The open source community does not have this ability with the output
of other standards organizations, I do not see justification to say
that its OK to do so for Internet technology. It seems to be
perfectly reasonable for an open source development effort to
implement a standard rather than assume they know better.
3.3. Call for discussion
The question of the IETF's getting from RFC authors the right to let
anyone create derivative should be discussed on the IETF IP working
group list and in the next meeting.
Adding something like the following as Section 3.3.(c) to RFC 3667
would make the change:
c. To the extent that a Contribution or any portion thereof is
protected by copyright and other rights of authorship, the
Contributor, and each named co-Contributor, and the organization
he or she represents or is sponsored by (if any) grant a
perpetual, irrevocable, non-exclusive, royalty-free, world-wide
right and license to extract, modify, copy, publish, display,
distribute, and incorporate into other works, for any purpose (and
not limited to use within the IETF Standards Process) any portion
of the Contribution as long as proper acknowledgement is given and
as long as the ISOC copyright notice is included. It also being
understood that the licenses granted under this paragraph (c)
shall not be deemed to grant any right under any patent, patent
application or other similar intellectual property right disclosed
by the Contributor under [IETF IPR]).
4. Other problems in what RFC 3667 requires from authors
Sam Hartman posted a note to the IETF IPR working group mailing list
in which he said that he was not sure that the current granting of
rights on RFC 3667 was sufficient to cover the case where he too text
from an existing standard to use in a new RFC since he felt that he
might not be able to fulfill the Internet-Draft boilerplate
requirements. (http://www1.ietf.org/mail-archive/web/ipr-
Bradner [Page 5]
Internet-Draft RFC Extracts February 2005
wg/current/msg02677.html) I'm not sure there is a problem but the
working group should explore the issue to see if a change is needed
to fix the problem Sam sees.
5. References
5.1. Normative References
[RFC 3667] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
5.2. Informative References
[RFC 1602] IAB, IESG, "The Internet Standards Process -- Revision 2",
RFC 1602, March 1994.
6. Editor's Address
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA, 02138
Phone: +1 617 495 3864
EMail: sob@harvard.edu
7. Full copyright statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Bradner [Page 6]
Internet-Draft RFC Extracts February 2005
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology
that may be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bradner [Page 7]
Reply to: