IETF Secretariat N. Bourbaki INTERNET-DRAFT IETF draft-ymbk-termroom-op-04.txt 00.09.12 IETF Meeting Network Infrastructure Lore This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 0. Abstract Creating and running the 'terminal room' for an IETF meeting is tantamount to building, running, and dismantling a small computer center. Although this is a well-known area of operations, the unique environment and its ephemeral nature warrant passing on the lore in a mildly organized fashion. It is expected that this document will be updated regularly. However, it is not clear that this will ever be published as an RFC. As the IETF can ill afford failure of this service, it is assumed that the host and organizers have the experience and resources to build such environments, understand power facilities, cabling, WAN and LAN building, workstation provisioning, staffing, etc. So this document does not attempt to detail how to build computer facilities or carry out prudent project management. Rather it concentrates on the unique aspects of the IETF 'terminal room'. N. Bourbaki Expires 01.03.12 [Page 1] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 1. External Network Connectivity The picky and analytic nature of a large number of IETF participants means that the connectivity and performance of that connectivity will be measured, whined about, ... Do not worry. Move the packets well, and the nit pickers will pick each other to death. 1.1 Bandwidth Requirements Bandwidth consumption is approximately 5kbps per attendee. So currently 10mbps of external connectivity seems sufficient. Unicast peaks at about five, and multicast at three. The addition of streaming services may require more bandwidth, especially if they are not cached off-site. 1.2 Path Diversity If possible, diverse physical and logical paths should be provided. It is understood that few conference centers have connectivity, let alone diversity. But it is prudent to coordinate with the ISP to get as much redundancy as reasonably possible. Redundant and diverse paths out of the local provider's POP(s) are advised when possible. 1.3 WAN Multicast Considerations It has been suggested that multicast WAN connectivity would benefit from being separated from unicast. This has been tried and worked, though it is not believed to be necessary. 1.4 IPv6 Considerations Increasingly it is expected that IPv6 connectivity is available. Ideally this would be via some production IPv6 service. If that is not available, at least 6bone access SHOULD be provided. 2. The Internal Network This has been the transport area of most concern at recent meetings. The bulk of the users require IPv4 unicast. IPv4 multicast is needed to originate MBONE content from selected Working Group sessions. Some users who have forgotten how to walk or may be extremely antisocial find it convenient to be able to receive the multicast feeds and other multicast content. Increasingly, some form of IPv6 connectivity is desirable. Like many academic computer centers, the IETF terminal room and LANs get 24 hour use for the duration of the meeting. While users do not N. Bourbaki Expires 01.03.12 [Page 2] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 expect staffed support at all times, they do expect the network to remain up even at 2AM. IETF attendees often do not recover from jet lag or operate on hacker [JARGON] schedules. A number of IETF old-timers consistently show up on the Saturday prior to the meeting; clever terminal room staff will leverage them in helping to crimp, cable, and configure the terminal room setup. Historically, terminal room staff who take a crisp officious view on when the terminal room and wireless LAN first become available are less successful than those who take a more flexible and friendly approach. While set-up will take a very large staff, if it has been done well, the staff needs during the meeting are small. General experience has been three to four people during the day, with some spares able to cover during meals etc. Having someone on cell phone or in the same hotel at night is prudent. Most IPv4 multicast traffic originates from one of the two concurrently operating multicast Working Group sessions. However, some multicast will be originating outside and consumed by IETF attendees in the terminal room. It is helpful if the IPv4 multicast router supports IGMPv2 [RFC-2236]. While current use is primarily IPv4 unicast or IPv4 multicast, in future the terminal room SHOULD also provide some form of IPv6 connectivity. If IPv6 [RFC-2460, RFC-2463] is deployed in the IETF network, at least IPv6 Neighbor Discovery [RFC-2461] with stateless autoconfiguration [RFC-2462] SHOULD be enabled to enable plug and play networking. 2.1 LAN Separation As they seem to interfere with each other, at least three separately routed LAN segments SHOULD be used for the terminal room, wireless ethernet, and multicast services. In particular, the high speed multicast feed exceeds the capacity of the wireless ethernet, and therefore MUST be separate. In case multicast causes wireless problems, be prepared to keep all IP multicast traffic off the wireless LAN. 2.2 Meeting Infrastructure Connectivity The registration desk SHOULD be provisioned to accommodate the Secretariat's firewall and LAN. It is also helpful if the Wireless LAN (more below) has good coverage around the registration desk. N. Bourbaki Expires 01.03.12 [Page 3] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 The IAB/IESG meeting room SHOULD have LAN coverage, preferably wireless. 2.3 Meeting Rooms Two of the meeting rooms MUST be provisioned for origination of IP multicast audio/video content. The IETF Secretariat will specify which rooms shortly before setup. 2.4 Mains Power Availability A scattering of mains power outlets in all meeting rooms is much appreciated by laptop-based attendees. Having a few power strips in the lobby, bar, and other places laptop users congregate is also much appreciated. Wireless folk use large qualities of power strips. Attendees appreciate having advance notice of which sort of power (i.e. voltage, frequency) and which sort of power connector will be present at the meeting location. This permits attendees to obtain appropriate adapters and widgets before coming to the meeting. This information SHOULD be included on the IETF meeting web page and SHOULD also be included in a message to the IETF Announce mailing list. 2.5 Wireless LAN Drops to connect the wireless ethernet base stations SHOULD be supplied at strategic locations throughout the facility. The primary targets should be large gathering areas with seating, e.g. the lobby and bar areas. All meeting rooms SHOULD have wireless coverage if at all possible. Historically, IETF used Digital RoamAbouts, the proprietary pre- standard WaveLAN technology that operated at 915 MHz (and 2.4 GHz outside North America). Recently, the IETF user base has been moving to the new IEEE Standard 802.11 wireless LAN technology at 2.4 GHz. This transition is now largely completeand the new IEEE 802.11 wireless standard [IEEE-99a] is dominant in the IETF user base. The IEEE standardized two incompatible variants within the 802.11 standards. One variant uses a Frequency Hopping Spread Spectrum (FH) technique. This is commonly called IEEE 802.11-FH. The second, far more widely deployed, variant uses a Direct Sequence Spread Spectrum (DS) technique. This is commonly called IEEE 802.11-DS. N. Bourbaki Expires 01.03.12 [Page 4] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 The IETF Wireless LAN MUST support at least the 802.11-DS technology. As these systems are able to automatically scan all the channels, the terminal room operator SHOULD configure immediately adjacent Access Points to use different channels within the 2.4 GHz band. The IEEE recently approved a higher-performance (11 Mbps) extension [IEEE-99b] to the basic 802.11 specification. The 802.11 Access Points SHOULD be configured to support the 11 Mbps speed. However, the Access Points SHOULD NOT be locked to only support 11 Mbps, as some attendees will have older PCMCIA cards that only operate at the older, slower speeds. It is assumed that attendees using wireless use (self-supplied) end-to-end encryption (e.g. SSH, ESP) or are suicidal. So the wireless network itself is run in the clear, i.e. encryption is turned off. If parameter values are chosen which are different from those described in this document, substantial advance public notice MUST be given to the IETF Announce mailing list and on the IETF meeting web page. Any additional wireless types beyond the IETF supported wireless standard, IEEE 802.11-DS, and all applicable user configuration parameters SHOULD be announced on the IETF meeting web page and to the IETF Announce mailing list well before the meeting so that attendees have an opportunity to obtain compatible adapters for their laptops. Examples of possible wireless additions include the older proprietary 915 MHz or 2.4 GHz RoamAbouts and/or 802.11-FH. 2.5.1 Wireless LAN (IEEE 802.11-DS) The IETF 802.11-DS systems and 802.11-FH systems have one primary configuration parameter. This is variously called "ESS ID", "Network Name", or "Network ID", depending on which documentation one is reading. This parameter MUST be set to the 4 character string "IETF" in all capital letters for the IETF 802.11 wireless LANs. Encryption SHOULD be disabled (see comment in 2.5 above). 2.5.2 Wireless LAN (Historic) Support for the older proprietary RoamAbout 915 MHz and 2.4 GHz systems MAY be provided as a convenience to those attendees yet to convert. The proprietary RoamAbout 915 MHz and 2.4 GHz wired- to-wireless bridges have parameters global to all bridges which MUST be set as follows: N. Bourbaki Expires 01.03.12 [Page 5] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 Domain ID: 0x1 Beacon key: 0x1E1F The proprietary RoamAbout 915 MHz and 2.4 GHz wired-to-wireless bridges have a Network ID (NWID) parameter that MUST have a unique value for each bridge location and which SHOULD be set as follows: 1st location's NWID: 0xAAAA 2nd location's NWID: 0xBBBB 3rd location's NWID: 0xCCCC 4th location's NWID: 0xDDDD and so forth. For users whose laptops do not support roaming, a map detailing the location of each bridge and its associated NWID SHOULD be provided. 2.6 Cabling IETF networks have been crippled when very long ad hoc fiber runs have been inadvertently smashed by workfolk and others, and no spare cable was available. Spares should be kept, and it might be advisable to mark the runs with caution tape (so users know where to kick), etc. 3. Network Services A lot of stress is put on DHCP, printing, and everything else. 3.1 Network Outlets Laptop users outnumber users needing desktop platforms. Currently one terminal room 10baseT Ethernet laptop drop per 15 attendees is comfortable. 10baseT Ethernet (e.g. RJ-45 connector) is sufficient, as 10base2 Ethernet has essentially disappeared, particularly in the laptop computer community. 3.2 DHCP Service A very wide range of DHCP clients are in use within the IETF community. The DCHP server SHOULD be widely interoperable and fully conformant to the DHCP standards [RFC-2131, RFC-2132]. Specifically, a WIDE DHCP or an ISC DHCP server running on a UNIX platform is strongly recommended until other DHCP servers have demonstrated better compatibility and standards-compliance. The IP address pool MUST be large enough to avoid shortages given constant connection churn. N. Bourbaki Expires 01.03.12 [Page 6] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 Repeated experience indicates that it is desirable to have a sufficiently large pool on standby to permit rolling over DHCP servers without making a mess. The Internet Registries have a temporary Class B (or equivalent) address that may be used if they are asked nicely. Of course it has to be registered routed to the WAN. The DCHP server will likely have to serve multiple subnets. This will also require router configuration. The DHCP lease timeout must be set short enough to roll over leases quickly (where 'quickly' is relative to the address space available for the pool) while not overwhelming the network with renewal requests. A lease lifetime of one hour appears to work well if address space is short. A lease lifetime of days can be used if there is a large free address pool. Too long a lease time followed by address pool shortage has been a problem at past meetings. Moderation in all things. Support for IPv6 DHCP has been provided but seldom used. It is appreciated by the (very few, if any) IPv6 users. 3.3 Static IP Addresses A pool of IP addresses for static assignment to laptop users without DHCP is necessary for approximately one client per 20 attendees. We do not know why that number is so high. There SHOULD be a mechanism at the help desk to allocate and register their use. Providing for allocation by email before the meeting is kind to those who need to configure security parameters with their normal home/corporate network prior to the meeting. The static IP allocation process SHOULD be announced to the IETF Announce mailing list well before the meeting. 3.4 Printing Printer services are very like those in a small computer center. Two paper printers SHOULD be provided, and a third for spare is advisable. The printing rate is about .05 PPM / attendee, and a typical attendee prints approximately 15 pages during the meeting. At a recent meeting, the desktop terminal room printer used twice the amount of paper than the laptop room (which was twice the size). This suggests that people who bring laptops don't print as much, copying documents to hard drives instead. N. Bourbaki Expires 01.03.12 [Page 7] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 One transparency printing facility MUST be provided. The transparency printing rate is about .01 PPM / attendee, and a typical attendee prints approximately 1.5 pages during the meeting. A reasonable alternative to a transparency printer is a copier machine with transparencies loaded. Such a copier SHOULD be clearly marked as being loaded with transparencies, lest someone erroneously attempt to use it to create paper copies. Users seem to be happier if at least one Postscript compliant laser printer is available. It is helpful to indicate in advance whether the printers will be supporting standard A4 paper or the strange but patriotic American 8.5x11 inch paper. Many laptop users are running some version of UNIX. It is helpful if these users can print documents without resorting to proprietary printing protocols. Accordingly, at least one printer that supports the BSD Line Printer (LPR) protocol [RFC-1179] SHOULD be provided. Configuration parameters for this printer SHOULD be posted in the terminal room. Deployment or use of the Internet [sic] Printing Protocol (IPP) is negligible, which is not actually on the Internet standards track, so supporting this is purely optional. Absence of IPP support is unlikely to create a furor among the IETF user base. Non-printer transparencies MUST NOT be available near the printers, or someone will put them in a printer and ruin it. Macintosh and MS-Windows systems need a print spooling server, either Samba-based or NT-based. A Samba-based approach will facilitate the use of the same printers for users of any OS and has worked well in the past. 3.5 Transparencies The cost of transparencies and their tendency to jam printers often warrants manual queue operation. It is kind to train a local and a nocturnal denizen or two in queue-running to reduce whining at three in the morning. 3.6 Mail Service A local SMTP server SHOULD be available for those whose home servers will not do mail forwarding for clients with strange DNS names and/or unknown addresses. This server MUST be configured to accept SMTP relay only when the source IP address is within N. Bourbaki Expires 01.03.12 [Page 8] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 the IETF LAN address space, as the IETF does not wish to contribute to SPAM. 3.7 Time Service An increasing number of users are running either NTP [RFC-1305] or SNTP [RFC-1769] on their laptops. A local NTP server SHOULD be available to serve ntpdate requests for users and to chime with locals who run NTP clients. The NTP parameters SHOULD be clearly documented in the terminal room. A UNIX ntpd daemon is strongly recommended. 3.8 Domain Name Service At least two local DNS servers MUST be available to users. Caching DNS servers are preferred. The IP addresses of these servers MUST be posted in the terminal room and SHOULD be included in the terminal room documentation supplied in the registration packet. 3.9 Server Load Considerations Consider splitting the UNIX server functions over more than one machine. Print spooling or X duty may bog down a single server. Consider one server for print queue and Xhost, another for DHCP and SMTP relay, and a third for NTP and DNS. Isolate the critical and non-critical server functions on different machines so a non-critical function, like print queuing, if it stalls or hangs the machine, won't stop DHCP and DNS. 3.10 Web Proxy/Cache As noted later, it is helpful to have all of the IETF RFCs and Internet-Drafts archived on a local server. Ideally this is accessible via http and also ftp. In some situations, performance can be boosted by providing a web proxy cache. If one is used, it is preferred that it NOT be of the 'transparent web cache' variety, due to concerns about the compatibility of such devices with all forms of web-based content. If a 'transparent web cache' will be used, this MUST be disclosed to users via the IETF Announce list prior to the meeting. It is reasonable to configure web browsers on the provided desktops to use the web proxy by default, provided users are able to disable this manually if needed. N. Bourbaki Expires 01.03.12 [Page 9] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 3.11 Help Desk The help desk SHOULD be staffed from early morning to late evening by people of patience and clue. As many attendees are rather experienced, their questions can be rather technical. Of course, like the typical user population, they also have less sophisticated needs and temperaments. An emergency contact number SHOULD be available when the help desk is not staffed. 3.12 Office Supplies A small stash of office supplies such as staplers, tape, markers, etc. is often much appreciated. It has been suggested that a lively market could develop in RJ4x adapters, RJ11 kits, AC plug converters, local phone to RJ11 adapters, etc. Small ethernet hubs have also proven useful for network debugging, etc. 3.13 Advanced Technology While it is tempting for a host/vendor to show off fancy technology at an IETF, this audience runs and uses the most arcane assortment of services, and is a very poor place to find out that your fancy new switch breaks when someone tries to run IPv42 through it. Run a simple production network. If one must run a technology demo, isolate it onto a separate network segment so that it is unable to interfere with the production network. 3.14 Failed Technology Two attempts have been made to use ATM LAN Emulation, aka LANE, as the primary backbone protocol connecting all ethernet switches and routers at IETF meetings. Both attempts were disasters. Some have asserted that IETF traffic patterns are unusually unsuited to LANE. You MUST NOT try to use LANE. 4. Computer Systems Some users prefer UNIX and X11, while others prefer MS-Windows or Macintosh. Many users are agnostic. But UNIX and Linux bigotry is increasing. The number of laptops is increasing, so the need for supplied desktop systems seems to be declining markedly. Its preferred that the terminal room support multiple platforms, though there have been successful terminal rooms with only one system or the other. Macintosh users tend to being their own systems and so Mac systems need not be supplied in the terminal room. Some folk need commercial tools (MS-PowerPoint, StarOffice, WordPerfect, etc.) to prepare presentations. N. Bourbaki Expires 01.03.12 [Page 10] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 Approximately one workstation per 20 attendees is more than adequate. The percentage of laptop users within the community has continued to increase to the extent that we now believe that approximately one desktop system per 30 or more attendees is sufficient. Some months before the meeting, the IETF Secretariat gives the local host an estimate of the number of attendees. 4.1 Desktop Software All provided desktops need at least the following: standards-compliant web browser SSHv1 client X11 server (i.e. the user/display portion) Telnet client FTP client It is very helpful if the following are also provided: One-Time Passwords (OTP) [RFC-2289] generator Adobe Acrobat (PDF) reader miscellaneous other plug-ins for the web browser 4.2 Presentation Tools A dozen desktops with presentation software applications SHOULD be provided for those very few working on presentations at the last moment in full panic. These SHOULD have floppy drives for folk who must use sneaker-net to move files around. 4.3 Environmental Air conditioning for the entire terminal room SHOULD be sufficient for the time of year, the heat load from the machines, and a lot of people. 5. Documentation As the users' needs mature, so do their expectations of documentation. It is helpful to document information about the terminal room and LAN facilities before the meeting on the IETF meeting web page. A summary should be provided in the registration packet. Full updated information should be posted in the terminal room. N. Bourbaki Expires 01.03.12 [Page 11] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 5.1 Address Plan Some weeks before the meeting, the network prefixes (with netmask) to be used SHOULD be announced on the IETF Announce list. This allows users with security issues to have their home networks adjusted if necessary. 5.2 Handout A single-page document SHOULD be included in the attendees' registration packets explaining the network layout, addressing, workstation facilities, printing facilities, LPR parameters, NTP parameters, SMTP parameters, wireless parameters, et cetera. 5.3 Opening Session A short presentation on the terminal room and wireless LAN arrangements is usually given by the local host at the opening session. 5.4 IETF Documentation A full on-site mirror of the RFC and I-D directories will lower demand on the circuits as well as the associated servers. The address of the mirror should be stated loudly in all documentation. It is also helpful to post this in the terminal room. An ftp-accessible or http-accessible on-site repository is desirable, even if one is using a caching web proxy of some sort. 6. Security Considerations As in most computer facilities, physical as well as network security is important. 6.1 Physical Security Physical security is difficult, with attendees walking in and out with laptops and other gear at all hours. The guards SHOULD be told to expect strange things, but to not let large equipment walk out without a green badge. Equipment has been "lost" in the past just before, during, or just after an IETF. Secure on-site storage for boxes and equipment makes life a lot easier. N. Bourbaki Expires 01.03.12 [Page 12] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 6.2 Network Security Network security is traditional, see the Site Security Handbook [RFC2196]. The IETF network has been attacked from the outside a number of times. The risk of attack on the IETF network seems to rise over time. The IETF network SHOULD be configured to perform source IP address filtering in accordance with [RFC-2267]. Any SMTP servers configured with mail relay enabled, SHOULD disable relaying from outside the IETF network. Enabling MD5 authentication of any routing protocols in use (e.g. RIPv2, OSPFv2, BGP4) is recommended to reduce risk of a routing-based attack. There have been exciting incidents where laptop users have inadvertantly run DHCP servers, started forwarding packets on the same wire, etc. If each computer drop (desktop or laptop) is on its own switched port, it aids in both finding the culprit and in rapidly reconfiguring for damage mitigation. It can be helpful if the switches have port filtering and RMON capabilities. It is believed that written warnings to users against these dangerous configurations are both prudent and ineffective. 7. Prudence Spares of all critical components, workstations, switches, routers, etc. SHOULD be on-site. "A fool and their data are soon parted." -- M Williams 8. References [IEEE-99a] IEEE, Information Technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications. ISBN 0-7381-1658-0, 1999. [IEEE-99b] IEEE, Information Technology -- Telecommunications and information exchange between systems -- Local and metropolitan area networks Part 11: Wireless LAN Medium Access Control (MAC) and Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band, ISBN 0-7381-1809-5, 1999. [JARGON] E. Raymond (Editor), The New Hacker's Dictionary, MIT Press, September 1996. ISBN 0-262-68092-0. Also, http://www.tuxedo.org/~esr/jargon N. Bourbaki Expires 01.03.12 [Page 13] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 [RFC-1179] L. McLaughlin, Line Printer Daemon Protocol, RFC-1179, August 1990. [RFC-1305] D. Mills, Network Time Protocol version 3, RFC-1305, March 1992. [RFC-1769] D. Mills, Simple Network Time Protocol (SNTP), RFC-1769, March 1995. [RFC-2131] R. Droms, Dynamic Host Configuration Protocol (DHCP), RFC-2131, March 1997. [RFC-2132] S. Alexander & R. Droms, DHCP Options and BOOTP Vendor Extensions, RFC-2132, March 1997. [RFC-2196] B. Fraser, Site Security Handbook, RFC-2196, September 1997. [RFC-2236] B. Fenner, Internet Group Management Protocol version 2, RFC-2236, November 1997. [RFC-2267] P. Ferguson, Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC-2267, January 1998. [RFC-2289] N. Haller, A One-Time Password System (OTP), RFC-2289, February 1998. [RFC-2460] S. Deering & R. Hinden, IP version 6 Specification, RFC-2460, December 1998. [RFC-2461] T. Narten et alia, Neighbor Discovery for IPv6, RFC-2461, December 1998. [RFC-2462] S. Thomson & T. Narten, IPv6 Stateless Address Autoconfiguration, RFC-2462, December 1998. [RFC-2463] S. Deering, Internet Control Message Protocol for IPv6, RFC-2463, December 1998. 9. Acknowledgments The author is indebted for very constructive contributions by a number of IETF local hosts, the IETF Secretariat, a NANOG local host, some operators of large networks, a Dutch geek, an amateur linguist, and of course Mr. (sorreeee) Wireless. N. Bourbaki Expires 01.03.12 [Page 14] INTERNET-DRAFT IETF Meeting Network Infrastructure Lore 00.09.12 10. Author's Address N. Bourbaki 666 Rue le Jour Sophia-Antipolis nbourbaki@ops.ietf.org 11. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. N. Bourbaki Expires 01.03.12 [Page 15]