[rfc-i] "Executive-level management": What is the purpose of the RSE?
dhc at dcrocker.net
Mon Jan 10 12:08:16 PST 2011
On 1/10/2011 5:25 AM, Andrew Sullivan wrote:
> In city government, there are (broadly) two models: the "strong mayor"
> model; and the "weak mayor" or "city manager" model. Similarly, in
> this case, I think there are really two possibilities: we can have one
> person who has several responsibilities and quite a lot of control; or
> else we can have those responsibilities divided up among many people,
In reality, both of the models you cite put primary responsibilities into a
single person's hands. With strong mayor, it's the elected mayor who might or
might not have the relevant skills.
The council/manager model has the city council select the city's lead,
professional manager who holds those responsibilities. Council/manager models
tend (or always) still have a mayor, but it has few responsibilities and is
largely a ceremonial or "bully pulpit" role.
The real-world council/manager model actually parallels quite well with what
Glenn has proposed. The council/manager model emerged for city operations from
a desire to move the management of city services onto a more professional, and
less politicized, footing.
A very good description is:
"The Mayor and Council is the legislative body"
"The manager prepares a budget for the Mayor and Council's consideration;
recruits, hires, and supervises the government's staff; serves as the Mayor and
Council's chief adviser; and carries out the Mayor and Council's policies"
Small caveat: We need to be careful to review all of the FAQ entries and not
cherry-pick ones that support a particular view, out of context...
The Wikipedia entry looks pretty reasonable, too:
Note the reference to the city manager's being equivalent to a CEO...
> with someone doing the work of a kind of senior special advisor to the
> community, and all the control vested in the community.
In the real world, neither management model reflects this arrangement.
Reference to a city manager's being advisor is true only within the context of a
longer list of duties that happen to include more responsibility and authority.
> This is why I argue we have a stark choice. These models are very
> different. They involve different costs and benefits.
Folks should try to provide and consider the accompanying details carefully,
rather than merely rely on an assertion of conceptual preference.
Ted did some of this for one preference, suggesting that the RSE edit documents,
and that nicely uncovers a conflict with the Production Center's
responsibilities, for example.
> For instance,
> your recommendations have a significant cost, as near as I can tell,
> because they seem to suggest some changes to BCP 101 are needed: if
> the RSE has some important level of control over people doing RFC
> production, then that must have some effect on contracts.
By my reading of the relevant documents, probably not.
Delegation of authority to the RSE does not necessarily require changes to the
BCP or contracts. Again, folks thinking otherwise should cite specifics.
> I like Olaf's suggestion elsewhere in this thread that there are
> distinct pieces that can be teased apart and then reasoned about
> I get that. What I am arguing is that there is in fact another way to
> do this, which is to break the "leadership" and "authority and
> responsibility" components apart.
The benefit of teasing things out can be clarity. The danger is in thinking
that the ability to list and discuss things separately means that there is no
requirement to embody their performance in a single person who integrates
things. Piecemeal, uncoordinated, incomplete coverage is the potential downside
When folks propose an alternative model, they need to provide a very clear basis
for believing it will work. Examples of similar operational environments would
be particularly helpful.
> Moreover, the present isn't like the past anyway. The broader IETF
> itself has changed dramatically over the period in question, and one
> can fairly ask whether, when the facts change, one ought to change
> one's opinion.
Correct. It's a justification for starting to ask some questions. However we
need to be careful that it is not, instead, used as a justification for making
particular changes to the model. Justification needs to be based on pragmatic
differences and needs.
Consequently, the fact that this sort of 'fact' is still in play at this very,
very late stage ought to strike us all as problematic.
In addition, the exploration needs to look at existing and historical problems,
not just broad conceptual preferences that are postulated to be easier, cheaper,
simpler or the like, but lack detail or experience.
The RFC Editor is a critical production service that produces 30 documents a
month. This is a dramatically different operation than a multi-year IETF
working group or thrice-annual IETF meeting planning.
There are well-established and well-understood organizational structures for
critical infrastructure services. If we adopt something that differs from those
structures, we are venturing into terra incognito. Sometimes experimentation is
great, but it's difficult to understand how this is one of those.
> "Motivations" says that production and day to day operation seem to
> chug along mostly just fine on their own. Therefore, I am not sure
> why the production-oriented nature is evidence in favour of an active
> and strong leader with a lot of independent authority.
This logic seems to be in line with the "fire everyone who works for the
government and is not at their job between Christmas and New Years" model.
When everyone is lucky, critical infrastructure services hum along nicely.
That is almost never a steady-state reality. Stuff happens and it tends to
happen frequently. Resolving that stuff entails a very different skillset from
what is needed to do the daily grind.
It seems to me
> that the stability of regular production could be construed as
> evidence that the direction and policy for the RSE could indeed come
> from a board or committee or something.
Only if one ignores what has not been getting done or has not been getting done
On 1/7/2011 2:29 PM, Bob Hinden wrote:
> On Jan 7, 2011, at 7:29 AM, Paul Hoffman wrote:
> I like the idea of RSOC being responsible for policy and the RSE (name TBD,
> the paid employee/contractor) implementing the policies. Much like the rest
> of the IETF.
The danger is in confusing the effort to define and promote policy with the
authority to approve policy. Committees aren't so good at the former, but quite
reasonable for the latter.
> I think there would also be value if someone from the IAOC served on the
> RSOC. My thinking is that this approach worked well for the IAOC. The IETF
> chair, IAB chair, and ISOC president are voting members on the IAOC. It
> helps to add the right perspective to the discussions. Given the desired
> coordination with the IAOC, having someone from the IAOC makes sense to me.
The more inclusive a group is, the less focus it is likely to have. It also
invites potential conflicts of interest, to the extent that an 'oversight' group
contains members who are supposed to be overseen.
There is also the very basic danger of confusing operations coordination with
More information about the rfc-interest