[rfc-i] Requested follow-up from last night's plenary

SM sm at resistor.net
Mon Nov 8 16:09:53 PST 2010

At 13:29 08-11-10, Ted Hardie wrote:
>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

According to RFC 4844:

   "The RFC Series is the archival series dedicated to documenting
    Internet technical specifications, including general contributions
    from the Internet research and engineering community as well as
    standards documents."

The RFC Series currently has four streams.  These streams has 
different characteristics.  The only uniformity is the format of RFCs.

>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

RFCs in the IETF Stream generally document the consensus as defined 
in the IETF Standards Process.  There are RFCs from the IRTF Stream 
covering Internet Research and an IAB Stream.  The process vary and 
there are different communities involved.

I would not describe the Independent Stream as "an outlet for 
specific documents identified by the ISE" as, from what I gathered, 
that stream was not supposed to be turned into a barrier to 
publication.  The stream might work along these lines:

   "The RFC Editor [ISE] is expected to consider all competent reviews
    carefully, and in the absence of some unusual circumstance, a
    preponderance of favorable reviews should lead to publication."

>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
>    "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."
>     "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
>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


There are differences between RFC 4844 and RFC 5620.  And there is 
also the reality on the ground.  The community could decide on what 
it wants and provide the tools to get the work done.  It should also 
take into consideration that there is a cost to it.

>The document also describes a change to the RSAG model, which it
>describes as "marginally expanded".  In fact,the RSAG in this

 From RFC 5620:

   "The RSAG is chartered by the IAB.  As such, it operates independently
    of the IAB to fulfill that charter, and provides periodic reports to
    the IAB via the RSE."

I did not discuss about this for the initial version of the RFC 
Editor as there was an upcoming transition.  Now that the transition 
is over, it is high time that the discussion is open again.

 From RFC 5620:

   "The RSAG members are proposed by the Series Editor in consultation
    with the sitting RSAG members, and then confirmed and formally
    appointed by the IAB."

That sounds like a gentlmen's club.  I don't have any issue with the 
experience or commitment of the members of the RSAG.  I appreciate 
their contributions to the RFC Editor Function.

If the RSE wants to keep the RSAG in that form, I am fine with that 
as long as it operate in a purely advisory capacity.  If the RSAG 
acts as an insular layer between the RSE and the Internet community 
or other bodies, it becomes the problem of the RSE.

>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:

If it is the opinion of the IAB that it is "to ensure that the RFC 
Series mission is being appropriately fulfilled", it should take 
responsibility for the hiring of the RSE.  If the IAB wants to 
delegate that to some committee, it is the its business.  An advisory 
group is not there to hire or manage people.  Its role is to advise.

>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

There are too many bodies in the mix (IAB, RSAG, IASA).  The 
reporting lines are unclear.  This is a recipe for organizational issues.

>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."

I already commented on the creation of that stream.

>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.


>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.

It is difficult to get a picture of what the problems were and as I 
said previously, I have to defer to the TSRE on this.  The lack of 
questions is partly because the TSRE is on contract and if there is 
there a problem, it should be taken to the body responsible for that position.


More information about the rfc-interest mailing list