[rfc-i] Role of the Editorial Board (was: Re: RFC Editor structure)

[John C Klensni]

Olaf,

I trust Bob will respond to this question and, in particular,
discuss his view of questions and issues on which the Ed Board
has been consulted, but I want to initiate the answering process
by identifying some areas in which the IAB is presumably already
quite aware of the Editorial Board's involvement...

--On Friday, 19 Sep 2008 17:01:08 +0200, Olaf Kolkman
<olaf at NLnetLabs.nl> wrote...

> Maybe you could  loosely describe whether there is any advice
> that the   Editorial board gives nowadays that are related to
> the   responsibilities that we identify for the RFC Editor
> function?
> 
> For reference, these were those functions:
> 	? Identifying appropriate steps for RFC Series continuity
> 	? Participate in IAOC reviews of the RFC Publisher and RFC
> Publication functions to ensure the above mentioned continuity
> 	? RFC Style Manual publication for use by authors, editors,
> and the   RFC publisher
> 	? RFC errata process management
> 	? Liaison with the IAB
> [end question]

The IAB is presumably aware of the following (at least):

	(1) While the impetus for the ISSN work came from
	elsewhere in the community, the specific proposal
	received significant review of the plans by other Ed
	Board members.  
	
	(2) The document that evolved into RFC 4846 was largely
	an Ed Board project.  I held the pen up until the time
	that the IAB took over, but the document would have been
	significantly worse without contributions from other
	members as well as RFC Editor staff.  And, as you,
	Leslie, and Dave (at least) are aware, there were very
	few substantive changes in the document after the
	handoff -- most of the changes were simply to harmonize
	with the style and assumptions of what became RFC 4844.
	
	(3) The recent proposal for image file components of
	RFCs was another Ed Board project.

Note that other things, about which I hope Bob will comment,
worked the other way -- the RFC Editor generated the ideas and
proposals and sought advice or review from the Editorial Board.

Speaking for myself only, I find three things interesting about
this list.   

	(i) In each case, much of the impetus came from Ed Board
	members.  So it is debatable whether the Ed Board
	members were providing [solicited] advice to the RFC
	Editor or initiating activities or proposals and taking
	the lead in putting them together, with the RFC Editor
	working closely with us.   The number of things on which
	the normal "RFC Editor asks for advice, we give it" is,
	of course, much larger.  I hope Bob will comment on the
	subset of those areas and topics that are not narrowly
	document review.
	
	(ii) While I would classify the first of these as
	vaguely "series utility and availability" if not
	strictly "integrity", the others are not, and I have no
	idea where they would fit in the model provided by the
	document.
	
	(iii) Those three examples are part of what I've tried
	to explain before, obviously unsuccessfully.  I think
	the community in general, and the IAB in particular, are
	underestimating the role of the RFC Editor function
	(including whatever advisors exist in the process -- and
	there has _always_ been an advisory function, however
	informal it may have been a decade or two ago) as a
	participating, and sometimes activity-initiating, part
	of the community, rather than simply a receiver of
	documents from "streams" and a publisher of those
	documents.

Except in a very limited way --almost by side-effect-- RFC 4844
did not discuss those non-publication functions.  That was
probably appropriate given that its focus was the definition and
management of documentation streams.  Its Section 3.1 is a
description of the RFC Editor function _with respect to the
types of tasks the document discusses_.   It is no more a
"charter for the RFC Editor" or "complete description of the RFC
Editor function" (or task) than Section 3.2 is a complete
description of the IAB.  I note that 4844 doesn't even claim to
update RFC 2850.

Many of us understood the limited nature of the Section 3.1
description when that document was being prepared.   I have
assumed that the IAB did too, but maybe I was wrong.

But now, not very long after 4844 and 4846 were published, we've
got an organizational proposal that appears to assume that
anything not listed in 4844 is entirely out of scope for the RFC
Editor function or any of its components.  Given how things are
structured in 4844 and elsewhere, I think that is ok if the IAB
is willing and able to take an active role in the strategic
parts of the "RFC Editor" process, not just a role as reviewer
of proposals, but one of taking leadership in initiating and
shaping ideas for the evolution of the series.  Of course, if
the IAB were going to add that responsibility to the other
things on its plate, I hope the community would expect IAB
members would acquire, or be selected for, the level of
experience with publications --including editorial and editorial
board experience with other publications, management of document
streams and series, etc.-- that characterizes the present
Editorial Board (as well as reflecting the very broad technical
perspective and cross-area experience that 
the IAB is expected to have anyway).  I will address that issue
in somewhat more detail in a different note I'm working on.

best,
    john