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(_at_)thinkingcat(_dot_)com>
To: <ietf(_at_)ietf(_dot_)org>
Cc: "Harald Tveit Alvestrand" <harald(_at_)alvestrand(_dot_)no>
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(_at_)thinkingcat(_dot_)com
-------------------------------------------------------------------
**********************************
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf