Howdy,
Responses inline.
At 1:28 AM -0400 9/8/04, John C Klensin wrote:
Ted,
Let me try to briefly start from your assumptions and explain why one might reach the opposite conclusion. Before I go on, I'm assuming that your conclusion really implies "organization separate from ISOC" rather than "separate organization within some ISOC framework". There are scenarios for the latter with which I'd be perfectly comfortable.
For starters, I'm a fan (if that term can be applied to a relatively dismal approach to things) of risk and cost-benefit analyses in a "whole system" environment. If a magic wand could be found that would assure an instant and smooth transition from wherever we are today to whatever state we would like to end up in, while simultaneously holding Murphy's Law at bay, and, in particular...
* providing our volunteer leadership with both a lot of extra cycles without subtracting those cycles from the standards process, and
* providing that same leadership with executive management skills for which they were not selected and that, to be blunt, are not in evidence, and
If you mean by the two points above the "existing volunteer leadership", this is exactly contrary to the point of functional differentiation. I heartily agree that role of "manage the standards process" and "manage the public policy outreach" and "manage the site selection process" are very different skills. The point is to get different people into the roles, so they can do them well.
I think we both agree that doing this well is not the IESG's forte. I think we disagree in that I don't see it as ISOC's forte either, and I'm not sure why you do. You know the history of ISOC's finances, especially related to meeting management. Would not the IETF administrative entity or ISOC need to _hire_ the key people for this?
* guaranteeing that the IRS would instantly award tax-exempt status to the new entity, avoiding a prolonged period in which we needed to collect circa 1.75 times the amount of money we needed to operate (contrary to the usual 12-24 months or longer it takes to get that status if there are no hitches) and escrow the tax reserve, and
This point and the related points below on donors and credit ratings are very important, but they are also very short term in an organization with a 25 year history and aiming for permanence. Building the relationships around these problems is not good planning, in my personal opinion.
* guaranteeing that the corporations and organizations who have generously supported the IETF via ISOC would be immediately willing to support an untried new entity at double (or more) the funding level when their history of the last several years with ISOC has been to push back on funding requests until and unless ISOC and the IETF could get a model into place that was sustainable at a much lower level of donations, and
* guaranteeing that, with the same leadership steering the administrative entity that steers the standards process (there are other models, and I hope to be able to circulate a proof-of-concept strawman within the next few days, but all of Carl's scenarios basically assume that relationship as, more or less, RFC 3716 did) doesn't get us into difficulties with either tax status, perceived conflicts of interest, or control/capture by donors,
One: I personally assume that day to day management is done by someone else than those managing the standards process, because doing so otherwise is deeply, deeply broken. Two: an administrative entity whose only purpose is to "keep the chips up" in the felicitous phrase of Bernard Woolley is not one where capture has the same level of concern as it would if both the standards process and the administrative entity were united. In other words, keeping ISOC (with its existing role in the standards process) separate from the Administrative entity is a better hedge against capture than combining them would be.
* guaranteeing that we could actually (and quickly) find and hire an Administrator and supporting staff (while the proposal claims "one person" that actually isn't what it says), including sorting out benefits and status, etc., and that the Administrator and staff could quickly and smoothly get things up and running while resisting micromanagement from the volunteer leadership and/or the community, and
This is not an insurmountable problem in my eyes; it's a hiring decision. Basing a long term decision on its difficulty doesn't make sense to me.
* guaranteeing that hotel and meeting facilities would be willing to book facilities at more or less current deposit/ advance payment rates when the booking organization has _no_ credit rating (or that we could transfer that booking responsibility to another organization that would be willing to assume that level of risk on our behalf without additional compensation).
... and so on. That isn't the whole list, but it perhaps starts to make the point.
Now, if someone supplied that particular high-potency magic wand, then I'd probably agree that a separate structure would make things cleaner and more obvious (not necessarily better in the grand scheme of things, but at least reasonable). But, from a risk analysis standpoint, even the abbreviated list above is a pretty long list. If any one of those assumptions (or any of several of those not listed) is not met and things go seriously wrong, the odds of the standards process grinding to a complete halt -- think "no meetings", "no IESG phone calls", and/or "even less functional mailing lists and archives" as examples-- are non-trivial.
You are asking for a high-potency magic wand. In fact, what we are looking for is energy. The energy to get this done right can be found in our community; there are enough people who care about it to make sure it happens. There are nightmare scenarios here, and I am sorry if they trouble your nights. But there are nightmare scenarios in any transition here. The basic point remains: we need to make sure that people can focus on their real jobs. ISOC has a job in education, outreach, policy making, and standards. Adding "keeping the chips up" for critical computer systems, meeting planning, and the related support systems does not make sense. The jobs just aren't congruent enough to support the connection.
Again, just two cents from an IETF participant, regards, Ted Hardie
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf