near-term improvements to resolve IETF problems of routine in
parallel with an integrated effort to reorganize the IETF and improve
our standards processes. None of the efforts suggested in this
document should be blocked pending the completion and publication of
this document. Ongoing efforts should continue, and new efforts
should start as soon as there is IETF consensus that they are
worthwhile.
In our improvement processes, we should attempt to focus our near-
term improvements on areas of routine that are less likely to be
substantially modified by any proposed structural changes, thus
minimizing the likelihood of double changes.
5.1. Improvements to Routine Processes
Many of the problems currently facing the IETF can be resolved, or
mitigated, through near-term improvements to our current IETF
organization and routine processes. Many of these improvements are
completely separable, and there is no reason to aggregate these
efforts into a single IETF WG. It is also unnecessary that all of
these changes be directed by the (already overworked) IESG.
However, in order to prevent the chaos and confusion that could be
caused by trying to change everything at once, it is recommended that
we choose a few high priority areas for improvement and focus on
making improvements in those areas.
In choosing which areas to pursue first, we should consider the
following criteria:
o We should address our most urgent, important problems.
o The areas chosen should be cleanly separable, to allow multiple
improvements to be carried out in parallel with minimal
interference.
o We should maximize the benefit vs. the cost of making the
improvements (i.e., look for low hanging fruit).
o As much as possible, we should focus on improvements that are less
likely to be completely invalidated by an overhaul of the IETF
management structure. This might be accomplished by focusing on
improvements at the WG and participant levels, rather than at the
IESG/IAB level.
In the sections above, we have identified several areas of routine
that could benefit from near-term improvements, including:
1. Improve WG quality processes and the effectiveness of document
reviews at all levels.
2. Increase the availability and use of issue tracking and document
sharing/revision control software in the IETF.
3. Improve training and resources for IETF leaders and participants
at all levels.
4. Improved communication between WG chairs to identify and resolve
inter-WG and inter-area problems.
5. Consider IETF processes or structures to better maintain IETF
standards.
6. Modify IESG-internal processes to make it impossible for one or
two IESG members to indefinitely delay a document.
7. Modify IESG processes to delegate more responsibility to WG
chairs, to directorates, to the IAB or to people in other formal
or informal leadership positions.
8. Modify the WG chair selection processes to widen the group of
people considered, and consider ways to develop more leaders for
the IETF.
9. Initiate regular AD review of WG milestones and progress.
Applying the criteria outlined above, it would make the most sense to
address areas 1, 2, 3, 4, and 5 through immediate near-term efforts.
These are high-priority issues, they are sufficiently separable to be
pursued in parallel, they place minimal additional burden on the
IESG, and they are the least likely to be affected by an
IESG/IAB-level reorganization of the IETF, or by changes to the
standards-track document maturity level classification and process.
Specific recommendations for how to proceed in each of these areas
are made in the following sections.
The IESG should consider internal changes to address areas 6, 7, and
8. Area 9 would require a substantial time commitment from IESG
members, so it is not suggested that near-term improvements be
pursued in this area, unless the IESG believes that the near-term
benefits would justify the effort.
5.1.1. Suggestions to Improve WG Quality Processes
A working group should be formed in the General Area of the IETF to
oversee improvements to the WG quality processes, including: The WG
(re-)chartering process, the quality processes used by IETF WGs, and
the effectiveness of IETF reviews at all levels. It should be the
goal of this WG to improve the quality and timeliness of WG work
output. This WG would be chartered to resolve the non-tools-related
portions of the Engineering Practices problem (Section 4.2) the WG-
related portions of the Engagement Problem (Section 4.5), and the
non-training-related portions of the WG Practices problem (Section
4.7).
A great deal of efficiency and synergy can be achieved by adopting
common processes throughout an organization. However, it is a
strength of the IETF that WG chairs are given a great deal of
latitude to choose their own processes and tools, based on the size
and nature of their WGs. So, in general, processes and tools should
be made available to WGs and WG chairs, not forced upon them.
5.1.2. Suggestions to Increase the Use of Tools
Ideally, the proliferation of tools within the IETF would be
accomplished via grass-roots efforts, organized by participants
within the IETF. One example of this type of effort is the recent
adoption of Jabber for use during IETF meetings.
However, it is also possible that the IESG could designate functional
leaders for specific tools-related efforts and support those leaders
in organizing those efforts. It also might be helpful for the IETF
to set-aside some technical and systems resources, to make useful
tools available to WGs and participants throughout the IETF.
These efforts should resolve the tools-related portions of the
Engineering Practices problem (Section 4.2).
5.1.3. Suggestions to Improve Training
The current WG chairs and newcomer’s training efforts should be
continued and expanded as appropriate to cover training for other
groups. This effort is expected to address the Preparedness problem
(Section 4.8), and the training-related portions of the Mission
Problem (Section 4.1) and the WG Practices problem (Section 4.7).
5.1.4. Suggestions to Increase WG Chair Communication
Some efforts are already underway to allow WG chairs to meet each
other, and to give them opportunities to establish communication
channels. These efforts include WG chair socials and training
sessions for experienced WG chairs. These efforts should be
continued.
The IESG could help to promote chair-to-chair communication by
encouraging direct communication between WG chairs when multi-WG
issues arise.
However, most of the responsibility for establishing effective
chair-to-chair communications channels lies with the individual WG
chairs. We should stop relying on the IESG to resolve inter-WG
issues, and start communicating with each other directly regarding
inter-WG issues.
These efforts may help to alleviate the Complex Problems problem
(Section 4.3), although a comprehensive solution to that problem
would probably require some changes to the IETF management
structures.
5.1.5. Suggestions to Improve Maintenance of Standards
The IETF should consider proposals to improve the way that IETF
standards are maintained. It might be possible for the IESG to
document and implement a mechanism to maintain IETF standards without
the need for a WG to enact this change.
This effort should address the maintenance-related portions of the
Standards Hierarchy problem (Section 4.4).
5.2. Changing the Structure and Practices of the IETF
A significant number of the issues that were identified in the IETF
Problem Statement appear to require alterations to the structure of
the IETF and/or the core practices which effectively characterize the
IETF. From the analysis in Section 4 the problems which might
require such alterations include:
o The Mission Problem (Section 4.1, [7]),
o the Complex Problems problem (Section 4.3, [3], [6]),
o the Standards Hierarchy problem (Section 4.4, [4]),
o the Management Scaling problem (Section 4.6, [6], [3], [2]), and
o The longer-term portions of the Engagement Problem (Section 4.5,
[5])
(Additional references on each item indicate associated documents
that may need to be updated as a result of this process.)
Poorly thought through changes to these areas could result in
irretrievable damage to the nature and effectiveness of the IETF, but
it seems essential that the necessary changes are identified and
accepted by the IETF community as quickly as possible. To achieve
acceptance by the largest possible number of IETF stakeholders, as
many of them as possible should be involved in the development of the
changes; the development and acceptance processes must be as open as
possible in line with normal IETF principles.
Development of the required changes under the aegis of a General Area
Working Group was extensively debated and a proposal was floated in a
previous version of this document. The proposal included a draft
charter for the working group. This way forwards has now been
rejected by the Problem working group because of
the perceived slow progress of such groups,
the difference in the nature of the problem from the usual
technical problems solved by IETF working groups and
the difficulty in achieving acceptance by all segments of the
community for work driven by a small group.
A proposal for coordination of the development of the structural
changes by a ’Strategy and Answers Panel’ composed of delegates from
IESG, IAB, and ISOC plus a number of members from the wider IETF
community (forming a small majority of the panel) selected using the
nomcom selection process can be found in [9]. The selection process
was intended to create a panel which would represent the interests of
the whole IETF community and so build solutions that would be
acceptable to the whole community. This proposal has not received
extensive support from the Problem working group either.
Other proposals advanced in discussions are:
o Delegation of the development of solutions to a team of ’wise men’
appointed by the IESG.
o Development of solutions by a design team with final approval by
the IESG.
o Development and implementation of the solutions by the IESG.
Discussions of alternative processes on the mailing list, at the
Problem WG meeting at IETF 57 and in the IETF 57 plenary did not
reach a consensus. Indeed some contributors took the view that the
problems could be overcome without (major) structural changes.
Given the lack of consensus and the lack of additional responses to a
previous appeal for alternative suggestions, this document has to
fall back to asking the IESG to take responsibility for controlling
the development of solutions to the structural problems identified
where it believes they are necessary.
6. Conclusion
The IETF has problems, and we need to work to solve those problems,
both via focused immediate improvements and possibly via an
integrated effort to build an IETF organizational structure and
develop processes that can better handle our current size and
complexity.
However, the IETF is also an effective organization with a long
tradition of excellence, and core values that we don’t want to
compromise in the course of improving our organization and processes.
So, any major changes undertaken in the IETF should include an
articulation of the IETF’s mission and our core values, so that we
can ensure that we build an organization that can carry out our
mission working in line with our core values.
The Problem WG has not been able to come to a consensus on a process
that could address the structural changes that may or may not be
needed. This is perhaps in line with previous experience of the
discussion of high level concepts in the IETF - the organization is
in general much better at discussion of and achieving consensus on
detailed concrete proposals. This document has little alternative
but to suggest that the IESG control the development of solutions to
any of the structural problems where they feel that changes are
necessary.
In the meantime, this should not be seen as gating discussions on
actual solutions for these problems - for example, the active
discussions that are in progress on alternatives to the current
maturity level system for IETF standards. Authors of solutions
should bear in mind the points made in Section 3: Evolutionary
rather than revolutionary proposals are more likely to be acceptable,
and an orderly transition must be possible.
Working together, we can resolve the problems currently facing the
IETF and make the IETF an even more effective, successful, and fun
place to work.
7. Security Considerations
This document contains suggestions for processes that the IETF could
use to resolve process-related and organizational problems with the
IETF. Although the structure and quality of the IETF’s processes may
have an affect on the quality of the IETF’s security-related work,
there are no specific security-related issues raised in this
document.
Acknowledgements
The contents of this document were greatly influenced by members of
the Problem Statement WG editorial team: Rob Austein, Dave Crocker,
Elwyn Davies, Spencer Dawkins, Avri Doria, Jeanette Hofmann, Melinda
Shore, and Margaret Wasserman.
Previous versions of this document were edited by Margaret Wasserman,
who was responsible for the original structuring of the solution.
In addition to the editorial team, the following people have provided
useful feedback on earlier versions of this document: Harald
Alvestrand, Randy Bush, Brian Carpenter, Leslie Daigle, James Kempf,
John Klensin, John Loughney, and Keith Moore.
Normative References
[1] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.
[2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall Committees", RFC
2727, February 2000.
Informative References
[3] Alvestrand, H., "An IESG charter", Work in Progress, April 2003.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[5] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP
25, RFC 2418, September 1998.
[6] Internet Architecture Board and B. Carpenter, "Charter of the
Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
[7] Harris, S., "The Tao of IETF - A Novice’s Guide to the Internet
Engineering Task Force", RFC 3160, August 2001.
[8] IETF, "Minutes of IESG Plenary at IETF55, Atlanta, GA, USA", Nov
2002, <http://www.ietf.org/proceedings/02nov/slides/plenary-
2/sld4.htm>.
[9] Davies, E., Doria, A., and J. Hofmann, "IETF Structural Problems
Improvement Process", Work in Progress, September 2003.
Authors’ Addresses
Elwyn B. Davies (editor)
Nortel Networks
Harlow Laboratories
London Road
Harlow, Essex CM17 9NA
UK
Phone: +44 1279 405 498
EMail: elwynd@nortelnetworks.com
Jeanette Hofmann (editor)
Wissenschaftszentrum Berlin
Reichpietschufer 50
Berlin 10785
Germany
Phone: +49 30 25491 288
EMail: jeanette@wz-berlin.de
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
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.