bad sentences, or bad grammar. There are of course limits to our
ability to repair bad writing; ultimately, quality depends upon
the authors as well as the editing process.
The only way to maintain quality is to continually monitor our
work internally, to track external complaints, and to adjust our
practice to correct frequent faults. Specific faults have
sometimes led us to create new tools for checking consistency, to
avoid clerical errors. Sometimes they have led to new user
guidelines (e.g., on abbreviations or on Abstract sections.)
3. Accessibility
An important part of the RFC Editor function is to provide a
database for locating relevant RFCs. This is actually a very hard
problem, because there is often a complex semantic web among RFCs
on a particular topic. We have made great improvements in our
search engine and web site, but there is undoubtedly a need for
more progress in this area. The challenge is to provide better
guideposts to users without creating a significant additional
manpower requirement.
We make heavy use of our own search and access tools, and this
gives us feedback on their success and sometimes suggests
improvements.
Finally, we offer some specific suggestions to answer the question,
"What can the IETF do to improve the RFC Editor’s evaluation" (i.e.,
our service to the community)?
1. Give us better documents to publish. Many are well written and
organized, but some are bad and a few are very bad and need a
great deal of work to create acceptable publications. Better
input documents will improve both our quantity and our quality.
The IESG has been making a large effort to improve the quality of
Internet Drafts before they become RFCs, and we are very grateful
for this.
One issue of particular concern is the increasing number of RFCs
authored by non-English speakers. These can consume much extra
editorial effort. We don’t know any solution to this problem, but
we know that the IESG is aware of it and working with them to
provide editorial assistance when necessary within working groups.
2. Prepare a series of RFCs containing "road maps" that describe the
semantic web of RFCs in a particular area. Although these would
rapidly become out-dated in detail, they would still provide very
important guides to RFC readers.
The RFC Editor is as self-critical as any organization could be, but
we believe there is no objective basis for claiming that we are not
doing a good job for the Internet. We continually strive to do a
better job.
*
* (4) How would you characterize the quality of your relationship
* with the IETF and its leadership? Is there mutual trust and a
* sense of working together on issues, or do you and your
* colleagues sometimes see the relationship as adversarial?
*
ANSWER:
The RFC Editor shares with much of the rest of the Internet community
a deep desire to advance the technology and practice of the Internet.
We consider ourselves partners with the IETF, the IESG, and the IAB
in this endeavor.
Although the major goals coincide, the IESG and the RFC Editor quite
properly have somewhat different priorities. The RFC Editor’s role,
historically and currently, is to create and maintain the RFC
document series as a high-quality and vital channel for technical
communication, while the IESG is concerned with managing the Internet
engineering and standards process. This difference sometimes leads
to honest disagreements, but we have generally worked out mutually-
satisfactory solutions to these conflicts.
The word "adversarial" seems completely inappropriate, and we are
struggling to understand what could have led to its appearance here.
* (5) Are there specific known problems you would like us to look
* at and understand? If so, please describe them.
ANSWER:
(A) The length of time for IESG review and recommendations on
individual submissions has sometimes become excessive. We
understand the load of IESG members, but we would like to ask
their help in keeping response to a few months.
The RFC Editor has been attempting to raise the bar on accepting
individual submissions, to avoid wasting valuable IESG time as
well as to maintain (or improve) the quality of the RFC series.
(B) We would like understanding and support of the RFC Editor’s
statutory and historic responsibility to publish significant
technical documents about networking that originate outside the
IETF standards process. This publication has several important
purposes.
One is to bring out new technical ideas for consideration and
discussion. We believe that the future success of the Internet
demands an infusion of new ideas (or old ideas revitalized), and
that the publication of such ideas as RFCs is important.
Another purpose is to build a shared literature of mature
technical discussion, to help avoid the periodic re-discussions
that take place on our mailing lists.
Finally, the RFC series provides a historic repository for
important ideas. We have come across a number of examples of
important suggestions and partial technology developments that
have been lost, or hard to locate, because they were not
published as RFCs. The community spends too much of our time
re-inventing many, many wheels.
Our ultimate goal is to publish more high-quality submissions, so
we can raise the bar for publication.
Independent submission publications represent only a minor
fraction of the RFC production. For example, so far in calendar
2003 we have published 178 RFCs, including 14 independent
submissions. If all the drafts that we think deserve to be
preserved as RFCs were to be published, this fraction would grow,
but we would not expect it to grow beyond 25% of the total number
of published RFCs.
(C) We would like to work with the IAB/IESG in re-examining the issue
of normative references. We believe that the current definition
of normative is ambiguous and unclear, and that as a result some
publications may be unnecessarily held up for normative
references where these are unnecessary.
(D) We would like to cooperate in an investigation of the issues in
extending the character set beyond US-ASCII, .e.g., to UTF-8. A
major issue is whether there is a set of preparation, display,
and searching tools for both the RFC Editor and the RFC
consumers. These tools need to be ubiquitously available and
mature enough.
The RFC Editor is looking for input on how we can best continue to
serve the community. We are grateful for the suggestions we have
received, and we have adopted as many of them as feasible; the result
has been quite a long list of incremental improvements in our service
over the past 5 years.
*
* (6) How do you see the costs of your function evolving? If
* things become more costly over time, what are the main
* determiners of cost (e.g., general inflation, general IETF
* growth, increase in the number of particular functions you are
* carried out to perform,...). Are you doing some things that
* IETF (IESG or otherwise) request that you do not consider
* cost-effective and, if so, what are they?
*
*
ANSWER:
The major cost factor is the number of documents submitted and
published. This has grown relatively slowly over time. It appears
to us that the IETF process has (perhaps fortunately) been the
bottleneck that has kept the rate of RFC production from growing
exponentially. We do not expect that to change dramatically.
In more detail, the cost factors are:
(a) Inflation (on salaries)
This shows a small and predictable annual increase.
(b) The number of RFCs published.
This is the primary cost factor. The bulk of the editorial
and coordinating functions are directly attributable to
specific documents. At present, we estimate that this cost
category represents 70% of our personnel time, and 63% of our
cost.
(c) Tasks not directly related to specific RFCs.
This includes many functions: management (budget and personnel
as well as policy and procedure development), IETF liaison,
reviews of independent submissions, development and
maintenance of web pages, scripts, and tools, the RFC Online
project, maintaining the Errata web page, etc. These are
currently estimated to require 30% of our personnel time, and
37% of our cost.
Minor extensions of function can be absorbed with little extra cost
(but at a leisurely pace). We are not proposing any major functional
extensions at this time; such extensions would have to be costed
separately (were money available for them.)
Disk storage and web services are provided by ISI’s support
organization and are treated as overhead. Most of the desktop
machines used by the project were originally bought under research
contracts, although the RFC Editor budget includes a very small item
for equipment upgrades.
APPENDIX -- FUNCTIONS OF RFC EDITOR
OVERVIEW
The RFC Editor edits and publishes the archival series of RFC
(originally "Request for Comment") documents. The RFCs form an
archival series of memos about computer communication and packet
switching networks that records the technical history of the ARPAnet
and the Internet, beginning in 1969. The RFC Editor is funded by the
Internet Society and operates under the general direction of the IAB
(Internet Architecture Board).
The RFC Editor publishes RFCs and a master index of the RFC series
electronically on the Internet, via all common access protocols
(currently, the Web, email, rsync, and FTP). It announces the
existence of each new RFC via electronic mail to one or more mailing
lists. The RFC Editor maintains a comprehensive web site with a
variety of tools and lists to locate and access RFCs. This website
also contains general information about RFC editorial policies,
publication queue status, errata, and any other information that will
make the RFC series more accessible and more useful.
During the RFC editing process, the RFC Editor strives for quality,
clarity, and consistency of style and format. Editorial guidelines
and procedures to achieve these ends are established by the RFC
Editor in consultation with the IAB and IESG (Internet Engineering
Steering Group). The RFC Editor periodically publishes a revision of
these its guidelines to authors.
The RFC Editor coordinates closely with the IESG to carry out the
Internet standards process as documented in the latest revision of
"The Internet Standards Process" and later amendments. The RFC
Editor also coordinates closely with the Internet Assigned Numbers
Authority (IANA), to ensure that the parameters used in new and
revised protocol descriptions are properly registered.
SPECIFIC TASKS
I. Editing and publishing RFCs
(1) Publication process. The RFC Editor edits and publishes RFCs in
accordance with RFC 2026 (or replacement documents) and RFC
2223bis. This includes the following tasks:
(a) Performing the final editing of the documents to maintain
consistency of style, editorial standards, and clarity.
At minimum, the RFC Editor:
(i) Copy-edits the documents, including the correction of
spelling and grammar, and some checking for
inconsistent notation. Ambiguous sentences are
resolved with the authors.
(ii) Enforces the formatting rules of Section 3 of RFC
2223bis
(iii) Ensures that sections follow guidelines and rules of
Section 4 of RFC 2223bis.
(iv) Verifies the consistency of references and citations,
and verifies contents of references to RFCs and I-Ds.
(v) Verifies that all normative dependencies have been
satisfied.
(vi) Verifies that guidelines from Section 2 of RFC 2223bis
are followed, with respect to: URLs, titles,
abbreviations, IANA Considerations, author lists, and
Requirement-Level words.
(vii) Typesets the documents in the standard RFC style.
(viii) Verifies the correctness of published MIBs and ABNF
fragments, using compilers.
(b) Providing authors with a review period of no less than 48
hours to approve the document.
(c) Publishing new RFCs online by installing them in the official
RFC archive, which is accessible via HTTP, FTP, and SMTP. The
RFC Editor also provides compressed aggregate files of subsets
of the complete RFC series, accessible via HTTP and FTP. PDF
facsimiles are also maintained for all .txt RFCs.
(d) Publicly announcing the availability of new RFCs via a mailing
list.
(e) Coordinating with the IANA for assignment of protocol
parameter values for RFCs in the submission queue.
(f) Coordinating closely with the IESG to ensure that the rules of
RFC 2026 (or replacement) are followed. RFC Editor personnel
attend IETF meetings. A designated RFC Editor person serves
as liaison to the IAB and IESG.
(2) Individual Submission Publication
The RFC Editor publishes technically competent and useful
documents that arise outside the IETF process, in accordance with
RFC 2026. The RFC Editor makes the final determination on the
publishability of such documents, with review by the IESG and
input from knowledgeable persons.
The RFC Editor reviews all such documents for acceptable editorial
quality and for content, and works with the authors when necessary
to raise the quality to an acceptable level.
(3) Online RFC meta-information
The RFC editor publishes the following status information via the
Web and FTP.
(a) A list of all RFCs currently published, including complete
bibliographic information and document status. This list is
published both in human and machine-readable (XML) forms.
(b) A document consisting of summaries of RFCs in each range of
100.
(c) A list of errors found in published RFCs.
(d) An "RFC Editor Queue" specifying the stage of every document
in the process of editing, review, and publication.
(e) An RFC Editor web site containing
(i) A search engine for RFCs.
(ii) Information on the RFC publication process.
(iii) Links to the above published items.
(4) Public Queries
Responding to, and when appropriate, redirecting, a wide range of
email queries received in the RFC Editor mailbox.
II. Improved Process and Infrastructure
When resources allow, the RFC Editor makes improvements to its
processes and to the RFC repository infrastructure. This includes
improvements and extensions to the set of scripts used by the RFC
Editor: (i) to maintain its databases and web pages, and (ii) to
increase the efficiency and quality of the editing process.
Changes in procedure are often suggested by IETF members as well as
by the IESG. Here are some examples of changes that are either in
process or have been suggested for possible action in the future.
(1) Publication process
(a) Accepting documents in XML encoding when there is an
accompanying tool that will produce nroff markup.
(b) Studying the feasibility of editing the XML form of
submitted documents, prior to producing the final nroff
and .txt versions.
(c) Adopting additional tools for verifying formal
specification languages used in RFCs in addition to MIBs,
PIBs, and ABNF.
(2) Database Accessibility and Quality
(d) Improving the usefulness of the Errata information
(i) Distinguish mere typographic errors from errors of
substance
(ii) Link errata to RFC index on web page.
(e) Providing Web-based "enhanced" views of RFCs, including:
(i) Links to other related RFCs and references.
(ii) Links to and from online errata pages.
(3) Maintaining an online repository of the corrected values of
MIBs that have been published in RFCs.
(4) Completing the RFC Online project, to bring online those early
RFCs that are available only in paper form.
Appendix D. Consultation with Foretec/CNRI: Secretariat and Meeting
Planning
Secretariat Responses to Questions from
IAB Advisory Committee
November 7, 2003
* (1) Your description of the function you are performing. Is that
* function, and its relationship to the IETF, adequately
* understood for working purposes, or is additional description
* required? If the latter, what would you suggest?
The Secretariat work is divided into four parts: Meeting Planning, WG
support, IESG support, and IETF Community support.
IETF meeting planning includes: identifying venues; negotiating
contracts; working closely with the WG chairs and the IESG to
schedule events and avoid conflicts; preparing the agendas for the WG
sessions; arranging for F&B and AV; handling registration; seeking
and signing up hosts; providing Internet access, a terminal room, and
a wireless network when a host is not available; providing on-site
support; and preparing the proceedings. Meeting planning also may
include organizing the IESG retreat.
WG support includes: maintaining and updating charters, milestones,
and other information for the 140+ WGs; tracking changes in chairs;
hosting and archiving the discussion mailing lists; and processing
requests to publish IDs as RFCs.
IESG support includes: providing all support required for IESG
teleconferences, which take place every two weeks and cover as many
as 20+ documents each (i.e., processing "Last Calls", preparing the
agenda and package, moderating the teleconference, preparing the
minutes, sending out approval announcements, and updating the
information in the ID Tracker); tracking the movement of I-Ds to
RFCs; interfacing with the RFC Editor; performing administrative
functions associated with WG creation, rechartering, and closing;
maintaining the internal IESG Web pages; sending miscellaneous
message to the IETF announcement list on behalf of the IESG, and
posting them to the Web site, where applicable (e.g., appeals to the
IESG and IESG responses to appeals); providing support to the NomCom,
as needed (i.e., sending announcements, hosting/updating the Web
site, arranging for conference calls); and developing Web-based tools
to support IESG decision-making.
IETF Community support includes: running the IETF meetings; hosting
the IETF Web site, and keeping the web site it up to date; hosting
the IETF announcement and discussion lists; responding to enquiries
sent to the IETF Secretariat, the Executive Director, the meeting
Registrar, the Webmaster, and the trouble-ticket systems; processing
Intellectual Property Rights Notices; processing Liaison Statements;
and posting I-Ds.
* (2) What staff is being used to perform these functions and
* what are their particular skills for doing so (either
* individually or in the aggregate)?
-- Three people perform administrative functions.
-- Four-and-a-half people perform technical support.
-- One-and-a-half people do development.
-- Three people do maintenance.
* (3) What criteria do you use to determine whether you are being
* successful, and how successful? Using those criteria, how
* successful are you and what could be done, especially from the
* IETF side, to improve that evaluation?
The continued efficient operation and evolution of the Internet is
one important goal and challenge facing the IETF, and also the IETF
Secretariat. Working together to assist the IETF in performing this
important function has been a motivating factor in CNRI’s support for
almost 15 years. The criteria followed by CNRI, and (more recently)
its subsidiary Foretec, in their efforts on behalf of the entire
Internet community is to provide a consistent and dependable
mechanism that enables those persons interested in the many and
varied issues that are raised within the IETF to perform their
important work in the Internet standards process unburdened by the
routine administrative tasks associated with such endeavors. While I
think this has been a successful activity over many years, there is
always room for improvement; and a continuing dialogue between CNRI,
ISOC, and the IETF leadership is useful for this purpose. High on my
list of suggestions would be finding a way to increase the funds
available to meet the increasing demands placed on the Secretariat.
We can no longer depend only on attendance fees at meetings for this
purpose.
* (4) How would you characterize the quality of your relationship
* with the IETF and its leadership? Is there mutual trust and a
* sense of working together on issues, or do you and your
* colleagues sometimes see the relationship as adversarial?
While the Foretec management may have issues arising from day to day
workflow demands on limited resources, CNRI values the trusted
relationship we have had with the IETF community. The issue is
cooperating in the development of new funding sources, and learning
to live within the available resources. There is also an issue about
effective lines of authority for the purpose of carrying out certain
aspects of the overall standards process. There are many demands and
pressures on the IESG and hence on the Secretariat. These workflow
demands need to be addressed in a more systematic way for the benefit
of all.
* (5) Are there specific known problems you would like us to look
* at and understand? If so, please describe them.
Workload is high. Given the budgetary constraints that the
Secretariat is under, there are no resources to take on additional
work. The staff supporting all areas are working overtime just to