Scott, Sam, and Glenn rightly pointed out last night that my comments
at the mic were
long on rant and short on substance. My apologies to the community for that.
I committed to provide more substantive comments; in order to meet the
time limits
Olaf noted, I have provided a first draft in plain text form
attached. If needed, I will
re-write as a draft when I have more time to wrestle with installing
xml2rfc on this
laptop.
I understand that Olaf would like follow-ups to rfc-interest, but since my
commitment to provide substantive comments was made in plenary, I
felt it best to cc them to the IETF list.
My thanks for your attention,
Ted
This document reviews draft-kowack-rfc-editor-model-v2-00.txt.
The document as written starts from a series of premises which have
sufficiently large fundamental issues that I do not believe it can
be the basis for a consensus call by the IAB on this topic.
In Section 1, the document describes the RFC Series in the
following way:
"The RFC Series is the Internet technical community's official
medium, through which it communicates with itself and the rest of
the world."
In addition to being needlessly grandiose, this statement is simply
wrong. Internet technical community members communicate among
themselves and to the world in a variety of ways, but the RFC
series has not been a primary mode of that communication for many
years. In the current model, it documents the outcomes of specific
process in the IETF, the IAB, the IRTF, as well as providing an
outlet for specific related documents identified by an independent
editor. If the bodies above have a document series by which they
communicate, it is the internet-draft series, which is fully open
and allows anyone to post a draft as a statement in any ongoing
conversation. Note, however, that the use of Internet Drafts is
largely restricted to statements recognized as under the IETF or
IRTF topic areas, and that wide swathes of the Internet technical
community use other modes entirely. In addition, the "Note Well"
statement and other boilerplate requirements restrict the
conversations using the internet-draft mechanism.
The draft goes on to propose a complete reorientation of the RSE
role put forward in RFC 5260 in a series of changes which it
blandly describes as "modest". Two paired statements make this
clear:
"the RSE role demands the expertise and experience of a senior
manager and subject matter expert in technical writing,
technical publishing, and technical series development."
and
"the overall leadership and management of RFC Editor functions
must be by the RFC Series Editor - the editorial and
publications subject matter and management expert.
However, this general leadership must be tempered by two
considerations.
o The Internet technical community has requirements, processes,
and traditions that must be followed by the RSE and across
the entire RFC Editor function"
As written, this declares the RFC Editor to be the lead of this
activity, with this general leadership merely "tempered by" the
processes and requirements of the streams which produce the actual
output.
Contrast this to the text in RFC 4844:
"The RFC Editor is an expert technical editor and series editor,
acting to support the mission of the RFC Series. As such, the
RFC Editor is the implementer handling the editorial management
of the RFC Series, in accordance with the defined processes. In
addition, the RFC Editor is expected to be the expert and prime
mover in discussions about policies for editing, publishing, and
archiving RFCs. "
The focus in RFC 4844 is support and implementation, with expertise
guiding discussion about editing, publishing, and archiving. This
document moves this to the general lead of this activity, a change
I cannot agree is modest.
The document states that this leadership would be "as it is
practiced in a typical not-for-profit organization" along with
specific community driven practices (seek input, foster volunteers,
supervise according to procedures). This is not the correct model
for a document series 90 per cent of whose output is standards
documents representing hard-won consensus. Those have to be led by
the communities producing the documents.
The document also describes a change to the RSAG model, which it
describes as "marginally expanded". In fact,the RSAG in this
document has a major change, buried in Appendix A, section 2.
Where the body of the document and RFC 5620 state that the RSAG is
not responsible for hiring the RSE, this gives the constituents of
the "search and selection committee", which includes 2 members of
the RSAG. This number is equivalent to the members provided by all
documentation streams (1 to IESG, and 1 split among all others).
Since the body of the document states that the RSAG is selected by
the RSE, this is a bit of problem. The current text is:
The RSE selects members for their experience and interest in the
RFC Series as well as in editing and publishing. Outside (non
community members) editorial and publishing experts may be
members, especially well-known leaders in technical writing and
publications. Outside experts must not be more than a minority
of full members. In particular, there is no requirement or
expectation that RSAG members will be IAB members. The Series
Editor proposes RSAG members in consultation with sitting RSAG
members; the IAB then confirms and formally appoints those
members.
This methodology, in which the role of the IAB is to formally
appoint rather than select and vet is, in fact, a major change; it
moves the RSAG from being an oversight body to being one which is
advisory only. The RSAG relationship has, in general, gotten
muddier, as has the overall reporting structure for the RSE, who
now appears to report to three bodies but to be fully responsible
to no one. Though the RSE provides reports to the IAB, the
contract is concluded with the IAOC and the result is that the
actual mechanism by which an RSE would be managed is unclear:
o report to the IAB for general matters and to the IAOC for RSE
contract requirements while following community direction.
This frankly seems to be deliberate, part of the document's effort
to support the RSE acting with very significant autonomy. Perhaps
the most telling aspect of the proposal that the RFC Series editor
be highly autonomous is this paired text:
"To return the RFC Editor to its historical level of independence,
this memo recommends creation of an RFC Editor stream."
and
"An unexpected consequence of the TRSE effort is that most of
the changes proposed for the updated model return the RFC Editor
to the style and perspective used during the first 40 years of
its life, although adapted to today's structure and operation of
the technical community."
First, I personally felt that the critical piece of independence
being maintained from our historical model was an independent
stream and an independent stream editor. In the plenary
discussion, it was made clear that the RFC Editor stream was seen
as important because it allowed the RFC Editor to publish documents
about the series without the review and approval of any of the
independent streams. That makes no sense to me. The RFC Editor
function reports to the IAB, which controls one of the streams; if
the RSE does not have the agreement of the IAB for a proposed
document, it does not have the level of community support that
should be present for publication in an archival series that
documents outcomes of our processes. I presume the RFC Editor
could still publish I-Ds to solicit that support, and that seems to
me personally enough.
The document further considers the RSE to have executive authority
over matters relating to "internal" issues of the overall RFC
editor function. In "Subjects for which discussion does not need
to occur", the document lists any issues where:
"the matter is strictly one of internal management within the RFC
Editor,"
Given that the RFC Editor function is split, an internal matter
might, in fact, be management related to the work of the
publication group; this is a seriously different model than where
we started with this.
To reiterate, I believe the IAB should decline the recommendations
in this report as the basis for a community consensus call. A much
simpler model in which the reporting structure is clearly from the
RSE to the IAB and in which the role is much more clearly
coordination among the streams is needed. This document arrogates
too much power to the RSE and to an RSAG not notably representative
of or responsible to the community in structure. It further
creates an executive authority where none is actually required.
In my view, previous incumbents in the RFC Editor position have had
significant moral authority because they did the day-to-day work
and understand a broad swath of the issues as a result. This
attempts to recreate that authority at the executive level,
presumably as a check on the authority of the bodies the running
the individual streams. I believe that this approach is
fundamentally flawed.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
