[rfc-i] Role of the Editorial Board

Brian E Carpenter brian.e.carpenter at gmail.com
Sat Sep 20 19:01:17 PDT 2008

Hi John,

A little bit of revisionism on my part, after reading your helpful comments

I see two roles here - a general Advisory Board role for the RFC series
as a whole, and a very specific Editorial Board role for the independent
submissions stream. The former is very specific to the nature of RFCs, and
the latter is closely analagous to the Editorial Board of an academic
journal, or the Program Committee of an academic conference.

I think both of these roles are valuable, and they might even be filled
by the same people. But they are separate roles, and the proposal as
circulated by Olaf seems to mix them up, which I think is what was
bothering me.


On 2008-09-20 10:40, John C Klensni wrote:
> 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
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list