idnits 2.17.1 draft-ietf-mtgvenue-iaoc-venue-selection-process-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2018) is 2171 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-mtgvenue-meeting-policy-04 ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mtgvenue E. Lear, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Best Current Practice May 11, 2018 5 Expires: November 12, 2018 7 IETF Plenary Meeting Venue Selection Process 8 draft-ietf-mtgvenue-iaoc-venue-selection-process-15 10 Abstract 12 The IASA has responsibility for arranging IETF plenary meeting Venue 13 selection and operation. This memo specifies IETF community 14 requirements for meeting venues, including hotels and meeting room 15 space. It directs the IASA to make available additional process 16 documents around that describe the current meeting selection process. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 12, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Venue Selection Objectives . . . . . . . . . . . . . . . . . 3 54 2.1. Core Values . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Venue Selection Non-Objectives . . . . . . . . . . . . . 5 56 3. Meeting Criteria . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Mandatory Criteria . . . . . . . . . . . . . . . . . . . 5 58 3.2. Important Criteria . . . . . . . . . . . . . . . . . . . 6 59 3.3. Other Consideraitons . . . . . . . . . . . . . . . . . . 9 60 4. Documentation Requirements . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 64 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 10.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The Internet Administrative Support Activity (IASA) has 75 responsibility for arranging IETF plenary meeting venue selection and 76 operation. The purpose of this document is to guide the IASA in 77 their selection of regions, cities, facilities, and hotels. The IASA 78 applies this guidance at different points in the process in an 79 attempt to faithfully meet the requirements of the IETF community. 80 We specify a set of general criteria for venue selection and several 81 requirements for transparency and community consultation. 83 It remains the responsibility of the IASA to apply their best 84 judgment. The IASA accepts input and feedback both during the 85 consultation process and later (for instance when there are changes 86 in the situation at a chosen location). Any appeals remain subject 87 to the provisions of BCP101 [RFC4071]. As always, the community is 88 encouraged to provide direct feedback to the Nominations Committee 89 (NOMCOM), Internet Engineering Steering Group (IESG), and IAB 90 regarding the discharge of the IASA's performance. 92 Four terms describe the places for which the IETF contracts services: 94 Venue: 95 This is an umbrella term for the city, meeting resources and guest 96 room resources. 98 Facility: 99 The building that houses meeting rooms and associated resources. 100 It may also house an IETF Hotel. 102 IETF Hotels: 103 One or more hotels, in close proximity to the Facility, where the 104 IETF guest room block allocations are negotiated and where network 105 services managed by the IASA (e.g., the "IETF" SSID) are in use. 107 Overflow Hotels: 108 One or more hotels, usually in close proximity to the Facility, 109 where the IETF has negotiated a group rate for the purposes of the 110 meeting. Of particular note is that Overflow Hotels usually are 111 not connected to the IETF network and do not use network services 112 managed by the IASA. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119][RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2. Venue Selection Objectives 122 2.1. Core Values 124 Some IETF values pervade the selection process. These often are 125 applicable to multiple requirements listed in this document. They 126 are not limited to the following, but at minimum include: 128 Why we meet? 129 We meet to pursue the IETF's mission [RFC3935], partly by 130 advancing the development of Internet-Drafts and RFCs. We also 131 seek to facilitate attendee participation in multiple topics and 132 to enable cross-pollination of ideas and technologies. 134 Inclusiveness: 135 We would like to facilitate the onsite or remote participation of 136 anyone who wants to be involved. Widespread participation 137 contributes to the diversity of perspectives represented in the 138 working sessions 140 Every country has limits on who it will permit within its borders. 141 However the IETF seeks to: 143 1. Minimize situations in which onerous entry regulations 144 inhibit, discourage, or prevent participants from attending 145 meetings, or failing that to distribute meeting locations such 146 that onerous entry regulations are not always experienced by 147 the same attendees; and 149 2. Avoid meeting in countries with laws that effectively exclude 150 people on the basis of race, religion, gender, sexual 151 orientation, national origin, citizenship, or gender identity. 153 Where we meet? 154 We meet in different locations globally, in order to spread the 155 difficulty and cost of travel among active participants, balancing 156 travel time and expense across the regions in which IETF 157 participants are based. Our regional location policy is 158 articulated in [I-D.ietf-mtgvenue-meeting-policy]. 160 Internet Access: 161 As an organization, we write specifications for the Internet, and 162 we use it heavily. Meeting attendees need unfiltered access to 163 the general Internet and their corporate networks. "Unfiltered 164 access" in this case means that all forms of communication are 165 allowed. This includes, but is not limited to, access to 166 corporate networks via encrypted VPNs from the meeting Facility 167 and Hotels, including Overflow Hotels. We also need open network 168 access available at high enough data rates, at the meeting 169 Facility, to support our work, including the support of remote 170 participation. Beyond this, we are the first users of our own 171 technology. Any filtering may cause a problem with that 172 technology development. In some cases, local laws may require 173 some filtering. We seek to avoid such locales without reducing 174 the pool of cities to an unacceptable level by stating a number of 175 criteria below, one mandatory and others important, to allow for 176 the case where local laws may require filtering in some 177 circumstances.[MeetingNet] 179 Focus: 180 We meet to have focused technical discussions. These are not 181 limited to scheduled breakout sessions, although of course those 182 are important. They also happen over meals or drinks -- including 183 a specific type of non-session that we call a "Bar BOF" [RFC6771] 184 - or in side meetings. Environments that are noisy or distracting 185 prevent that or reduce its effectiveness, and are therefore less 186 desirable as a meeting Facility. 188 Economics: 189 Meeting attendees participate as individuals. While many are 190 underwritten by employers or sponsors, many are self-funded. In 191 order to reduce participation costs and travel effort, we 192 therefore seek locations that provide convenient budget 193 alternatives for food and lodging, and which minimize travel 194 segments from major airports to the Venue. Within reason, budget 195 should not be a barrier to accommodation. 197 Least Astonishment and Openness: 198 Regular participants should not be surprised by meeting Venue 199 selections, particularly when it comes to locales. To avoid 200 surprise, the venue selection process, as with all other IETF 201 processes, should be as open as practicable. It should be 202 possible for the community to engage early to express its views on 203 prospective selections, so that the community and the IASA can 204 exchange views as to appropriateness long before a venue contract 205 is considered. 207 2.2. Venue Selection Non-Objectives 209 IETF meeting Venues are not selected or declined with the explicit 210 purposes of: 212 Politics: 213 Endorsing or condemning particular countries, political paradigms, 214 laws, regulations, or policies. 216 Maximal attendance: 217 While the IETF strives to be as inclusive as possible both online 218 and in person, maximal meeting attendance in and of itself is not 219 a goal. It would defeat a key goal of meeting if active 220 contributors with differing points of view did not have the 221 opportunity to resolve their disagreements, no matter how full the 222 rooms. 224 Tourism: 225 Variety in site-seeing experiences. 227 3. Meeting Criteria 229 This section contains the criteria for IETF meetings. It is broken 230 down into three subsections: mandatory criteria, important criteria, 231 and other considerations, each as explained below. 233 3.1. Mandatory Criteria 235 If criteria in this subsection cannot be met, a particular location 236 is unacceptable for selection, and the IASA MUST NOT enter into a 237 contract. Should the IASA learn that a location no longer can meet a 238 mandatory requirement after having entered into a contract, it will 239 inform the community and address the matter on a case by case basis. 241 o The Facility MUST provide sufficient space in an appropriate 242 layout to accommodate the expected number of participants, 243 leadership, and support staff to attend that meeting. 245 o The Facility and IETF Hotels MUST provide wheelchair access to 246 accommodate the number of people who are anticipated to require 247 it. 249 o It MUST be possible to provision Internet Access to the Facility 250 and IETF Hotels that allows those attending in person to utilize 251 the Internet for all their IETF, business, and day to day needs; 252 as well as sufficient bandwidth and access for remote attendees. 253 This includes, but is not limited to, native and unmodified IPv4 254 and IPv6 connectivity, global reachability, and no additional 255 limitation that would materially impact their Internet use. To 256 ensure availability, it MUST be possible to provision redundant 257 paths to the Internet. 259 3.2. Important Criteria 261 The criteria in this subsection are not mandatory, but are still 262 highly significant. It may be necessary to trade one or more of 263 these criteria off against others. A Venue that meets more of these 264 criteria is on the whole preferable than another that meets fewer of 265 these criteria. Requirements classed as Important can also be 266 balanced across Venue selections for multiple meetings. When a 267 particular requirement in this section cannot be met, the IASA MUST 268 notify the community at the time of the venue announcement. 269 Furthermore, it may be appropriate for the IASA to assist those who, 270 as a result, have been inconvenienced in some way. 272 3.2.1. Venue City Criteria 274 o Travel to the Venue is acceptable based on cost, time, and burden 275 for participants traveling from multiple regions. It is 276 anticipated that the burden borne will be generally shared over 277 the course of multiple years. 279 o The Venue is assessed as favorable for obtaining a host and 280 sponsors. That is, the Meeting is in a location that it is 281 possible and probable to find a host and sponsors. 283 o Travel barriers to entry, including visa requirements, are likely 284 to be such that an overwhelming majority of participants who wish 285 to do so can attend. The term "travel barriers" is to be read 286 broadly by the IASA in the context of whether a successful meeting 287 can be had. 289 o Economic, safety, and health risks associated with this Venue are 290 acceptable. 292 o The selection of the venue comports with 293 [I-D.ietf-mtgvenue-meeting-policy]. 295 3.2.2. Basic Venue Criteria 297 The following requirements relate to the Venue and Facilities. 299 The IETF operates internationally and adjusts to local requirements. 300 Facilities selected for IETF Meetings SHALL have provided written 301 assurance that they are in compliance with local health, safety and 302 accessibility laws and regulations, and will remain in compliance 303 throughout our stay. 305 In addition: 307 o There are sufficient places (e.g., a mix of hallways, bars, 308 meeting rooms, and restaurants) for people to hold ad hoc 309 conversations and group discussions in the combination of spaces 310 offered by the facilities, hotels and bars/restaurants in the 311 surrounding area, within walking distance (5-10 minutes). 313 o The cost of guest rooms, meeting space, meeting food and beverage 314 is affordable, within the norms of business travel. 316 o The Facility is accessible or reasonable accommodations can be 317 made to allow access by people with disabilities. 319 3.2.3. Technical Meeting Needs 321 The following criteria relate to technical meeting needs. 323 o The Facility's support technologies and services -- network, 324 audio-video, etc. -- are sufficient for the anticipated activities 325 at the meeting, or the Facility is willing to add such 326 infrastructure or these support technologies and services might be 327 provided by a third party, all at no -- or at an acceptable -- 328 cost to the IETF. 330 o The IETF Hotel(s) directly provide, or else permit and facilitate, 331 the delivery of a high performance, robust, unfiltered and 332 unmodified Internet service for the public areas and guest rooms; 333 this service is typically included in the cost of the room. 335 3.2.4. Hotel Needs 337 The following criteria relate to IETF Hotels. 339 o The IETF Hotel(s) are within close proximity to each other and the 340 Facility. 342 o The guest rooms at the IETF Hotel(s) are sufficient in number to 343 house 1/3 or more of projected meeting attendees. 345 o Overflow Hotels can be placed under contract, within convenient 346 travel time to and from the Facility and at a variety of guest 347 room rates. 349 o The Facility environs include budget hotels within convenient 350 travel time, cost, and effort. 352 o The IETF Hotel(s) are accessible by people with disabilities. 353 While we mandate wheelchair accessibility, other forms are 354 important, and should be provided to the extent possible, based on 355 anticipated needs of the community. 357 o At least one IETF Hotel or the Facility has a space for use as a 358 lounge, conducive to planned and ad hoc meetings and chatting, as 359 well as working online. There are tables with seating, convenient 360 for small meetings with laptops. These can be at an open bar or 361 casual restaurant. Preferably the lounge area is centrally 362 located, permitting easy access to participants. 364 3.2.5. Food and Beverage 366 It is said that an army travels on its stomach. So too does the 367 IETF. The following criteria relate to food and beverage. 369 o The Facility environs, which includes both onsite, as well as 370 areas within a reasonable walking distance or conveniently 371 accessible by a short taxi ride or by local public transportation, 372 have convenient and inexpensive choices for meals that can 373 accommodate a wide range of dietary requirements. 375 o A range of attendee's health-related and religion-related dietary 376 requirements can be satisfied with robust and flexible onsite 377 service or through access to an adequate grocery. 379 o The Facility environs include grocery shopping that will 380 accommodate a wide range of dietary requirements, within a 381 reasonable walking distance, or conveniently accessible by a short 382 taxi, bus, or subway ride, from the Facility and IETF Hotels. 384 3.3. Other Consideraitons 386 The following considerations are desirable, but not as important as 387 the preceding requirements, and thus should not be traded off for 388 them. 390 o We have something of a preference for an IETF meeting to be under 391 "One Roof". That is, qualified meeting space and guest rooms are 392 available in the same facility. 394 o It is desirable for Overflow Hotels provide reasonable, reliable, 395 unfiltered Internet service for the public areas and guest rooms; 396 this service is included in the cost of the room. 398 o It is desirable to enter into a multi-event contract with the 399 Facility and IETF Hotels or associated hotel chains in case such a 400 contract will either reduce administrative costs, reduce direct 401 attendee costs, or both. 403 o Particularly when we are considering a city for the first time, it 404 is desirable to have someone participate in the site visit who is 405 familiar with both the locale and the IETF. Such a person can 406 provide guidance regarding safety, location of local services, and 407 understanding best ways to get to and from the Venue, and local 408 customs, as well as identify how our requirements are met. 410 4. Documentation Requirements 412 The IETF Community works best when it is well informed. This memo 413 does not specify processes nor who has responsibility for fulfilling 414 our requirements for meetings. Nevertheless, both of these aspects 415 are important. Therefore, the IASA SHALL publicly document and keep 416 current both a list of roles and responsibilities relating to IETF 417 meetings, as well as the selection processes they use in order to 418 fulfill the requirements of the community. 420 5. IANA Considerations 422 This memo asks the IANA for no new parameters. 424 [The RFC-Editor may remove this section prior to publicaiton.] 426 6. Security Considerations 428 This note proposes no protocols, and therefore no new protocol 429 insecurities. 431 7. Privacy Considerations 433 Different places have different constraints on individual privacy. 434 The requirements in this memo are intended to provide for some 435 limited protections that attendees can apply. As meetings are 436 announced, IASA SHALL inform the IETF of any limitations to privacy 437 they have become aware of in their investigations. For example, 438 participants would be informed of any regulatory authentication or 439 logging requirements. This note reveals no personally identifying 440 information apart from its authorship. 442 8. Contributors 444 The following people provided substantial text contributions to this 445 memo: 447 Fred Baker 448 Email: fred.ietf@gmail.com 450 Fred originated this work. 452 Ray Pelletier 453 Email: Rpelletier13@gmail.com 455 Laura Nugent 456 Association Management Solutions 457 Email: lnugent@amsl.com 459 Lou Berger 460 LabN Consulting, L.L.C. 461 Email: lberger@labn.net 463 Ole Jacobsen 464 The Internet Protocol Journal 465 EMail: olejacobsen@me.com 467 Jim Martin 468 INOC 469 Email: jim@inoc.com 471 9. Acknowledgements 473 Additional contributions came from Jari Arkko, Scott Bradner, Alissa 474 Cooper, Dave Crocker, Jordi Palet Martinez, Andrew Sullivan, and 475 other participants in the mtgvenue working group. Those listed in 476 this section or as contributors may or may not agree with the content 477 of this memo. 479 10. References 481 10.1. Normative References 483 [I-D.ietf-mtgvenue-meeting-policy] 484 Krishnan, S., "High level guidance for the meeting policy 485 of the IETF", draft-ietf-mtgvenue-meeting-policy-04 (work 486 in progress), February 2018. 488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 489 Requirement Levels", BCP 14, RFC 2119, 490 DOI 10.17487/RFC2119, March 1997, 491 . 493 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 494 IETF Administrative Support Activity (IASA)", BCP 101, 495 RFC 4071, DOI 10.17487/RFC4071, April 2005, 496 . 498 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 499 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 500 May 2017, . 502 10.2. Informative References 504 [MeetingNet] 505 O'Donoghue, K., Martin, J., Elliott, C., and J. Jaeggli, 506 "IETF Meeting Network Requirements", WEB 507 https://iaoc.ietf.org/ietf-network-requirements.html. 509 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 510 BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, 511 . 513 [RFC6771] Eggert, L. and G. Camarillo, "Considerations for Having a 514 Successful "Bar BOF" Side Meeting", RFC 6771, 515 DOI 10.17487/RFC6771, October 2012, 516 . 518 Appendix A. Change Log 520 [RFC Editor: Please remove this section prior to publication.] 522 2016-01-12: Initial version 524 2016-01-21: Update to reflect https://iaoc.ietf.org/documents/ 525 VenueSelectionCriteriaJan2016.pdf and 526 https://iaoc.ietf.org/documents/VenueSelectionProcess11Jan16.pdf, 527 accessed from https://iaoc.ietf.org/private/privatemeetings.html. 529 2016-02-23: Reorganize and capture IAOC Meetings Committee 530 discussions. 532 2016-03-03: Final from Design Team. 534 2016-03-17: First update incorporating mtgvenue@ietf.org comments 536 2016-05-20 Updated in accordance with editing by Laura Nugent, Dave 537 Crocker, Lou Berger, Fred Baker, and others. 539 posting as working group draft August 2, 2016 541 Reorganized per Alissa Cooper outline Work in progress. In 542 addition, contributors were re-organized to be authors. 544 2016-10-28 Editor changeover. Further alignment with guidance by 545 Alissa Cooper, Andrew Sullivan and the mtgvenue working group. 546 Many various changes. 548 2016-11-16 Extensive editorial, format and polishing pass. A few 549 substance changes, including food section. 551 2016-11-30 Additions based on working group meeting and off-list 552 discussions; more editorial and format hacking. 554 2016-12-24 Various clarifying bits to provide some glue between the 555 high-level 'objectives' and the detailed criteria and roles, per 556 suggestions fronm Lear. Editorial changes, per 12/27 response to 557 Cooper. Refined uses of 'Facility' and 'Venue', per 12/4 response 558 to Carpenter; also added Carpenter 'lounge' text. Moved community 559 consultation to a separate criterion; removed 'acceptable to the 560 IETF Community from the 2 entries that had it. Removed Post- 561 Seroul Revisions and Text Carried Forward. 563 2016-12-24 Address comments made on list by Stephen Farrell 564 . Minor text change in Section 5. 565 Replaced links in sections 5.3 and 5.5. 567 2017-03-12 Add openness comment as requested by Stephen Farrell. 568 Add statement about 4071 as proposed by Brian and modified by 569 Jari. Elaborated on what "unfiltered" means, based on discussion 570 between Eliot and Stephen. Preface to Section 5 as discussed 571 between Lou and Stephen. Slight editorial tweak to that by Eliot. 572 IETF operates internationally, as proposed by Brian. 574 2017-04-18 Add new introductory text. Sharpen mandatory definition. 575 Split first criteria into two, and reword them to be more 576 actionable. Remove net cash positive requirement. Change many 577 critera from Mandatory to Important. Remove consensus text. 578 Modify chapeau. Add some normative MUSTs in Section 5, and 579 restructure Section 5.5. A bunch of other stuff as well. Use 580 diff. 582 2017-05-14 Happy Mother's Day. This version removes the tabular 583 format of requirements, moves mandatory requirements up front, 584 adds a desiderata section, adds a mandatory filtering requirement, 585 consolidates introductory text, moves procedural requirements into 586 Section 5, removes the definition of Headquarters Hotel, removes 587 the MUST in late changes, and adds a desire for a local 588 participant in site selection. 590 2017-09-12 These are last call edits. Big change is around Internet 591 requirements. Also, address Andrew Sullivan comments, as well as 592 SM comments. Brian Carpenter big scrub on IAOC to IASA. 594 2017-10-20 Final edits from WGLC based on Laura Nugent's review. 595 Most are editorial for clarity. Also, remove large table and link 596 to the live copy. 598 2018-01-10 Changes based on AD review. 600 2018-02-02 Changes based on genart review and IETF last call. 602 2018-05-07 Several versions of changes. Based on reorg of meetings 603 committee, Section 4 and 5 moved out. Also, final LC comments 604 addressed. In particular: no smoking added. Reference to RFC8174 605 added. Reference to meeting policy doc added. 607 2018-05-11 Remove no smoking. 609 Author's Address 611 Eliot Lear (editor) 612 Cisco Systems 613 Richtistrasse 7 614 Wallisellen CH-8304 615 Switzerland 617 Phone: +41 44 878 9200 618 Email: lear@cisco.com