[rfc-i] RFC Editor Structure

[Olaf Kolkman]

[Dropping the independent list in order to keep the discussion  
constrained to one place]

What follows are some clarifications and answers to issues brought up  
during the discussion.

On Jun 4, 2008, at 3:59 PM, Frank Ellermann wrote:
> Olaf Kolkman wrote:
>
>> The proposed model is posted on the RFC interest list, see
>> http://mailman.rfc-editor.org/pipermail/rfc-interest/2008-May/000581.html
>> and made available through
>> http://www.iab.org/documents/resources/RFC-Editor-Model.html
>
> Thanks for info.  Some quick observations while looking at the
> picture of your model:  You don't cover the rather convoluted
> interactions between IESG and "ISS", to fix that please sort
> the "stream" columns like that:  IAB | IETF | community | IRTF.
>

Yes, the picture does take a high level view of the processes and  
production process.

But to clarify:
The convoluted interactions are documented in RFC4846, with cross  
reference to 3932, and thus well defined part of the existing review  
process. Nothing here that is going to change that. It is the ISS that  
in this model is responsible for following the process. Once the ISS  
is done a document with appropriate boilerplates pops out and the RFC  
production house takes over.


Frank also asked:
>
> What does "selected by the community and confirmed by the IAB"
> actually mean, is it the same idea as for area directors, i.e.
> NomCom representing a random set of volunteers from visitors of
> three out of five recent IETF meetings ?

That is one of the approaches, in the document we suggested an  
approach similar to that of RFC4333. There may be other approaches to  
selection of the ISS and the RFC Editor, and those selection processes  
may be different. Ideas, suggestions, and opinions are most welcome


Frank again:
> Why should there be two persons - new "ISS" and new RFC-editor -
> instead of one ?  In what way would a new "ISS" selected by the
> NomCom be really independent from IETF / IESG considerations,
> which is the whole point of this "independent" escape hatch as
> noted two years ago in the RFC 4844 discussions by John Klensin ?

The _intention_ is to recognize the independence of the stream and  
construct an appointment process that matches that. This intention is  
(attempted to be) captured in the profile of the ISS "Good standing in  
the technical community in and beyond the IETF".

The reason why there are two _functions_ in the model is because they  
are different in nature and responsibilities. The ISS being an  
experienced technical person that understands the content and  
organizes and manages the process for getting that content reviewed  
and takes responsibility for approval. The RFC Editor being with a  
focus on style, presentation, and series continuity.  It seemed  
natural to decouple to function description. But it is not said that  
the same person, or organization cannot fill both of these functions.  
In fact, observe that Brian Carpenter suggested coupling between the  
Editor and the Production function.





Frank continued:
>
> RFC number assignment should be the privilege of the RFC editor,
> not of some "outsourced" RFC production entity.  This used to be
> great magic in the past, and it is a completely subjective magic.
>

In an earlier version the RFC assignment lived with the editor. It was  
thought to be more pragmatic to move the magic to the production  
house, this seemed to be more in line with the current practice, as  
Bob Braden also argued in his June 4 reply.



And finally Frank remarked:
>
> Moving some "RFC publisher" functions to the IETF secretariat
> could make sense, if that is about maintaining a high traffic
> Web server with tricky forms.  But the quality of some IETF Web
> server forms is not yet up to the standard of some RFC editor
> forms.  Working Web forms can't be expensive, please don't try
> to fix it if it is not broken.


That is to some extend an implementation issue that should be  
decoupled from the long term perspective that we are trying to make  
with documenting this model.


Brian also had a number of queries:
> 1. What's the funding model for the "Independent Stream Supervisor"?
> That's not a job title that is very inspiring, and if it's a volunteer
> position, it would seem very unlikely to me that we'll find reliable
> and conscientious individuals willing to do it in the long term.
> I don't see it as comparable to an unpaid Editorship of an academic
> journal, for example, unless it is described in much more exciting
> language. But it also seems hard to justify as a funded service
> on its own. "Expenses to support the administrative operation of
> the Independent Stream Supervisor selected in this manner would
> be part of the IASA budget." Well, that is a very explicit extension
> of the scope of IASA beyond IETF activities. I'd want to see a
> consensus call on that.

Currently the funding is provided through the RFC-Editor contract that  
is in place with ISI, so de-facto this is already covered by the IASA  
budget. In fact all functions in the model are currently executed and  
funded by IASA.

Calling out the ISS as a separate function allows us to think about  
separate funding sources, although that also opens the question about  
the selection process.

Brian also remarked:
> 2. Also re the Independent Stream: "...no changes to the Editorial
> Board are being proposed." Let's discuss that. I don't like the
> current degree of secrecy around the way the EB reviews independent
> submissions. Especially if we end up spending IASA money explicitly
> for this stream, I'd like to see all EB reviews being made public.
> People who want to publish via confidential peer review have lots
> of other places to try.


Although maybe not completely orthogonal I think it would be good to  
have that discussion separate from this particular discussion. We  
converged on the independent approval process about 1-2 years ago and  
that cumulated in RFC 4846. What is important though is to assess if  
this model would prevent any changes to the approval process. I do not  
think it does.

Finally I observe that we have had no concrete feedback on the  
selection process by which the ISS and the RFC Editor should be  
selected. Would folk consent with a RFC 4333 type selection of those  
roles?



--Olaf


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080624/2b4aba4d/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
Url : http://mailman.rfc-editor.org/pipermail/rfc-interest/attachments/20080624/2b4aba4d/PGP.bin