[rfc-i] RFC Editor structure

Brian E Carpenter brian.e.carpenter at gmail.com
Wed Sep 24 15:43:30 PDT 2008


John,

I held off for 24 hours in case others wanted to chime in, but here
goes.

On 2008-09-24 05:52, 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 

Well, I really think it's too soon to tell, as has been remarked
of the French Revolution. I think we'll need several years to know,
so my unstated assumption was that we're collectively trying to
make them work, which amounts to needing to treat them as axioms
for the time being.

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

Put it this way: they seem to me to meet the Churchill criterion
("the worst form of government we know of except for all the others").
I'll leave Ray to comment in detail on your response to him.

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

Certainly they are not stone tablets.

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

Agreed. In fact, I thought that's where 4844 and 4846 came from,
in many respects.

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

Yes, I agree that we disagree on that. I really don't see the
close binding between the quality of the content of independent
submissions and the consistency, production and presentation
of the series as a whole.

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

Well, I've developed the view that, given the consensus to retain
independent submissions (and you know there were those who simply
wanted to abolish them), we should really emphasise the integrity
of that independence. To me, that means complete editorial
independence.

It's certainly true that the RFC Editor executes a very important
function once an RFC has been approved for any of the streams,
which I think we agree is significantly more than copy-editing.
But I believe that as a matter of principle, that should be
decoupled from the individual streams, including the independent
stream.

  Brian

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


More information about the rfc-interest mailing list