[rfc-i] RFC Editor structure

Olaf Kolkman olaf at NLnetLabs.nl
Thu Sep 25 09:17:03 PDT 2008

John, and others.

I tend to write shorter and less eloquently than yourself but let me  
try to summarize your two perspectives.

I read the following high order bits in your feedback:

1. Separation of the RFC Editor function from the Independent stream  
Editor is a 'no go'. These functions are much to intertwined. And, one  
needs a forceful role to push back to the powers that be (the IESG  

2. The IAOC/IAB are not in the position to select  the Independent  
Stream Editor, the RFC Editor function, or the combined function; they  
lack the experience and the perspective. In the light of that we  
should be having an subject matter expert group to select those  

The reason why I want to see this high order bits stick out is because  
although I think I understand you argument I would like to know if it  
is supported by a consensus. As far as I can tell there is no strong  
consent with these two positions.

I think that there is at least consensus that both roles are supported  
by what is initially the current RFC Editorial board. I think that if  
we leave the wording sufficiently vague the RFC Editorial board can  
take up both roles or evolve. I would think that everybody agrees to  
not formalize the role of the RFC Editorial board to much. But in  
those discussions I have not read that the Independent Stream Editor  
and the RFC Editor function should be merged. What is clear is that  
they will need to communicate to each other structurally and the RFC  
Editorial board might create the necessary glue for that.

On point 2, the only point of view that I've seen is that the RFC  
Editorial board should take up the responsibility for selection. If  
that plan would have demonstrable support then it needs significant  
work. But I am not sure that we should create yet another formal body  
within the umbrella of IETF organizations.

At some point I, supported by the IAB will need to do a consensus  
call. My plan is to fix parts of the model in such a way that the IAOC  
can proceed with its work, working out the details on how the RFC  
Editorial Board works with and interfaces with the Independent Stream  
Editor and RFC Editor function can be ironed out. I would prefer to do  
that next Wednesday. Depending on how this thread develops.

I will now go off-line until Tuesday morning. :-(



On Sep 23, 2008, at 7:52 PM, John C Klensin wrote:

> Responding to comments from Brian and Ray from last week....
> I'm sorry to have been so slow about this, but substantially all
> of my time in the last couple of weeks has been taken up by a
> work emergency and I'm only now able to start digging out.
> Brian wrote...
>> My personal view at the moment is that the proposal put
>> forward by Olaf as a consensus candidate is more complicated
>> than necessary. I see nothing in the current model that will
>> cause difficulty in the processing and publication of the
>> variously approved streams defined in RFC 4844. There is a
>> tactical argument for separating out the Publisher function so
>> that it could, in theory, be jointly contracted with other IT
>> services such as I-D publication. But that doesn't justify the
>> separation of the nominal "RFC Editor" warm body as a separate
>> contractual entity. I'd roll that into the Production contract.
> Brian,
> We have fundamentally different perspectives on several aspects
> of this, including on the rather basic subject of whether RFC
> 4844 and RFC 4846 have worked well and, more generally, whether
> the community-based mechanisms for selecting people for tasks
> that require very specific skills have worked well.  I infer
> from your note and other recent comments that you believe that
> they have.  I believe that they have not, something I'll explain
> in more detail below.  To the extent to which one believes that
> the model described in those documents has not worked as
> expected, one can say "whether they worked as expected or not,
> the community agreed to them a year ago and we must proceed down
> the path they appear to set without looking sideways".  The
> other possibility is to consider whether 4844 and/or 4846 should
> be reconsidered and possibly modified or improved as part of any
> next steps in RFC Editor [re]organization.
> Because I believe that the first, "proceed down the path we set
> out on, no matter what", option involves the possibility that
> the next step may take us over a cliff, I believe that
> consideration of this organizational model also requires review
> of 4844 and 4846.  If we conclude that they still work for us,
> that is fine.  If not, we should be looking at the RFC Editor
> structure as an implementation case, working it out correctly,
> and then modifying the existing documents so that they match.
> That is, of course, exactly what we do with technical
> specifications.
> This is one of the fundamental sources of our disagreement.  You
> see completely separating these functions as an important
> objective.  I see it is nearly impossible in practice without
> loss of important functionality and perspective.  I also see the
> entire idea of designating two individuals and giving them the
> sole responsibility, while separating them from each other and
> the people who do the work as, at bst, fundamentally naive.
> On Tue, 16 Sep 2008 09:34:53 -0400, Ray Pelletier
> <rpelletier at isoc.org> wrote...
>> On Sep 15, 2008, at 6:00 PM, Brian E Carpenter wrote:
>>> On 2008-09-12 04:08, Bob Braden wrote:
>>>> SM wrote: *
>>>> *>
>>>> *> As in any structure, there is a need for accountability.
>>>> How   is the
>>>> *> Independent Streams Editor accountable to the community?
>>>> To   whom is
>>>> *> the RFC Editor accountable?
>>>> *>
>>>> The accountability and transparency of the Independent
>>>> Streams Editor function are spelled out in some detail in
>>>> RFC 4846.
>> ...
>> Question is how to pick the RFC Editor to sustain the RFC
>> Series.    Shall the IAOC do it by RFP and see what XYZ, ABC
>> and 123 Corp proffer   as the Editor, or should there be a
>> community based process by which   one is selected?
>> I don't know who the companies will propose every 2 - 3 years,
>> but I   have a high degree of confidence in a community based
>> process to   select from a significant number of highly
>> qualified individuals, and   do so time after time.
>> Ray
>> In community hat
> This is part of our second major disagreement.  Dave Crocker
> often points out (generalizing a bit and paraphrasing
> significantly) that  the community expects people who are
> deliberately selected without any consideration of how much
> experience they have with particular roles to then select others
> to perform those roles.  They don't have the background and
> perspective needed to evaluate the needed skills and attitudes
> and (at least he and I believe) they often do fairly poorly as a
> result.  His usual example involves randomly-selected Nomcom
> members picking the IESG and then expecting the IESG to show
> strong and effective management skills.  Probably we get lucky
> and end up with people who can manage in the IETF environment
> much more often than, given the process model, we deserve.
> However, we have an even worse and more risky example if we
> expect the IAB and/or IAOC, neither of whose membership are
> selected for a deep understanding of editorial matters or
> understanding of the special role of the RFC Editor (even if the
> Nomcom were required to have enough knowledge of those editorial
> roles to make it plausible that they could select an IAB or IAOC
> that did have the needed understanding and experience) to be
> able to competently pick single individuals to perform the roles
> called for in the draft.
> We also need to be careful what we wish for when we demand
> "openness", "accountability", and "transparency".  While all of
> them are good ideas in principle, we also need to optimize for
> expertise, we also need to optimize, IMO, for expertise and
> especially careful review and balanced discussion by those who
> actually have significant competence in the relevant issues.   I
> don't see that as being inconsistent with openness, but I am
> concerned about the flavors of openness that assume that anyone
> with an opinion ought to be a candidate for any position in
> which they might express interest and that bodies who have
> opinions are appropriate to make selections to bodies that
> require expertise.  If we need proof of where an excess of
> "everyone who can mouth off gets an equal vote" leads, all we
> need to do is look at the processes and careful decision-making
> of ICANN (another component that used to be closely connected to
> the RFC Editor role), activities that are of course based on
> deep understanding of the Internet.
>    john
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> http://mailman.rfc-editor.org/mailman/listinfo/rfc-interest

-------------- 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/20080925/1b261abd/PGP-0001.bin

More information about the rfc-interest mailing list