Internet Engineering Task Force IESG INTERNET-DRAFT July, 1991 An Internet Evolution Plan For The IETF 1 Status of the Memo This document is a working paper by the IESG to guide future work in the Internet. It will be submitted to the RFC Editor as an Informational document. Please send comments to IESG-FYP@nri.reston.va.us. Contents 1 Status of the Memo 1 2 Introduction 7 3 Description of IAB and IETF/IESG organization 9 4 Setting the Goals and Overall Agenda for Internet Evolution 10 4.1 Goals -- One (arguably arguable) vision of the future 10 4.1.1 ``Integration'' 10 4.1.2 The Ubiquitous Internet 10 4.1.3 New Technology 11 4.1.4 Diversity 12 4.1.5 New Service Providers 12 4.1.6 Transition from ``Old'' to ``New'' 13 4.1.7 New Uses of the Internet 14 4.1.8 How to Get to the Future 15 INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4.2 Agenda -- Categories for focus in IESG Planning 15 4.2.1 Planning for Coordinated Global Operations 16 4.2.2 Enhanced Protocol Infrastructure 17 4.2.3 Enhanced Applications and Services 17 4.3 Multi-protocol Integration 18 5 Technical Planning for Applications 19 5.1 Area Overview 19 5.2 Goals 19 5.3 Specific Work 20 5.3.1 Information Representation 20 5.3.2 Information Applications 21 5.3.3 Directory Services 21 5.3.4 Information Retrieval 22 5.3.5 Personal Communication Applications 23 5.3.6 Person-to-group communication 23 5.3.7 Group scheduling 24 5.3.8 Operational Applications 24 6 Internet Area Plan 26 6.1 Area Description 26 6.2 Area Technical Goals 27 6.2.1 Routing and Addressing 28 6.2.2 Congestion Control and Resource Management 29 6.2.3 Configuration 30 6.2.4 A New IP Packet Format 31 6.3 Specific Actions 32 IESG [Page 2] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 6.3.1 Addressing 32 6.3.2 Congestion and Resource Allocation 32 6.3.3 Configuration 32 6.3.4 Security 33 6.3.5 High Speed Switch Architectures 33 6.3.6 IP Encapsulation 33 6.3.7 Media Support 33 6.3.8 Router Requirements 34 6.4 Host Requirements 34 6.4.1 IP Specification 34 6.4.2 ICMP Specification 34 7 Network Management 35 7.1 Area Goals 35 7.2 Specific Work 36 7.2.1 Comprehensive Instrumentation 36 7.2.2 Maturity and Deployment 36 7.2.3 Multi-Protocol Context 37 7.2.4 Cooperative Foundation 37 7.2.5 Product Range 38 7.2.6 Scope 38 7.2.7 Secure Operation and Administration 38 7.2.8 Architectural Effectiveness 39 7.2.9 Enriched Management Applications 39 8 OSI Integration 41 8.1 Area Overview 41 IESG [Page 3] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 8.1.1 OSI in Internet in 1995 41 8.1.2 Physical & Link Layer 41 8.1.3 Network layer 41 8.1.4 Transport 42 8.1.5 Applications 43 8.2 Specific Work 44 8.2.1 Physical and Link Layers 45 8.2.2 Transport 47 8.2.3 Applications 48 8.2.4 Network Management 51 8.3 An Infrastructure for OSI 51 9 Operational Requirements 53 9.1 Description 54 9.1.1 Provide a forum for coordination between operational groups 54 9.1.2 Development of operational methods, practices, and policies 55 9.1.3 Guidance to other IETF technical development efforts 55 9.2 Technical Goals For The Operational Requirements Area 57 9.3 Specific Actions For The Operational Requirements Area 58 10 Routing Area Plan 60 10.1 Description of Routing Area 60 10.2 Technical Goals for the Routing Area 61 10.2.1Internet Growth - Routing should not be the limit to growth 61 10.2.2Provide Routing Protocols for Future Environments 61 10.2.3Provide for Multivendor Interoperation 62 IESG [Page 4] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 10.3 Specific Actions Required 62 10.3.1Standardize on one Interior Routing Protocol 62 10.3.2Define Requirements to Advance Internet Routing Protocols to Draft Standard and Full Standard| 62 10.3.3Deploy BGP to Replace EGP 63 10.4 Develop Routing Protocols for Large Data Networks 63 10.4.1Authentication of Internet Routing 63 10.4.2Routing and Addressing Architecture 64 11 Security Area Plan 65 11.1 Objectives and Overview 65 11.2 Objectives 65 11.2.1Arenas of activity 65 11.3 Specific Work) 66 11.3.1Protocols 66 11.3.2 Policies 69 11.3.3 Standards and Development 70 11.4 Organization 70 11.4.1SAAG 70 11.4.2PSRG 70 12 Transport and Services Area 72 12.1 Description 72 12.2 Technical goals 72 12.3 Current and future actions 72 13 User Services 74 13.1 Area Overview 74 IESG [Page 5] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 13.2 Goals 75 13.2.1 User Information 75 13.2.2 Network Information Services Infrastructure 76 13.2.3 Network Operational Management 76 13.2.4Education 77 13.2.5 Documentation and Distribution 77 13.2.6Interaction with IESG Areas 77 13.2.7 Interaction with other User Services Organizations 78 13.3 Goals 78 13.3.1User Information 78 13.3.2 Network Information Services Infrastructure 81 13.3.3 Network Operational Management 82 13.3.4 Education 84 13.3.5Documentation and Distribution 86 IESG [Page 6] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 2 Introduction This document is an initial draft of an Internet evolution plan for the IETF. It is submitted for comment and review by the Internet Engineering Steering Group (IESG) of the IETF. The motivation for developing this document is to give specific shape and form to the general directions for IETF guidance that have developed in the IESG over the last 1-2 years. It is also intended to make this available for widespread review and comment by the IAB and broader community. It is assumed that IAB and community feedback will play a large role in shaping the final document. The IETF has always been a completely open organization. Submitting this document for open review and comment is in keeping with the IAB/IETF goal of a completely open process. The IESG is currently composed of the following technical ``Areas'' and Area Directors: IETF and IESG Chair: Phill Gross/CNRI Applications: Russ Hobby/UC-Davis Internet and Noel Chiappa/Consultant Philip Almquist/Consultant Network Management: James Davin/ MIT OSI Integration: Rob Hagens/UWisc and Ross Callon/DEC Operational Requirements: Phill Gross/CNRI Bernard Stockman/Nordunet Susan Estrada/CERFnet Routing: Robert Hinden/BBN Security: Steve Crocker/TIS Transport and Services Dave Borman/Cray User Services Joyce Reynolds/ISI Standards Management: Dave Crocker/DEC IESG Secretary: Greg Vaudreuil/CNRI In sections 3 through 10 of this document, Area Director(s) have individually contributed ``Area Plans'' for each IETF area. Each ``Area Plan'' follows the same general outline. o Description of Area (eg, topics covered, topics not covered, relation to other areas) o Technical goals for the Area (ie, Description of what advancements are needed in this area to work toward overall goal of Internet evolution o List of specific actions required to accomplish goals in section IESG [Page 7] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 (b). Some actions may already in progress in IETF WGs. For any action not currently in progress, the intent is to include a short description, timeframe, and priority for each action, suitable for broadening into a prioritized list of WG charters. Section 1 of this document is meant to provide an overview of the history, organization, practices, procedures of the IAB and IETF/IESG. This may be useful for those not already familiar with the IAB and its structure. It may also help justify the IAB as an Internet-wide (ie, international) organization. (This section has not yet been written.) Section 2 discusses the overall goals for Internet Evolution. In a subsection, we discuss one (arguably arguable) vision of the future Internet. The intent was to motivate and guide the ``technical goals'' sections in each of the individual Area plans. In another subsection, we lay out broad categories for focus in IETF Planning. This is meant to act as a broad ``technical agenda'' for the IETF -- that is, these are the broad categories for IETF activity taken from a slightly different point of view than the strict ``Area'' breakdown. I'd like to thank the entire IESG for the work involved in developing this initial draft. I'd also like to thank IESG Secreatary Greg Vaudreuil for his important contributions to this and other IESG activity. This is a great start -- with feedback from the Internet community, the next draft should be even better. Phill Gross IETF Chair IESG [Page 8] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 3 Description of IAB and IETF/IESG organization To Be Provided IESG [Page 9] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4 Setting the Goals and Overall Agenda for Internet Evolution 4.1 Goals -- One (arguably arguable) vision of the future In this section, we discuss one vision of the future Internet. The intent was to motivate and guide the ``technical goals'' sections in each of the individual Area plans in sections 3 through 10. 4.1.1 ``Integration'' We can expect the future Internet to be ``integrated'' into the fabric of normal society in several ways. The Internet will be ``geographically integrated'', by which we mean that it will be physically ubiquitous. The Internet will be ``socially integrated'', meaning the Internet will become a ``commodity''. It will be commonly used by people everyday without a great deal of thought to the underlying infrastructure. It will be accessed by commercially available equipment and through commercially provided services. It will be used by commercial concerns and individuals as commonly as it is used for research and education today. Finally, the Internet will be ``technologically integrated'', meaning it will accomodate older and newer style technologies and multiple services and protocols. 4.1.2 The Ubiquitous Internet Currently, wherever you go, telephones are an integral part of the modern world-wide infrastructure. Moreover, the most powerful thing about telephones is that most can directly contact any other telephone, not just telephones in the same organization or site. The Internet will be everything that phone service is now, but far more powerful and flexible, and even more integral to daily life in every way. In basic terms, this means that in the year 2010 there might be 100 million networks and 1,000 million end users in a worldwide interconnected service featuring bandwidths up to 100's of gigabits per second. The Internet will change the way that society communicates and relates. People will talk to each other because of common interests without the restriction of geographic location. Unlike the phone, which is used primarily for one-to-one conversations, the Internet allows global group discussions and sharing amoung all those interested in a subject. The Internet makes the whole world your neighborhood. Perhaps, the most noteable aspect of the future Internet is that, like the phone system today, no one will ``notice it'' unless it breaks, that is, no one will give much thought to the IESG [Page 10] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 underlying infrastructure unless it stops providing the expected routine service. 4.1.3 New Technology Network connections and typical end user machines will be quite different. Within 10 years, the current difference between PC and workstation capabilities will be eliminated. The typical ``PC'' at that time (ie, found in many homes and most offices) will be a 100 MIPS workstation, with 1 gigabyte disk, 100 megabyte memory, and high-resolution color graphics screen. On the otherhand, preoccupation with speed and storage size will become less important. For example, who cares how many MIPS and bits are in your TV or Phone. It just does the job. The most important part of this future ``PC'' will be the input and output devices. High-definition video and stereo sound will be commonplace. In fact, the network will become both an important input and output device to the ``PC''. The network may also be a storage device for the ``PC''. Most industrial network connections will be a gigabit/second or greater to accomodate the bandwidth requirements of advanced applications. In the home environment, T1 connections (or whatever it takes to allow some reasonable form of compressed video images) will be common. As the community served by the Internet grows, there may come a decreased emphasis on computing and traditional data communications as the primary use of the network. Although traditional computer applications like electronic mail will continue to be an important use of the network, integrated network services bearing voice and video information are likely to dominate bandwidth consumption. The future internet will commonly carry both compressed and uncompressed audio and video, because the relative economy of compression and transmission technologies will vary with location, time, and application. To support this integration of services, the future Internet will incorporate fairly elaborate facilities for articulating and realizing service guarantees (e.g., bandwidth, latency) and resource allocation policies. Moreover, these guarantees and policies will be effected in the network by efficient mechanisms that exploit statistical economies. Users will be able to select the level of service that they expect from the Internet. They will be able to select the network service provider they want to use to carry their traffic for specific applications. For example, One carrier may be used for business IESG [Page 11] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 communication, another for entertainment, and yet another for bulk data retrieval. 4.1.4 Diversity Just as relevant as the tremendous growth in Internet transmission speeds will be the tremendous growth in the *range* of transmission speeds and technologies that a truly ubiquitous Internet must accommodate. This technological heterogeneity is not only inevitable: it is desirable. Although it complicates the technological integration of the Internet, only by broad technological variety can Internet users properly balance their service requirements against the cost of their participation. As the Internet grows increasingly commercial in both its operation and use, technological variety will be central to its social value. The underlying network might be based on new and different hardware technologies but that will unimportant to most users because the actual underlying technology will be transparent to them. In 10 years, network management will work! The MTBF and MTTR for average service will be the same as telephone service. There will be no intermittent lapses in service due to ``routing loops'' or ``black holes''. The routing problem will be ``solved'', and it will be invisible to the user. 4.1.5 New Service Providers Part of the reason for this ``invisibility'' of the network is that major telephone companies will have entered the networking market in a big way. Networking will be a ``commodity'' service like telephone service or PC's today. Prices will be affordable to home users for what would be considered very high-end services today. However, in line with the trends of decentralization in the telephone system, we will contine to see large portions of the network run by non-carriers, especially at the fringes, or where a large user can economically provide his own service over leased physical assets. The greater flexibility of the Internet will help drive this trend. Legal limitations on the character of services provided by common carriers may contribute to this diversity of administration in the future Internet. Security will no longer be an issue because it will have integrated into every facet of the technology and service. People will not have to think about it. All applications will be secure (exchanges will be authenticated and private), and all network services will have authentication and access control. Not only will security services mediate the use of network resources, they will enable the network as IESG [Page 12] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 a medium for commerce --- the network will be a market both for familiar tangible products and for innovative information services that are themselves delivered via the network. 4.1.6 Transition from ``Old'' to ``New'' It is likely that the system will still be in some stages of transition at this point, particularly in the less developed regions of the world. This means there is also likely to continue to be a wide mixture of environments within this new system. Old lower speed connections (eg, 9600 baud dial-in modems and 56 Kbits/second) may still be in service in places in the system. And remnants of the current networking hierarchy are likely to still be in place (eg, local campus ethernets connected by old style routers, and regional or campus-based networks based on IP routers as switches). Higher speeds (for reasons apparently based on the usual laws of physics, thermodynamics and economics) will continue to cost more than lesser speeds. Although bandwidth is likely to decrease in cost, deliberate over-provisioning will continue to be an unattractive solution to resource allocation and performance problems. For reasons which include the broad user base, the wider range of more demanding applications, and the increasingly commercial character of the future Internet, the system will accomodate a wide dynamic range of capabilities and will still have to worry about backward compatibility with old-style systems. This, in addition to the need for robustness and reliability, will place a premium on features that can isolate bad behavior (eg, non-conforming hosts, pockets with low security, lower quality network management,etc). The new systems will have to be fault tolerant of non-conforming systems. The local environments will auto-configure themselves as part of a higher level network management scheme. All local configuration parameters will either be assigned by the network or, for a basic ID, burned into ROM. The network will ``remember'' each host, so that it will boot up into the same configuration whereever the host is located. This will allow ``mobile hosts'' like palmtop and notebook computers to be used anywhere with the same environment as at the local home or office. In particular, the cellular telephone network will be one component of the future Internet infrastructure, and, in general, relatively low-bandwidth devices (e.g., telephones, PCs, personal locators) may often enjoy ``wireless'' connections to the Internet. IESG [Page 13] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4.1.7 New Uses of the Internet In the future Internet, phone answering machines and Faxes will have had their day. Such services will be provided to each desktop in the home and office environment by the ``PC''. There will be a wider range of high-capability applications available on the network. The Internet will look like a combination of the phone company, the post office, the cable TV company and others. Commercial applications and services will be routinely available. Desktop video conferencing will be common service (and may pose a rival to normal phone service in office, if not home environments). Transaction processing will experience an enormous growth as the network gains the ability to handle these with reliability and securely, and as the network spreads ubiquitously. Electronic mail will continue to grow and play an increasingly important role in everyday life (home and office). Because of the large volume, we will need vastly different paradigms and user interfaces to be usable. Of course, electronic mail will be fully multi-media, with voice, video, and graphics-prepared documents common. Actual storage of most data will be handled by a replicated, centrally backed up distributed file system, access to which is over the network from most ``PC''s. Entertainment will consume a growing prortion of the bandwidth of the internet. This will range form conventional video's to interactive multi-party simulation games. Some potentially serious issues relating to ``information explosion'', eg, electronic junk mail and electronic mail overload, will be solved in innovative ways. To the extent that a ubiquitous Internet may enable anonymous product discovery and advertisement, it may help avoid the potential erosion of personal privacy due to electronic junk mail. The compilation and use of consumer profiles to support directed marketing may decline when consumer choices can be shaped as much by pro-active interrogations of online product databases as by reactive responses to unsolicited advertising. For old-fashion physical mail, it takes much longer to send mail than to receive it. For Email, it is much faster to send one message to 2000 recipients (or, in the Internet of the future, 100,000,000 recipients!) than to receive 2000 messages. Plus, the very nature of the Internet is to increase the ``community'' with which you normally interact. In the past, you might interact with your office or your department. With the Internet, you interact with a larger and more geographically dispersed community. This results in chronic email overload. Although email has become the staple for interacting in this large diverse environment, it is not uncommon for current Internet users to be behind in reading email. It is also not uncommon IESG [Page 14] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 for important pieces of email to quickly become ``lost'' in large online ``folders'' of email. In the future, new paragigms, tools, and applications, including sophisticated database management methods, will have to become available to manage this inevitable ``information explosion''. 4.1.8 How to Get to the Future To reach this environment will require us to solve many thorny technical problems that we've known about for years but are only now beginning to fully understand. These problems include -- scaling, deployment, coordinated management and problem resolution, high speed transport, congestion control, advanced routing, auto-configuration, connection and transaction oriented support for applications that need it, issues resulting from scaling (such as consumption of addresses and increased address size), directory services (white and yellow), and work on high-capability applications (like multi-media electronic mail). Providing performance guarantees appropriate to new applications will be necessary to support technological integration of services in the future Internet. Support for a broad range of resource allocation policies will be necessary to the technological integration of multiple services and to the social integration of multiple administrations in the future Internet. Support for a broad range of security policies will be necessary to the social integration of multiple administrations in the future Internet. Perhaps the biggest issue of all, however, will be the transition from the old regime to the new! We will not have the luxury of leaping to the new regime. We will have the problem of dealing with the old installed base. (We can term this the ``MS-DOS problem''!) Plus, until the bright new day of networking arrives, we will have to worry about the installing and deployment of the new technologies as they arrive. 4.2 Agenda -- Categories for focus in IESG Planning In this section, we lay out broad categories for focus in IESG Planning. This is meant to act as a broad ``technical agenda'' for the IETF -- that is, these are the broad categories for IETF activity taken from a slightly different point of view than the strict ``Area'' breakdown. IESG [Page 15] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4.2.1 Planning for Coordinated Global Operations This category covers issues in the Operational Requirements and User Services Areas. o Higher-level Operational Issues We need to develop ``plans'', ``policies'', and multi-lateral agreements to coordinate the following issues on a global scale. These involve issues that require coordination and planning between high-level organizations. Topics include: - Coordination and planning of network interconnections - (eg, international links ) - Coordination and planning of Global routing - Coordination and planning of Global DNS operations - Coordination and planning of Global IP address and DNS name registration issues o Lower-level Operational Issues These issues involve coordination and interaction at a local level. Issues in this category might include implementation of policies/procedures/technology agreed upon in the above ``Higher-level'' category. Topics include: - NOC coordination * liaison * end-end trouble reporting/resolution * common methodologies * shared information * well defined interaction and division of responsibilities with NICs * etc. - NIC coordination * liaison * common terminology * common user interfaces * wide availability of common information shared across boundaries * well defined interaction and division of responsibilities with NOCs * etc. - Definition of common methodologies and procedures (common mapping formats; set of common performance metrics, common measurement tools/methods and common display formats; etc) IESG [Page 16] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4.2.2 Enhanced Protocol Infrastructure This category covers issues in the Internet, Routing, Network Management, and Security Areas. The issues in this category involve the basic protocol architecture. Topics in this category include the usual suspects: o expansion of address space o advanced inter-domain routing o Relation between addressing and routing o general attention to scaling o high speed transport for new network services (eg, SONET speeds) o congestion control o connection-oriented support for application that need it o etc, etc Topics in this category have traditionally been those dealt with best by the Internet research community. For example, the upcoming IAB Workshop on Internet Architecture should shed considerable light on topics in this area. 4.2.3 Enhanced Applications and Services This category covers issues in the Applications and Security Areas. (Also, perhaps, issues in the Operational Requirements and User Services Area.) These include the development of enhanced network services. Some examples are below. Many others exist and should be added! o Email - multimedia support - national character set support - better configuration/operational/problem-resolution support - etc o Security - need security support for at least the ``core'' services on a case-by-case basis, (eg, routing, net mgmt, email, remote login) - need more comprehensive infrastructural support for broader security capabilities (eg, access control, privacy, authentication, etc) IESG [Page 17] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 4.3 Multi-protocol Integration We should concentrate on ways of allowing all technologies to utilize the common plant. Interoperation has always been a key goal in the Internet. We should stress the non-denominational goal of ubiquitous interoperation. The Internet is primarily based on TCP/IP services. However, the installed base of connections and equipment opens up the possibility of even wider interconnection between other protocol technologies. OSI is the obvious example. Topics in Multi-protocol Integration include: o General non-Internet protocol integration and interworking - SNMP MIB development for non-Internet protocols - IP-over-Foo-net-technology - Foo-protocol-family-over-IP - For some cases: Foo-protocol-family-over-Foo-net-technology, (eg, Decnet-over-PPP) - Non-Internet applications over IP (eg, NNTP, FAX over IP, OSI applications over TCP/IP) - Application gateways between IP applications and similar applications in other protocol families (eg, any of the various email gateways) - etc. o OSI integration and interworking -- in each case below, these topics are meant to be considered solely in the context of the Internet. The IAB/IETF do not have direct change control over OSI standards, so any OSI topics considered in the Internet must be constrained to the area of profile development and deployment planning. - Overall, integrated, planning for OSI integration - into the Internet - CLNS deployment planning - NSAP/addressing formats - IS-IS routing development/deployment - X.400/X.500 definition/development/deployment - Connection-oriented/Connection-less interworking - Application gateways between OSI and Internet applications - etc. IESG [Page 18] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 5 Technical Planning for Applications 5.1 Area Overview We, as the engineers of the Internet, have had a tendency to look at the network from the bottom of the protocol stacks looking up. We have mainly focused on how we get the bits across the network and not so much how they are used. We have now created a large network with many users. It is time for some of us to look at it form their point of view. In planning for the future of applications on the Internet, we need to answer a few questions. What do the users want to do with the network? What resources are available on the network today? Do they meet the needs and expectations of the users? If not, what do we do next? Let's look at the network from the users view point. There are at least three, and probably more, types of applications. First there are applications for the searching, retrieval, and distribution of information. Next there are applications for personal communications and finally there are operational applications for use in the general computing environment. To bring these applications to life, we need to agree on formats for information, such as character sets, graphics format, file structures and command syntax. Most of these formats do not have a standard definition for the Internet. Worse yet, there are many groups claiming to be developing the standards but there is no coordination among these groups. Thus, we are being faced with choosing one of several overlapping standards. We also need the tools to create network applications. Many applications have lower level functions in common, such as authentication, remote procedure calls, and remote file operations. These are functions that the Transport and Services Area and Security Area need to provide for a base on which to build the new Internet applications. 5.2 Goals One of the first things that we need for the Internet is to define the common set of information formats. Without these, we will have no way to use the information that we are exchanging. Once we have defined what the information will look like, then we can figure out what we really want to do with it. After we have defined the information formats, we can then define the applications to locate, move, manipulate, and display that information in a wide variety of ways built on the lower layer tools provided by IESG [Page 19] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 the other areas. 5.3 Specific Work 5.3.1 Information Representation For information exchange between systems to be useful, it must be in a format that is understood by the system so that it can be presented to the user. This enters into the world of multimedia where the user wants to have text, image, sound and video on the desktop. Function What's Needed Text Information in the form of text is compact and can be edited after retrieval. However, the ASCII character set is not the only one used on the Internet any more. The use of multiple character sets needs to be defined. Image We need to standardize a format for the presentation of images on the Internet. The format should be flexible for various resolution and color combinations and have compression capabilities. Several organizations are working on this problem but we don't need multiple standards confusing users and leading to noninteroperability. Graphics We need to standardize a graphics format for vector graphics. Vector graphics can represent graphs and drawings in a concise, editable manner, but there needs to be agreement on format. With such a format, one could imagine things like architectural blueprints being transported over the network. Video A standard video format is also needed. Unlike Image and Graphic formats, the video format has to worry about real-time delivery. Compression of the data will also be important to keep the data streams to a minimum bandwidth. Audio/Analog We need to standardize a format for sound representation or for analog signals to be sent on the Internet. Although audio will be the primary use for this format, all types of analog signals could be transported this way. The format should be flexible for various bandwidth capabilities and allow compression. Display We will need a standard display format so that applications can have a uniform screen environment for information presentation to the user. X-windows is a IESG [Page 20] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 good example and may indeed be the standard that we need. Data Objects While most computer languages and operating systems have standard data objects, such as integers, floating points, strings, etc, we need a standard form of exchange on the network for these items. These will be especially important for the inter-process functions such as remote procedure calls. 5.3.2 Information Applications There is already a vast amount of information on the Internet, but it is not easy to find or access. We need applications to help search for and retrieve information, and standard formats for that information so that something can be done with it after we retrieve it. 5.3.3 Directory Services First let's look into finding the information or directory services. People using the network want to find information on other people, services and information bases on the Internet. They also want to find it without having to know where it is in the first place. In other words, to do a global search. Probably the best directory service that we have on the Internet today is the Domain Name System. Although DNS still has some problems, it shows that a system that is globally managed but locally maintained does work. It is also well integrated into the system such that the user never really knows that they are using it. Function What's Needed People Lookup We need a globally coordinated locally maintained people directory. WHOIS and FINGER are used some but the data is not well coordinated. We need to determine if X.500 meets the immediate need. Resource Lookup We need a system to find a variety of resources such as databases, software, super- computers, or specialized devices. The FTP site list just isn't good enough. Document Lookup Many libraries have card catalogs on line, but the systems are usually incompatible with each other. We IESG [Page 21] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 need a global system. We particularly need to be able to locate documents that are on line. Some groups are looking into Z39.50 as a solution. 5.3.4 Information Retrieval Once you locate the information, you would like to retrieve it. Currently you can TELNET to the information source and view it there; or FTP the information to your location and process it locally. In many cases, what is desired is more of the client- server model where just the information needed is retrieved and is processed locally. Function What's Needed File Resources People want not only to transfer files, but also to do software archiving and distribution. FTP needs some updates to allow for transfer of file attributes and archive creation and retrieval functionality. Remote Database People want access to all types of databases on the Internet. We need to standardize the client/server protocols used over the network. Work will continue on the standardization of SQL over TCP/IP. Info Server Sites want to setup client/server information systems. With client/server systems each entity providing the service can also be responsible for the resources to store and provide the information. Likewise, those wishing to retrieve the information (clients) provide the equipment. Standardization of this service will allow development of different user interfaces in the clients to suit the users and allow access to any information server. Windowing We need to standardize a method for establishing screen window connections for the presentation of the information. We spoke of the window format above, but we also need a way to establish the connection across the network for a window. Currently TELNET is the only standard in this class of functions. However, it is suitable for text only and is missing many functions desired by todays users. X- windows again may answer this problem. IESG [Page 22] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 5.3.5 Personal Communication Applications Three types of personal communications that people seem to want are person-to-person, person-to-group, and calendar/scheduling. Person-to-person is communications to one person or a small known group of people and include functions such as electronic mail, talk/chat, video conference and, of course, the telephone. Function What's Needed Email SMTP and RFC822 need updating to completely separate the message delivery and message format functions. Delivery needs to make sure that a block of data is delivered. Message format needs to be updated to allow for various body parts such as text with other character sets, binary data files, images, and sound. Email Maintenance Email lists on the Internet are, for the most part, maintained manually. There is a desire for automatic maintenance and distributed delivery systems for email lists. The BITNET LISTSERV function has done this quite well for many years. It is time to have this functionality on the Internet. Message Handlers Currently most email users receive and store their message on a single host that is on the network all the time. Message systems need to be standardized to allow store and forward of messages for computers that are connected to the network part-time. There is also a desire for multiple host mail message systems that allow users to maintain their mail on several computers. POP, PCMAIL and IMAP are starts in this area. Conference System Interactive text conference systems seem to have limited functionality. Most people just can't type fast enough. More work needs to be done on text/voice/image/video conference systems and standards for the Internet. Standards for image and voice formats mentioned above will help in this work. 5.3.6 Person-to-group communication Person-to-group is a broadcast type of communication where you are communicating with a large unknown group. This includes services such as forums and bulletin boards. USENET is probably the most popular type of this service currently available. IESG [Page 23] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Function What's Needed BBS/Forums USENET/NNTP have done quite well in this area. However, it is not now a standard and the system needs to be updated to consider efficiency and the current size of the Internet. 5.3.7 Group scheduling For the third type, imagine that you could maintain your personal calendar on your own computer. Now imagine that your calendar could talk to all other calendars on computers all over the Internet and schedule people, rooms and other resources. This is the type of functionality that people want of network calendar/scheduling. Function What's Needed Scheduling The whole system needs to be defined, and standardized. 5.3.8 Operational Applications There are network functions that are associated more with distributed computing rather than communications. These generally have to do with resource sharing of devices such as printers, disks, backup storage and to some extent, CPUs. Back in the ``old days'' of computers and mainframes, users had to know where each peripheral was and how to access it. Operating systems have now made that invisible to the user on individual computers. When it comes to network resources, however, we have jumped back twenty years. You still need to know where each resource is on the network and how to access it. We need to use what we have learned in operating systems and apply it to networks. Think of the network as a computer buss with lots of CPUs and peripherals hung on it. The network is the computer. Now we just need to write a user friendly operating system for this new computer. The real problem, of course, is that with single computers it has been just one vendor that has had to coordinate within itself. With networks, we are operating in a multi-vendor environment and coordination means that we need standards. Function What's Needed IESG [Page 24] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Network Printer We need the ability to plug a printer into the network and allow controlled access from anywhere on the network. Network FAX Network FAX is like a printer but uses a FAX machine instead. We also need to be able to connect to FAX machines that are not on the network. Backups We need to define a way to do disk backups over the network. Modifying FTP for archiving may solve this problem too. Remote Programs We need to define and standardize a means to run a program on a remote computer but have it look like it is running locally. REXEC for UNIX does this but is too centered on UNIX. The window standard and information formats above are important aspects of this function. IESG [Page 25] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 6 Internet Area Plan 6.1 Area Description The Internet Area covers, broadly speaking, that portion of the architecture which is responsible for delivering packets from one host to another. Thus, this area covers such topics as operation of IP on all local media, the functions of routers, and low-level inter-network control mechanisms such as ICMP. The Internet Area does not include routing, which is its own area due to its complexity. Addressing is technically a part of the Internet Area, but because of the close ties between addressing and routing, it is and must continue to be coordinated closely with the Routing Area. Because the distinction between the Internet Area and the Routing Area can be constraining, it is hardly surprising that the Area with the closest relation to this one is the Routing Area. Router Requirements (in this Area) and IP over Large Public Data Networks (in the Routing Area) are good examples of current projects where the two Areas overlap, and this overlap can only be expected to increase as we seek new solutions to the very difficult problems of addressing and routing in a very large network. However, the Internet Area also has significant interactions with most of the other IETF areas. Work here is obviously of some interest to both the Applications Area and the Transport and Services Area, since they utilize the services of the Internet Layer, particulary to the latter as we start to tackle the issues of resource allocation, and congestion control. Both the Network Management Area and the Operations Area have focused much of their attention on the management of services which fall within the Internet Area. Security is of course a major concern of this Area, as of most Areas, and one which has received too little attention in the past. This area will be working closely with the Security Area to ensure that security is designed into new services and, when possible, retrofitted into the existing ones. There are several other areas of inter-Area cooperation which would be worth pursuing, but where collaboration in the past has been hampered by difficulties in finding volunteers with the time, expertise, and energy to pursue them. For example, the Internet Area (in conjunction with the Operations Area) probably ought to provide more technical support than it has in the past to efforts within the User Services Area to demystify the procurement, installation, and management of IP hosts and routers. Likewise, the Internet Area probably needs to work more closely with the OSI Integration Area as the latter works to transform the fabric of the Internet from a (predominantly) IP-only network to truly multi-protocol network. Collaboration with the OSI Transition Area should also try to ensure that efforts in the Internet IESG [Page 26] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Area can benefit from the ideas, and when appropriate even the protocols, developed in forums such as ISO, ANSI, and the CCITT. 6.2 Area Technical Goals The general goal for this Area are to provide ubiquitous packet level service at high speeds throughout the world. The existing architecture at the packet level is fairly successful, and the system in the future should present much the same appearance the the average user, although much larger and (in most places) much faster. To the users, the only noticeable changes will be that more controls are available for implementing policies, both in controlling where traffic flows, and how resources are allocated when contention for them exists. These tools will aid the transition of the data communications system to a commercially viable and available infrastructure. The system as it stands has three main places where work is needed in the medium term. The first is in addressing and routing; this work is mostly in the Routing Area, but has some overlap into the Internet Area. The second is in congestion control and resource allocation; service guarantees are part of this issue. It was felt that these conditions are too dynamic to handle with routing in a system this large; separate mechanisms are needed. Some work has been done on this, but further research is needed. The third is in the area of configuration; the system at the moment is far too dependant on complex configuration by skilled personnel. The system simply cannot continue to grow if this continues; the system should be self-configuring where possible, and where not, the configuration should be both simple and strongly resistant to faulty configuration. These are the three largest problems, since they have substantial technical components of some difficulty. The other area needing work is of a different nature; security needs to be added (where appropriate) throughout the architecture, and this Area is no exception. Little can be done until Routing is i) secure and ii) provides better tools, but at that point it should be possible for users with security needs to obtain the level of service they need from the system. The system should also become better prepared to handle denial-of-service attacks, although this will probably depend in part on the congestion control work above. Clearly, service guarantees cannot be met if the system is not secure! Other than these points, the system appears to have handled past growth quite well, and while many new technologies have been deployed, and the system has grown quite a bit, it has all fit in fairly smoothly. Some minor points which were left unhandled in the original architecture are being dealt with, such as Router Discovery and MTU Discovery, but handling these has not required a major effort. In general, most existing unhandled small issues are being handled by IESG [Page 27] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 recently created efforts. Additional areas needing work in the medium term time frame are wider deployment of multicast capabilities, development of high speed switches, rationalization of the various network level support functions (primarily those currently in ICMP), and specifications for wrapping various other network protocols in IP and vice versa (principally CLNP) but these topics do not appear to present any fundamental challenges and should happen in short order. A number of additional standards documentation efforts are also needed. Further codification, in clear and complete fashion, is needed on the running and demultiplexing of network layer protocols (with obvious emphasis on IP) on various media. Particular attention needs to be paid to clearly addressing framing methods, address mapping techniques, access methods, and detection of and recovery from hardware faults. We anticipate starting an effort to address these issues once Router Requirements has been completed. This effort will produce a Link Layer Layer Requirements document, which will be applicable to both hosts and routers. This effort will also codify what needs to be included in future IP over XXX RFCs. A new version of the Host Requirements document set will also need to be produced (in cooperation with the relevant Areas), though this is not a pressing issue in the short term. Because of the substantial manpower requirements of such an effort, it probably cannot be started until after the completion the Link Layer Requirements effort. 6.2.1 Routing and Addressing Routing is mostly in the Routing Area, but is of interest to the Internet Area in two ways. First, it is quite likely that the next Internet routing architecture will explicitly recognize the fact that data usually passed through the Internet in identifable collections, which are being called 'flows'. Taking cognizance of this (although without storing any critical state in the network, merely 'hints') allows very effective mechanisms that meet certain problems to be deployed, not only in the routing area, but in others such as access control and resource allocation. For example, access control can be an expensive operation to implement if every packet must be considered individually: individual switches often have complex access control policies, and checking each packet aginst these policies can be expensive. Flow identification allows considerable efficiencies in this, by making the check only once, when the flow is set up. Following packets are only checked for their membership in the flow, not against the complete access control policy. IESG [Page 28] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 In addition, the routing of packets through the system, which is currently done on a hop by hop basis, will quite likely in the future be more completely controlled by the source, to allow the users more policy control over the flow of their packets through the system. Second, it appears that the existing IP address architecture is unsuitable for long-range growth, and needs to be redone. The existing addresses are both too small, and lack enough structure to be useful in a really large network. A new address structure will have to be designed and deployed. A final scheme has not yet been picked, but the are good arguments that the address design should be an integral (and dependant) part of the design of a new routing protocol (i.e. the addresses should be whatever makes the job of the routing protocol easiest), so the primary technical content for this work will come from the Routing Area. As a side effect of some of the schemes, the IP model may be enriched by the concept of a host identifier (separate from the concept of network attachment address), which would allow work to meet some longstanding goals of the architecture, such as moving hosts. 6.2.2 Congestion Control and Resource Management Another area in which flows can perhaps usefully help is in the are of congestion control and resource allocation. When congestion happens, having a history of past behaviour can be useful in identifying which host needs to be told to decrease its resource usage. Also, if guarantees of available resources in the future are to be made, the system needs some way of identifying the entity that 'owns' those resources. Some very good work has been done in handling congestion with respect to long-lasting flows at fairly constant rate, but new applications, such as remote file access (as opposed to, say, file transfer) will subject the system to demand patterns which are more variable, and it is clear that the system is not prepared to deal with this. The most serious point to be recognized here is that almost anything done in the way of handling congestion control will require cooperation from all the hosts in the Internet, which means that all the hosts in the system will have to be modified. Since this is a lengthy and laborious process, for practical logistical reasons, this work needs to be commenced as soon as possible; the longer the delay, the more painful putting it into service will be. However, unlike the routing problem, a lot of full time research in the congestion control area remains to be done before the outline of the correct solution is avaiable. The spectrum of control mechanisms ranges from a pure feedback system (in which information about IESG [Page 29] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 conditions in the network is sent back to the source of the traffic) to a pure reservation system (in which resources must be reserved before any traffic can be sent). Proposed solutions to the problem range along this spectrum, and there are good theoretical arguments for each proposal. Some work has been done in this area by various researchers, but things are not yet at the state where only engineering remains. These researchers have come together under the umbrella of the End-to-End Task Force of the IAB, and are making good progress in their work, but a definitive answer is not yet clear. Probably large-scale experimental experience will be necessary before it is possible to make a single recommendation as to the architecture to be followed in this area. 6.2.3 Configuration As the Internet becomes more ubiquitous, it becomes increasingly important to simplify the addition of new nodes to the network. Hosts and routers often require extensive manual configuration by a person with a fair amount of technical knowledge before they can communicate on the Internet. Although this is perhaps not as immediate a constraint on Internet growth as are the addressing and routing problems described earlier, we do need to make an effort to reduce the number of knobs and switches that have to be correctly set in order to communicate. To the extent which we are not successful in that goal, we need to further refine our practical knowledge of how to make the system be tolerant of misconfigured hosts and routers. The exact steps that we ought to take to make configuration simpler are far from obvious, though some have suggested that the Appletalk protocol family might have some approaches which we could usefully adapt. And some progress is already being made: Router Discovery will eliminate the need for one particularly mystical bit of host configuration, and Dynamic Host Configuration will make it much easier for organizations to centralize host configuration, making it less necessary for individual system managers (or even work station users, in an extreme but very common case) to be fluent in the configuration of host networking software. Configuration complexity is something that we need to give increased weight to when we evaluate future protocols and changes. This is also an area where we need to work with the other IETF areas, since configuration complexity is a problem which is hardly limited to the lower layers of the protocol stack (in particular, the bulk of the configuration of the lower layers is involved with routing and addressing, the domain of the Rouing Area). Probably the lead in this area should be in the hands of either the Operations Area or the User Services Area. IESG [Page 30] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 6.2.4 A New IP Packet Format There is some feeling that the new address format, together with changes in such areas as resource allocation and policy routing, will make the existing IP packet format obsolescent, and that an effort should be started now to design a replacement. This idea has merit, but at the moment it appears that this should be delayed. The counter-argument goes that the world of data communications is above to receive a substantial upheaval based on the deployment of new technologies such as ATM fabrics, and that as a result of that, ten years down the road, the environment will be fundamentally different, and any protocol designed at this point will be incorrect for it. For instance, if the ATM fabric is the ubiquitous data transport mechanism, a classical layer 3 might not be needed at all. It is not clear whether this is in fact the path we face. There are arguments that physics and economics will continue to mandate a range of data transmission technologies, much as these forces have kept a range of storage media, from RAM through disk, in existence over a far longer period than was expected. In any case, it seems wise to delay action on this matter until a clearer view of the future is available, but only if no pressing need is being supressed. Clearly, if some major problem needs a new IP packet format to be solved, then this decision will have to be revisited, but at the moment it does not appear that this is the case. Solutions are available for the two major problems listed above which do not mandate the immediate deployment of a new IP packet format. (This has the obvious side benefit of saving valuable resources, both in protocol design effort as well as deployment.) A number of new addressing and routing architectures have been proposed which do not require a new packet format. Among these are at least one which proposes a very agressive new architecture, the full benfit of which would not be available until a new packet format is available, but which can be deployed in its (effectively) final form without changing the format. The benfit of this is obvious; when and if a new packet format is deployed, it will not be crippled by an addressing and routing architecture which was unable to target all the goals it should have since it had to work with the old packet format. The situation is less clear in the resource allocation and congestion control area, since the work there is somewhat less advanced, but from early indications it appears that the same is effectively true there as well. IESG [Page 31] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 6.3 Specific Actions In reviewing these actions for priority, it is clear that the new addressing/routing work must be given a high priority, as the lead time is substantial, and the work difficult. An equally high priority must be given to the work on resource allocation, since the changes to the hosts need to be undertaken as soon as possible. Since both are likely to use the 'flow' mechanism, there does need to be coordination between the two efforts. 6.3.1 Addressing Very short term solutions to the address space depletion problem will be investigated by a working group convened for that purpose. The likelihood is that we will experience problems with the address space before a full solution is available, and this group will investigate simple, easily deployable patches to extend the life of the existing addressing architecture to allow a good job to be done on the replacement. That group will be formed shortly, and we will be paying close attention to it in order to ensure that that group reaches a conclusion in fairly short order. Development of a longer term solution will be left to the Routing Area, since it is critical that the solution also address the problem of the explosion in the amount of routing information. Because we view this as critical to the long term success of the Internet, we expect to make substantial contributions to that effort. 6.3.2 Congestion and Resource Allocation It appears that is not yet quite time to start developing the effort in this area, since until a clearer idea of the congestion control and resource allocation architectures (which probably are not the same, although they will probably be closely related) is available the effort will be slightly groping in the dark. It is slightly premature to say what WG structure will be needed since it is unclear to what degree the transport protocols, etc will have to be modified, if at all. 6.3.3 Configuration Short term, we will be working on two projects. First, we will attempt to wind up and then progress through the standards process the IESG [Page 32] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Router Discovery effort. Second, we will work with the Dynamic Host Configuration to brind that effort to fruition in a timely manner. There are currently no longer term plans in this area, though we will continue to look for attractive avenues to pursue. 6.3.4 Security The security problems will need WG's set up to address individual areas of concern, but the main security problem at the packet layer is in the routing, and once again this must wait on the new routing architecture. There are existing efforts to define IP options for security labelling in both the U.S. military and the commercial domains. These efforts are outside of the Internet Area. 6.3.5 High Speed Switch Architectures It does not appear that the Area needs to sponsor work on high speed switches, since a number of commercial entities are doing this. 6.3.6 IP Encapsulation A working group to specify the encapsulation of IP in CLNP and vice versa needs to be spun up, in conjunction with the ISO Area. This is not expected to be difficult, but mayh not be done in the short term because of an apparent lack of personnel to carry this effort through. 6.3.7 Media Support A number of working groups to specify the support of IP on various media are currently operational, and no major media are unspeccified. Some of the early efforts could use revisiting, a problem we will be addressing through the Link Layer Requirements effort. We intend to defer that effort until Router Requirements is complete, since we don't think that adequate manpower will be available until then. We will continue to start up groups as necessary to specify IP over new media types that are developed. IESG [Page 33] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 6.3.8 Router Requirements The current Router Requirements effort is expected to complete in the Fall. Long term another revision will be needed, but not for several years and not until the Link Layer Requirements and the revision of the Host Requirements are completed. There have been a few suggestions that Router Requirements will need an addendum to cover non-IP protocols, most notably CLNP. We have no plans to pursue that at this time. 6.4 Host Requirements Once the Router Requirements and Link Layer Requirements are complete and their authors have had a short rest to recoup energies, the Host Requirements update can be undertaken in cooperation with the Transport and Application Areas. 6.4.1 IP Specification There are a number of areas where the architecture has evolved but the specifications have not. Short term, we will be beginning an effort to specify the use of variable width subnets and another effort to study the use of multiple logical networks or subnets on a single physical network. We don't expect that either of these efforts will be terribly difficult, but they do need to be done. We would also like to produce a modern specification of subnetting, since this seems to be an area of considerable mystery to many network managers. At this point, we don't know whether the manpower which would be necessary to do this can be found. 6.4.2 ICMP Specification The ICMP Protocol currently is documented though a basic document, and then tangentially in a number of more recent documents. Also, the protocol contains some obsolescent feaures which have been replaced by more powerful equivalents. A clear document needs to be created, and obsolescent mechanisms removed. This effort will also be low priority due to the lack of manpower. IESG [Page 34] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 7 Network Management This chapter outlines a plan for Internet network management in the next five years. It includes an overview of the current state of internet network management, a description of relevant goals, and a plan for realizing those goals. The Network Management Area of the IETF engages in discussion, definition, and evolution of common mechanisms for the management of host systems, gateways, bridges, modems, terminal servers --- in short, all of the devices that may be present in a managed internet. Owing to the management need to instrument all relevant functions in each network element, the network management activity has a natural overlap with IETF areas that focus on those functions (e.g., Internet, Routing, Applications). The NM Area comprises all activity that pertains to the management of network elements that implement the TCP/IP protocol suite. This definition includes the activities of numerous IETF Working Groups that are based on the SNMP network management framework as well as the use of OSI management mechanisms in the context of the TCP/IP protocol suite. The management of pure OSI devices deployed within the internet is a concern of the OSI Area of the IETF. The NM technology currently deployed in the internet is the SNMP network management framework. It is widely deployed and supports the operation of production networks on a daily basis. The SNMP framework currently comprises a common methodology for defining management information (RFC 1155), a common management protocol (RFC 1157), and common instrumentation for core aspects of the TCP/IP protocol suite (RFC 1215). In addition, management instrumentation has been developed for a wide range of device types and functions. While a certain portion of the deployed instrumentation is of proprietary origin, the use and value of such instrumentation in this framework is often comparable to that based on common definitions. The evolution of network management technology must address the challenges of ubiquity, reliability, and both technological and administrative heterogeneity posed by the future internet; at the same time, it must not compromise those aspects of existing mechanisms that are ultimately of greatest value to network operators and users alike --- their operational robustness and capacity for broad deployment. 7.1 Area Goals The overall goal of the network management activity is to provide a robust and ubiquitous infrastructure that assists network administrators in assuring the operational availability of network services --- both in the short-term (e.g., by fault isolation, configuration, or security functions) and in the long-term (e.g., by IESG [Page 35] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 performance analysis or accounting functions). Implicit in this overall goal are a number of aspirations for the future NM infrastructure in the internet. 1. To address the issue of reliability in the future internet, it should realize common management services consistently with the robustness, ubiquity, and cost requirements that distinguish network management systems from other network applications. 2. To address the issues of reliability, ubiquity, and technological heterogeneity in the future internet, it should afford common, integrated instrumentation for monitoring and control that is comprehensive both in scope and deployment. 3. To address the issue of administrative heterogeneity in the future internet, it should provide for secure monitoring and control of network devices or functions by appropriately authorized parties. 4. To address issues of reliability, ubiquity, and administrative heterogeneity in the future internet, it should provide for ``end-to-end'' management --- potential management of any managed node by any management station --- subject to relevant topological and administrative constraints. 5. To address issues of scale and ubiquity in the future internet, it should provide a common framework and mechanisms for administrators to distribute management function among network elements in ways that are consistent both with the robustness requirement and with local topologies or administrative policies. 6. To address issues of reliability, scale, and ubiquity, it should provide frameworks and mechanisms to support powerful management applications in ways that neither constrain application internals nor impose burdens on managed nodes. 7.2 Specific Work 7.2.1 Comprehensive Instrumentation 7.2.2 Maturity and Deployment Realizing instrumentation that is comprehensive in its deployment will require maturation and wide implementation of currently defined MIB specifications. Although implementation of the latest core MIB (MIB-II) is heartening, it represents but a relatively small fraction of the more than 1000 MIB objects defined in recent times. While further MIB development in certain areas is required to complete the picture of MIB work already begun, in other areas, deployment and operational experience lag behind the specification process. Accordingly, timely closure, review, and advancement of outstanding IESG [Page 36] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 MIB definitions should be sought. Implementation of these MIBs in relevant products should be sought informally by providing opportunities for discussing such implementations and issues related thereto. Where appropriate, working groups could be chartered for modest, well-focused MIB development that directly complements or rounds out current MIB efforts. 7.2.3 Multi-Protocol Context In a multi-protocol internet, comprehensive instrumentation means that MIBs are defined as needed to provide for management of multi-protocol devices via whatever management protocol community need and interest demand. It is absurd to require implementors to realize multiple mangement protocols in a single device merely for want of MIB definitions that support comprehensive management of that device via a single management protocol. Common MIB definitions to support management of multiprotocol devices via the SNMP are currently of limited scope and should be developed as community need and interest demand. 7.2.4 Cooperative Foundation Realizing comprehensive instrumentation can also be facilitated by seeking ways of enlarging the cooperation between the IETF and other standards bodies in the development of SNMP MIB specifications, particularly in those functional areas where such bodies can provide specialized expertise. This sort of cooperation may be facilitated by extensions to the management framework, mechanisms for liaison, clarification of techniques and process, or other strategies. The addition of a small number of SMI types could possibly facilitate the incorporation of MIBs produced in other standards forums into the internet context, and adoption of more formalized schema for defining SNMP MIB objects could foster internet MIB development within other standards organizations. Clarifying the process by which MIBs developed in other IETF areas and in other standards bodies are incorporated into the internet context could also facilitate productive cooperation in MIB development. Consistent with the goal of a robust, ubiquitous, and cost-effective management infrastructure, future MIB development should always minimize the amount of instrumentation required in multi-protocol implementations by aligning the definitions of MIB objects as much as possible with similar objects in other MIBs or with descriptions of management or protocol functions published by other standards organizations. IESG [Page 37] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 7.2.5 Product Range Comprehensively instrumenting internet devices in a coherent, useful way will require a framework for representing relationships among various components of individual devices. As the range and composition of vendor products becomes broader and more various, it becomes increasingly difficult to capture the structure of many products (e.g., brouters, ``wiring centers,'' hubs, repeaters, and multiplexors of various sorts) via static, traditional models of networking. Such a framework should be formulated, and, if it entails definition of common mechanisms, these should be developed in appropriate working groups. 7.2.6 Scope Comprehensive instrumentation entails the development of MIB support for management of all relevant aspects of the internet. In particular, MIB support for the mangement of hosts and applications will be needed. Achieving this goal requires architecturally acceptable solutions to some rather daunting technical problems, and it requires definition of common mechanisms that can accommodate the overwhelming heterogeneity of host systems. In this context, initial work towards this goal is likely to be specialized, fragmentary, and experimental. Owing to the many technical unknowns, exploratory work should be pursued as experimental efforts. For example, exploratory definition of instrumentation for a standard TCP/IP application (e.g., FTP, SMTP) may clarify the issues of realizing that instrumentation in a heterogeneous environment. Another possible exploratory course to exploit the work of other organizations (e.g., IEEE 1003.7) to realize richer host management in an internet context. Practical success in host and application management for at least the near-term may depend directly upon the quality of common mechanisms for distributing management function (e.g., ``proxy'' configurations). 7.2.7 Secure Operation and Administration The goals of secure network monitoring and control, properly mediated ``end-to-end'' management, and more flexible distribution of management function and responsibility all depend in large part on realizing a properly secured management infrastructure. Accordingly, the administrative model set forth in RFC 1157 should be elaborated into common mechanisms for both secure network management and so-called ``proxy'' management relationships. IESG [Page 38] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 To this end, the formulation of any new protocol mechanisms required to properly secure the management function should be considered. Any such solution should be realized in a way that supports transparent interplay with so-called proxied network elements. To foster interoperability the proper function of proxy devices in the internet context should be clarified and delimited as part of an integrated administrative model. 7.2.8 Architectural Effectiveness It is critical that the insights on which effective management is based today not be forgotten or diluted as the network management infrastructure evolves to meet the growing demands upon the internet. The lessons learned by the community about the proper relegation of management burden to achieve ubiquity or the proper distribution of management function to achieve robustness should not be abandoned and should shape the design of new MIBs and new management mechanisms in general. For example, mechanisms whose value depends on the assumption that failing network elements will reliably and correctly report their own failures to a responsible management station are inappropriate to an efficient, effective management system. Similarly suspect are management mechanisms that require extensive control apparatus to mitigate the potential ill-effects of their own operation. The common management infrastructure of the future internet should rest on a sound foundation. It would be irresponsible for the community to foster and encourage the definition of common network mangement mechanisms that do not contribute to (and even detract from) the overall goal of the management task --- which has more to do with the needs of internet users and operators than with the needs of product developers. Realizing the goal of an effective management infrastructure requires an attention to the principles of effective management in the development of MIBs and in the formulation of new management mechanisms. It is facilitated by an awareness of the central technical issues by participants in the standards process. These needs should be addressed by the ongoing custodial and educational activity of the SNMP Network Management Directorate and the community leadership. 7.2.9 Enriched Management Applications One aspect of the future management infrastructure is a rich set of management applications and management station functions. Much as the success of a RISC system depends upon the power of its compiler, the IESG [Page 39] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 efficacy of SNMP management systems depends on the power of management stations and applications. But also like a RISC system, the effectiveness of the management infrastructure will depend enormously upon the correct partitioning of function among its components. In this context, the enrichment of management applications must be predicated upon a deeper cleavage in the SNMP information model between the abstractions realized by managers and those realized by managed nodes. In this way, the design principles that assure ubiquitous, effective management can be preserved while the infrastructure is augmented to provide richer support for management applications. The community should consider qualifications to the SNMP information model that may be required to support further growth of management applications without compromising the technical principles from which the management system as a whole derives its success. Once an appropriate architectural model is in place, support for common application support mechanisms should be pursued along at least two paths. One path has to do with defining common notations for exchanging information about managed elements and networks among managers. This sort of information is comparable to that currently captured by templates in MIB specifications, but it is information that, while of mosest value to the manager software, is not strictly necessary to the unambiguous operation of the management protocol. For example, the tabular abstractions currently implicit in today's MIB notation have no relevance to the operation of managed nodes: inclusion of such information in MIB documents is an artifact of historical IAB policies, it is confusing to readers who lack that historical perspective, and it is not an adequate foundation for the abstractions required by future management applications. Development of an appropriately bifurcated notation requires, first, some definition of its form and appropriate architectural role and, second, the specification of its substance. The other path has to do with MIB objects for representing aggregations or distillations of management information for use by managers. This work is predicated on the assumptions that (a) prudent distribution of management responsibility can be useful in certain circumstances and (b) network devices whose sole function is aggregation of management information are increasingly common. In addition to these two areas of activity, informal discussion that fosters enrichment of MS technology (e.g., improved configuration management or interfaces with databases) should be encouraged within the NM Area. Standardization of higher-level functions in management tools (including user interfaces) is not likely to be valuable in the foreseeable future. IESG [Page 40] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 8 OSI Integration 8.1 Area Overview The goal of the OSI area of the IETF is to facilitiate incorporation of the OSI protocol suite into the Internet. The plan has two main parts. The first part defines the goal; it provides a summary (by layer) of the deployment of OSI protocols envisioned by 1995. The second part presents a snapshot of the current state of OSI deployment, and enumerates the major tasks that must be accomplished in order to reach the goal. 8.1.1 OSI in Internet in 1995 This sections presents a layer-by-layer view of the integration of OSI into the Internet. It is a goal to achieve this degree of integration by 1995. 8.1.2 Physical & Link Layer It should be possible to operate OSI and TCP/IP (as well as selected other protocol suites) over all appropriate physical and link layers. 8.1.3 Network layer There are two main OSI approaches at the network layer: connectionless service and connection oriented service. The OSI connectionless network layer protocol (CLNP -- OSI 8473) is very similar to IP, and can essentially be thought of as IP (including features from ICMP) with the addresses made larger and more flexible. As such, CLNP is the logical OSI protocol for use alongside of IP in those parts of the Internet which are currently based on IP. Note: for the remainder of this chapter, the term ``IP'' will be used to refer to the Internet Protocol component of the TCP/IP Protocol Suite. CLNP is the term used for the OSI Connectionless Network Protocol -- the OSI counterpart to IP. The term ``CONS'' is used to refer to the OSI Connectionless Network Service (for example, as provided by X.25). In practice, it is not clear whether either CLNP or IP will be ubiquitous in the Internet in 1995. However, it would be highly desireable to provide a ubiquitous network layer service. The availability of a ubiquitous IP service has been a major reason for the success of the TCP/IP protocol suite. Thus, ubiquitous IESG [Page 41] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 availability of CLNP service, at least in all major Internet backbones, is seen as an important goal of the OSI Integration area of the IETF. The major Internet backbones will be dual protocol: they will support IP and CLNP. CLNP is supported by the following protocols (which will be widely available as part of any commercial vendor's network product set): o ISO 8473: (Connectionless Network Layer Protocol -- CLNP) o ISO 9542: (ES-IS protocol) o ISO 10589: (IS-IS protocol, for routing within a domain) o ISO xxxxx: Inter domain protocol The Internet will continue to be divided into routing domains. Most of these domains will be dual. However, some will operate only the OSI network service and others will operate only the IP network service. We anticipate that both integrated routing and ``ships in the night'' will be used. Most likely, Integrated IS-IS will be common in those routing domains where IP and OSI CLNP topology and routing policy are similar. Other domains that have different topologies for IP and OSI will use the ships in the night approach. There will be (at least) two different inter-domain routing protocols in use, one for OSI traffic and one for IP traffic. Technically, one protocol could be used (development of a single inter-domain routing protocol to support both IP and CLNP is technically very simple). However the political difficulties in standardizing one common inter-domain protocol make this unlikely. Also, there is less need for a single inter-domain protocol (as compared to a single intra-domain protocol). OSI connection-oriented network service (CONS) may also be common, particularly outside of the USA. This may imply that there will be no single ubiquitous network service. OSI CLNP, CONS and IP will be deployed in various combinations. 8.1.4 Transport The following combinations of network service and transport protocol are expected to be in common use with OSI applications: o TP4/CLNP o TP0/CONS IESG [Page 42] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 o RFC 1006/TCP/IP There is some chance that other OSI transport protocols may also be in use over CONS (X.25) in some countries. It is hoped that as CLNP availability becomes more ubiquitous, the use of RFC 1006 will fade. However, both CLNP and CONS are expected to remain in common use. Interoperation between common applications running over different transport and network protocols will therefore be important. In some places, careful placement of application relays that support more than one network service/transport protocol combination will be used to bridge the different communities. In other situations, transport service bridges will be deployed. It is an important goal to allow interoperation between OSI applications over different transport and network protocols, as well as to minimize the complexity, as seen by the user, of such interoperation techniques. 8.1.5 Applications Many applications will be in use: some OSI, some TCP-based, and some of other origin. The applications which are expected to be most common (and most important) are listed below. X.500 Directory Services By 1995, X.500 will be widely deployed in the Internet. This will be used by other OSI applications (e.g., to find the destination corresponding to known user name). In addition, X.500 is important for aiding in interoperability with other protocol suites such as TCP/IP (e.g., to determine which protocol suite can be used to contact a known user, to locate application gateways, etc..). Also, X.500 may be used to offer extended directory services in otherwise pure-IP environments X.400 & RFC 822 based mail RFC 822 mail may still be in widespread use. However, many 822 users may have switched over to X.400. Important goals, necesary for the adoption of X.400 in the Internet, include: (i) Availability of publically-available software providing a high quality user agent for X.400; (ii) Availability of multi-body- part X.400 services, possibly including convenient handling of Postscript, FAX, ODA, and image data; (iii) Widespread availability of X.500 directory services; and (iv) Agreement on a user-freindly naming scheme, which can be available in the X.400 user agents through use of IESG [Page 43] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 the X.500 directory service; (v) Availability of Email gateways, allowing SMTP users and X.400 users to interoperate. Many users may also be using ``integrated'' user agents, in which the user deals with only one electronic mail user interface, but which is capable of sending and receiving mail in a variety of mail formats (including SMTP and X.400) FTAM & FTP VTP & Telnet, or ??? It is very difficult to anticipate the degree to which VTP is likely to displace Telnet, and/or other protocols may be important for future terminal access. For example, special forms protocols (for low end terminals) and X-windows (for high end workstations) may become important. ODA The Office Document Architecture allows documents to be exchanged between dissimilar text/document processing systems. This is of importance, for example, in order to facilitate cooperation in document preparation between people with different worstations or word processing systems. It is therefore an important goal to ensure the widespread availability of ODA in the Internet. Network management Both SNMP and CMIP will be widely deployed. Of greater importance, however, is the development of more powerful and more convenient network management applications, which rely on development and widespread availability of standard MIBs. 8.2 Specific Work This section describes the status of OSI integration in 1991, and additional work that is needed in order to meet the goals stated above for OSI service in five years. This section is organized by layer. We can expect that introduction of OSI into the Internet will be gradual. Some services (Electronic mail, directory services, connectionless network service) are likely to be introduced at an early stage. Other services will be introduced later. There are some places where the existing OSI protocols are incomplete, or require subsetting or ``profiling''. Thus there may be places where we either need to introduce interim solutions, come up with IESG [Page 44] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Internet-specific profiles, and/or work with other standards committees to fill in ``holes'' in the OSI protocol suite. 8.2.1 Physical and Link Layers Choice of Point to Point Protocol PPP is the Internet standard point to point protocol. HDLC is the International standard point to point protocol. Both protocols can, at least in principle, be used to support both IP and CLNP service. However, some work is needed to standardize how to do this (see below). It is unlikely that PPP will be adopted by ISO, and it is therefore likely that there will be two different standard point to point protocols. The protocol to use over any particular link will in general be a configuration option (in the sense that any particular link will use one protocol or the other, and the choice will either be a function of what equipment is placed on the link, or of the configuration of the equipment). OSI over HDLC and X.25 There is no specification for the multiplexing of OSI and IP packets on an HDLC link, nor over a single X.25 virtual circuit (it is possible to mutiplex CLNP and IP packets by using two X.25 virtual circuits, but this in undesireable in some cases when using equipment that limits the number of virtual circuits that can be open at one time). We need a specification which defines a standard method for the operation of OSI and TCP/IP over HDLC. This would allow OSI and IP packets to be distinguished on an HDLC link (or a single X.25 virtual circuit) by examining the Network Layer Protocol ID (NLPID) field of the HDLC or X.25 header. NLPIDs have been assigned for IP and CLNP. Technically this is a very simple task, but there is a need to identify an individual to push this in standards forum, and there is an issue as to which standards forum would be appropriate. OSI over PPP There is currently an Internet Draft which specifies operation of CLNP over PPP. This needs to be reviewed and progressed as an RFC. OSI over 802 networks CLNP and IP packets may be distinguished on 802.2 links by examining the Destination Service Access Point (DSAP) field in the 802.2 header. DSAP values have been assigned for OSI packets as well as IP packets. IESG [Page 45] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Network Layer The OSI connectionless network service is important for early introduction in the Internet because (i) it forms a base for other OSI protocols to run on; (ii) Products are available, or are expected to be available soon; and (iii) Given the increasing address limitations of IP, ISO offers a solution which is needed in the Internet (or will be needed within two to five years). The connectionless Network Layer Protocol (CLNP -- ISO 8473) is complete, as is the End-System to Intermediate-System Protocol (ES-IS, ISO 9542). A CLNP pilot project is currently underway in both the US and Europe. The IS-IS intra-domain dynamic routing protocol is currently a DIS in the ISO/IEC standards organizations. IS-IS for CLNP is being progressed rapidly, and is anticipated to become an International Standard in 1991. Some products are in field test, a public domain implementation of IS-IS is nearing completion. CLNP routers will be widely available in late 1991. There is a draft specification of an Inter-Domain Routing Protocol (IDRP). This specification is being progressed through ANSI. We need to work in conjunction with ANSI X3S3.3 and/or associated ISO groups to ensure the rapid development of (i) An ISO standard for inter-domain routing; and/or (ii) an interim solution (based on the draft work in ANSI) for inter-domain routing. Large scale CLNP pilots have begun in Europe (centered on Nordunet) and the US (centered on the NSFNET backbone). These pilots are interconnected. It is expected that these pilots will grow into an operational service. The US GOSIP NSAP format is complete (given GOSIP Version 2.0 final release -- GOSIP Version 1.0 has an errata that specifies use of the GOSIP Version 2.0 NSAP address format). The lower portion of the address has a structure that ensures compatibility with the IS-IS intra-domain routing protocol. The GOSIP Version 2.0 format should be used for those administrations which are getting their address assignments from the US government address space. ANSI also assigns NSAPS with a format that currently has no structure imposed on the DSP (the lower order part of the address). These addresses will be used by U.S. non-government networks. A common DSP structure similar to that defined in GOSIP Version 2.0 is being progressed in ANSI Other NSAP formats will be used in other countries. These may in some cases be different from the formats used in the US. This should not prevent interoperation (since routing to destinations outside of any particular routing domain is based on address prefixes, and does not IESG [Page 46] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 require any particular low order part of the address). However, this may be awkward for vendors, by requiring that products support multiple formats. The NSAP working group in the IETF is working on guidelines regarding OSI addressing. Of particular concern is NSAP administration, and assurance that the manner inwhich NSAPs are assigned will support routing in a very large Internet (several orders of magnitude larger than the current Internet). An Internet Draft has been released (and upgraded based on comments received), and an RFC is expected soon. Finalization of a scheme for multi-level hierarchical address assignment, particularly in a large Internet whose topology does not follow a strictly hierarchical model, is a difficult task. There are fundamental tradeoffs required between routing quality and flexibility, and the amount of information required to achieve routing. We expect that as CLNP is deployed in the Internet, we will continue to learn more about the use of hierarchical addressing in a large Internet. The current NSAP guidelines document represents the best knowledge available for assignment of NSAP addresses. However, these guidelines may be upgraded in the future as additional operational experience is achieved with CLNP. We are not aware of any Internet-specific work that is needed for introduction of OSI connection-oriented network service (based on X.25) into the Internet environment. However, assuming that CONS will be common use (probably outside of the US), the interoperation of TP4/CLNP and TP0/CONS (CO/CL) is an important OSI problem. A set of Internet Drafts has been released (and are being actively reviewed) which specify a proposed solution to this problem. 8.2.2 Transport The OSI Transport Layer protocols (TP0 through TP4) are finished, and have been available in products for several years. Not all current TP4 implementations have incorporated enhancements similar to the recent improvements in TCP. There is an urgent need for development of solutions which allow interworking between stations using common OSI applications over dissimilar network and transport services. Specifically, work is needed on transport relays between (i) Systems running RFC 1006 (OSI applications over TCP over IP); (ii) systems running OSI applications over TP4 over CLNP; and (iii) systems running OSI applications over TP0 over X25. Due to the complexities involved in use of such relays, it is desireable to faze out the use of RFC 1006 over time, as well as to attempt to move towards a single ubiquitous OSI network layer service. IESG [Page 47] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 8.2.3 Applications Introduction of OSI applications in the Internet may be expected to take place on a gradual basis (with additional applications introduced over a period of time). Pilot projects are currently underway for X.400, X.500, and ODA. It is highly desirable that future Internet applications work be coordinated with OSI applications standards. For example, in those specific cases where a new application is needed for the Internet, where an existing OSI standards exists, and where the OSI standards is found to be acceptable, then it would be unfortunate for the Internet to develop an separate independent protocol for the same application. This presents an opportunity for international standardization of common applications for use with both OSI and TCP/IP protocol suites. In the short term, it is also useful to run OSI applications over TCP/IP, using the approach outlined in RFC 1006. In order to facilitate eventual transition to pure OSI service, it is highly desireable that all end systems which are deployed with the ability to run in a mixed-stack mode (OSI applications over TCP/IP) also have the ability to run in a pure-OSI mode (OSI applications over TP4 over CLNP). Directory Services / X.500 Electronic Mail / X.400 An Internet X.400 pilot project was started in September 1990. The goal of this pilot project is to operate a production quality management domain in the Internet and document the information that is learned from such an operation. A working group in the IETF has been formed to produce a document that specifies the requirements of a X.400 management domain in the Internet. This group's task is to insure that the various management domains in the Internet can interoperate with each other. A requirement of X.400 naming in the US is that a central authority take charge of administering X.400 management domain names. One of the important tasks of this group is to insure that management domain names are unique. An initiative with the US State Department (Study Groups A-D) has been formed to oversee the creation of such an administration in the U.S. We are not aware of the status of similar efforts in other countries. The interoperation of X.400 and RFC 822 has been specified by RFCs 987 and 1148. IESG [Page 48] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Operation of an 987/1148 gateway requires the global distribution of static address mapping information. The current practice of manual distribution will not scale. An experimental use of the DNS to store the mapping information has been undertaken at the University of Wisconsin. Storage of the mapping information in the DNS allows the information to be stored in a distributed manner. An internet draft produced by the IETF-X.400 working group defines the method of storing mapping information in the DNS. The widespread acceptance and use of X.400 will largely depend upon the availability of suitable user agents, and on the availability of extended ``body parts'', which provide service beyond ASCII text. Of particular importance are Postscript, ODA, and FAX (although other extended body parts such as image may become important as well). Development of a public domain user-friendly user agent for X.400, offering extended services, is therefore of very high priority. X.400 Security There is considerable work in both the Internet (RFC 822) community and the ISO (X.400) community on security for electronic mail. It does not appear that there has been any serious study of how a mail gateway affects the two security models. Other types of application layer gateways and transport layer bridges may also effect security. Virtual Terminal Protocol The Virtual Terminal Protocol VTP is the OSI version of remote login. There has been a VTP profile written, that is similar to the Internet TELNET protocol. There currently is an implementation of this, where both the OSI VTP and the Internet TELNET can run in the same host. This results in an application relay running directly in the host, thereby by-passing the added complication of determining where the application gateway is located. A user can login to the host via either VTP or TELNET and from there perform additional remote logins to other machines with either TELNET or VTP. There is also another profile which is more in tune with the International Telegraph and Telephone Consultative Committee (CCITT) recommendation for the terminal standard X.3, X.28, and X.29. The functionality is very similar to TELNET. In addition, there is a third generic VTP profile. In regards to the user locating the application gateway, one solution is to require a two step login. The user explicitly logs into the application gateway via VTP or TELNET and from there uses TELNET or VTP to get to another destination. More work is needed on virtual terminal protocols for use in the Internet. This may, for example, include work on VTP support for forms and X Windows, and might possibly include use of Telnet directly IESG [Page 49] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 over the OSI Transport Service. File Transfer An experimental application gateway between the OSI File Transfer, Access and Management (FTAM) and the Internet File Transfer Protocol (FTP) has been written. There is an internet draft that specifies the operation of an FTAM FTP gateway. As in the VTP and TELNET scenario, it is feasible for a user to use a two step approach. For file transfer it is a burden since multiple file transfers may be executed in a login session as well as in application software. It would be greatly preferable to make use of gateway functions which were transparent to the user (although the means to provide this service, such as automatic application gateway discovery through use of directory services, have not been specified). Remote Database Access (RDA) This standard has two parts (Part 1: Generic Model, Service, and Protocol; and Part 2: SQL Specialization. Both parts are expected to progress to DIS status in October, 1991. It would therefore be a good time to start thinking about a possible RDA pilot effort in the Internet. Office Document Architecture (ODA) There is currently an ODA pilot project in the Internet, coordinated by the IETF ODA working group. There is also ODA software (backend converters, editors) available for public use. Information Retrieval -- Z39.50 Z39.50 is an US ANSI standard protocol that specified how information retrieval systems search and retrieve information from each other. It is specified in ISO DP 10162 and DP 10163. In the US there are a group of implementations either currently underway or in the planning stages. An implementors workshop has been formed. There are two basic camps involved in the implementation. One groups is planning on doing an implementation as a straight OSI protocol stack using all seven layers. The other plans on running the protocol on TCP networks and will implement session, presentation, and ACSE directly on top of TCP. IESG [Page 50] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 8.2.4 Network Management SNMP is widely in use for management of TCP/IP systems. Pursuit of the use of CMOT for management of pure TCP/IP systems does not seem fruitful at this time. There is some work (both inside and outside of the Internet community) on the use of CMIP for management of pure OSI systems. The use of both CMIP and SNMP to manage pure OSI networks should be explored. An attempt should be made to coordinate SNMP-based OSI MIB development and CMIP-based OSI MIB development. MIBs should be defined for (i) management of IP using SNMP (in progress, outside of the scope of this area); (ii) management of OSI using CMIP; (iii) management of dual IP and OSI systems using SNMP; and (iv) management of dual IP and OSI systems using CMIP. Note that operation of two management protocols (SNMP and CMIP) in a single management station is not as much of a problem as the potential for different MIBs using the two suites. In addition, the experience gained in management of current IP systems may be of use in management of OSI systems. Thus the development of OSI MIBs should be coordinated with the current efforts for development of IP MIBs. 8.3 An Infrastructure for OSI TCP/IP has been very successful for a number of reasons, including the existence of an intrastructure for facilitating TCP/IP operation. In order to make OSI successful, it is similarly necessary to create an OSI infrastructure. The TCP/IP infrastructure can serve as a model of what an OSI infrastructure will need. In addition, some specific parts of the TCP/IP infrastructure may be used directly for support of OSI. The necessary elements of a infrastructure may include: o Means for creating base standards; and o A timely means for ``fixing errors'' in the base standards o Means for document distribution (including protocol standards, related proposals, general ``how to'' information, etc); and o Means for controlling which documents are distributed o Method for address and name allocation / Registration. o Access to software and intellectual property. o Backbone and Regional networks o etc.. It is clear that many parts of the OSI infrastructure already exist, but the infrastructure is incomplete (or in some cases ineffective). IESG [Page 51] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Also, it is clear that an infrastructure for OSI must be distributed (i.e., there is no one central organization which can take control of the process). This makes coordination difficult and liaison essential. In general, the development of an OSI infrastructure must be handled on an item-by-item and case-by-case basis. There are a large number of organizations and committees which must play a role in the definition and use of OSI. Naturally, this includes OSI-related standards committees and related activities (including, but not limited to, ISO, ANSI, CCITT, etc). Also, as OSI becomes more common in the Internet, the activities of other areas of the IETF will become increasingly OSI-related. Thus we can expect that extensive liaison will always be part of the function of the OSI-area of the IETF. Much of the OSI-related work in the IETF will increasingly be of interest to other areas as well. For example, much of the OSI Applications work is of interest to both the OSI and Applications areas. As OSI is further introduced into the Internet, we can expect that the distinction between the OSI and TCP/IP protocol suites may become less clear. We should therefore be expecting that the OSI-related work in the IETF will gradually be integrated with other work, thereby eventually eliminating the need for a distinct OSI Integration area. There is another important issue relating to both the OSI and the TCP/IP infrastructures. In particular, it is clear that both OSI and the Internet protocol suite will continue to be developed and enhanced in years to come. For example, there is a project in ANSI to develop a next generation network protocol. Similarly, there is a proposal for a project in the IETF to develop a successor to IP. It would be highly unfortunate if these efforts were to take place independently. Coordination is important for two reasons: (i) To allow sharing of ideas and results, in order to cause both solutions to be as good as possible and to reduce redundancy in the research efforts; (ii) If possible, to allow convergence of the two protocol suites. IESG [Page 52] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 9 Operational Requirements The IETF has traditionally been a technology development group. Its original constituency was protocol developers and researchers. During the earliest period (including prior to the formal formation of the IETF), there were no ``operational'' networks. All networking activity was ``research and development''. Therefore, the protocol developers and researchers were often also the same people who administered the local networks. Over time, as the number of networks comprising the Internet increased, non-networking specialists began to use the Internet and to rely on it as a necessary tool of every day business. This signaled a significant change in the character of the Internet, as networks evolved from testbed to more fully operational. This also signaled a change in the constituency of the IETF. In addition to the protocol developers and researchers, network administrators began to participate regularly in IETF. Perhaps in a more turn-key environment, this would not have been the case, and the mixed audience of developers and operators would not have seemed so natural. However, it is fair to say that the evolution from research vehicle to fully operational entity has not been completely smooth. In some respects, it is still going on today. The TCP/IP protocol suite originated as non-vendor specific products. Instead of vendors delivering fully supported products, researchers often released to the public domain what amounted to beta versions of software packages. Although this resulted in very quick distribution of new software capabilities, it also resulted in labor intensive maintainence of the resulting capabilities. The early breed of Internet network administrator was indeed a hearty soul, who fit in very nicely with the protocol development community at IETF -- largely out of necessity. Therefore, from the beginning of the emergence of the Internet as an operational facility, the IETF has seen network operators and administrators as a natural part of its constituency. When the IETF Steering Group (IESG) was originally formed, it did not have a distinct ``Operational Requirements'' Area. There was never any question that about whether the IETF (or any other centralized authority) could actually administer Internet operations on a global scale from a single central vantage point. Of course, it could not. Further, it was felt that operational requirements cut across all the other IESG Areas, and therefore operational concerns could be addressed separately in each area as required. Therefore, it was initially felt that no separate operational area was required. However, the audience of network operators in the IETF voiced a need for a specific forum for operational requirements. In time, a firm IESG [Page 53] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 ``charter'' for the IETF Operational Requirements Area emerged. This ``charter'' will be discussed in the next section. The goal of organizing an ``IETF Operational Requirements Area'' has been an elusive goal, in part because the early vision was not as firm as that of the other areas. However, the charter and mandate has taken shape, and the organization of the IETF Operational Requirements Area is now in progress. 9.1 Description This section provides a description of the Operational Requirements Area. This section will discuss the topics covered, topics not covered, and the relation of the Operational Requirements Areas to other IETF areas. The IETF Operational Requirements Area has following mandates: o Provide a forum for coordination between operational groups. This includes encouraging and assisting deployment of new technoloy and techniques. o Development of operational methods, practices, and policies. (eg, end-end trouble resolution) o Guidance to other IETF technical development efforts. 9.1.1 Provide a forum for coordination between operational groups The Internet is now an international communications inter-network which has grown beyond its original TCP/IP beginnings. As recently reported, the Internet has directly IP-reachable hosts in 25 countries over 5 continents. There are many hundreds of administrative domains, thousands of networks, and hundreds of thousands of hosts. There are now also numerous other interconnected networks using other protocol families (e.g., Appletalk, DECnet, OSI). It is clearly not possible for a single group to act as the main focus for managing the operations of this global enterprise. However, coordination and liaison between network managers and operators is not only possible, it is crucial for maintaining smooth operations. It is the goal of the Operations Area to encourage coordination and liaison between the various national and international network operators and operational groups, and with this liasion to encourage the usage of commonly agreed methods and practices. This should include coordinated routing, DNS, and other network management services to minimize problems, and the utilization of coordinated trouble reporting and resolution policies for when problems do occur. IESG [Page 54] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 To serve this mandate, the IETF Operational Requirements Area will need to interact with other groups formed for operational purposes. Such groups include RARE/RIPE, CCIRN/IEPG, FNC/FEPG, FARNET, and network service providers. Forging this interaction and determining the right level of interaction for the IETF will be challenging. In some cases, the IETF should take direction from and serve as agent of other higher-level policy-setting groups. In other cases, IETF may be able to serve as the forum for bringing together operational groups that otherwise may not have productively interacted. 9.1.2 Development of operational methods, practices, and policies The first bullet charts the mandate for liasion between network operators to implement coordinated operations. This is only possible to the extent that common methods and policies exist. In cases where such methods or practices do not exist, the Operational Requirements Area will take an active role in developing guidelines and practices for internet operations, management, and interconnection. This could include attempting to reach consensus upon common joint management methods for common links. It could include specifying common managment tools, common minimum collection metrics, common data storage formats for interchange of information, common display and reporting formats (e.g., performance data or topology maps). It is hoped that such consensus guidelines would then be applied in the coordinated network management activities of the first bullet. 9.1.3 Guidance to other IETF technical development efforts The IETF was formed as a technical development body in support of operational networks. Many IETF activities are still motivated by the goal of improving the operations of real networks. Several of the other IETF Areas have development activities that affect network operations (e.g. Network Management, Routing, User Services, DNS in the Applications Area, etc.). It will be a goal of the Operational Requirements Area to help define operational requirments and set priorities for development in these other IESG technical areas. This demonstrates one of the main strengths of the IETF as a technical development body. The developers of the technology and the users of the technology work closely together with a common focus. This mixture of developers and knowleable users sets the IETF apart from other technology development bodies, and it shows the importance of raising Operational Requirements to the level of an equal Area. IESG [Page 55] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 It is this special focus which gives the Operational Requirements Area its title. Examples To show how this threefold charter works in the formation of working groups, recent working groups in the Operational Requirements Area are discussed in relation to the above stated goals. o Provide a forum for coordination between operational groups. Under this bullet, standing WGs generally serve the purpose of liaison. These group are different from other WGs in that they may never produce written documents (other than meeting notes). They are standing groups with less specific goals and milestones than typical WGs in other technology development areas. - DDN Interconnectivity WG Liasion group between DDN and its clients, and between DDN and its peer networks. This group meets on an as-needed basis. - Network Joint Management WG Liaison group between regional mid-level networks and national backbones. This started as a group between regional networks and the NSFnet backbone, has since broadened it focus somewhat. - Topology Engineering WG o Development of operational methods, practices, and policies. WGs under this bullet develop technology, but in general are more concerned with development of technical methodology rather than protocols. For example, in the Operational Statistics WG, methodology and tools are being developed, but the underlying network management techniques are taken as defined by the NM Area. - Benchmarking Methodology (bmwg) Developing benchmarking and testing methodology routers, bridges, and other network components. - Operational Statistics (opstats) Developing commonly agreed metrics and tools for network managment - User Connectivity (ucp) Developing methods for problem resolution across administrative domain boundries. o Guidance to other IETF technical development efforts. There are no specific WGs under this bullet. This function of the Operational Requirements Area is discharged simply by bringing together network operators to develop methodology that is then made available to technology developers in other areas. IESG [Page 56] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 These network operators also naturally participate in the technical developments of other areas by virtue of being at the same IETF meetings. Organization The Operational Requirements Area of the IETF will have a board of advisors (the ``Operational Requirements Directorate'', ORD) comprised of national and international network operators. Participation on the ORD will be invited from various sectors, e.g research, government, industry, and private. The Operational Requirements Area Director(s) will serve as the Chair(s) of the ORD. It will be the responsibility of the Operational Requirements Area Director(s) to establish the ORD and arrange for the appropriate membership. The Operational Requirements Area Director(s) will serve on the Internet Engineering Steering Group (IESG), which functions as the executive board and steering group of the IETF. 9.2 Technical Goals For The Operational Requirements Area The Operational Requirements Area (ORA) is fundamentally different than all other IETF Areas, with the possible exception of User Services. The ORA is not primarily a technology development Area. It serves the function of liasion and requirements definition (although there are also some aspects of technology development, too). Therefore, this section doesn't quite apply the way it does for a technology development area. We need to examine the issue of what basic services should be provided by any network before it joins the Internet. That is, what services should a network provide to be considered a good neighbor network? In the same way, what services should a network operations center provide in order to be able to function as a full member of good standing in the Internet? As many small enterprises join the Internet community, it would be very useful to have a document, or set of documents, that define basic services, and the methods of implementation of those services, that are typically expected in Internet good neighbor networks. Such requirements definition could be used for both network planners and protocol developers. It could also be used by network administrators to develop bi-lateral and multi-lateral operational relationships on a coordinated basis. As the outline below shows, some services are obvious. However, the IESG [Page 57] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 exercise of defining these services are likely to enumerate more details. o Definition of network infrastructure services - a network operations center - a user services and assistance facility - Coordinated network interconnections (eg, FIX's, CIX's) - Coordinated Dynamic Routing - Coordinated Domain Name System (DNS) - Network time - Directory Services o Definition of minimum operations center capabilities - Statistics gathering using common metrics and tools - Problem resolution methods - automatic network mapping With the definition of basic service requirements, it will be a major goal of the Operational Requirements Area to encourage the implementation of the minimum required operations center capabilities and infrastructure services in all Internet networks. The Operational requirements Area will also encourage the definition of procedures and methodology to coordinate infrastructure services across administrative domain boundaries. 9.3 Specific Actions For The Operational Requirements Area In the section, we will identify actions required to fulfill the broad goals of the last section. o Establish clear relationships with other organizations with operational concerns and responsibilities. Determine the right level of interaction with these groups (e.g., establish in each case whether the IETF should take direction from, or provide a forum for liaison with, these other groups). A partial listing of such groups includes CCIRN/IEPG, FARNET, FNC/FEPG, RARE/RIPE, and commercial network service providers. o Network Operations Center Coordination - Establish up-to-date online database of contact information for problem resolution - Establish up-to-date online database of link and map information - Establish and utilize common problem escalation procedures - Establish and utilize security incident handling IESG [Page 58] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 o Statistics and Monitoring - Define common minimal set of metrics necessary for network operations. Propose for MIB if not already in. - Define common storage formats - Define common presentation formats - Define new collection and presention tools based on common metrics. - Propose old tools be retrofitted to utilize new paradigm. o Explore legal implications of shared data and joint management o Routing - Design Intercontinental multiprotocol BACKBONE routing structure based on a defined Administrative-Domain hierarchy. The IEPG of the CCIRN has set a course of direction for this topic. o Global DNS Service - Design and utilize true global DNS service o Security - Assist Security Area in defining security requirements for network operations - Utilize secure techniques for all the above activities as soon as available IESG [Page 59] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 10 Routing Area Plan 10.1 Description of Routing Area This chapter outlines a plan for Internet routing in the next five years. It includes an overview of the current state of internet routing, a description of what needs to be done, and a plan for implementing the work. The Routing Area of the IETF is responsible for the TCP/IP family of routing protocols which are used in the Internet. It is not responsible for routing protocols of other protocol suites. It is responsible for extensions of other routing protocols to support TCP/IP routing (e.g. Dual IS-IS). Routing protocols as well as internet addressing are the key elements in the both the current operation and sustaining the growth of the Internet. The success of the IETF in providing standard routing protocols which meet the needs of the Internet will determine how far the Internet will grow and evolve. Internet routing protocols are divided into two classes: Interior Routing Protocols and Exterior Routing Protocols. Interior routing protocol run inside an autonomous domain (AD). Exterior routing protocols run between autonomous domains. These are sometime referred to as Inter-AD and Intra-AD routing protocols. The current Interior protocols in use in the Internet are: Routing Information Protocol (RIP), Vendor Proprietary (CISCO IGRP, IBM IS-IS, BBN SPF, etc.), Open Shortest Path First Protocol (OSPF) In addition, there is the recently released Dual IS-IS routing protocol, but at the time this report was written it is not running as part of the Internet. The current Exterior protocols in use in the Internet are: Exterior Gateway Protocol (EGP), Border Gateway Protocol (BGP) There is also currently under development in the IETF an Exterior protocol called the Inter-Domain Policy Routing Protocol (IDPR). This protocol supports policy based Inter-AD routing. The routing in the Internet is currently based on routing on a flat address space. The one exception to this is sub-networks. All routing protocols are required to carry information about all routes. There is no hierarchical structure. It is doubtful whether this model for routing can be sustained if the current exponential growth rate of the internet is to continue. Currently there is not one standard common interior routing protocol for the Internet. The two likely candidates are OSPF and Dual IS-IS. IESG [Page 60] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 The RIP protocol is out dated and does not provide for adequate Inter-AD routing. This protocol needs to be replaced by a more modern routing protocol such as OSPF or Dual IS-IS. The EGP protocol is the most widely used Inter-AD protocol, but it has been stretched well beyond its limits and needs to be replaced. The IETF has recommended that the BGP protocol be used as a replacement for the EGP protocol. There are several potential services that the current Internet Routing protocols to not support. These are: Multiple Routing Policies, Multicast Services, Authentication of Routing Protocols, and Routing on Large Networks 10.2 Technical Goals for the Routing Area There are several high level goals for the routing area. These are: 10.2.1 Internet Growth - Routing should not be the limit to growth The overall goal for routing in the internet is that routing protocols should not be the limit to the continued growth of the Internet. This is key. Internet routing needs to support growth in both size and complexity. Size in terms of number of hosts, networks, autonomous systems. Complexity in terms of topology, diversity of network types, and policy restrictions. 10.2.2 Provide Routing Protocols for Future Environments There are a number of new types of public networks being developed, including Switched Multimegabit Data Service (SMDS), Frame Relay, Integrated Services Data Networks (ISDN), Asynchronous Transfer Mode (ATM), and Gigabit networks. Routing protocols will need to evolve to meet the routing requirements of these new environments. In addition to new types of network topology being introduced, there are trends to provide different classes of networks. These include Commercial, Public, Private, Government, and University Research networks. Routing will need to perform to provide routes for and control access to these classes of networks in line with the users requirements. IESG [Page 61] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 10.2.3 Provide for Multivendor Interoperation Routing protocols need to be able to be implemented and run in systems made up of an arbitrary collection of vendors equipment. To meet these goals the following five year routing protocol evolution plan is proposed: 1-2 Years Modern IGP's (IS-IS, OSPF) deployed widely, EGP Replaced by BGP 3 Years Routing Protocols available for New Environments (SMDS, FR, ISDN, ...) Support for Commercial / Public / Private Classes of Networks 5 Years Transition to New Addressing and Routing Model 10.3 Specific Actions Required The issues in the routing area as to what work should be done in the next five years fall into the short term and the long term issues. Generally, the short term issues deal with modernization of the current protocols to provide better routing service today and provide for internet growth in the next few years. The long term issues cover how far the internet can grow and the type of routing that will be supported. 10.3.1 Standardize on one Interior Routing Protocol The first issue is to pick a standard Interior Routing Protocol for the Internet. The two serious contenders are the OSPF and the Dual IS-IS protocols. This is important because the most common protocol in use (RIP) works poorly and the vendor proprietary protocols do not allow multiple vendor routers in a single AD. Both of the contenders promise improved operation and multi-vendor operation. This issue has been active for about a year, and needs to be resolved quickly. 10.3.2 Define Requirements to Advance Internet Routing Protocols to Draft Standard and Full Standard| An issue that relates to picking a standard inter-AD routing protocol is the need for a standard procedure to evaluate the operational IESG [Page 62] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 experience of a new routing protocol. Routing protocols are complex, distributed, real-time algorithms. They are difficult to implement and to test. Even though a protocol may work in one environment with one implementation, that does not ensure that it will work in a different environment with multiple vendors. A routing protocol may work well with a range of number of networks and routers , but fail when an unforeseen limit is reached. The result is the even with considerable operational experience, it is hard to guarantee that the protocol is mature enough for widespread deployment. A procedure needs to be developed to evaluate the operational experience that a routing protocol has before making it a Draft Standard. 10.3.3 Deploy BGP to Replace EGP The current Intra-AD protocol, EGP, is in need of replacement. With the size of the current Internet, it provides at best marginal service. The BGP is being developed to replace it. BGP needs to advanced in the standardization process and then be deployed. 10.4 Develop Routing Protocols for Large Data Networks The last short term issue is routing on large data networks. The current routing protocols (Inter-AD and Intra-AD) do not work well on large networks where they may be hundreds to many thousands of routers. All of the protocols require full information exchanges. The inter-AD protocols require order N**2 routing exchanges where N is the number of routers. This will consume excessive resources in the network and the routers. There is a need for a new protocol(s) to provide for routing on this type of networks. 10.4.1 Authentication of Internet Routing Currently none of the current routing protocols have viable authentication mechanisms. In theory, it is possible that internet routing could be attacked (accidently or maliciously) and the routing in a AD or perhaps across large portions of the Internet could be adversely affected. Also, as commercial pay for service routes are added to the internet it will become even more important that there be a high assurance that routers are who they say they are. As a result, it is important the general authentication mechanisms be added to the routing protocols. IESG [Page 63] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 10.4.2 Routing and Addressing Architecture The most important long term driver in Internet Routing is growth in size and diversity. A number of factors are at play. The Internet is growing in size at an exponential rate. There are signs that there will be many a variety of public, commercial, and governmental backbones networks built which will have different policies/terms for the traffic that they carry. While it is impossible to predict the details of the future, it is clear that in the long term the Internet will be much larger and much more complex than today's Internet. As a result of increased size and diversity, Internet Routing and Internet Addressing will have to evolve to meet these expanding requirements. There are currently a number of efforts underway that are working to addressing some or all of these issues. These include: o The Open Routing work, IDPR, which concentrates on a link state system to do policy routing in an AS topology, led by Martha Steenstrup of BBN; o A combination of the above and BGP which has desirable 'common case optimization' characteristics, put forward by Deborah Estrin at USC; o A proposed new combined routing and addressing architecture, put forward by Noel Chiappa. o An address mapping scheme proposed by Van Jacobsen of LBL and being worked on by Paul Tsuchiya of Bellcore. There is currently no plan to determine how these efforts relate to each other and which are the most promising to pursue. The following two actions are proposed in this area: The IDPR protocol appears to be a promising solution to handling Internet growth in size and diversity. It is using a number of techniques which are gaining some consensus as appropriate solutions to growth issues. It's development should be completed and it should be deployed to allow operational experience to be gained in order to understand how will it can help meet internet growth. A new effort be started to develop an overall Routing architecture which can meet the long term requirements of Internet routing. The result of this effort should be a framework where specific protocols and mechanisms can be developed. It will develop a timetable for routing protocol evolution as well as a plan for migration of the Internet to new protocols. Due to the overall success of the Internet, the problems associated with migration may be the hardest to solve and have the most effect on the solutions chosen. IESG [Page 64] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 11 Security Area Plan 11.1 Objectives and Overview Security has become a major concern within the Internet. Users, site administrators, network administrators and vendors are all increasing their attention to security matters. Security services are being added to existing protocols, and new protocols specific to security are being defined. In addition, more attention is being given to security in the implementation and operation of sites and networks. 11.2 Objectives The overall objective of the security area is to develop a combination of protocols, polices and practices that provide: o protection of the network infrastructure against unauthorized tampering, o protection to network users against compromise of confidentiality and integrity, and o support for protecting network services against unauthorized use. These objectives are general in nature. There are numerous aspects of each, some of which are spelled out below. This plan does not attempt to provide all possible forms of protection. For example, an obvious aspect of confidentiality is protection of the contents of electornic mail messages from disclosure to unaddressed parties. A more subtle aspect of confidentiality is protection of the knowledge of which people are communicating with each; this is often called traffic security. This plan does include a path for attaining confidentiality of electronic mail messages, but does not contain a plan for attaining traffic flow confidentiality. 11.2.1 Arenas of activity Although the main work in the IETF is the development of protocols, the work in the security area encompasses other activities as well. Security area work takes place in four arenas, protocols, policies, assessment and process. o Protocols What changes need to be made to existing protocols? What new protocols should be defined and designed? o Policies IESG [Page 65] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 What policies need to be developed or promulgated? Who needs to be involved in the policy efforts? o Assessment What are the actual security issues in the Internet today and in the future? How effective are the security controls and practices? What changes in protocol designs, protocol implementations or system administration are needed to improve security in the Internet? o Standards and Development What changes, if any, are needed or are desirable in the development process? What changes are needed, if any, in the standards process? o Organization How is the work in the security area to be organized? How will it be coordinated with other groups, e.g. the PSRG. Because security has become a major focus of attention, a large number of people are involved. Not all of these have the same perception of what security servides are needed or desired, and not all of them have the same priorities. This diversity is healthy, but it increases the need for an explicit statement of each party's goals and for coordination among the different parties. This document is a statement of the objectives and plans for the IETF security area. As with any plan, the actual details will tend to vary over time. 11.3 Specific Work) 11.3.1 Protocols The first part of this list is the set of active protocol activities. The second part is the set of protocols or protocol groups which do not have security revisions or extensions in progress, but which have been discussed as needing such changes in the future. SNMP Authentication An encapsulation layer for SNMP is being defined. It provides authentication and privacy services for remotely managed agents. The work is being done by Davin, Galvin and McCloghrie in the IP Authentication Working Group. Four documents exist and have been reviewed extensively. The PSRG has taken exception to some of the details, and these are being negotiated now. It is hoped that this protocol will advance to Proposed Standard at the IETF meeting in Boulder, though its progress is uncertain at the moment. This work is taking place within the Authentication Working Group. In principle, this group is working on both IP authentication and SNMP IESG [Page 66] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 authentication, but only the SNMP authentication work is progressing. This group should be renamed, rechartered and a new chair named. Schedule: Forward to IAB with recommendaiton to advance to Proposed Std at or immediately after Boulder IETF meeting. Privacy Enhanced Mail Specifications for privacy enhanced mail have been developed by the PSRG. These provide for sender authentication, message integrity and optional confidentiality. A combination of DES, RSA and either MD2 or MD4 algorithms are used. User identities are matched to public RSA keys using certificates. Certificates are signed by issuing authorities, and a hierarchy of issuing authorities must come into existence. The oroginal specs for PEM are published as RFCs 1113, 1114 and 1115 and are marked Draft Std. In principle, these should be considered to be Proposed Stds under the current guidelines. Revisions of these three documents and a new document will be forthcoming later this year. PEM will cause a major change in the Internet, and a number of logistic and policy issues need to be addressed. The schedule for initial deployment of PEM on the Internet now looks like April 1991. There is a PERT chart showing the activities of RSADSI, BBN and TIS, but, as Fermat said, the margins are too small to contain it here. Part of the schedule involves the reissue of RFCs 1113, 1114, and 1115, and the issuance of a new RFC. These contain the revisions. Not all of the changes are widely accepted, and we will need to figure out the procedures for reviewing and approving specifications arising from a closed group like the PSRG. IP security options (DoD and commercial) There are two main versions of the IP security option, a DoD version and a commercial version. The DoD version is currently documented in RFC 1108, and is being reviewed and revised. It contains a basic security option and an extended security option. The latter is only partly specified because some aspects are classified. Work on this protocol has been dormant for more than a year, but work on it has been restarted, principally under Vint's direction. Some sort of working group or the equivalent needs to be created to follow through with this effort. At the moment, the ad hoc group consists of Steve Kent, Jon Postel, Hans-Werner Braun, and Steve Crocker. Schedule: Revised RFC by 12/31/90. Some questions as to when and how it enters the standards track. The default assumption is it becomes a IESG [Page 67] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Proposed Std then. The commercial IP security option is being developed by the Trusted Systems Interoperability Group (TSIG). I believe they've agreed to act as an IETF WG and go through the process of preparing their specs for review and publicaiton via the IETF/IAB standards track. There is some confusion at the moment as to how this work relates to the DoD IP security option, and this will be sorted out. I'd guess this group will be ready to present its work for IETF review at either the St. Louis or the Atlanta IETF meeting. Security services in Telnet, etc. The Telnet folks have asked for help in designing an authentication and an encryption option for Telnet. This is more complicated than it first seems, and no real progress has been made. Jeff Schiller is now assigned as the SAAG representative on this WG. (I have not yet communicated this fact to Borman.) Security services at the IP layer This area has been dormant. I am folding down the working group. We will revisit this topic when it's clear what needs to be done. There is substantial resistance from various quarters because there is similar work in the SDNS arena. Routing protocols In principle, the routing protocols should be augmented to be protected against maliciously supplied routing updates that are intended to undermine the integrity of the network. Similar requirements are appearing in more than one protocol, e.g. OSPF and BGP. No explicit work on this subject has been organized, but it's a topic that will be put before the SAAG to see if we can find someone with the relevant expertise to work with the routing protocol folks. Login security Poor password selection and configuration errors have been identified as the primary vulnerabilities among network hosts. DARPA has requested that we look into this situation and recommend improvements. A related but somewhat different matter is transmission of passwords in the clear over the network. It's possible to improve the security of password transmission by using either one time passwords or encrypted authentication exchanges. Ken Van Wyck has been leading an effort on one time passwords, and I'm exploring turning his activity into an IETF WG. I also asked Jeff Schiller to take the SAAG role of forming the necessary working IESG [Page 68] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 group(s) and/or working with existing groups. MD4 A distinguished panel is needed to review MD4. Steve Kent and I are cooperating on trying to set up the panel. We have had trouble finding a chair, and we are attempting to populate the panel and deferring the question of a chair until later. If need be, Steve K or I will chair the panel. 11.3.2 Policies Internet security policy The draft Internet security policy now exists. I expect substantial comment, discussion and interpretaton during the next IETF meeting, and then we'll assess where we stand on it. This exercise opens up new territory because it's not a protocol. I recommend we bring up in the IESG and IAB what is intended for this work. One key question to resolve is whether to quit with the publication of this document or whether to press on and develop interpretations and implementation guidelines for networks, vendors, etc. Security impact statements We have begun asking for security impact statements in all RFCs. This is a useful process, but the groundrules are not yet clear to everyone. This is a matter to be taken up in the SAAG and developed further. Database accuracy and privacy There is an opportunity to set forth a policy on accuracy and privacy of databases containing information on persons and organizations, particularly NICs and other directory services. I do not think there is widespread agreement that this is an area that requires attention, so we need to discuss the issues before plunging forward. It is an area I feel is important, so I'm inclined to press the matter. Export of security related implementations Export restrictions currently prevent the general shipment outside the U.S. of software or hardware which contains DES or RSA based encryption technology. This is awkward. It's not clear what, if anything, can be done about it. We can try to pyut together an interest group and cooperate with other efforts to get clarification and relaxation of the restrictions, but I'm not convinced this will be effective. IESG [Page 69] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Assessment How effective are the security measures now in place? What problems actually exist? These questions are important if we want to formulate the right plans. I have begun to explore this question. No specific plans are visible at this time. 11.3.3 Standards and Development Security impact statements As noted above, we are beginning to require these in RFCs. The process is not spelled out completely yet. Security review of RFCs My intent is that every RFC will be reviewed. This will become a SAAG responsibility. Improvement in development, testing and documentation I would like to seem some move toward the use of reasonable formal specifications, tools, etc. This is somewhat of a swamp draining exercise, inhibited by the presence of a very large and viable alligator population. 11.4 Organization 11.4.1 SAAG Current members include: John Linn, DEC Dave Balenson, TIS Jim Galvin, TIS Jeff Schiller, MIT Paul Holbrook, CERT Rich Pethia, CERT Joel Jacobs, MITRE 11.4.2 PSRG Strong attempts to coordinate our related activities. Some differences in tradition, point of view and style, but I believe there IESG [Page 70] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 is a shared commitment to work together. IESG [Page 71] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 12 Transport and Services Area 12.1 Description The topics covered in the Transport and Services Area can be divided into there sections. The first section is that part of the protocol stack above the network layer, and below the application layer. This includes the various existing and proposed transport protocols, such as TCP, UDP, VMTP and NETBLT. The second section involves low level protocols, protocols that logically sit above one of the transport protocols, but are not tied to a specific application. A simple view would be that if a protocol would typically have more than one application protocol built on top of it, then it belongs in this area. Some of the topics that this would cover are remote procedure calls, and data representation, or presentation services. The third section involves the grey area between transport and applications. These are the applications that the user normally does not directly interact with, and that are not covered in other Areas. For example, routing protocols could fit this description, but they are covered in a seperate Area devoted specifically to routing. applications, but the user does not normally see or use the applications directly. Currently, this section involves topics such as distributed file systems, and the Domain Name System. 12.2 Technical goals Currently the Internet is growing in size and speed, gigabit cross country links will soon be a reality. New applications are being developed, some with characteristics and network demands quite different from the current established set of applications. The main technical goal of the Transport and Services Area is to make sure that the current transport protocols can support new applications, and continue to support the existing applications as the Internet continues to expand. 12.3 Current and future actions The main Internet transport protocol, TCP, has not changed much in the recent past. Currently, RFC 1072 proposes three new TCP options for dealing with high-speed, long delay networks. These changes will allow TCP well into the gigabit rates. There are several things that will probably be needed within the next five years, but are currently still research topics. Rate based protocols will probably be needed to support things such as real-time IESG [Page 72] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 video. Many UDP based applications implement a protocol on top of UDP to make it reliable; a reliable datagram protocol would be useful for these applications. The area of multicast transport protocols is one that is very interesting, but still very much in the domain of the research community. The general question of whether or not multicast is a good idea has not yet been answered; but assuming that it is decided as a good thing, there will need to be transport protocols to make effecient and easy use of this mechanism. IESG [Page 73] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 13 User Services 13.1 Area Overview As the Internet has rapidly developed to encompass a large number of internationally dispersed networks in academic and research fields, many new users of different backgrounds are added to the community. This growth has placed the user services provider in the difficult position of trying to provide much needed user support, while at the same time restructuring the user services' system to accommodate continued expansion. Recent changes include the establishment of a User Services Area within the Internet Engineering Task Force (IETF). This area provides an international forum for people interested in all levels of user services, to identify and initiate projects designed to improve the quality of the information available to users of the Internet. The IETF does not view itself as making standards for user services. Instead, it provides a forum where the user services community can meet, both to discuss internal coordination problems and to share its views with and explain its needs to the technical community. In addition, the IETF encourages collaboration among the various organizations that also have an interest in user services. When the Internet Engineering Steering Group (IESG) was first established, it did not immediately create a distinct User Services Area. As of 1991, this area has grown to take its place with other IESG areas as the importance of a user services forum has increased globally. The actual projects of the User Services Area are handled by the creation of IETF Working Groups. Included in these groups are user services that are addressed in other areas of the IESG. For example, the Security Area and the User Services Area combined their efforts to create a Site Security Policy Handbook Working Group. Overlapping of efforts within the IESG are not uncommon, and actually increase the quality of end-products produced by the IETF. Other organizations such as SIGUCCs, CERFnet, RIPE, RARE, etc., regularly attend the IETFs and contribute to the user services efforts. A User Services Area Council (USAC) has been established to promote and encourage creative exchange of international user service needs and concepts. Constructive input from various national and international user services organizations for the purpose of not duplicating each organization's efforts is also encouraged. USAC will be responsible for researching and defining short term and long term user services needs and coordinating developments in finding solutions. The primary responsibilities of USAC members are to actively provide input for the current and future developments of user services concerns. This forum will conduct meetings in conjunction with the IETF plenaries. Additional communication will take place via IESG [Page 74] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 electronic mail. The User Services Area Director of the IESG chairs the USAC. 13.2 Goals A survey was conducted throughout the Internet from 17 October 1990 - 18 January 1991. IETF User Services members, technical and commercial users, user services national organizations, and NICs and NOCs were polled on what goals and objectives the Internet community should be aiming for. An international survey will be conducted in the near future via USAC. From this survey, seven types of user services objectives and goals emerged. Additional types will be added as warranted: o User Information o Network Information Services Infrastructure o Network Operational Management o Education o Documentation and Distribution o Interaction with IESG Areas o Interaction with other international user services entities. 13.2.1 User Information The Internet community requires up-to-date, basic Internet knowledge and experience. These can be achieved by publication of handbooks, bibliographies, directories, and glossaries. Yet, how does the IETF ``get the word out'' beyond the normal distribution and announcement via the RFC series?? Identification and research on various existing distribution resources, and consideration of possible long term distribution methods are required. A continuing goal of the User Services Area is to create and develop helpful, high quality, and up-to-date information easily available to Internet users of all levels. Researching pertinent user information for the Internet community involves many processes: o Addressing user information that needs to be provided. o Define target audiences (What level of audience?? New user, intermediate, or advanced??) o Identify and categorize current useful documents to avoid duplications and redundancies. o Creation and publication of documents, and distribution. o Development and implementation of procedures to maintain and update the materials. o Identify organization or individuals who will accept the IESG [Page 75] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 responsibility for maintenance. o Identification of future projects via the USAC. Publicizing the Internet requires an activity to make sure users know that the Internet is available for their use. There are a considerable number of sites which are connected to the Internet which have many users still unaware of the resource that is available to them. The Internet must also focus on helping commercial organizations make their users aware of what Internet offers, and make Internet users aware of the valuable commercial services which are available to them. The User Services Area has specific objectives targeted for development and implementation (see specific work section). 13.2.2 Network Information Services Infrastructure A global infrastructure for common, shared Internet-wide network information services is needed. Research and development for what is required to implement an information services ``infrastructure'' for the Internet community is in progress in the User Services Area. Documentation needs to be developed that suggests methods to improve the interaction and cooperation among NICs. This includes Internet Administrator's guides, file retrieval programs, user liaison guides, and white and yellow pages services. We intend to coordinate closely with other efforts in the international networking community via the USAC. 13.2.3 Network Operational Management This topic overlaps with other areas such as network management, operations, and applications. Yet, development of general information to users is essential. For example, there is a critical need for the development, implementation, and standardization of applications for the user services community. Many Internet applications still have user unfriendly interfaces. There needs to be a ``user'' perspective developed and added to interfaces. The User Services Area intends to contribute by providing documentation. This documentation should be developed in tandem with technical specifications as the demand for general information regarding ``user-friendly'' descriptions on Internet protocols increase. This may be in the form of catalogs, checklists, site policy handbooks, and network services information documentation for all levels on how to utilize the Internet. IESG [Page 76] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 13.2.4 Education The educating of new network users is mandatory. The future goal of User Services is to provide organized Internet tutorials, ``hands on'' training programs, active participation in the K-12 education initiative, and Internet specific documentation. 13.2.5 Documentation and Distribution One continuing goal of the User Services Area is to coordinate the development of user information services by clearly and concisely providing documentation information and distribution for the Internet community. FYI RFCs are introductory and overview documents for network users. Their purpose is to make available general information, rather than the protocol specifications or standards that is typical of other RFCs. FYIs are allied to the RFC series of notes, but provides information about who does what on the Internet. The FYI RFC series has proved a success since its initiation, and its goal is to continue to do so. 13.2.6 Interaction with IESG Areas The interaction with other areas so not to have duplications or redundancies is imperative to the global success of the Internet community. The IESG teams up together for the same purpose, as overlaps do exists. Proposed combined goals include: Applications Documentation of ``user-friendly'' information about how and why the technical specification is supposed to work. Internet Services Host Requirements/Required Site Policies Operations Internet Installation Checklist Internet Statistics OSI Integration Facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards by producing FYI RFCs intended to serve as a Directory Services ``Administrator's Guide''. IESG [Page 77] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Security Site Security Policy Handbook 13.2.7 Interaction with other User Services Organizations Interaction with other national and international user services entities has begun in 1991 with the creation of USAC. Currently, USAC's membership includes representation nationally by BBN/NNSC, Merit, CERFnet, SIGUCCS, FARNET, and CICNet. International membership representation includes Europe, Japan, Australia, Canada, and Israel. USAC's goals will be ongoing as the Internet evolves globally. 13.3 Goals The User Services Area encompasses numerous projects. We have divided these projects into 5 sections: User Information, Network Information Services Infrastructure, Network Operational Management, Education, Documentation and Distribution 13.3.1 User Information Internet Q&A ``If I see that SAME question about how to obtain RFCs via anonymous FTP on the TCP-IP mailing list ONE MORE TIME, I'm going to start screaming!!!'' Users joining the Internet community for the first time have had the same questions as did everyone else who has ever joined. The Internet community requires up-to-date, basic Internet knowledge and experience, while moving redundancies away from electronic mailing lists such as TCP-IP, Header-People, etc., so that the lists' subscribers do not have to read the same queries and answers over and over again. To eleviate these redundancies, two Questions and Answers FYI RFCs (QUAIL) are produced and updated on a regular basis by the User Services Working Group. One targets the ``New Internet User'' and the other targets the ``Intermediate Internet User''. Common User Interfaces and User Perspectives Graphics interfaces are now common, yet many Internet applications still have user unfriendly interfaces. There needs to be a ``user'' perspective developed and added to interfaces. The User Services Area should work with the other IESG areas to make this happen. Copyright & Intellectual Property IESG [Page 78] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Development of documentation on copyright policies for electronic information transferral is a topic being discussed within the Internet community and the User Services Area. One thought is to have some way to have electronic libraries installed where the authors could be compensated for their work. This would be considered a long-range project for the IETF. Distribution & Announcement of IETF products The immediate role of the IETF in broadly distributing information to the international Internet community is to make use of communication avenues already developed by other organizations. How does IESG Area Directors and IETF WG Chairs ``get the word out'' beyond the normal distribution and announcement via RFC series?? Identification and research on various existing distribution resources, and consideration of possible long term distribution methods are required. The User Services Working Group is examining distribution resources for an IETF internal publication, ``Distribution and Announcement Handbook'', to get information out by using existing methods and begin to address long term global distribution methods. Historical Documentation Historical documentation that the ``old boys'' may write. Interface with Commercial Networks The Internet is increasingly being linked up to commercial services. If both the Internet and commercial services are to get the most out of this connectivity, we need focus on helping commercial organizations make their users aware of what Internet offers, and make Internet users aware of the valuable commercial services which are available to them. This is an activity where the combined efforts of the IESG should be utilized. Network Service Guide A ``Network Service Guide'' for the Internet community was proposed by an IETF member. This would entail research, development, and creation of a template setting the criteria for the selection of a network to connect to (e.g., membership and its cost, services provided, acceptable use, etc.) is a start. There is a continuing need for more types of these kinds of documents. The User Services Working Group is chartered to develop documents such as this. ``Public Relations'' for the Internet Publicity for the Internet requires an activity to make sure users know that the Internet is available for their use. There are a considerable number of sites which are connected to the Internet which have many users still unaware of the resource that is available to IESG [Page 79] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 them. Articles in journals, magazines, and newsletters, posters, direct mailings, etc., can help make sure that potential users become actual users. With the expansion of the Internet internationally, much of the future potential Internet user community will not be from the U.S. scientific community. As such, new users may not be reached unless assertive public relations efforts are made to contact them. This is an area in which the IETF can contribute, by coordinating publicity activities among various networks, NICs, or NOCs, and by organizing groups of people to speak at various conferences or write for publications. User Services is interested in this endeavor, and we expect this activity to be one of the priorities for our area. For example, we will be conducting a ``User Services'' session at Interop '91. The session will describe our Internet user services community. Specifically, we will present a 1-2 hour session that describes the IETF user services group, including three or four ``user services'' representatives (e.g., the BBN/NNSC, Merit, etc.). Each representative will speak for approximately 20 minutes or so on what our organizations/sites provide to the Internet population. User Bibliography A basic Internet bibliography containing general networking terms and pointers on how and where to obtain these sources requires a document that provides to the new Internet user a place to start. The User Documents Working Group has produced a FYI RFC, ``Where to Start - A Bibliography of Internetworking Information''. The User Services Working Group is responsible for maintaining procedures for the periodic review of this work and updating of this document. User Directory There is a critical need for a directory that can provide help to users who want to find out who else is on the network. Once the appropriate technology for supporting a user directory is found and standardized, it will still take a multi-year effort to get all users appropriately registered in the directory system. Based on experience converting to the Domain Name System, registration will be an intensive effort, requiring extensive technical support and work to encourage sites get their data on-line. This is an activity in which the IETF has the potential to be the forerunner, via regular progress reporting on the users in the directory and finding ways to gently nudge sites to enter and maintain user information. The BBN/NNSC recently published an ``Internet Manager's Phonebook'', at the request of the IETF. It attempts to list everyone who is responsible for a domain name or IP network number as of 1 August 1990. This phonebook could be taken as a model for a User Directory. User Glossary IESG [Page 80] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 There are many on-line and hardcopy computer glossaries in existence, but not one of them is an Internet specific glossary. A glossary of this type needs to be a publication of Internet terms and acronyms. The User Glossary Working Group is in process of this task. Upon publication of a glossary, the User Services Working Group will be responsible for maintaining procedures for periodic review of this work and updating of this document. 13.3.2 Network Information Services Infrastructure Interaction & Cooperation among NICs Documentation needs to be developed that suggests methods to improve the network information infrastructure which consists of Internet NICs on all levels. The NISI Working Group of the User Services Area is chartered to research and develop this documentation. Internet Administrator's Guide Documentation is needed that would provide Internet administrators with guidance. This would be a separate endeavor from the Internet Installation Checklist. This topic was briefly discussed at the IETF in Vancouver. USAC should pursue this subject. Network Services Collecting, editing, and publishing information about available network services and presenting the information in a form which is useful to the Internet community is an on-going dilemma. Many Internet members are suffering from information overload. Their ``real work'' does not allow them to spend hours each week going through mail or making numerous phone calls to locate new services or data. The user services community has made exceptional progress in this area over the past few years, but it is still true that alot of information is not available to users. The IETF has a good track record of assisting people engaged to this sort of work and expects to continue to do so. (The IETF has encouraged its members to help these projects and an inspection of the acknowledgement sections of several of the recent networking books show we've had success). However, these editing and collection activities are extremely labor intensive and expensive, and while users will certainly be willing to pay for the packaged information produced, they probably cannot be expected to cover all costs. New Applications to make NICs Work More Efficiently. SIGUCCS has a concept about a NETHELP command, which when entered into any system, would would search a distributed database which contains information on HELP desks, or who to go to from help about networking. IESG [Page 81] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 SIGUCCS is looking into further development of this idea. USAC should work in tandem with SIGUCCS to achieve this concept. User Liaison Guide CERFnet is developing a guide that they intend to provide to their customer sites which would assist them with educating their user community and their job in general. While strong technical support systems exist, what about a similar system for the user liaison group? This would be different from a user's guide, as it is specifically for those who run the NICs and interface with end users. A template for this kind of guide could be developed for the Internet community via NISI. White Pages Services There are a number of White Pages directories on the Internet; however, all of them are far from complete. The two largest directories available are the WHOIS database at the DDN NIC and the PSInet White Pages. Generally, it is still necessary to ask the person for his or her electronic mail address. A task for the User Services Area is to develop a comprehensive White Pages Service for the Internet. X.400, X.500 Services The question of what will be offered through X.500 services and how they are to be offered and to whom has significant implications for the NICs. The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. Yellow Pages Services There is a need to develop a Yellow Pages Service. This would include information about what services are currently available on the Internet and who the points of contact are for them. System administration staff have users who want to know, ``Now that we are on the Internet, what's out there??'' The User Services Area has this on their priority list. 13.3.3 Network Operational Management Applications There is a need for general information regarding ``user-friendly'' descriptions on DNS, DFS, mail, etc., and explanations on how they work. This type of documentation should be developed in tandem with IESG [Page 82] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 technical specifications. The User Services Working Group has this on its priority list. It is also timely to add documentation on how applications are supposed to work. For example, protocol comparisons like, ``TCP or UDP: What's Your Application?'' Catalogs Providing current and practical information to site administrators and network managers of the Internet requires the development of a catalog containing descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. A NOCTools Working Group was established to develop a catalog, ``A Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices''. Entries in the catalog include: what a tool does, how it works, and how it can be obtained. The NOC-Tool Catalogue Revisions Working Group is responsible for maintaining procedures for periodic review of this work and updating of this document. There are also numerous information servers on the Internet. It would be an asset to have a comprehensive catalogue of servers for the Internet community. Ethics and Etiquette There is a substantial amount of work going on in all user services organizations on this topic, yet the thoughts are not to develop an ``official usage'' statement, but rather a template of issues which a new site (or old) could use as guide for creation of their own site specific rules. The User Services Area could collaborate with other outside organizations on this subject. This effort can be coordinated through the USAC. ``How to Utilize the Internet'' There's been quite a bit of clamoring from the User Services trenches regarding network services information documentation for all levels on ``How to Use the Internet''. Many users don't know how to obtain information about network contacts via, for example, the WHOIS database or electronic mail to: info-nis@site.edu. An application needs to be developed where a user could send electronic mail to a netnews group requesting ``How do I obtain contact information about net xxx.yyy? A representative document on how to utilize the Internet also needs to evolve from this effort. This is a long overdue task for the IETF. Internet Installation Checklist A qualitative checklist for the Internet Community is long overdue. It should require a new user to have only a minimum knowledge of the subject at hand. This should include identification and sources of IESG [Page 83] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 Internet registrations, routing in the Internet, other parallel networks, additional Internet services, and worksheets. This checklist should also be comprehensive enough so that it may also be used as an important reference tool for those intermediate and advanced users desiring to expand their knowledge of currently available Internet sources, points of contact, and documentation. The User Services Working Group is in process of writing documentation for this purpose. Internet Introduction Packages There is a need for ''Intro Packages`` for all levels of new Internet users. Such as, ''How to join the Internet``, or documentation describing existing (implemented) network services (i.e., a new Internet user thinks, ''I just connected to the Internet, what services does it offer me??.`` A compiled list of all network services available is required. Specifically, NTP, FINGER, WHOIS, domain name service, SMTP, file transfer capability, network terminal, TCP/UDP/ICMP Echo services, etc. For example, using the list of assigned TCP and UDP ports can quickly reference these services. A notation can be cited, stating if each service is in widely distributed use. This information may be easily obtained based on the IAB's ''Official Protocol Standards`` publication on the state of standardization of protocols used in the Internet (e.g., recommended standard, historical, etc.). This could also bring out those services which aren't as widely discussed as electronic mail, TELNET and FTP. The User Services Working Group has this topic on its priority list. Site Policy Handbooks Internet specific handbooks should act as a guide to setting computer policies and procedures for sites that have systems on the Internet. They should list issues and factors that a site must consider when setting their own policies, and suggest recommendations and give discussions of relevant areas. In this context, a handbook should provide only a framework for setting site policies and procedures. In order to have an effective set of policies and procedures, a site will have to make many decisions, gain agreement, and then communicate and implement the policies. 13.3.4 Education Education of Special User Groups The Internet community has been encouraging new groups of users to consider using the Internet. Examples of such users are supercomputer users, ecologists and astronomers. As we invite these user groups to participate in the Internet, we also need to make sure user services is prepared to assist them. Specifically, new users with specialized IESG [Page 84] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 interests need to be able to obtain information on what the Internet can offer them. For example, supercomputer centers must show their users how to best utilize the network to perform supercomputing; mechanisms for informing scientists about where to find special data repositories and archives need to be established. So far, the user services community has dealt with this problem reasonably well, but this task is a continuing need, as new users appear in the Internet community. IETF Tutorials There has been an increase in new participants at the IETF plenaries, and they are detracting from the other activities. There is a need to conduct IETF ''intro`` sessions (e.g., how to mail to the world, etc.). Introductory sessions like these can be coordinated by the User Services area, in partnership with other IESG areas. The IETF will be experimenting with this concept. K-12 Education Initiative The National Science Foundation has identified K-12 networking as an important mission and is preparing solicitation in this area. Merit is currently researching initiatives in their state. They have discovered that people working in the K-12 educational system perceive many obstacles to using computer technology (e.g., financial and equipment limitations, and a sense that network use will not be supported within school systems). The IETF should look into the K-12 Education Initiative and provide assistance in identifying existing applications in the Internet that may be targeted for K-12, research and develop new applications, and establish a consistent way to access those applications. Providing significant user support for using the applications should also be targeted, as well as assisting in the establishment of a reliable and easy-to-use network service for school systems globally. ``Standard Curriculum'' Training Programs and Improving Training Material for Local Instructors Not all users are able to go to commercial tutorials on how to use the Internet, due to exorbitant costs. Yet, the educating of new network users is mandatory. Hence, teaching will need to be conducted at local sites. It can be ascertained that the teachers of new users have attended courses and have have become ``certified'' to teach students on how to use the network, but there is a need to pay attention to the quality of training materials and supplies these teachers will have in hand and use when they go back to their sites. This goes beyond the ``Conventional'' hardcopy textbook sources. Instructional videos illustrating how to use the network, ``hands-on'' demo programs, such as a program that acclimates new users through IESG [Page 85] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 sending their first e-mail message, and quality course notes from which local courses could be taught is needed. Clear, concise, and up-to-date documentation has been produced by the User Services Area via the FYI RFC series of notes, and has been applauded in the user services community, but there is an acute need for more materials to be developed. TCP/IP Tutorials New members to the Internet community experience some frustration on the lack of one Internet specific tutorial. There are MANY tutorials in existence, but a representative Internet TCP/IP Tutorial needs to evolve, perhaps entitled, ``A Tutorial on the TCP/IP Protocol Suite''. 13.3.5 Documentation and Distribution One of the tasks of the User Services Area is to coordinate the development of user information services by clearly and concisely providing documentation information and distribution for the Internet community. The FYI RFC series provides information about who does what on the Internet. Current list of publications related to user services: ``FYI on Questions and Answers - Answers to Commonly asked `Experienced Internet User' Questions'', FYI 7, RFC 1207, March 1991. ``FYI on Questions and Answers - Answers to Commonly asked `New Internet User' Questions'', FYI 4, RFC 1206, March 1991. ``FYI on the X Window System'', FYI 6, RFC 1198, January 1991. ``FYI on Where to Start - A Bibliography of Internetworking Information'', FYI 3, RFC 1175, August 1990. ``FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices'', FYI 2, RFC 1147, April 1990. Soon to be published: ``Internet Site Security Policy Handbook''. ``Internet User Glossary''. ``FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices, Revised''. ``FYI on Directory Services Administrator's Guide''. IESG [Page 86] INTERNET-DRAFT An Internet Evolution Plan For The IETF July, 1991 ``FYI on Where to Start - A Bibliography of Internetworking Information, Revised''. IESG [Page 87]