One document matched: draft-george-travel-faq-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.barnes-healthy-food SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.barnes-healthy-food.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-george-travel-faq-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="george-travel-faq">IETF meeting attendees' Frequently Asked
(travel) Questions</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Wesley George" initials="W" surname="George">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703-561-2540</phone>
<email>wesley.george@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="23" month="February" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>Meetings</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document attempts to provide a list of the common Frequently
Asked Questions (FAQs) that IETF meeting attendees often ask regarding
travel logistics and local information. It is intended to assist those
who are willing to provide local information, so that if they wish to
pre-populate answers to some or all of these questions either in the
IETF Wiki or a meeting-specific site, they have a reasonably complete
list of ideas to draw from. It is not meant as a list of required
information that the host or secretariat needs to provide, merely as a
guideline.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IETF attendees come from all over the world. The typical IETF meeting
has representatives from in excess of 50 countries. It is quite likely
that a large portion of the participants in any given IETF are newcomers
to the specific location where it is being held, or even the country or
region itself. As a result, they are going to have questions regarding
their own personal travel needs and logistics that may only be
answerable by someone who has either been to the area before, someone
who lives there, and/or someone who speaks the local language.</t>
<t>The IETF, its secretariat, and any local host organizations
responsible for the logistics of making IETF meetings happen are not
travel agencies, but they often can and do assist with identifying and
hosting the common information that most attendees wish to have while
they are planning their trip. This document attempts to cover the most
commonly asked questions and categories for information. This document
is not intended to provide answers to these questions for every possible
location in which IETF meetings may be held. Rather, it is intended to
provide a set of FAQs for use by the hosts and others who have
experience with the area where the event is being held, so that the
questions and answers can be handled more efficiently than waiting until
someone sends an email to the meeting attendees email list in the days
leading up to the meeting.</t>
</section>
<section title="Why is this document necessary?">
<t>In reading this document, one may ask, "Isn't that why search engines
and travel sites exist?" And the answer is that yes, we can sometimes
find what we're looking for with search engines, but that results in
hundreds of people spending their time searching, which is not very
efficient. In addition, despite the widely held belief that if it is
published on the Internet, it must be true, sometimes the information
that is available is either inaccurate, incomplete, or out of date, so
it may be less reliable than firsthand info from someone who has been
there. Also, no matter how much online translation has improved, some of
the most useful local travel information sites may be difficult for
non-native speakers to navigate and find information, because navigation
buttons, graphics, and other active content are typically not
machine-translatable, and non-native speakers may not realize when
machine translation is inaccurate in a critical way. Lastly, while the
companies which serve as hosts for IETF meetings often have participants
attending IETF, the folks who are responsible for handling the details
of hosting an IETF may not be regular attendees. Therefore, this
document, especially section 3, is intended to be something that can be
provided to host event organizers that may not have much familiarity
with the IETF, so that they have a better sense of the information that
attendees will find helpful.</t>
<t>The format of this document was chosen so that it captures the
Frequently Asked Questions, but usually not their answers. This is
because IETF RFCs are typically static and infrequently updated, which
does not make them a particularly suitable format to contain
location-specific information. The questions found in this document are
a result of informal review of multiple past meeting attendees mailing
lists and the feedback of many individuals, and are believed to be
reasonably static from one meeting to the next. This document is not
necessarily all-inclusive, but should serve as a reasonable baseline
such that a static format like an RFC is appropriate. It is likely that
the RFC will need to be revised periodically - a clue that this is
necessary will be when, over the course of multiple meetings, multiple
additional questions that are not covered by this document surface on
the attendees list and start becoming frequently asked questions.</t>
<t>The answers to this document's questions are expected to be stored in
a location which is more easily updated by multiple parties, so that
site-specific information can be refined and updated as often as
necessary, thereby creating a living document. There are several options
as to where to store the location-specific living document. For some
past IETF meetings, the hosting organization or an individual has set up
a special website, e.g. <xref target="STOCKHOLM">ietf75.se </xref>,
<xref target="PHILLY">ietf71.comcast.net</xref>, or <xref
target="HIROSHIMA">hiroshima-info.info</xref>, etc. This has been a
source of much additional information about the location, and is always
quite helpful. If the host decides to set up a site like this, the hope
is that this document will provide guidance as to the sorts of
information with which to populate such a site. However, it is by no
means a requirement that the host set up an external website. Further,
not every IETF meeting has a local host, or even a host at all. In these
cases, the need for the same set of information is not lessened, but the
IETF will be more reliant on the willingness of those with experience in
the area where the meeting will be held to share the benefit of that
experience with others. The IETF has provided a hosted <xref
target="WIKI">Wiki</xref> which can simply be populated with the same
sorts of information. This has the added benefit of having a single
location where additional information can be provided by experienced
travelers, locals, and host representatives alike, and is therefore not
completely reliant on the host. In the case where the IETF-hosted Wiki
is to be used, this document may serve as a framework of categories that
could be pre-built when the site-specific page is set up, so that others
can begin populating the information.</t>
</section>
<section title="Helpful information">
<t>There are a number of general categories of information listed below.
Some of it, such as sections 3.1 and 3.3, is necessary for travel, the
rest can be considered nice-to-have. All of it has come from actual
frequently asked questions from the attendees mailing lists.</t>
<t>Much of the needed information may already be available in another
form online. There is no need to reproduce information that can be found
on external websites, so simply providing pointers to information
already available in other locations is quite appropriate. However, it
is very helpful if some validation and vetting of the provided
information is performed in order to avoid outdated or inaccurate
information. Additionally, because this is a static and
location-agnostic document, it's quite likely that some questions are
either irrelevant or confusing for some locations. Therefore, "not
really relevant here" and "we don't know" may be valid answers to some
of these questions. In those cases, it's better to say this explicitly
than to simply omit the section, as this will confirm that the
information was not simply omitted. The main thing to remember when
providing information in these categories is that those traveling to the
event have not been there before, and so one should not assume a high
level of background knowledge about the area, its customs, etc.</t>
<section title="Travel">
<t><list style="symbols">
<t>Recommended airport(s) for domestic and international
connections - include the appropriate IATA Airport code(s)
whenever possible to avoid confusion.</t>
<t>Non-flight options to get to the city where the meeting is
being held (e.g. if there are convenient rail travel options)</t>
</list></t>
<section title="Transit between the airport and primary hotels">
<t>Information in this section is especially critical if the airport
is significantly distant from the venue or use of a taxi is
otherwise impractical or not recommended (e.g. if attendees must use
a train or long-distance bus to get to the venue locale from the
airport)</t>
<t><list style="symbols">
<t>Estimated travel time - this is also important for return
travel from the venue to the airport. It is worth noting any
recommendations about leaving extra time if airport security and
check-in is always busy or there will be significant differences
in travel time due to rush hour traffic</t>
<t>Shuttles (if applicable)</t>
<t>Arranging transit directly with the hotel (if applicable) -
hotels sometimes provide car service or are willing to pay taxi
bills upon your arrival so that the charges can be added to the
hotel bill instead of requiring local currency. It is helpful to
know in advance if this is common or uncommon in the local
area.</t>
</list></t>
<section title="Taxi information">
<t><list style="symbols">
<t>Credit cards accepted (yes/no and which ones, if yes)</t>
<t>Foreign currency accepted?</t>
<t>Estimated costs for Taxis, as well as any
rules/recommendations about metered fares vs. fixed-rate or
prenegotiated fares</t>
<t>Description of "official" taxis if appropriate</t>
<t>Links to websites or phone numbers for remote/pre-booking
Taxis</t>
<t>How to find the taxi stand at the airport/train station</t>
<t>Printable local-language address card to show taxi driver
in case of language barrier</t>
<t>Ride sharing - the IETF Wiki usually has a section where
attendees can post arrival times and work out Taxi sharing</t>
</list></t>
</section>
<section title="Mass Transit">
<t>Navigating an unfamiliar mass transit system can be
challenging. Things that seem obvious to the locals may not be as
obvious to out-of-town travelers.</t>
<t><list style="symbols">
<t>English map</t>
<t>How and where to purchase farecards/tokens</t>
<t>How to use tickets/tokens (where to insert them, get them
stamped, how to transfer, etc)</t>
<t>How trains/buses are labeled and how to identify the
destination of a particular train/bus</t>
<t>The general frequency of service, and in particular whether
one should just go to the station or should consult a schedule
first</t>
<t>Which transit system to use for which destination (when
there are multiple transit systems in the area)</t>
<t>Nearby stations and how to identify a station entrance
(common logo, color, etc)</t>
</list></t>
</section>
</section>
<section title="Getting around near the conference venue">
<t>The same info relevant for airport transit will likely be
relevant here, including taxi and mass transit information. If
possible, walking directions between the conference venue and the
hotel(s) should be provided if the venue is not co-located with the
hotel.</t>
<t>Additionally, It is helpful to note if having a vehicle available
(rental or personal car) is a help or a hindrance in getting around
in the local area. For example, it may not be recommended to try to
drive in the area near the conference venue due to:<list
style="symbols">
<t>Parking availability and costs</t>
<t>Congestion charges and other restrictions on when and where
one can drive</t>
<t>Traffic</t>
</list></t>
</section>
</section>
<section title="Food">
<t>The nature of IETF's schedule means that food and drink provide
both a welcome break as well as a venue to continue discussions with
colleagues, either related to IETF work, other shop talk, or anything
*but* shop talk. During IETF's lunch break, approximately 1000 people
are simultaneously looking for reasonably priced lunch options, with
timeframes ranging from "grab and go" for a working lunch to 75
minutes for a sit-down meal. When meetings have concluded for the day,
the wide variety of attendees means that people are looking for all
types of food, all price ranges, and atmosphere ranging from someplace
suitable for an in-depth conversation to a table at the bar. The more
information that is available about the food and drink options nearby,
the better. This information is especially helpful during the first
few days of the conference, because the amount of folks looking for
assistance from the hotel concierge or other information desk staff at
one time tends to overwhelm the personnel available.</t>
<section title="Restaurants">
<t>It's generally helpful to note whether restaurants
require/recommend reservations, if they have busy/rush times that
should be avoided or planned for, etc.</t>
<t>It's helpful for Restaurants to be categorized by:<list
style="symbols">
<t>Price</t>
<t>Proximity to venue - It's useful to highlight quick options
for lunch breaks.</t>
<t>Type of cuisine - This is a great place to highlight local
specialties and favorites.</t>
<t>Special dietary needs <list style="symbols">
<t>Vegan/Vegetarian</t>
<t>Halal/Kosheroi</t>
<t>It's also extremely helpful to discuss methods for
communicating these needs to restaurant staff when
ordering</t>
<t>A more in-depth discussion of dietary concerns can be
found in <xref target="I-D.barnes-healthy-food"/></t>
</list></t>
</list></t>
</section>
<section title="Other Food items">
<t><list style="symbols">
<t>Local grocery/convenience stores - for attendees who cannot
find restaurant options which meet their dietary needs</t>
<t>Coffee shops and Tea Houses nearby - specifically, where can
we find the best espresso/cup of tea?</t>
<t>Bars/pubs nearby</t>
<t>Restaurants/pubs with private rooms or large seating areas
for big groups</t>
</list></t>
</section>
</section>
<section title="Regional/International considerations">
<t><list style="symbols">
<t>Plug type/voltage - this can simply be a reference to <xref
target="PLUGS">electricaloutlet.org</xref> unless there are
specific exceptions or details that need to be highlighted</t>
<t>Visa requirements, pointers regarding travel documents - IETF
typically provides information about visas via a pointer to an
embassy or similar page that has general information about common
types of visas, when they are required, waived, etc. It also
includes information about how to obtain a letter of invitation
should one be required. It is helpful to provide information that
goes beyond that, especially if there are known issues where it
may be difficult for entrants from certain countries to get a visa
processed in the time between when the meeting is announced and
when travel must commence. If there are expedite processes, this
is a good place to discuss them.</t>
<t>Languages commonly spoken</t>
<t>National/regional holidays, work stoppages/strikes, or other
issues which may impact travel or business hours during the week
of IETF</t>
</list></t>
<section title="Health and Safety">
<t><list style="symbols">
<t>Phone numbers to access local emergency services (e.g. 911,
999, etc)</t>
<t>Closest health clinic/hospital facilities</t>
<t>Areas of high crime to avoid</t>
<t>Common local scams</t>
<t>Hostile flora and fauna and how to identify/avoid</t>
<t>Local air quality considerations - everyone has different
thresholds for "unhealthy" air quality, and especially those
with health or respiratory problems may need to be able to
locate local air quality monitoring information to determine how
best to prepare themselves.</t>
<t>Smoking rules <list style="symbols">
<t>Are most bars/restaurants smoking or non-smoking?
Separate smoking section?</t>
<t>Rules on smoking in public places?</t>
<t>Availability of dedicated smoking/non-smoking rooms in
hotels?</t>
<t>Rules on smoking outdoors?</t>
</list></t>
</list></t>
<section title="Water availability">
<t><list style="symbols">
<t>Is local tap water potable/drinkable (if not, is it truly
unsafe because of impurities or contamination or does it
simply taste bad by local standards?)</t>
<t>How does one differentiate between tap water and bottled in
a restaurant when ordering?</t>
<t>Are water fountains/bubblers or watter bottle refill taps
commonly available in public places?</t>
</list></t>
</section>
</section>
<section title="Money">
<t><list style="symbols">
<t>General credit card acceptance in common locations, including
any restrictions (requires a PIN or chip, no AMEX, etc)</t>
<t>ATM locations near the venue, at the airport - note whether
these accept foreign cards, which systems they participate in,
whether they have an English language option</t>
<t>Tipping customs, particularly for Taxis, restaurants, and
hotel staff</t>
<t>Currency conversion rate - a reference to a currency
converter site, e.g. <xref target="CURRENCY">Yahoo!</xref> will
suffice unless there are specific conversion details that one
believes to be relevant</t>
<t>In establishments where foreign currency is accepted either
for purchase or for exchange, note whether this is recommended
or not due to favorable or unfavorable exchange rates, etc.</t>
<t>For what types of purchases (if any) bargaining/haggling on
the price is expected or customary, and if so, customary methods
for successful bargaining</t>
</list></t>
</section>
</section>
<section title="Communications and electronics">
<t><list style="symbols">
<t>Places to purchase local SIMs, and types of mobile voice/data
service supported, (e.g. GSM, LTE, UMTS, CDMA, etc)</t>
<t>Places to get replacement electronics and accessories (e.g.
power cords, adaptors, batteries, etc)</t>
<t>Public Wi-Fi access (outside of hotel and venue) including
Wi-Fi availability in the recommended airports, mass transit,
etc.</t>
</list></t>
</section>
<section title="Weather">
<t><list style="symbols">
<t>Link to a site or brief info on temperature and humidity norms
for the time of year when the meeting will be held, e.g <xref
target="WEATHER">Weather Underground</xref></t>
<t>If this is an area known for extreme weather, note any
amenities to make travel easier, such as enclosed walkways or
indoor passages between buildings</t>
<t>This also refers to indoor weather: what is the common indoor
temperature?</t>
</list></t>
</section>
<section title="Fitness">
<t><list style="symbols">
<t>Soccer: If the weather cooperates, it is common for some
IETFers to try to hold a "soccer BoF" - a pick-up soccer game
sometime during the week of IETF. If you know of a field
appropriate for soccer in proximity to the venue, this is useful
information to have.</t>
<t>Running/walking paths or routes - some folks prefer this method
for exercise over using a treadmill</t>
</list></t>
</section>
<section title="Tourism and Souvenirs">
<t>While this is certainly not necessary information for the primary
goal of an IETF attendee, many attendees earmark a day or two on
either side of the conference for sightseeing, and this is an
opportunity to highlight local attractions. Links to sites containing
information about walking tours, local tourist attractions and the
like are certainly appreciated.</t>
<t>Additionally, many attendees choose to purchase souvenirs as gifts
or for personal use. In addition to the standard "tourist-trap" items
such as t-shirts and knick-knacks, many attendees are looking for
items that are locally crafted, local specialties, or otherwise
significant to the local area and culture. This is another area where
the local area can be highlighted in the information provided to
attendees.</t>
</section>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to the following folks (and probably others the author has
unintentionally forgotten) for their valuable feedback.</t>
<t>Dave Crocker, Simon Perreault, Joe Touch, Lee Howard, Jonathan
Lennox, Tony Hansen, Vishnu Ram, Paul Kyzivat, Karen Seo, Randy Bush,
Mary Barnes, John Klensin, Brian Carpenter, Adrian Farrel, Stephen
Farrell, Yaacov Weingarten, L. David Baron, Samuel Weiler, SM, Ole
Jacobsen.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document is not a protocol specification and therefore contains
no protocol security considerations. However, some of the above items
refer to the physical security of IETF participants and their property.
This document is not intended to be a comprehensive discussion of
physical security matters for IETF attendees.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&I-D.barnes-healthy-food;
<!-- A reference written by by an organization not a person. -->
<reference anchor="STOCKHOLM"
target="http://web.archive.org/web/20100812231105/http://www.ietf75.se/">
<front>
<title>Internet Wayback Machine version of ietf75.se</title>
<author>
<organization>.se</organization>
</author>
<date year="2009"/>
</front>
</reference>
<reference anchor="PHILLY" target="http://ietf71.comcast.net">
<front>
<title>IETF 71 Philadelphia microsite</title>
<author>
<organization>Comcast</organization>
</author>
<date year="2008"/>
</front>
</reference>
<reference anchor="HIROSHIMA" target="http://hiroshima-info.info">
<front>
<title>Ole Jacobsen's Hiroshima info site</title>
<author>
<organization>Jacobsen</organization>
</author>
<date year="2009"/>
</front>
</reference>
<reference anchor="WIKI"
target="http://www.ietf.org/registration/MeetingWiki/wiki/doku.php">
<front>
<title>IETF hosted meeting-specific Wiki pages</title>
<author>
<organization>IETF</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="PLUGS" target="http://electricaloutlet.org/">
<front>
<title>Reference site for plug types by location</title>
<author>
<organization>electricaloutlet.org</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="CURRENCY"
target="http://finance.yahoo.com/currency-converter/">
<front>
<title>Yahoo! Currency Converter</title>
<author>
<organization>Yahoo!</organization>
</author>
<date year="2011"/>
</front>
</reference>
<reference anchor="WEATHER" target="http://http://www.wunderground.com/">
<front>
<title>Weather Underground</title>
<author>
<organization>Weather Underground</organization>
</author>
<date year="2011"/>
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:08:57 |