draft-hardie-12-2-1
Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc.
June 2003
Twelve heresies, two visions, and one belief
draft-hardie-12-2-1-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
The IETF brings together a technical community that shares a
common dedication to making the best possible engineering choices
and protocol standards for the Internet as whole. The community
shares a number of common beliefs, which create the basis of a
common work style and inform many of the decisions made within the
IETF. As in many communities of believers, some of these beliefs
have been elevated to the status of dogma. In the process of
considering reform, the treatment of these as unquestionable may
be hindering progress. This document challenges some of the
beliefs which the author believes have become dogmatic. It also
presents two visions for the evolution of the IETF and articulates
a single belief.
1. The Heresies
1.1 Rough consensus.
"rough consensus and running code" is a way to judge whether or
not an an idea will work, not a goal in and of itself.
Dave Clark's much-quoted credo for the IETF cites "rough consensus
and running code" as the key criteria for decision making in the
IETF. Aside from a pleasing alliteration, these two touchstones
provide a concise summary of the ideals which guide the IETF's
decision making. The first implies an open process in which any
technical opinion will be heard and any participant's concerns
addressed; the second implies a recognition that any decision must
be grounded in solid engineering and the known characteristics of
the network and its uses. As touchstones, they are excellent.
The aim of the IETF is to make the best possible engineering
choices and protocol standards for the Internet as a whole, and
these two statements should guide it in making its choices and
standards.
Note, though, that they should be guidelines, not inflexible
rules. We rely on this viewpoint as a way of judging things for
many situations, but we can't be hamstrung by it. There are times
when the IETF's need to make a decision on a technical point may
be greater than its need to use consensus as a process to reach
that goal. RFC 3127 documents one such occasion. There are
others where the failure to use other methods delayed or destroyed
important efforts, and these occasions should warn us not to treat
this advice as dogma.
1.2 Working group participation.
Working groups need to identify their participants.
The IETF uses an open process which allows technical contributions
from any one, regardless of affiliation or attendance. This is a
good thing. A bad thing which has arisen from that good thing is
a reluctance to identify the participants in a working group
effort, presumably out of fear that working group "members" will
ignore the input of those who are not members and that the
openness will thus be compromised. Openness is important, but the
result of this choice can be broken working group processes.
Chairs and document authors may have to make generic pleas for
participation or document review, rather than asking specific
individuals to undertake those tasks. Since some of those who
might be willing if asked instead assume someone else will take
the task, participation is reduced despite there being a pool of
participants who are fundamentally committed to the work.
Identifying working group participants acknowledges that the IETF
is much larger than the current pool of authors or slate of Area
Directors and working group chairs. Making participation more
explicit improves the ability of those outside a particular effort
to tap expertise in it and enables the organization to identify
those who may be ready to take on new roles as authors, chairs, or
mentors. Identifying participants should not exclude technical
comments from those outside an effort who review its work, and
checks and balance may, of course, still be needed to make sure
such exclusion does not occur.
1.3 Working group oversight.
Self-organizing working groups need oversight to ensure that the
decisions they reach are the best decisions for the Internet as a
whole.
A rational decision for a working group may not be the right
decision for the IETF as a whole. From some perspectives, it may
be rational to resist change to deployed clients, even though they
contribute to congestion or lack security. It may be rational to
avoid interoperability with competing systems, so that a larger
scope for the current effort may be planned. It may even be
rational for the working group to replicate at one layer a suite
of services developed or being developed at another, so as to
avoid dependencies.
At the moment, the IETF has poor mechanisms to deal with those
tensions, even though most IETF participants would agree that
congestion control, security, interoperability, and the reuse of a
common core set of services are all laudable design goals. The
community reviews charters and constrains them such that efforts
are expected to meet certain design goals. There can be pushback
during IETF Last Call or during the IESG's review. Fundamentally,
though, we trust that participants have internalized the issues
and that they, therefore, will handle the tension themselves.
That can and does work, but we need other mechanisms to reinforce
it: some of those may be training, some may be structural reviews
at periodic intervals, and some may be creating methods to ensure
that cross-speciality expertise is more consistently available.
Some form of oversight is required, though, to ensure that it has
worked. The current form, though, is not the only possibility.
The IETF might shift to a system in which working groups are not
entirely self-organizing but instead requires participation by
those with specific expertise or points of view (e.g. security,
operations), so that "oversight" is in fact part of normal working
group processes. It also might mean oversight by bodies other
than those currently handling the task, but with the same duty to
examine the working group's output from the broader perspectives
available outside the group or its area.
1.4 Interim meetings.
Interim meetings are not inherently a bad thing.
Working groups need to make progress throughout the year, not
just in the period immediately before and after an IETF plenary
meeting. While the IETF's main mode of operations, working on
mailing lists, supports this goal, face to face time can help.
Face to face meetings or open conference calls can help a group
make progress by helping focus the participant's efforts and by
providing for a quicker exchange of ideas than is possible on
mailing lists. Interim meetings can be just as open to those
doing the work as the plenary meetings, provided they are
well-advertised, planned sufficiently far in advance, and take
into account the need for fairness in travel budgeting when
selecting locations.
Interim meetings do not allow for the same level of interaction
outside the core participant group as is allowed by IETF plenary
meetings, but minuted results provide a reasonable degree of
openness for those not actively engaged in the work.
1.5 Areas.
It does make sense to group work together.
The existence of useful directorates outside the set of current
areas (e.g the LDAP directorate or XML directorate) indicates
that this grouping may in fact be valuable at multiple levels,
and that some groupings may intersect. The current set of areas
and interactions may or may not make sense and may or may not be
sufficient, but the idea is fundamentally sound.
1.6 Dependencies.
The work of one group must be able to depend on the work of another.
An organization with expected output of the IETF must be able to
have the work of one unit depend on the work of another. Working
groups commonly divide their work into multiple related documents,
rather than trying to create a single, monolithic specification.
The IETF as a larger community needs to be able to do the same
thing, by allowing specific groups' work to depend on that being
done at other layers or in other areas. One advantage the IETF
has in open review and input is that when one group's lack of
conclusive output is gating other work, those waiting can add
their energy to the working group they depend on.
1.7 One way.
There is no fundamental requirement that the IETF use a single way
to make decisions or progress standards.
While it is important to specify the ways decisions happen and
progress is made, there is no reason to assume that one single
process must be used in all cases. Having multiple ways of doing
things that fit different circumstances allows us to focus on the
output needed, rather than the process used to achieve it. As we
consider reform, we must recognize that replacing one single way
of doing the work with any other single way of doing the work will
move the pain, but may accomplish little else.
1.8 Legal fiction.
The IETF operates under a legal fiction that relates its work to
ISOC; that fiction needs to be replaced with a new legal fiction
that lets the IETF stand apart.
The legal fiction that the IETF is an organized activity of ISOC
grew out of the need for the IETF to have an organizational home
that could provide insurance, legal counsel, and related services.
The author believes that it also grew out of the reluctance of
many participants in the IETF to be pinned down as a membership
organization, for reasons articulated in 1.2, above. To restate
those reasons in an organizational form, the author believes that
there was considerable concern that those funding the IETF would
expect or receive treatment that limited the IETF's ability to
make the best engineering decisions for the Internet. Allowing
the IETF to exist as an activity, rather than an organization, put
it at one remove from direct funding and helped assuage those
fears.
The IETF existed prior to ISOC's formation, and has related to the
IAB, IRTF, RFC Editor and other organizations in ways very
different from those currently in place. The current legal
fiction has had a host of unintended consequences, and we find
ourselves at a moment when ending it makes sense. ISOC has a
stable income stream related to PIR's management of the .org TLD,
and it has itself created a new structure to refocus its
priorities.
The IETF, too, is considering reform and in so doing it has the
opportunity to put in place other mechanisms to ensure that it
retains the ability to make the best possible engineering
decisions while obtaining the ability to make more direct
decisions about its supporting organizations and external
relationships.
1.9 Paid staff.
The pride the IETF takes in having volunteer effort should not
blind the IETF to the opportunities that having paid staff may
represent.
There are already a number of critical services that the IETF
derives through Memoranda of Understanding or other contracts, and
the benefits in event planning, publication services, and related
capabilities are clear. There are other areas, such as working
group management, where the IETF does not use paid staff and where
doing so would represent a fundamental change in the nature of the
IETF. There are also, however, some grey areas where having paid
staff who worked directly for the IETF might be a significant
advantage. An IETF-employed executive director might logically
negotiate contracts on its behalf, for example, where one employed
via an MoU would be barred from negotiating at least that
contract, if not all contracts.
1.10 Document Series.
The existence of an independent, technical RFC editor is vital to
the ongoing dialog about what technologies and services will
improve the Internet. It is also best served by splitting the
document series so that IETF-produced documents and other
documents published by the RFC editor cannot be confused.
At the moment, there is a tension between the community's need and
desire for an open publication series which allows for
wide-ranging documents exploring the space of packet-switched
networking and the community's need for a clear set of
specifications for the protocols and practices it has developed.
Note, in particular, that the community needs for the set to be
clear as well as the documents themselves to be clear. This
tension means that attempts to publish the specifications which
have not been considered or selected by some working groups face
resistance that may derive from the need for a clear set, rather
than any inherent flaw in the ideas themselves.
The IETF has tried to assuage that tension by supplementary
marking, using the "standards track" and "Informational or
Experimental" as tags to indicate which documents do and do not
belong to the set. This effort has largely failed. It is blurred
partly by our own rules, which allow some IETF-produced or
set-relevant documents to use the same categories as those outside
the IETF set. It is also blurred by the ease of misunderstanding
the categories and the ease of elision of the supplementary
marking.
Further efforts to increase the supplementary marking, with "IESG
notes" and similar commentary take a great deal of time and increase
the tension between the two needs articulated above. There is also
no substantial indication that they are or will be more effective.
Eliminating these efforts and returning the others to primary markings
is both likely to be more effective and likely to increase the
freedom of the RFC editor to publish documents that, in its independent
judgement, should be part of the ongoing dialog on how to improve
the Internet.
1.11 Personalities.
The IETF community has consistently placed its trust in specific
individuals, trusting that they had the personal contacts, charisma,
or technical knowledge to resolve thorny problems. This trust is
a mistake.
It is not a mistake because the assessments of those individuals
are wrong; it is a mistake because it works around structural
problems with the effort and abilities of people who may not
always be available. To answer the question: "Should the reform
process be managed by the AD for the General area?" with "Sure, I
trust Harald to do the job." is confuse the personal abilities and
manner of the current person doing the job with the job itself.
To scale to a reasonable level, the IETF must be able to define
the work associated with specific roles. It can then recruit or
train people for those roles. Working the mechanism in reverse,
so that the individual's capacities are the primary gauge for
the scope of the job occupied, makes for serious succession problems.
1.12 Reform.
"If it ain't broke don't fix it" does not apply on a piecemeal
basis to complex systems.
In a reform process, ruling some items out of bounds for change
because they do not cause current pain is a mistake. If you
change any fundamental part of a system, you must consider whether
the other parts of a system need to be adjusted to handle new
load, tasks, or interactions. This does not mean that all change
must occur at once, but it does mean that the process of reform
must be open to change at all levels.
2. The Visions
2.1 New integration along traditional lines.
The author believes that the IETF has traditionally been
integrated in two different ways, one formal and one informal.
The formal integration relates to the steps of the standards
process and the precursor steps of working group formation and
chartering. The informal integration is an overlapping set of
personal relationships that allows participants to identify
skills, perspectives, or energy needed to complete the efforts
identified in the formal processes. During a period of rapid
growth and a follow-on period of contraction, the second system has
been strained to the point of failure. Though the IETF retains a
large pool of skilled professionals with energy and needed
perspectives, the overlap in personal networks is now not
sufficient to associate those with the efforts the IETF has taken
on. This has led to delay, lowered quality, and frustration, both
among those whose skills and perspectives are not appropriately
connected to salient efforts and among those whose efforts have
stalled for lack of energy or early input by those with relevant
expertise.
One path forward for the IETF is to retain much or all of its
current formal process, but take the traditionally informal lines
of integration and to increase its efforts to create and support
them. It may also have to shift some of those lines of
integration from the informal to the formal. The SIR proposal,
and especially its color-coded variant (SIRS), provides one
example of how the IETF might create a formal mechanism
(opportunity for early review by those outside an area) to replace
the informal mechanism of passing work back and forth among one's
colleagues.
Beyond that are a host of possible mechanisms. Having an
identifiable group of committed participants may create an esprit
de corps among those actively participating in a particular
working group that will carry on beyond the group's tasks.
Initial training sessions can create lines of contact both among a
cohort trained together and between those trained and the
trainers. That can be extended by fostering round table
discussions among participants from different groups, document
authors, and chairs. Cross-area and cross-working group
integration can be improved by setting up liaison roles.
Mentoring programs and peer review systems can be used to create
new lines of communication. The connection provided by
directorates can also be extended, both by having open-membership
directorates for some specific topics and by increasing the amount
of inter and intra-group communication expected.
None of the changes described above is a magic bullet, and none,
at first glance, creates much structural change in the IETF. Each
mechanism is, after all, an elaboration of something we already
do. It is, instead, a cultural change that suggests the real
strength of the IETF is that it brings together folks from
substantially different backgrounds who still share a common goal.
More importantly, it suggests that to retain that strength the
IETF needs to foster mechanisms that brings those folks together
early and often. It also presumes that with renewed strength in
this core area that the quality problems, delay, and frustration
can be addressed within the framework already established.
There is a long-held belief by some that the real work of any
organization gets done in hallways. For the IETF, the right
response to that may be to make sure that the networks of folks in
those hallways is vibrant, active, and just as open to new
membership and participation as its formal processes have always
been. That may mean moving some of those meetings out of the
hallway and into meeting rooms and mailing lists, but the
trade-off might be worth it.
2.2 Coordination as an alternate path.
The vision set out above presumes that the best result is an IETF
with approximately the same scope as it has now but an increased
effectiveness within that scope. More importantly, it presumes
that a tight integration among the different parts of the IETF
is of benefit to each of those parts.
One contrary view is that the right path may actually be to shift
to a model in which the different parts of the IETF are far more
loosely integrated than they are now. Under this view, the IETF
as a whole should become a coordinating body, which would create
and coordinate more focused organizations. To some extent, this
view recognizes that a great deal of the work of protocol
development and Internet engineering is done outside of the IETF
as it stands now, and that this is not likely to change. Rather
than attempting to change that fact, it suggests that the IETF
should evolve to be a coordinating body that can reconcile the
work both of its sub-organizations and those organizations outside
the current IETF which wish to be part of the larger framework.
It also answers the question of how to maintain informal personal
networks by suggesting that the natural size of an organization of
this type should be one in which the participants can or would
know each other personally.
Under such a system, the IETF would create individual
organizations for its areas or other suitable clusters of
activity, and it would then create a set of mechanisms to
coordinate the work in those activities. The individual
organizations might have working groups and directorates that
behave much as they do now, but the integration with other
organizations would be different. These mechanisms might include
liaisons, cross-cluster meetings and mailing lists, and periodic
review. That coordination could include organizations that have
historically been focused on specific applications of IETF
technology.
At the forefront of this vision of the IETF is the idea that the
field of protocol design and Internet engineering is very large
and getting larger, and that getting all of the work into a single
organization is unwieldy and unlikely. Rather than attempt it, it
suggests that the right answer is to create a group of smaller,
focused organizations that can take on specific roles. As a
coordinating body, the IETF's role would be both to charter new
organizations as needed and to coordinate them once chartered.
A critical part of that coordination would be ensuring that
work done in one organization is reviewed in other organizations
whose work would be effected.
To some extent, the IETF already holds this vision, since it does
not do all protocol design in a single working group or even a
single working group per area. Whether it wants to extend that
vision to clusters of working groups as a mechanism for scaling
may depend on how we balance the types of coordination. It would
also depend on the development of a host of subsidiary mechanisms
for coordination that we don't have now. Despite that dependence
on systems with no running code, there is an argument to be made
that this simply recognizes a reality--that groups spin off to
take on new tasks--and attempts to enable the IETF to retain a
coordination role after that has occurred. As the field expands,
this may well be one of the key ways that the IETF can help ensure
that engineering decisions take into account what's best for the
Internet as a whole.
3. The Belief.
The work is worth doing.
The IETF has no enforcement power. Every adherent to any standard
or engineering recommendation put forward by the IETF follows it
voluntarily. That makes clear that the work of the IETF is not to
manage the Internet, or even manage protocol development for the
Internet. The work of the IETF is to provide a community and set
of tools for those who want to see the Internet grow and develop;
nothing more. Nothing less.
That work is worth doing.
6. Security Considerations.
Any change to organizational structure creates risk that attackers
will be able to game the new system in ways they could not game the old.
7. IANA Considerations.
This document does contain any actions for IANA.
8. Normative References
None.
9. Non-Normative References
Mitton, D. et al. "Authentication, Authorization, and Accounting:
Protocol Evaluation",
RFC3127. (RFC3127)
Carpenter, B. et al. "Careful Additional Review of Documents (CARD) by
Senior IETF Reviewers (SIRS)" draft-carpenter-solution-sirs-01.txt
(SIRS)
10. Author's Address
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Suite 200
Campbell, CA
U.S.A.
EMail: hardie@qualcomm.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.