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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>
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
> [EMAIL PROTECTED]
> -------------------------------------------------------------------
>
**********************************
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 mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
