Director's Message I knew it would happen, but not to this degree. It is getting to be a tradition to begin this message with a pronouncement that we have just concluded yet another record breaking meeting, and the San Jose IETF meeting was no exception: the most IETF attendees (1079), the most on-site registrations (176), the most first timers (448), the highest number of remote multicast hosts (725), the highest number of countries listening in to the IETF multicasts (25), even the most expensive orange juice! Acknowledgments I believe everyone will agree that the ``Internet Room'' provided by Sun Microsystems was one of the most ambitious efforts to date. Much of the credit for the setup goes to Cathe Ray and Carl Smith for taking care of everything, and to Bob Hinden for providing these two people. I also want to thank the many volunteers (and the conscripts - you know who you are :-) for the time and energy they put into providing Internet connectivity to the IETF meeting attendees. The configuration of the terminal room facilities depends a great deal on the generosity of equipment vendors and service providers, and I want to thank the following organizations for their contributions and assistance: Sun Microsystems Workstations and Servers Hewlett-Packard X-terminals and Net Advisor Cayman Systems Gator Boxes Proteon Routers Lancast Hubs Barrnet Internet Access Pacific Bell Three T1 Lines Interop Warehouse Staging and Equipment Internet Multicasting Service A/V Multicasts NASA/Ames Secondary Internet Connection What is the IETF? This question was asked during the open plenary meeting, and while many were holding their breath in anticipation of an answer (or opinion), there was no definitive response. Instead, a follow-up question was posed: Why do you ask? Why indeed. The structure and organization of the IETF has gone through significant changes over the past two years. The Poised effort of 1992 redefined the roles and responsibilities of the IAB and IESG. The IESG is now responsible for standards track activities while the IAB is focusing on architectural issues. Another change is that IAB and IESG members are now selected, by a nominating committee of volunteers, to serve two year terms. Everything about the Internet is growing: public awareness, confusion, books and articles, more confusion, users, vendors, access software and hardware, routing tables, the number of people participating in the activities of the IETF, etc. The TCP/IP Protocol Suite is gaining acceptance on all fronts, and other standards organizations are establishing liaisons with the IETF, opening the door for other organizations to reference (and use!) Internet standards. More and more, people and organizations, users and vendors, are affected by the actions of the IETF. The IETF has an honored tradition of open specifications, readily available to anyone at no cost. The IETF also requires that it have change control over its specifications. As such, a deliberate effort is taken to avoid adopting technical specifications which require use of patented technology. However, the IETF also has a tradition of producing the best specifications, and sometimes a solution involves use of a patented technology. Over the past few years, the subject of Intellectual Property Rights, particularly copyrights and patents, licensing, and a concern over liability, has received a considerable amount of attention and discussion. The issues involved in obtaining permissions, rights, and licenses are very complex and provide yet another challenge for the IETF: to address these legal concerns, the rapid growth of the IETF, and the continuing evolution of the Internet while retaining the open pioneer spirit of the IETF. The IETF has demonstrated, time and time again, that a group of cooperating individuals (often business competitors) can work together to develop protocol specifications and provide solutions to benefit the entire Internet Community. This characteristic needs to be demonstrated in the future. Who is the IETF? While pondering the question of what is the IETF, I asked myself another: who is the IETF? Who shows up at the meetings? The same old crowd, or an ever increasing number of newcomers? Perhaps looking at some historical data will provide some answers, or some interesting observations. Over 3300 people have attended one or more of the previous 20 IETF meetings. 70% of these folks have attended one or two meetings. 13% have attended more than five meetings, and 4% have attended more than 10 meetings. Of the 3300, only six have attended all of the last 20 meetings. Attendance at IETF meetings continues to grow. My first meeting was in Atlanta (July, 1991) where there were 387 attendees. There were almost three times as many attendees at the San Jose meeting. The number of groups meeting has grown from 54 in Atlanta to 77 in San Jose (though there was one meeting when over 80 groups met during the week). The terminal room in Atlanta was relatively small, contained about 15 workstations and a printer, and was closed at midnight! There has been a recent explosion in the size and complexity of the terminal rooms. San Jose had 60 workstations and terminals, a number of LANs, and its own NOC! What about all these newcomers? Over 35% of the attendees at a meeting will be first-timers. Over time, though, 43% of these newcomers (or 16% of the attendees) will attend only one meeting. Those numbers are for the past 20 IETF meetings. When looking at the past two years (six meetings), almost 60% of the newcomers will be attending their first and last IETF meeting. Of the 200 first time attendees at the previous IETF meeting (Toronto), only 57 (28%) returned to attended the San Jose meeting. Interesting statistics, but what do they all mean? We are in for [still more] interesting times! Future Meetings The next IETF meeting will be in Danvers, Massachusetts the first week of April (April 3-7, 1995), and is being co-hosted by FTP Software and NEARNet. Following Danvers, NORDUnet we will be our hosts for the meeting in Stockholm, Sweden July 17-21, 1995 (our second time in Europe). MCI will host the final meeting of 1995 in Dallas, Texas on December 4-8, 1995. Note that information on future IETF meetings can always be found in the file 0mtg-sites.txt which is located on the IETF Shadow Directories. Or, you can check the IETF Home Page on the Web. Our URL is: http://www.ietf.cnri.reston.va.us/home.html Stephen J. Coya Executive Director, IETF IETF Progress Report The IESG and IETF have been very active since the Toronto IETF meeting last July; 166 Internet-Drafts, 29 Protocol Actions, and 58 RFCs were produced. Between the IETF meetings in Toronto and San Jose, there were eleven working groups created: 1. Site Security Handbook (SSH) 2. IPNG (IPNGWG) 3. New Internet Routing and Addressing Architecture (NIMROD) 4. SNMP Version 2 (SNMPV2) 5. Inter-Domain Routing (IDR) 6. Quality Information Services (QUIS) 7. HyperText Markup Language (HTML) 8. Address Autoconfiguration (ADDRCONF) 9. Authenticated Firewall Traversal (AFT) 10. TFTP Extensions (TFTPEXTS) 11. Responsible Use of the Network (RUN) Ten working groups were concluded: 1. TELNET (TELNET) 2. Border Gateway Protocol (BGP) 3. OSI Directory Services (OSIDS) 4. User Documents Revisions (USERDOC2) 5. OSI IDRP for IP Over IP (IPIDRP) 6. Networked Information Retrieval (NIR) 7. Minimal OSI Upper-Layers (THINOSI) 8. Modem Management (MODEMMGT) 9. Relational Database Management Systems MIB (RDBMSMIB) 10. Simple Internet Protocol Plus (SIPP) Additionally, 58 RFCs have been published since the Toronto IETF meeting in July, 1994: RFC Status Title RFC1650 PS Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2 RFC1664 E Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables RFC1666 PS Definitions of Managed Objects for SNA NAUs using SMIv2 RFC1667 I Modeling and Simulation Requirements for IPng RFC1668 I Unified Routing Requirements for IPng RFC1669 I Market Viability as a IPng Criteria RFC1670 I Input to IPng Engineering Considerations RFC1671 I IPng White Paper on Transition and Other Considerations RFC1672 I Accounting Requirements for IPng RFC1673 I Electric Power Research Institute Comments on IPng RFC1674 I A Cellular Industry View of IPng RFC1675 I Security Concerns for IPng RFC1676 I INFN Requirements for an IPng RFC1677 I Tactical Radio Frequency Communication Requirements for IPng RFC1678 I IPng Requirements of Large Corporate Networks RFC1679 I HPN Working Group Input to the IPng Requirements Solicitation RFC1680 I IPng Support for ATM Services RFC1681 I On Many Addresses per Host RFC1682 I IPng BSD Host Implementation Analysis RFC1683 I Multiprotocol Interoperability In IPng RFC1684 I Introduction to White Pages services based on X.500 RFC1685 I Writing X.400 O/R Names RFC1686 I IPng Requirements: A Cable Television Industry Viewpoint RFC1687 I A Large Corporate User's View of IPng RFC1688 I IPng Mobility Considerations RFC1689 I A Status Report on Networked Information Retrieval: Tools and Groups RFC1690 I Introducing the Internet Engineering and Planning Group (IEPG) RFC1691 I The Document Architecture for the Cornell Digital Library RFC1692 PS Transport Multiplexing Protocol (TMux) RFC1693 E An Extension to TCP : Partial Order Service RFC1694 DS Definitions of Managed Objects for SMDS Interfaces using SMIv2 RFC1695 PS Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2 RFC1696 PS Modem Management Information Base (MIB) using SMIv2 RFC1697 PS Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 RFC1698 I Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications RFC1700 S ASSIGNED NUMBERS RFC1701 I Generic Routing Encapsulation (GRE) RFC1702 I Generic Routing Encapsulation over IPv4 networks RFC1703 I Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures RFC1704 I On Internet Authentication RFC1705 I Six Virtual Inches to the Left: The Problem with IPng RFC1706 I DNS NSAP Resource Records RFC1707 I CATNIP: Common Architecture for the Internet RFC1708 I NTP PICS PROFORMA For the Network Time Protocol Version 3 RFC1710 I Simple Internet Protocol Plus White Paper RFC1711 I Classifications in E-mail Routing RFC1712 E DNS Encoding of Geographical Location RFC1713 I Tools for DNS debugging RFC1715 I The H Ratio for Address Assignment Efficiency RFC1716 I Towards Requirements for IP Routers RFC1717 PS The PPP Multilink Protocol (MP) RFC1718 I The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force RFC1720 S INTERNET OFFICIAL PROTOCOL STANDARDS RFC1721 I RIP Version 2 Protocol Analysis RFC1722 DS RIP Version 2 Protocol Applicability Statement RFC1723 DS RIP Version 2 Carrying Additional Information RFC1724 DS RIP Version 2 MIB Extension RFC1725 DS Post Office Protocol - Version 3