[rfc-i] Fwd: Alternate Proposal for RFC series management

Glenn Kowack glenn at riveronce.com
Mon Jan 10 08:09:52 PST 2011


Paul, (et al),
 Thanks for putting this together.  It's a good vehicle for revealing design choices.
In that spirit, I have tried to link all my comments to well-understood principles or
input heard from the community.  In your replies, it would be helpful if you could
similarly reveal the bases for your positions.  I start with the primary concerns
about your alternative proposal:

1) A major reason for having an oversight committee (with an "advised and consent
model") was to support the RSE without suffering the problem of having a committee
attempt daily, hands-on, direct management of a critical service.  By making the
REOC (your RSOC) a management committee, you re-introduce this problem. (See
Joel Halpern's recent comment on committee think.)  And, a small detail, but another
source of confusion: the name RSOC is fundamentally misleading; you describe a
management committee, not an oversight committee.

2) Under the Recommendations, the RSE is the one person responsible for making
sense of the Editor and the Series as a whole and has no other conflicting interests.
This makes it clear to the community who they can unambiguously point to (the RSE)
if the RFC Editor or Series are going in the wrong direction.  You undo that.

3) The IAB's chartered responsibilities include the approval of the appointment of the
RFC editor and approval of the general policies to be followed by the RFC Editor.
"providing direction" to the RSE, or to the RSOC as you suggest, would be a
significant increase in the work load on the IAB.  One of the important goals of the
proposal on the table is to reduce the work load this function places on the IAB, not
increase it. It is also worth noting that if the IAB were responsible for providing such
direction, the IAB would have to be the party responsible for judging gathering and
judging community input about the RFC Series. While the IAB is ultimately
responsible for that, avoiding needing them to directly do that seems a good thing.

4) The TRSE Recommendations continue 5620's division of work between the
Production Center and the RSE, under which the RSE does not perform regular
editorial work.  When you overlap responsibilities you create confusion.  It would be
redundant and confusing for the RSE to be a technical editor, and would destroy
today's clear division of responsibilities and direction. You reverse that. I earlier
stated that I have seen no need for the RSE to be involved in regular production.
 They might edit a document now and then for quality-monitoring purposes, but
that's all.

5) In one of your alternatives, you would have the REOC select winners of bids. On
first principles, this is a bad idea.  The RSE and REOC should limit themselves to
their specific 'technical' expertise as it relates to editing, publishing, etc.  They
should, for example, lead the discussion with the community in putting together
SOWs for new bids, while the IAOC should continue they authority for contracts,
legal, and financial matters.  Your proposed alternative interferes unnecessarily and
inappropriately with the IAOCs responsibilities as defined in BCP 101.

Detailed points follow.

Begin forwarded message:
> From: Paul Hoffman <paul.hoffman at vpnc.org>
> Date: January 7, 2011 10:29:49 AM EST
> To: rfc-interest <rfc-interest at rfc-editor.org>, Internet Architecture Board <iab at iab.org>
> Subject: [rfc-i] Alternate Proposal for RFC series management
> 
> Greetings again. Andrew's questions about executive-level management helped me clarify some of my thoughts on why I prefer that management to be in the REOC instead of the RSE. Basically, even after reading Glenn's motivations document, we haven't seen any strong need to add the large amount of individual management that he has proposed so far.

This is a surprising comment since several of the elements below actually increase
the managerial 'weight' of the RSE's job, which is both inappropriate and not
motivated by work requirements.  More details below.

> Given that, I have an alternate proposal, given as changes to RFC 5620. Even if only some pieces of this are adopted, I hope it helps move the discussion forwards. Comments and criticisms are welcome.

> 
> --Paul Hoffman
> 
> New body: RFC Series Oversight Committee (RSOC)
> Responsible for overall series management and stability
> Creates policy for the RFC series

There is long-held understanding that committees are ineffective at leadership (see
Joel Halpern's response) but are excellent at oversight.   It also makes the position
less attractive to the calibre of person required to do the job well.

> Six members
> One representative from each stream
> Two selected by Nomcom with staggered terms

I believe we can leave these details up to the IAB.  Furthermore, others have
pointed out that adding to the load of the already overburdened Nomcom is
problematic.

> Gives significant input to IAOC on selection of RFC series contractors

This is ambiguous, but otherwise not bad.  See my point above re SOW preparation.

> Appeals of RSOC decisions go to the IAB

This is consistent with the IAB maintaining its chartered responsibility.

> Takes input from the IAB on overall direction of RFC series

I understand the IAB wishes to and should morse properly be in a position of
ensuring proper processes rather than providing direction.  This also flies in the face
of the RSE and REOC (or RSOC) working with the community to determine policy
(hence direction). It also threatens confounding the RSE reporting to the REOC.

> New person: RFC Series Administrator (RSA)
> Replaces the RFC 5620 "RSE"
> Contractor who reports to RSOC
> Takes direction from RSOC on new initiatives

Ditto above: this loses the power of the RSOC's "advise and consent" model (per
Brian Carpenter)

> Primary jobs of the RSA:
> Acts as public face on RFC series
> Leads discussions of proposed policy changes
>   Reports results to RSOC for decision
> Edits RFC series documents
>   Style guide and production process guide
>   Explanations of the RFC series (new)

"Edits RFC Series Documents" is problematic, per above.  I have not observed a 
requirement for this activity, and it could create unnecessary confusion, and 
interference with RPC Staff.

> Makes rfc-editor.org web site more useful to different audiences
> Handles errata system
> Creates monthly public reports on Production Center and Publisher

This appears to get in the way of already successfully delegated functions provided 
by the RPC. The RSE should own the requirements and have the RPC do the vast 
majority of specified reporting.

> Performs sampled reviews of Production Center processing of drafts
> Mediates disputes between streams
>   Reports on dispute and results to RSOC and public
> Mediates disputes between authors and Production Center
>   Reports on dispute and results to RSOC and public
> Expected workload is 15 hours/week

Probably just a bit short; 20 hrs/wk (50% FTE) is minimum.

> RSAG becomes advisors to both RSOC and RSA

This takes away the RSE's unique stable of advisors, which he will need and create 
anyway.

> Alternative: RSOC does bidding and selection of RFC series contractors
> Would first require buy-in from ISOC
> Would then also require change to BCP 101

Per above, this provision is neither necessary nor wise, and goes far beyond the 
TRSE recommendations.  The RSE should focus on SOW content and evaluation of 
technical (as in tech writing) competence of applicants while the IAOC continues its 
responsibilities for contractual, legal, and financial.

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