Hi,
In general I agree with the document and the analysis.
Follow my inputs regarding my personal experience or views.
Regarding 2.3 (meetings), I think one of the problems is that the information regarding the meetings is not clear in the IETF site, and moreover, the decision about where a meeting is being organized and why (or why not) is not an open process (even for candidate hosts !). I already mention a couple of times in this list that I've been offering myself to host a meeting in Madrid and another one in Barcelona, and after 3 (_THREE_) years the Madrid proposed venue was visited by the secretariat and initially qualified as excellent ("the best property even seen" according to the secretariat words after the visit, if I recall correctly), but afterwards, the decision was that was not convenient not being in downtown and not having "other" facilities nearby (what is not correct), but the most interesting thing is quite contradictory is this with the organization of the IETF60 in San Diego, where the problems where even bigger than compared to the Madrid proposal. This is probably c!
onsequence of the not open and democratic decision process and lack of information on the venue selection.
Consequently is also not correct that there are no "single" host offering to organize everything ... on the other way around, for some reasons have not been sufficiently considered, or may be unfairly decided to host the meeting in US having a better chance in Europe and with less security troubles for non-US attendees, but that is probably part of another discussion. Not really sure if this aspect should be considered in the organization of the meetings and standardized somehow, that only those countries that don't restrict (or set high levels of difficulties) for the attendance of participants of all around the world, being accepted as candidates.
In fact, my proposal was organizing the event in Madrid the week after another big event (Madrid Global IPv6 Summit) that I organize there every year (since 3 already, next one in March 2005), in order to take advantage of the network deployment and some other facilities and also have a better chance for negotiating a lower price with the hotel, and even take advantage of sponsorships for both events, or even having some attendees/speakers the chance to lower their traveling expenses (in case they are participating in both events).
I agree that the organization of IETF meetings is being done with not enough long term planning, regarding the host/venue decision (my own event is usually organized almost 1 year ahead and agreed with the venue at that time), and that usually means higher cost and lower number of probably venues.
Just to clarify, my comments in this case aren't a critic, but hopefully serve as real example case inputs to the document ;-)
Regarding the possible repetition of visits to allied properties, I'm not convinced is always possible, because the IETF is usually a to big meeting to have hotel chains or alliances that could have the correct venues in all the locations where we can find host. If this is done in US, it may be possible, but if we compare the normal size and number of the meeting rooms available in US hotels versus Europe, I don't think is realistic, at least not to be considered as a generic rule. The alternative is then to decide if we only organize the meetings on those chains (and restrict the possible candidate locations), or if we try both ways ... depending on the location.
Regarding the advanced payment cash flow needs, this could be negotiated usually, and even provide bank warranties instead of the actual payment, in case this help. Those bank warrantees could come from the supporting organizations instead of the IETF itself, if required.
I think is also important to balance the cost of the meeting for the IETF and the attendees, as this could be a factor for the number of participants. One additional consideration could be to choose locations that could be tied to vacations of some of the participants. I think for example this could be an ingredient if arranging a meeting in Spain (and sure in other locations), because the cost for the participants is lower than in US, and they can enjoy nice vacations after (or before) the meeting, probably helping to increase the participation and consequently the financing of the IETF costs.
An interesting question here will be if we are really looking for big meetings in terms of number of participants, that non necessarily "contribute", but increase the financial support for the IETF costs in general, or in the other way around, the extra costs and difficulties of organizing such big meetings doesn't compensate for those extra revenues. I will ask myself if we need in that case a way setup a bar to allow the participation of only those that really contribute ... another difficult debate.
Regarding the recommendations (3.1), I wonder if in addition to the single staff member, is more convenient to have a minimum own-staff, who can take care of all the different required activities including the long-term meeting planning. Usually the cost of the outsourcing, not just in terms of money, but also of training different people instead of having long term "IETF experienced" personal, can make a big difference looking into the productivity and actual support provided to the community. I will seriously prefer to consider this option instead of the RFP, and issue only RFP for specific task if required, when the own personnel can't take care of some of the activities because is not financially convenient only.
Regarding the basic computing infrastructure (3.2.1.1), based on customers experience in similar situations, I will much prefer a single distributed but unified platform, as a way to ensure common tools like search, information flow, archive, etc. A larger concentration of roles could be very appropriate, if correctly managed.
For some of the RPF components, we could consider sponsors or volunteers, of course, contractually bound. For example, I offered several times to mirror the IETF sites in order to provide IPv6 access.
Regarding the options for an Institutional Basis for Administrative Activities (4), I think it will be quite appropriate, considering the relation with ISOC and avoiding unnecessary expenses, going for Scenario A, but probably as a quick approach while we work on the Scenario B. May be is required in the document to look with much more detail into a comparison about possible drawbacks/pros/cons for every model to take a more consequent decision ? Foe example, I understand that the advantages of Scenario C, in terms of taxes, VAT, etc., are also applicable under the ISOC umbrella ? Are we considering for the incorporation country only those mention in the document? (it may be the case that what is described for Scenario C is not necessarily completely applicable everywhere, but may be some other advantages are available in some countries, including incorporation expenses, legal cost for yearly requirements as registered auditors, etc.). Are we considering the impact, in the s!
ense of the credit rating of a new entity, compared to an existing one ? Is more convenient to have a higher tax refunding than more freedom, if that's the case depending on the incorporation place ? Possibly all this questions need to be considered only if we go for Scenario C, but the decision to go to Scenario C could also depend on this answers ...
I don't think Scenario D is realistic, unless there is some "hidden" and insolvable issue with ISOC ?
Section 9. Ack. Mike St. Johns is duplicated.
Regards,
Jordi
----- Original Message -----
From: "Leslie Daigle" <leslie@xxxxxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Cc: "Harald Tveit Alvestrand" <harald@xxxxxxxxxxxxx>
Sent: Thursday, August 26, 2004 7:53 AM
Subject: Options for IETF administrative restructuring
>
>
> Hello, IETF community.
>
> Attached is the document we promised you in San Diego - a report from
> our consultant, Carl Malamud, which lays out a series of options and
> recommendations for moving forward with the IETF administrative
> restructuring process, according to the recommendations laid out
> in RFC3716 (the Advisory Committee report). It has been submitted
> to the Internet Drafts repository and should be showing up there
> shortly.
>
>
> Some important things to note:
>
> THIS IS NOT A DOCUMENT TO BE READ IN ISOLATION.
> Minimally, reviewing the Advisory Committee report (RFC3716) is
> necessary to understand the context of the proposals laid out in
> this draft.
>
> THIS IS NOT YET AN IETF DECISION.
> That will be taken later, based on your input and IETF rough consensus.
>
> THIS IS NOT THE IESG/IAB's RECOMMENDATION.
> Our recommendation will come later, based on your input and the
> evolution of our thinking.
>
> THIS IS NOT AN ISOC POSITION.
> The document describes potential relationships of the IETF
> administrative activity and ISOC. However, the document is written
> as a proposal for IETF discussion -- the ISOC Board has not been asked
> to formulate a position on supporting one or any of these proposals; we
> need to have that discussion as it becomes clearer what the IETF wants
> in its future.
>
>
> This IS, however, the culmination of many, many hours of information
> gathering and a near-infinite number of conversations by Carl Malamud,
> attempting to give the best basis on which the IETF could make a
> decision that he could within the timeframe given.
>
> We encourage all interested IETF participants to read the report most
> carefully, and give feedback on it - on the IETF list for public
> discussion, directly to Carl or the IETF and IAB chairs if you want to
> make off-list comments.
>
> FURTHER STEPS
>
> The next steps in this process depend on the community feedback and
> whether we can gauge a consensus of the IETF on this mailing list. What
> we think is reasonable so far is:
>
> - Have a public discussion on the IETF list on the options presented in
> the draft
>
> - By early September, the IESG and IAB will attempt to distill a set of
> recommendations that we think capture a reasonable consensus of the
> community, and publish this as an internet-draft, which will be revised
> over the next month, possibly several times, based on further
> discussions
>
> - By late September, we emit a Last Call on this set of recommendations,
> if we deem that we have a reasonable consensus for the proposals
>
> - By late October, if the IETF community still shows consensus, we will
> declare that we have a decision, and will start executing based on that
> decision.
>
> In order to be able to move rapidly when we go into the "execution"
> phase, we may initiate some activities of a "fact-finding" nature - such
> as investigating possible suppliers of services and candidates for the
> positions we envisage filling - before that, but irrevocable decisions
> will await IETF consensus.
>
> Please read the attachment - please comment - please THINK.
>
> While this in itself should not change the IETF standards process at
> all, support functions are important to the IETF.
>
> We need to take the time to get this one right.
>
> Leslie and Harald.
>
>
>
> --
>
> -------------------------------------------------------------------
> "Reality:
> Yours to discover."
> -- ThinkingCat
> Leslie Daigle
> leslie@xxxxxxxxxxxxxxx
> -------------------------------------------------------------------
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf