Processes for Management of IETF Liaison Relationships", and
[BCP103], "Procedures for Handling Liaison Statements to and from the
IETF". The best place to check to see whether the IETF has any
formal liaison at all is the list of IETF liaisons,
www.ietf.org/liaisonActivities.html. The list shows that there are
many different liaisons to ISO/IEC JTC1 subcommittees.
10.2. Press Coverage of the IETF
Given that the IETF is one of the best-known bodies that is helping
move the Internet forward, it’s natural for the computer press (and
even the trade press) to want to cover its actions. In recent years,
a small number of magazines have assigned reporters and editors to
cover the IETF in depth over a long period of time. These reporters
have ample scars from articles that they got wrong, incorrect
statements about the status of Internet Drafts, quotes from people
who are unrelated to the IETF work, and so on.
Major press errors fall into two categories: saying that the IETF is
considering something when in fact there is just an Internet Draft in
a Working Group, and saying that the IETF approved something when all
that happened was that an Informational RFC was published. In both
cases, the press is not fully to blame for the problem, since they
are usually alerted to the story by a company trying to get publicity
for a protocol that they developed or at least support. Of course, a
bit of research by the reporters would probably get them in contact
with someone who could straighten them out, such as a WG chair or an
Area Director. The default press contact for the IETF is the IAD,
who can be reached at mailto:iad@ietf.org.
The fact that those reporters who’ve gotten it wrong once still come
back to IETF meetings shows that it is possible to get it right
eventually. However, IETF meetings are definitely not for reporters
who are naive about the IETF process (although if you are a reporter
the fact that you are reading this document is a very good sign!).
Furthermore, if you think that you’ll get a hot story from attending
an IETF meeting, you are likely to be disappointed.
Considering all this, it’s not surprising that some IETFers would
prefer to have the press stay as far away from meetings as possible.
Having a bit of press publicity for protocols that are almost near
completion and will become significant in the industry in the next
year can be a good thing. However, it is the rare reporter who can
resist over-hyping a nascent protocol as the next savior for the
Internet. Such stories do much more harm than good, both for the
readers of the article and for the IETF.
The main reason why a reporter might want to attend an IETF meeting
is not to cover hot technologies (since that can be done in the
comfort of your office by reading the mailing lists) but to meet
people face-to-face. Unfortunately, the most interesting people are
the ones who are also the busiest during the IETF meeting, and some
folks have a tendency to run away when they see a press badge.
However, IETF meetings are excellent places to meet and speak with
document authors and Working Group chairs; this can be quite valuable
for reporters who are covering the progress of protocols.
Reporters who want to find out about "what the IETF is doing" on a
particular topic would be well-advised to talk to more than one
person who is active on that topic in the IETF, and should probably
try to talk to the WG chair in any case. It’s impossible to
determine what will happen with a draft by looking at the draft or
talking to the draft’s author. Fortunately, all WGs have archives
that a reporter can look through for recent indications about what
the progress of a draft is; unfortunately, few reporters have the
time or inclination to do this kind of research. Because the IETF
doesn’t have a press liaison, magazines or newspapers that run a
story with errors won’t hear directly from the IETF and therefore
often won’t know what they did wrong, so they might easily do it
again later.
11. Security Considerations
Section 8.4.4 explains why each RFC is required to have a Security
Considerations section and gives some idea of what it should and
should not contain. Other than that information, this document does
not touch on Internet security.
Appendix A. Related Information
A.1. Why "the Tao"?
Pronounced "dow", Tao is the basic principle behind the teachings of
Lao-tse, a Chinese master. Its familiar symbol is the black-and-
white yin-yang circle. Taoism conceives the universe as a single
organism, and human beings as interdependent parts of a cosmic whole.
Tao is sometimes translated "the way", but according to Taoist
philosophy the true meaning of the word cannot be expressed in words.
A.2. Useful Email Addresses
Some useful email addresses are listed here. These addresses may
change from time to time, and it’s a good idea to check the IETF web
pages for the correct address before sending your mail.
Address Description
-----------------------------------------------------------------
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-action@ietf.org Requests for things to be done when you
don’t know exactly where to send the
request
ietf-info@ietf.org General questions about the IETF
ietf-registrar@ietf.org Questions about registration, meeting
locations, and fees
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-secretary@ietf.org Questions for the Secretariat
ietf-web@ietf.org Questions or comments about the IETF
web site
internet-drafts@ietf.org Internet Draft submissions and queries
proceedings@ietf.org Where to send Working Group minutes and
slides for the IETF Proceedings
iana@iana.org Internet Assigned Numbers Authority
rfc-editor@rfc-editor.org RFC Editor
statements@ietf.org Incoming liaison statements from other
organizations
Online upload pages are planned for the future to facilitate
submission of Internet Drafts, Proceedings, and Liaison statements.
A.3. Useful Documents and Files
The IETF web site, http://www.ietf.org, is the best source for
information about meetings, Working Groups, Internet Drafts, RFCs,
IETF email addresses, and much more. Click on "Additional
Information" to find a variety of helpful links. Internet Drafts and
other documents are also available in the "ietf" directory on
anonymous FTP sites worldwide. For a listing of these sites, see
http://www.ietf.org/shadow.html.
Check the IESG web pages, http://www.ietf.org/iesg.html, to find up-
to-date information about drafts processed, RFCs published, and
documents in Last Call, as well as the monthly IETF status reports.
A.4. Acronyms and Abbreviations Used in the Tao
Some of the acronyms and abbreviations from this document are listed
below.
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
Numbers, http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force,
http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1 Joint Technical Committee of the International
Organization for Standardization and
International Electrotechnical Commission,
http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union,
http://www.itu.int
RFC Request for Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working Group
Appendix B. IETF Guiding Principles
If you’ve gotten this far in the Tao, you’ve learned a lot about how
the IETF works. What you’ll find in this appendix summarizes much of
what you’ve read and adds a few new points to ponder. Be sure to
read through all the principles; taken as a whole, they’ll give you a
new slant on what makes the IETF work.
B.1. General
P1. The IETF works by an open process and by rough consensus. This
applies to all aspects of the operation of the IETF, including
creation of IETF documents and decisions on the processes that
are used. But the IETF also observes experiments and running
code with interest, and this should also apply to the
operational processes of the organization.
P2. The IETF works in areas where it has, or can find, technical
competence.
P3. The IETF depends on a volunteer core of active participants.
P4. Membership of the IETF or of its WGs is not fee-based or
organizationally defined, but is based upon self-identification
and active participation by individuals.
B.2. Management and Leadership
P5. The IETF recognizes leadership positions and grants power of
decision to the leaders, but decisions are subject to appeal.
P6. Delegation of power and responsibility are essential to the
effective working of the IETF. As many individuals as possible
will be encouraged to take on leadership of IETF tasks.
P7. Dissent, complaint, and appeal are a consequence of the IETF’s
nature and should be regarded as normal events, but ultimately
it is a fact of life that certain decisions cannot be
effectively appealed.
P8. Leadership positions are for fixed terms (although we have no
formal limitation on the number of terms that may be served).
P9. It is important to develop future leaders within the active
community.
P10. A community process is used to select the leadership.
P11. Leaders are empowered to make the judgment that rough
consensus has been demonstrated. Without formal membership,
there are no formal rules for consensus.
B.3. Process
P12. Although the IETF needs clear and publicly documented process
rules for the normal cases, there should be enough flexibility
to allow unusual cases to be handled according to common sense.
We apply personal judgment and only codify when we’re certain.
(But we do codify who can make personal judgments.)
P13. Technical development work should be carried out by tightly
chartered and focused Working Groups.
P14. Parts of the process that have proved impractical should be
removed or made optional.
B.4. Working Groups
P15. Working Groups (WGs) should be primarily responsible for the
quality of their output, and therefore for obtaining early
review; WG chairs as WG leaders, backed up by the IETF
leadership, should act as a quality backstop.
P16. WGs should be primarily responsible for assessing the negative
impact of their work on the Internet as a whole, and therefore
for obtaining cross-area review; the IETF leadership should act
as a cross-area backstop.
P17. Early review of documents is more effective in dealing with
major problems than late review.
P18. Area Directors (ADs) are responsible for guiding the formation
and chartering of WGs, for giving them direction as necessary,
and for terminating them.
P19. WG chairs are responsible for ensuring that WGs execute their
charters, meet their milestones, and produce deliverables that
are ready for publication.
P20. ADs are responsible for arranging backstop review and final
document approval.
B.5. Documents
P21. IETF documents often start as personal drafts, may become WG
drafts, and are approved for permanent publication by a
leadership body independent of the WG or individuals that
produced them.
P22. IETF documents belong to the community, not to their authors.
But authorship is recognized and valued, as are lesser
contributions than full authorship.
P23. Technical quality and correctness are the primary criteria for
reaching consensus about documents.
P24. IETF specifications may be published as Informational,
Experimental, Standards Track, or Best Current Practice.
P25. IETF Standards Track specifications are not considered to be
satisfactory standards until interoperable independent
implementations have been demonstrated. (This is the
embodiment of the "running code" slogan.) But, on legal
advice, the IETF does not take responsibility for
interoperability tests and does not certify interoperability.
P26. IETF processes are currently published as Best Current Practice
documents.
P27. Useful information that is neither a specification nor a
process may be published as Informational.
P28. Obsolete or deprecated specifications and processes may be
downgraded to Historic.
P29. The standards track should distinguish specifications that have
been demonstrated to interoperate.
P30. Standards Track and Best Current Practice documents must be
subject to IETF wide rough consensus (Last Call process). WG
rough consensus is normally sufficient for other documents.
P31. Substantive changes made after a document leaves a WG must be
referred back to the WG.
P32. The IETF determines requirements for publication and archiving
of its documents.
Informative References
[BCP9] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in
the IETF Standards Process", BCP 11, RFC 2028, October
1996.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP22] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BCP25] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[BCP39] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, RFC
3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, July
2003.
[BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[BCP79] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP
95, RFC 3935, October 2004.
[BCP101] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005.
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes
for Management of IETF Liaison Relationships", BCP 102,
RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF", BCP
103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are
Standards", RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[STD3] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
Authors’ Addresses
Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
US
EMail: paul.hoffman@vpnc.org
Susan Harris
1722 Chandler Road
Ann Arbor, MI 48104
US
EMail: srh@umich.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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
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 provided by the IETF
Administrative Support Activity (IASA).