[rfc-i] REOC membership

Glenn Kowack glenn at riveronce.com
Thu Jan 20 15:24:42 PST 2011


On Jan 19, 2011, at 6:38 PM, Bob Hinden wrote:

> Glenn,
> 
> On Jan 18, 2011, at 11:38 PM, Glenn Kowack wrote:
>> Recent discussions point toward the following specification of REOC (RFC Editor Oversight
>> Committee) membership.
> 
> I support having an oversight committee.
> 
>> Four background items:
>> 1) The IAB has been discussing constituting the REOC per their RFC Editor oversight role.
>> 2) Some IAB members have indicted they do not want the membership of the REOC
>> 	to be very tightly specified, if at all.
>> 3) Some participants in the rfc-interest list recommend that the membership of the REOC
>> 	be specified in RFC Editor Model (Version 2) and that a majority be representatives
>> 	of the Streams.
>> 4) The Overview originally mandated that REOC members be knowledgeable w/r/t technical
>> 	writing and publications and/or experience at using RFC Editor services as an author
>> 	or (draft) editor.
>> 
>> The gap (tightly defining REOC membership vs not defining it) may be bridged by providing
>> the IAB with broad guidelines for REOC membership.	By 'guidelines', I mean broad principles
>> and approaches that the IAB should follow if practical matters permit, and if superior
>> considerations do not conflict.
>> 
>> The IAB should follow these broad principles:
>> - REOC members must focus on the requirements of the Editor and how it can and should
>> 	serve the community.
>> - The REOC is an expertise and experience-oriented committee.  It should be guided by
>> 	professional expertise (in editorial and publications technique) expressed in line with
>> 	community opinion and interest.
> 
> Could you be clearer on what this means.  Does this mean that the people on the oversight committee should have IETF community publication experience or would any publishing experience be sufficient?

This is partially addressed by my point just below re "approximately 5-7 REOC members", 
where I aimed to make a case for "knowledge over politics."  While REOC members are 
knowledgeable about the specific requirements of the part of the IETF community they come 
from, they are to represent the interests of the broad community. They should not be narrow 
representatives of, e.g., individual streams.

> If this is to be an oversight committee, then it needs to provide balance from the IETF community, especially if the RSE is, as you are proposing, have more experience in publishing than in the IETF.  Otherwise, we don't really get much of an oversight committee.

Absolutely. Nearly all members should be from the IETF community.  An exception could be 
where the IAB knows of a highly-regarded expert in technical publications, or someone from 
the community long ago who has since done serious time in publications. These should never 
be more than a small minority of the REOC, or the "community oversight" standard would be 
broken.

>> I recommend the following approach toward appointing REOC members:
>> 
>> - The IAB should appoint approximately 5-7 REOC members, with a balance of:
>> 	- knowledge of and/or experience in editorial and publications matters,
>> 	- experience at being customers of RFC Editor services as authors, editors, and past members of
>> 		stream approver bodies, and
>> 	- experience as direct users of RFCs.
> 
> This is good, but I would like to see more of this in the earlier text.
> 
>> - The IAB should avoid appointing:
>> 	- current stream approver committee members, to allow focus and sufficient time to satisfy the
>> 		requirements of REOC membership, and
> 
> I don't see the need for this rule.  Your text says that it because they won't have enough time.  Anyone who is willing do the job will need to commit the time.

The REOC is not merely advisory; it's oversight of the Editor entails real exercise of authority. 
REOC decisions well might come into conflict with demands by a stream. The recommendation 
above is therefore necessary to avoid conflicts of interest. It would not be good for a large 
fraction of the REOC to frequently recuse themselves because they're on both sides of a 
controversy.  This point probably needs to be a hard rule, whereas most of the other points 
here are guidelines.

Regarding time: I was taking into account reports that many I* leaders are massively 
overworked and that many others have the similar knowledge of broad requirements through 
prior experience. I was thinking of enlarging the base of people involved, but really didn't make 
a strong case for it with my terse language.  I hear that the IETF is putting too much load on 
too few people, and that this is a reason it is so difficult to find candidates for some positions.

> I also think there is value in having a few people involved in the streams be on the oversight committee.  Even as far as having someone from every stream.

As long as 'involved' doesn't conflict with the point above.  Note that the Overview doesn't say 
much about voting structure, other than the possibility of there being a non-voting IASA liaison.  
In time, more distinctions between liaison and regular members might be made, and voting and 
non-voting status might be used

>> 	- standing members of the various other I* entities. Doing so is unnecessary and could make it
>> 		more difficult for members to focus on Editor issues.
> 
> Likewise, I don't see the need for this rule.  Please explain.

See above.

Bob - thanks for asking these questions.  I hope the added details are informative and even
compelling.

regards,
Glenn
___

> Thanks,
> Bob
> 
> 
>> - REOC member terms should be staggered 2-year appointments.
>> 
>> The above approach aims to find a balance between the community's need to ensure appropriate structure of the REOC with the IABs need to for flexibility in establishing oversight of the RFC Editor.
>> 
>> thank you,
>> -Glenn
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 



More information about the rfc-interest mailing list