[rfc-i] a possible refinement to draft-iab-rfc-editor-model

SM sm at resistor.net
Sat Apr 18 03:31:42 PDT 2009


Hi John,
At 12:36 16-04-2009, John C Klensin wrote:
>Because I have a tendency to worry about what can go wrong and
>because I think the job of the initial RSE is going to be hard
>--perhaps very hard, depending on what some of the words in the
>SOW mean-- and very time-consuming, I think the community has to

This is unchartered territory.  It will up to the initial RSE to 
define the job while trying to keep everything running.

>         (iii) There are plausible people who would be willing to
>         be candidates for the RSE role, but only if they know
>         the "stipend"  or other compensation arrangements in
>         advance or understand the terms and conditions under
>         which such an arrangement might be negotiated.

If you want a person who can take on the initial RSE role, you have 
to talk about compensation instead of expecting them to step forward.

>Now, in any of those unfortunate --and, I hope, improbable--
>scenarios, we are going to need sources of significant and
>substantive advice.  Under some of them, providing that advice
>to the RSE should be fine.   Under others, that advice should go
>directly to the IAB, unmediated by the RSE.  And, under still
>others, it should involve a discussion with the IAB and IAOC
>about things that are not working well and need to be changed,
>unmediated by either the RSE or the IAD.  Logically, I can see
>only the following possibilities for that advice:
>
>         (i) Hire Bob Braden as a consultant, assuming that he is
>         not involved in the Production House bid.
>
>         (ii) Hire Alice and/or Sandy as consultants, assuming
>         that they are not involved in the Production House bid.
>
>         (iii) Hire Joyce Reynolds as a consultant, assuming that
>         she is not involved in the Production House bid.
>
>         (iv) Recruit a committee of experts to provide that
>         advice.
>
>I note that neither the "RFC Editor Model" document nor BCP 101
>seem to allow for any of the first three options, even if the
>community, IAB, or IAOC concluded that they were needed.

If the "RFC Editor Model" is an impediment, fix it.  You don't 
necessarily have to follow the BCP 101 route for any of the first 
three possibilities.

>With regard to the fourth option, there is only one organized
>group with the needed expertise and perspective, and that is the
>current Editorial Board (or whatever subset of them can be
>persuaded to do this).  The other possibility is to try to
>recruit such a group de novo, as some have proposed in various
>parts of this process.  The difficulties with doing so are that
>
>         * the IAOC has really left the community no time to
>         organize a recruiting process and
>         * trying to change contractors/editors and
>         organizational model at the same time is inherently and
>         severely risky, trying at the same time to create a new
>         body to carry forward institutional memory would, IMO,
>         border on the insane.
>
>and, if you want the Editorial Board to do this, I think logic
>dictates that you don't want to start replacing that group via
>an untested (and, indeed, still undesigned) procedure until
>there is reasonable confidence that the new RFC Editor structure
>and interrelationships are stable ... or until it is clear that,
>whatever the issues are, the Editorial Board is not helpful in
>resolving them.  Longer-term, I agree with Olaf's observations
>about institutional memory and consistency, especially if people
>assume that we are unlikely to ever again have only two RFC
>[Series] Editors in a forty year period.  Anyone who believes
>that the cutoff date between a temporary and transitional
>arrangement and that longer-term one can be set arbitrarily at
>six months or some other predetermined short interval has, IMO,
>either never been involved in a project that slipped longer than
>expected or never learned anything from it.

I think that most of us would not dispute that the Editorial Board is 
better placed to oversee the new RFC Editor structure.  If it is 
decided that the Board should do that, it is better to keep the 
Editorial Board as it is.  Replacing the group entails giving the new 
people time to fit in and match the pace.  This is not the time for 
experimenting if one is serious about institutional memory and consistency.

Having two RFC Editors over the last forty years turned the RFC 
Editor into an institution.  It was more about the job fitting the 
person instead of the reverse.  We have been discussing about "the 
model" as the succession.  What we have on the table is an unproven 
model that comes without any transition considerations.  For the (RFC 
Editor) changes to be manageable, the focus should also be on the 
arrangements necessary for a smooth transition.  You have outlined 
the worse case scenarios.

It is premature to determine how long the transition should be.  We 
should however bear in mind that a transition is not a substitute for 
the permanent solution.  That's something that can be addressed by a 
charter without hard coding cut-off dates.

>Now, if we can agree that the above describes, more or less,
>what we are trying to accomplish, then I really don't think it

We also need some "insurance" (don't read the word literally).  It's 
safer to pick one of the first three possibilities and the fourth possibility.

>* "decided".  I can find nothing in BCP 101 that authorizes the
>IAOC to "decide" on the Statements of Work to be used in
>contractual processes.   Even if the community had seen those
>SOWs before in the context of preparations for an RFI, it
>appears to me that BCP 101 (and certainly the discussions that
>led up to it and the discussions during the Minneapolis plenary)
>make it clear that the community is expected to be consulted
>again.  When the SOWs are actually modified by the IAOC, without
>any community consultation prior to their being decided upon and
>announced, that appears to me to be a fairly clear violation of
>at least the intent of the processes.  To reprise that plenary
>discussion as well as the pre-BCP 101 ones, the IAOC conducts
>bidding processes, determines successful bidders, and negotiates
>contracts and, for obvious business reasons, is likely to need
>to keep those stages confidential.  But the documents on which
>bids are requested, job descriptions and statements of work,
>etc., are all expected to be exposed for community review and
>comment _before_ decisions are made that lead into the
>confidential parts of the process.
>
>I have been deliberating as to whether to turn this into a
>formal appeal but have been reluctant to do so because of
>concern that the time it would take would lower the odds of
>having a functional RFC Editor on January 1 (or would be used as
>an excuse if the existing process does not lead to one).  But I
>believe that the process that has been followed here should be
>of great concern to the community, at least unless the community
>is far more comfortable than appeared to be the case during the
>1995 discussions, with an IAOC that works in silence and is, in
>practice, accountable only to its membership.

The IAB and IAOC (the body and not the individual members) suffer 
from a communication disconnect.  Thrice a year, they leave the 
monastery to face the peasants.  Fortunately for them, the peasants, 
on the whole, have been a passive bunch.

If I recall the plenary discussions correctly, it was mentioned that 
there would be further consultation with the community.  That has not 
happened up to now.  There may be good reasons for that but it 
doesn't change the fact that it is a cause of concern.  There's 
still, albeit not a lot of time for the IAOC to break the silence.

Trust is something that must be earned.  If the IAB would like the 
community to trust it to do "the right thing", it should strive to be 
more open.  There is a danger to that but that's the only way to 
ensure accountability.

Regards,
-sm 



More information about the rfc-interest mailing list