 documents known as request for comments (RFC). The RFC document tradition, going back to the original RFP 1, has a history stretching back over 50 years. The RFC editor is directly respons- ible for the publication of the RFC, under the general direction of the Internet Architecture Board (IAB). To get adopted, a specification undergoes a period of development and cycles of review and updates by the Internet community. This is not an easy process, because even the status of "Draft Standard" requires at least two completely independent implementations of the standard that have been demonstrated to interoperate. Eventually the revised document is adopted as a standard and is pub- lished, but only when it has gained substantial operational maturity and a significant number of suc- cessful implementations. The IETF divides its work into various areas, and each focus area has its own set of working groups: Applications and Real-time Area (art): Develops application protocols and architectures for "real-time" applications-voice, video, instant messaging, and SO forth, applications that may be more tolerant to delay-HTTP, email, FTP, and SO forth; and applications that have a wide range of use across real-time and nonreal-time deployments-Uniform Resource Identifier (URI) schemes, Multipurpose Internet Mail Extensions (MIME) types, authentication mechan- isms, codecs, and SO forth. General Area (gen): Focuses on updating and maintaining the IETF standards development process. Internet Area (int): Includes the IP layer (both IPv4 and IPv6), co-existence between IP ver- sions, issues associated with IPv4 address space limitations, DNS, Virtual Private Networks (VPN), and pseudo-wires and Multiprotocol Label Switching (MPLS)-related issues, mobility, and SO on. Operations and Management Area (ops): Includes network management, Authentication, Au- thorization, and Accounting (AAA), and various operational issues with the DNS, IPv6, secur- ity, and routing. The IETF further divides ops into two separate functions: Network M