What I'm saying is that this has been done wrong, and probably the only way
to avoid it is to:
1) Not accepting a venue which is not "directly" connected (and CONFIRMED by
the secretariat) by an international airport, served by at least 3 different
alliances (example, OneWorld, Star, Skyteam). It will be acceptable a train
or bus from the airport to the venue/hotels, let's say less than one hour
trip, AND with no "line" changes.
2) If the venue don't met that requirement, then the secretariat should take
the responsibility to double check that the different recommended
transportation suggestions are valid and perform as announced by the
provider (example, the railway company).
Maastricht didn't met any of both choices.
I don't think the responsibility of the IAOC/secretariat finish by providing
the venue and hotels. It must be a GOOD venue. Otherwise we may choose as
venue ANY city lost in a far corner of any country, right ? And that should
include the most obvious info about how to reach the venue (especially if is
not next to an international airport). If somebody take the risk of choosing
an alternative path, of course, that's a different history.
I don't agree either that the secretariat should not make a minimum
supervision of the host provided info. I know it is impossible not being
local to monitor all, but in a case where we don't have an international
airport, the secretariat should make sure that the trains have the right
information, definitively !
From: Olaf Kolkman <olaf(_at_)NLnetLabs(_dot_)nl>
Date: Fri, 27 Aug 2010 12:06:14 +0200
Subject: Re: [78attendees] WARNING !!! Re: Maastricht to Brussels-Nat-Aero,
On Aug 26, 2010, at 3:07 AM, JORDI PALET MARTINEZ wrote:
I'm forwarding this message to the general IETF mailing list, because I
think we need a good discussion on this and the confirmation from the
secretariat/IAOC that this work will be done CORRECTLY NEXT TIME.
The fact is that if we don't make sure that a venue has good connections
then should not be candidate to be an IETF venue.
I'm not referring to plane vs train. I'm fine with train if the information
provided is accurate. Some times, for people in Europe, train can be more
convenient than planes, but this is only true if the train system is
reliable in general (of course, a strike, crash or anything like that is
something that we can't predict/avoid).
Maastricht proved that the information provided by the train web sites was
This is something that the secretariat/IAOC SHOULD verify before accepting a
I hope that we learn the lesson.
You are suggesting that the secretariat or the IAOC does research into the
correctness of information that is linked from the host site, correct?
If so: The host site is _not_ the responsibility of the IAOC or the
secretariat, it is the responsibility of the host. And although I would agree
that there should be some expectation that the host does its best to provide
accurate venue information one cannot expect the host to actually _test_
whether sites that (in their eyes) are supposed to give authoritative
information are actually correct.
Suppose that this link was not provided by the host.
You would probably have googled for "Maastricht Brussels Train"? That query
provides me with the mentioned site as first hit. Would you have complained
to google that the first hit for that query contained false information?
But to the underlying point: I think the responsibility of the IAOC and
secretariat stops with providing accurate hotel and venue location
information. How to get from home to the venue is _your own_ responsibility by
which you might be aided through links provided by the hosts and hints and
tips from your colleagues on the various IETF lists. I would agree that it is
fair to expect that folk providing those hints and tips do so diligently but
that is not the responsibility of the IAOC or Secretariat.
On purely personal title,
Olaf M. Kolkman NLnet Labs
Science Park 140,
http://www.nlnetlabs.nl/ 1098 XG Amsterdam
Ietf mailing list
The IPv6 Portal: http://www.ipv6tf.org
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