Minutes of IAB Meeting -- June 28-29, 1990 Bolt, Beranek, and Newman, Cambridge, MA This document contains minutes of meeting of the Internet Activities Board, held on June 28-29, 1990, at BBN in Cambridge, MA. The meeting agenda will be found in Appendix A. The attendees were: IAB Members: Bob Braden, ISI Hans-Werner Braun, Merit Vint Cerf, NRI David Clark, MIT Phill Gross, NRI Steve Kent, BBN Tony Lauck, DEC Barry Leiner, RIACS Dan Lynch, Interop Jon Postel, ISI FNC Visitors: Bill Bostwick, DOE Paul Mockapetris, DARPA Ira Richer, DARPA The IESG (Internet Engineering Steering Group) was invited for the second day. The following IESG members attended: Steve Crocker, TIS Craig Partridge, BBN Ross Callon, DEC Russ Hobby, UC-Davis Dave Crocker, DEC Bob Hinden, BBN Greg Vaudreuil, NRI These minutes were prepared by Greg Vaudreuil of NRI and edited by Vint Cerf and Bob Braden. We have endeavored to accurately reflect the content and thrust of the discussions. Although the IAB members have reviewed the results, we must take responsibility for any unintentional misrepresentation. Bob Braden Vint Cerf Greg Vaudreuil 1. REVIEW ACTION ITEMS A detailed list of old action items will be found in Appendix B. The following significant points emerged from the discussion: Braden [Page 1] Minutes of June 1990 IAB Meeting October, 1990 o Gross has completed the task of updating the charters of all the IETF working groups, and the results are available online in the IETF directories. NRI has nearly completed a database contain- ing all working group information. o Cerf is continuing the effort to register the Internet name with the US trademark office. The law firm of Haley, Bader, and Potts has been retained. o A subcommittee of the IAB called the Policy Working Group (PWG) has been formed, chaired by Leiner. The function of the PWG will be to consider particular policy issues, as directed by the IAB, and to draft proposed position statements for IAB con- sideration. The Policy Working Group was convened for the first time on June 27th and produced its first recommendations for this meeting. o At the previous meeting, the IAB had instructed its Executive Director (ExecD) to publish IAB meeting minutes as RFCs. The ExecD requested that this decision be reconsidered, since IAB minutes are generally topical, not appropriate for enshrinement in an archival document series. It was decided to delay publi- cation as RFCs, pending a review of all IAB publications. In the meantime, the ExecD will (continue to) make minutes publicly available for anonymous FTP, and publish summaries in the Inter- net Monthly Report. 2. BRIEF MEETING REPORTS 2.1 CCIRN Meeting report -- Leiner Leiner and Bostwick attended the May 9-11 meeting of CCIRN (Coor- dinating Council for International Research Networks) in Nice, France, as the IAB international representative. Leiner reported that the CCIRN meeting made major progress. (1) There is rising interest in Europe in building a coordinated structure for network engineering, to keep up with the grow- ing European Internet. The IAB wants to encourage these developments, to allow better international cooperation in building the intercontinental Internet. (2) Gross and Bostwick helped in writing Terms of Reference for an Intercontinental Engineering Planning Group (IEPG); see Appendix C. The IEPG will meet for two days in October 1990, with Gross attending. The IEPG also plans to hold a workshop in July 1990 on CO vs. CL protocols. Braden [Page 2] Minutes of June 1990 IAB Meeting October, 1990 There is also a European initiative to build a European Engineering Task Force (EETF), to parallel the IETF in the US. (3) RIPE (the European organization for IP networks) is drafting a plan for a European IP registration authority. The IAB will have a chance to review it. (4) The CCIRN has agreed to the proposed international intercon- nection guidelines developed by the IEPG. Gross will publish these guidelines as an RFC. (5) The CCIRN has been working on an acceptable-use policy. It has also adopted an official ethics statement, based upon the IAB ethics statement [RFC-1087]. (6) The CCIRN has responded positively to the IAB decision to extend the Internet to support multiple protocols. NEW ACTION: Gross: Publish international interconnection guidelines as an RFC. This led to a discussion of how to "internationalize" the IAB, to reflect the emerging international Internet. The following points were made: * There is a serious need for an organization for solving international operational issues. * The IEPG, which will include both government and non- government interests, will not be an exact parallel to the North American Engineering Planning Group (NAEPG), which is intended to deal only with government-related connections. There was concern in the IAB that the NAEPG is too government-centric. It seems desirable that every organiza- tion putting in an intercontinental link (e.g., PSI, UUnet, and IBM) be represented in NAEPG. Bostwick reiterated the preliminary nature of this organizational structure and emphasized that other options are being considered. * The IAB was concerned that there is much more to organizing the global Internet than simply coordinating links. Clark pointed out the need to develop a long-range architectural strategy for organizing the global Internet. This is a big job, and requires input from a lot of different players. He noted that this level of planning is much different from the Braden [Page 3] Minutes of June 1990 IAB Meeting October, 1990 topology planning that the IEPG, for example, is expected to perform. Lauck observed that for networking to succeed, three things are needed: mechanisms, topology, and policies, in a reasonable level of harmony. * It was noted that, despite the growing importance of CCIRN, there are no RFC's describing its organization or position statements. NEW ACTION: Leiner: Publish the charter ("Terms of Reference") and ethics statements of the CCIRN as an RFC. 2.2 ANSI Meeting Report -- Cerf The proposal to put the core Internet protocols into the ANSI standards process was tabled by the ANSI X3S3.3 meeting. There was a lot of uncertainty about how the IAB would work with ANSI to change the protocols, should they need modification. The original idea of IAB handing fully standardized protocols to ANSI for yes or no approval was not acceptable to X3S3.3. ANSI rules on protocol standards are strict. To remand an issue to the IAB, ANSI would required that the IAB be accredited, and X3S3.3 was not sure that IAB procedures would be consistent with the ANSI procedures. If ANSI had change control itself, two divergent standards might emerge. Cerf suggested that the next step should be to convene a small joint working group of the IAB and ANSI X3S3.3, to consider feasi- ble modes of collaboration between the IAB and ANSI and report back to both organizations. One model that was suggested was an IETF working group accredited by ANSI and operating under ANSI rules, analogous to the accreditation of IEEE. The question was raised, whether ANSI standardization of the core Internet protocols would really be a great benefit to anyone. 3. CRITICAL ISSUES & RESEARCH AREAS At its meeting one year earlier, the IAB had created a list of criti- cal issues in the Internet, at the request of the FNC (FRICC); this list is contained in Appendix D. The June 1990 meeting reviewed this list to consider what progress had been made and to construct a new list: "Principle Foci for Internet Evolution 1991-1992". Braden [Page 4] Minutes of June 1990 IAB Meeting October, 1990 3.1 Operational Stability In the process of reviewing the list, the detailed bullets were somewhat modified and expanded to the following. o Internet Instrumentation Fault isolation, data gathering and analysis. o Routing Continued growth affects operational stability, as routing tables overflow. The open IGP candidates, OSPF and IS-IS, provide better algorithms: less computation although more memory. Lauck suggested the need for a technology forecast, comparing projected growth vs. expected hardware capability in routers. o Domain Name Server/Resolver repair o Inter-Autonomous Region routing o Topology Management o Define Service requirements on regional and backbone networks Since regional networks typically have a monopoly, they are obliged to maintain their service quality. Braun suggested that the higher speeds of backbones today may be hiding prob- lems that will show up out in the leaves of the connectivity tree. o Handle conflict between installed-base and new technology infusion Clark deplored the fact that we are still in reactive mode with respect to routing and growth. Leiner agreed that an architec- tural plan for growth is THE key to operational stability. Richer observed that development of an NREN architecture plan is in progress, and that this needs to be coordinated with IAB/IETF planning. 3.2 User Services The bullets are: Braden [Page 5] Minutes of June 1990 IAB Meeting October, 1990 o White Pages/Knowbot Information Services o Private Electronic Mail o Public, Private, International Email Links. o Application Support Tools/ Protocols The IAB expressed concern that progress in most of these areas has been very slow. It was suggested that the problem is a lack of coordination and funding for development and deployment. The PSI Quipu service appears to be quite successful. Two major technical problems in the White Pages area are: (1) constraints on broad searches and (2) access control. Kent observed that X.500 will be needed for private email. Cerf listed important applications: * Digital Library Services * Distributed Processing * Video Conferencing * Collaboration Research * Security Services 3.3 OSI Integration o Multi-Protocol Gateways There now exist some multi-protocol gateways, but the IAB should actively encourage development and deployment of more of them. o X.400/RFC 822 Relays o X.500 Pilot Projects o Registration Facilities Major issue: Privacy-Enhanced Mail needs good registration and directory services. Some progress has been made towards Braden [Page 6] Minutes of June 1990 IAB Meeting October, 1990 the creation of a Registration Authority for PRMD's and NSAPs, but the political process is very slow. NEW ACTION: Lauck: Report at next IAB meeting on status of OSI registration procedures and authorities. 3.4 Testbed Activities o Multi-vendor gateway testing: to test network management and multi-protocol routing and forwarding. o Open architecture gateway testbed: DARTNET. There is a benchmarking effort in the IETF, working to define multi-protocol interoperability and performance issues. This will coordinate with the experimental networks. Collaboration research may need more push. Lauck suggested that testability needs to be part of the architec- ture. NEW ACTION: Lauck: Write down the actions that the IAB could take on testing. 3.5 Getting Big o Large Scale Internet Architectures Need a long-term architectural plan for Internet. o Naming, Addressing, Routing, Navigation Issues are: size of routing tables and updates, quality of routing metrics. 3.6 Getting Fast o Limits to Internet architecture? Braden pointed out that his End-to-End Research Group has been thinking about the limits of the Internet architecture, Braden [Page 7] Minutes of June 1990 IAB Meeting October, 1990 and this has resulted in RFC-1072 [and RFC-1185: ExecD]. o High speeds and latency o Internet use of gigabit technology o Improve TCP implementation and functionality NEW ACTION: Braden: Summarize E2E RG work on architecture lim- its for IAB. 3.7 Major New Initiatives o International Internet Architectural Plan - potentially a huge undertaking - structural components are diverse - constituents (Federal, private, commercial, interna- tional) - need operational plan and framework - need to identify use and access policies o Internet Security Architecture - Technical infrastructure requirements - Mechanisms for end-node (host) protection - Access control to protect Internet infrastructure - Configuration of hosts, routers, etc. for security ("pre-flight check lists") 4. INTERNATIONAL CONNECTIVITY AND COLLABORATION The IAB considered and adopted, with editorial changes, the "Recom- mended Policy Change to Internet 'Connected Status'" prepared by its Braden [Page 8] Minutes of June 1990 IAB Meeting October, 1990 Policy Working Group. The problem of "IP islands" came up, i.e., isolated internets using IP addresses. These addresses will not be expected to appear in the primary Internet's IN-ADDR data space. Thus, the policy of dropping "Connected Status" should be interpreted to mean that inclusion of an IN-ADDR record for an IP address is optional, not mandatory. Mockapetris noted that the recommendation removes the brake on appli- cations for name registration. This may increase the cost of administration. The IAB also considered and adopted, with editorial changes, the "Recommended Policy on Distributed Internet Identifier Assignments" prepared by the PWG. [Both recommendations have since been published as RFC-1174: ExecD] NEW ACTION: Gross: Present to the Engineering and Operations Working Group (EOWG) of the FNC the IAB recommendations on changes to connected status and on distributed IP network number assignments. 5. MULTI-PROTOCOL INTERNET The IAB has taken the position that the Internet should support mul- tiple protocol suites, but what this means has not been clearly defined. Discussion included the following points: * There are major architectural issues. It is analogous to the Internet's idea of connecting multiple networks to form an internet. * Are we talking about N = 2 (i.e., IP and CLNP), or N >= 2? Some felt more comfortable with N = 2, others felt that the architec- ture should be extensible to handle N>2. * Is this a research issue, or should the IAB be taking opera- tional responsibility? The latter would take lots of resources. * This may conflict with the standards and profiling bodies responsible for the other internet protocols (e.g., OSI). * There is a need for technical profiling and implementation recommendations, e.g., an OSI router requirements document. Braden [Page 9] Minutes of June 1990 IAB Meeting October, 1990 However, Gross does not want to retard the current router requirements effort by expanding their charter to include multi-protocol routers. He feels that work on multi-protocol mail system is a higher priority. Braun suggested a new IETF working group on OSI Requirements. The PWG reported that they had discussed this issue, but in the lim- ited time available they were unable to reach any specific recommen- dations. The chair directed the PWG to continue working on this topic. 6. THE IP ADDRESS SPACE PROBLEM We could run out of IP addresses. There are approximately 18,000 IP numbers assigned currently. Several questions were raised. 1. How fast are we consuming numbers? 2. How long will they last? 3. Is this a real problem, or will we run out of router capacity first? 4. Are the 16 bits for AS number enough, or much too little? Removing connected status will make this problem more severe. There will be a huge increase in rate of number assignment when economies of scale bring in major new markets -- e.g., home Ethernets ("toaster nets"). Clark predicted that toaster nets will be a reality in ten years; Lauck suggested that ISDN will have an impact too. Might there be a creative hack around the limitations? It was accepted that a hack might be technically possible, but a more coherent approach would be much preferable. Some felt that it may be better to install OSI for the network layer, at least; however, it was questioned whether we have convincing evidence that OSI can han- dle the large Internet we are facing. The change would be much less traumatic if applications did not have to change. Braden [Page 10] Minutes of June 1990 IAB Meeting October, 1990 NEW ACTION: Postel: Get statistics on the rate of IP network number consumption by class. Clark pointed out that the Internet will run out of routing resources long before it runs out of network numbers. Hierarchical routing is very important. We need more hierarchy in the IP space than subnets give us, and we may need more than even OSI can give us. There is much work to be done with the use of autonomous domains. NEW ACTION: ExecD: Put on next IAB meeting agenda a further dis- cussion of the IP address space problem. 7. EXTERNAL RELATIONS The Corporation for Open Systems (COS) has approached the IAB seeking a closer working relationship. After discussion, the IAB concluded they had no clear idea of the value of a formal relationship with COS. It was observed that COS has no role in R&D, which is an impor- tant IAB concern. NEW ACTION: Lynch: Write to COS to encourage their participation in IETF and their suggestions for joint projects. The IAB has been approached by EDUCOM, COS, FARNET, and others. How should the IAB to respond? All these organizations are different, so a global policy may be difficult. The IAB is willing to engage in relationships that are perceived to be advantageous to the Internet community as a whole. FNC has a special relationship to the IAB by nature of support and research interest. The IAB is generally open to the use of the IETF and IRTF as an administrative framework to carry on network-related research and engineering activities. For example, the Collaboratory research work could be coordinated under the IRTF. 8. IAB ADMINISTRATION Although this agenda topic had been intended to cover purely adminis- trative issues, two major substantive issues were introduced and dis- cussed. Braden [Page 11] Minutes of June 1990 IAB Meeting October, 1990 8.1 Liability and Standards Setting The IAB members who attended the ANSI meeting were impressed by the liability precautions taken by that organization. This raised (again) a concern about openness and fairness in the Internet standards activities of the IAB, to avoid potentially severe lia- bility problems. This led to a discussion of possible alternative mechanisms for Internet standards setting. The extreme position would be for the IAB to stop setting stan- dards. Internet standards might then be set by an open procedure group discussion on a moderated mailing list, with some arrange- ment for balloting. Another suggestion was for a new ISTF (Inter- net Standards Task Force), accredited to ANSI and operating under ANSI rules. The IAB could still take the role of profiling stan- dards for Internet usage. However, there were strong objections to giving up responsibility for standards, since some felt that this would risk losing the coherence of the architecture, and it might slow or halt progress. The current, relatively informal, IAB standards machinery has been quite effective, and is sometimes cited by members of the Internet community as a strong advantage. The challenge is to make the process sufficiently open that liability is not an issue, without losing effectiveness. No conclusions were reached. NEW ACTION: Gross: Encourage Noel Chiappa to release the results of the Hale and Dorr liability studies. 8.2 Operational Responsibility There is a perception that the IAB is responsible for operation of the Internet. Some reasons cited for this perception include: - The work of the Topology Engineering Working Group of the IETF. - The IAB Ethics Statement - The IP Number Assignment Authority (IANA) being on the IAB. The Internet is a collaboration of many administrations. The IAB cannot be responsible for Internet operations, since it does not control all the parties, nor is it funded for such a major job. The IAB has always viewed its role as a facilitator, through tech- nological and policy guidance. After some discussion, the IAB agreed that it should also accept limited responsibility for Braden [Page 12] Minutes of June 1990 IAB Meeting October, 1990 operational issues, and in particular for facilitating cooperation and coordination of the operational parties. For this purpose, some administrative structure is required; the obvious approach is an operations area in IETF. Gross reported that he has been trying to form such an area, but it has proven difficult to get the correct people. There is not yet an operations area director in the IESG. Gross suggested creation of an Operations Board, an incarnation of the Topology Engineering Working Group (TEWG) in an executive role, with the TEWG Chair serving as an Area Director in the IESG. While the IETF contributes to operational stability, no one group can be responsible for the operation of the whole Internet. The IAB can and will provide for the cooperation of operation folks in the Internet. 8.3 IAB Load There was a discussion of the increasing time and email load on IAB members, and of possible measures to contain it. There is a conflict between the apparent need of the Internet for prompt, carefully-researched decisions from the IAB, and the fact that the IAB is an extra job for most of its members. Formation of an IAB subgroup devoted to standards issues was discussed, but no deci- sion was made. 9. STATUS REPORTS The IESG joined the IAB at this point, Friday AM. 9.1 IETF Report -- Gross The IESG has made the IETF more manageable, and with better management there are now many more working groups. [The IAB expressed concern that the number of working groups may again grow beyond the management structure, so that the number of working groups needs to be limited. The limiting factor for the number of groups and amount of simultaneous work is the number of active participants.] A trend related to the growing number of groups is the tendency of non-IETF groups to hold meetings at IETF plenaries in order to reduce travel expenses. Examples include the FNC working groups, NIST working groups, ANSI X3S3.3, and IRTF working groups. Braden [Page 13] Minutes of June 1990 IAB Meeting October, 1990 9.2 IRTF Report -- Clark The network research community is significantly different from the Internet engineering community, at least in part because the fund- ing agencies are no longer focusing on specific agendas related to networking. The IRTF role is to serve the research community, facilitating interactions among researchers and coordinating research initiatives. The IRSG is not the analogue of the IESG. Currently the IRSG is a largely dormant but should be resuscitated, hopefully with a longer term vision. The IRTF research groups are: End-to-End (which is doing lots of network dynamics work, although its name has become a bit anomalous); Autonomous Networks; Privacy and Security; Collabora- tive Technology; and Naming and Resource Location. An important function of the IRTF should be to organize one-shot workshops on specific topics. IRTF sponsored a very successful gigabits workshop at BBN last January, put together by Craig Par- tridge. 9.3 NSFNET Report -- Braun The NSFNET backbone is evolving towards T3 speeds. The T3 network will be constructed as an overlay to the current NSFNET. The switching nodes will be co-located routers in the inter-LATA car- rier POPs, and some of the T3 tails will use digital radio. In this configuration the core network is more robust, even if the tails are a bit more delicate. Initial T3 deployment is likely to be this year. OSI CLNP code will be available for deployment in the T1 network in the next few months. NSFnet is cooperating with Proteon and Cisco for CLNP support outside the backbone. The CLNP service will extend into CA*net. OSI NSAP addresses are locally assigned; there is no central authority, which is a problem. The NSFNET backbone is performing well. The T1 network is still not very loaded. Hosts are generally configured for slower net- works and are using a sub-optimal window size. 9.4 DARTNET Report -- Braden Braden reported on the DARPA Research Testbed Network, or DARTNET. This will be an open gateway testbed built of T1 circuits, which will allow the experimenters to replace the router code. It is Braden [Page 14] Minutes of June 1990 IAB Meeting October, 1990 expected to become operational early in the Fall. 9.5 Privacy-Enhanced Mail Report -- Kent and S. Crocker Crocker reported that a reference implementation of Privacy Enhanced Mail (PEM) is being alpha-tested at Trusted Information Systems (TIS). It will soon begin a staged beta release, first to BBN, CNRI, and the Privacy & Security Research Group (PSRG). The initial implementation runs on Sparcstations with interfaces to MH. The source code may be made available, but the RSA routines will be object-only. NEW ACTION: Kent: Provide a document specifying the configura- tion needed to run the PEM software. The next version of PEM will include the organizational notary software under development at BBN; it is not expected until Sep- tember. General availability is predicted for the end of calendar 1990. There are efforts underway to get agreements to allow a variety of computers to use the RSA software. This will require object code for each platform. The license agreement being proposed by RSA Data Security, Inc. (RSADSI) has changed and needs IAB review again. Wider review would be highly desirable. There was some concern about the patent issue. Implementation of PEM depends upon RSA code that is covered by a US patent, and to make PEM an Internet standard, we will have to incorporate this patent in the standards documents. Lauck pointed out the ANSI rule: for a standard to incorporate a patent, the patent holder must agree to license the use of the technology for a reasonable fee and in a non-discriminatory fashion. Kent noted that MIT, which is typically very picky on patent issues, has reviewed the agreement and intends to sign it. Crocker urged a full public review of the agreement, although there was some feeling that the IAB has already extensively alerted the community about its plans for PEM. NEW ACTION: Kent: Get latest proposed RSADSI agreement text for IAB review. Kent noted: * The fourth RFC in the series on PEM will be ready in about two months. * Implementation experience has led to some changes in the Braden [Page 15] Minutes of June 1990 IAB Meeting October, 1990 existing PEM RFCs. * Schiller of MIT is integrating PEM code into Gnu Emacs. * RSADSI is prepared to allow use of certificates for other than private mail, but they need an explicit list of applica- tions. * The Europeans are planning to allow RFC-822 secure mail (PEM) as a body part in X.400 mail. 10. ROUTING Clark reported on the inter-AD routing meeting, which was convened at IAB request by Bob Hinden, the IETF area director, and by Dave Clark. Attendees included Bob Hinden, Dave Clark, Ross Callon, Radia Perl- man, Yakov Rekhter, and Martha Steenstrup. o The fundamental questions were, "What happens when the Internet gets big?" and "What mechanisms will we need to deal with this growth?". On the table are BGP and IDPR (Inter-Domain Policy Routing). o As the Internet expands, there will be a fundamental stress between the differing requirements of the multiple government- agency networks and the commercial networks. The two broad strategies for dealing with this mixed use are to: (A) Impose policy, or (B) Impose topology Those who believe in imposing policy say topology cannot funda- mentally be changed, and that the networks will become increas- ingly interconnected. Those who believe in imposing topology, e.g., operational mission folks, do not believe policy control will be sufficient; they perceive a need to protect assets by topological construction. The conflict fundamentally is resource protection vs resource allocation. o We need a strategy for handling growth. The direction we choose depends upon what we think the shape of the future Internet will be. But chosing a direction for inter-AD routing may in fact partially determine future shape of the Internet. o One suggested starting point: there is a basic requirement that routing always work; however, not everyone agrees on this. Braden [Page 16] Minutes of June 1990 IAB Meeting October, 1990 o Accepted principle: must be able to compose a route using par- tial knowledge, obtaining a route that is correct but not neces- sarily optimal. o Since IDPR will change the headers, we should look carefully at all the requirements and make only one global change in the architecture. However, we must be realistic and follow the rules: (1) Preserve existing functionality. (2) Don't modify the hosts. (3) Can't change all the routers quickly. o The BGP and the IDPR approaches had been contrasted. BGP: * Route binding can be done near source. * Routes available are pre-composed. * Database grows as O(size of Internet) IDPR: * Route binding must occur further from the source. * Route includes some source specification. * Database grows as O(Number of "connections"). The scaling of the number of connections is very unclear and is a subject for research. o The general conclusions of the meeting were: BGP is what we ought to do NOW; IDPR is research. o The meeting also came to the conclusion that when IDPR becomes real, IDPR and BGP can coexist. This was the end of the report from the earlier inter-AD routing meeting. The IAB and IESG then held a lively discussion of the report. Assuming that BGP will be the short-term solution, there was a dis- cussion of the implications. There was some uncertainty about what is currently included in the BGP specification, and whether any current implementation of BGP reflects the current RFC. It was sug- gested that a BGP subset definition may be needed. Clark commented that "the water over the dam has taken us downstream". The BGP documents have been approved by the IAB as proposed Braden [Page 17] Minutes of June 1990 IAB Meeting October, 1990 standards. There is strong pressure to freeze the spec and implement the subset needed immediately, while continuing to address the open issues, e.g., transport and security. However, there was concern that this approach will result in freezing the actual implementations at a level which will not be adequate for long. NEW ACTION: Gross: Ask IESG for document describing subset of BGP that is currently being implemented. The BGP documents have been submitted to ANSI for consideration as the basis of an Inter-Domain Routing Protocol (IDRP) for OSI. It was noted that ANSI is developing a new transport protocol for IDRP. The meeting expressed a desire for IDRP and BGP to evolve together, remaining as close together as possible. There were concerns expressed that the ANSI IDRP could not be implemented using the lim- ited memory of current routers, and that BGP has been submitted to ANSI without knowing the long term effects of the protocol. 11. STANDARDS PROCEDURES 11.1 Requirement Level. The IAB debated several proposals for updating the procedures for specifying the "requirement level" or applicability of Internet standards. Among other thoughts: o The IAB must be able to specify applicability of protocols that did not originate in the IAB. This is one reason to separate the the applicability statement from the protocol specification document. o A standard needs to have a requirement, and this requirement needs to be published, if not with the specification, then often and accurately. o It may not be good to republish documents when they change standards status if the documents have not significantly changed. "Check the IAB standards documents for the latest status of this document". o It will sometimes be useful to specify "intended applicabil- ity", giving background and motivation. Even if the status is separated from the protocol spec document, the latter should contain a narrative to explain the motivation for the protocol spec. o Requirements documents do not change very fast. Could Braden [Page 18] Minutes of June 1990 IAB Meeting October, 1990 publish applicability document, just short lists, more often. There might be three kinds of documents defining applicability and requirements for protocols: o A terse list of protocols and recommendations -- this is the existing IAB Official Protocols RFC. This RFC can refer to other elaboration documents. o Requirements documents, e.g., the Host Requirements and Router Requirements documents. o Profile documents, simple lists of applicable protocol requirements for each type of device. There are timing issues involved in the update cycle of these documents. o There must be a requirement or applicability statement for a protocol when it becomes a standard. o There should be a "Heads Up" anticipated requirement level for protocols earlier in the standards track. This can be done easily in the profile documents. The meeting agreed upon the following: DECISIONS: (1) Both the status (requirement level, e.g., Required or Optional) and the state (e.g., Proposed Standard or Standard) will separated from the actual protocol specification documents, to appear instead in the Offi- cial Protocol Standards RFC and in requirements and applicability documents. (2) A protocol specification documents will include a statement of motivation or intent of the protocol. (3) There will be a new class of profile documents, terse statements of the protocols required to build an X. Braden [Page 19] Minutes of June 1990 IAB Meeting October, 1990 11.2 Moving Off the Standards Track There was discussion of the guidelines for protocol changes as a document moves through the standards track. The following agree- ments were reached. DECISIONS: (1) From Proposed Standard to Draft Standard: The implementors of the protocol should expect protocol changes. The document should move to Draft Standard only if it is expected to be stable, and satisfies its function. (2) From Draft Standard to Standard: Advancement to Standard is only allowed with minor changes. If there is a non-interoperable change to the protocol it must have a new version number, but it may remain at the Draft Standard level. Demoting the protocol to Proposed Standard is a judgement call, based on the expectation that the stability of the revision. In the case of uncertainty, the IAB should err on the conservative side, demoting the revision to Proposed Standard. When a protocol in the standards track ceases to advance, it should be retired. DECISION: If a protocol stays in Proposed Standard or Draft Standard state for two years, it must be reconsidered by the IAB. 11.3 Vendor Contributed Protocols The Policy Working Group introduced a recommendation on rules for IAB standardization of vendor-contributed protocols (VCP), and after discussion the IAB adopted them. DECISIONS: The IAB may standardize a VCP if either of the following holds: (1) The vendor will turn over protocol change control to the IAB/IETF. Hopefully, the vendor will continue to participate in the evolution of the protocol through participation in Braden [Page 20] Minutes of June 1990 IAB Meeting October, 1990 the IETF working group. The VCP might have been entered into the IAB standardization process during its initial evolution, or it might be a de facto standard for which the vendor is willing to grant responsibility for further evolution to IAB/IETF. (2) An IETF working group starts with a vendor protocol as level zero, and with the vendor's permission, evolves the protocol independently of the vendor's version. In either case, the standards specification must be open and freely available for RFC publication. If neither of these holds, a VCP cannot be in the IAB standards track, although it will certainly be a candidate for publication as an information-only RFC. A related issue is an IAB standard that simply depends upon a VCP; a current example is the Lan Manager MIB. The IAB does not need to control the VCP (e.g., the Lan Manager protocol), but it must have agreement from the vendor that the IAB has control over its own protocol (e.g., the MIB). DECISION: The IAB/IETF can create a secondary protocol standard that depends upon a primary VCP only if the specification for the primary protocol is openly available and if the vendor agrees to IAB/IETF control over the secondary protocol. NEW ACTION: Cerf: Get a note from Microsoft that the Lan Manager MIB effort is accepted and supported. 12. Standards Actions The IAB decided upon the following standards actions. (1) The following grand-fathered protocols will remain as Proposed Standards for the present: SUPDUP (RFC-734) and Finger (RFC- 742). (2) The following grand-fathered protocols will be moved to Experi- mental: Resource Location Protocol (RLP, RFC-887) and Simple File Transfer Protocol (SFTP, RFC-913). (3) The Hostname protocol (RFC-953) will be moved to Historical. (4) The Internet-Draft documents: DRAFT-UCL-KILLE- Braden [Page 21] Minutes of June 1990 IAB Meeting October, 1990 NETWORKADDRESSES-00.PS.1 and DRAFT-UCL-KILLE-PRESENTATIONADDRESS-00.PS.1 will be remanded to the IESG for further work. (5) The Point-to-Point Protocol Initial Configuration Options (PPP Options) specification will be published as a Proposed Standard as soon as a security issue raised by Kent is resolved. NEW ACTION: Gross (Hobby): Obtain better RFC on finger and have some working group reexamine SUPDUP. NEW ACTION: Kent: Resolve PPP Options problem. [DONE: RFC-1172]. Finally, the IAB and IESG discussed whether the revised CMOT specifi- cation should be published as a Proposed or a Draft Standard. Based on this discussion, the IESG will later make a recommendation to the IAB. It was agreed that, when a major revision is made to a Draft Standard protocol, the decision on whether to leave it at Draft or return it to Proposed Standard state is a judgment call. It depends upon the extent of the changes as well as the degree of community investment in the protocol. In the case of CMOT, it is clear that the earlier version did not have any significant deployment, and it was suggested that Proposed Standard would be quite appropriate for its actual state of development and deployment. [On 31 August, 1990, the IESG recommended that the revised CMOT become a Proposed Standard, and the IAB subsequently voted to adopt this recommendation: ExecD]. There was some limited discussion of network management policy. It was pointed out that SNMP lives up to its name as a simple protocol, but that as people use it for more applications, it will need to become less simple. Two problem areas mentioned were (1) security and timing, and (2) alert management. We should expect pressure to extend SNMP. At the end of the meeting, Gross introduced a proposal for require- ments documents, to obtain the reaction of the meeting. The Router Requirements Working Group has suggested separating link layer and IP issues from the Router Requirements document. There was agreement on the link layer, but there was concern that a consolidated IP require- ments document might not adequately address the differences between hosts and gateways. This is a touchy architectural issue. Braden [Page 22] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX A -- MEETING AGENDA DRAFT AGENDA -- IAB MEETING JUNE 28-29, 1990 BBN, Cambridge, MA THURSDAY 6/28 9AM - Review Action Items 10:00 - BRIEF Meeting Reports: o CCIRN/IEPG - Bostwick, Gross, Leiner o ANSI Meeting - Cerf 10:30 - break 11:00 - Review the list of Critical Issues/research areas from July 1898 meeting 12:00 - [working lunch] International Connectivity and Collaboration o Endorse FEPG recommendation to the FNC, to decouple naming from routing. o [International] Connectivity Procedures o Role of EETF vs. IETF vs. FEPG ? 13:30 - Multi-protocol Internet 14:45 - The IP address-space problem [15:00-15:15 - break] 16:15 - External Relations o COS o General policy 16:45 - IAB Administration o Future Meetings o Scribe o Adopt minutes o Role of PWG: conference vs. executive committee? 17:15 - Adjourn FRIDAY 6/29 -- IESG Attending Braden [Page 23] Minutes of June 1990 IAB Meeting October, 1990 9:00 AM - BRIEF Status Reports o IETF/IESG - PG o IRTF/IRSG - DDC o NSFnet - HWB o Dartnet - Richer, Braden o Private Email - Kent 10:30 - break 10:45 - Routing [12:00 - lunch] 13:00 - Standards Procedures o Requirements Level for standards o Moving standards OFF the standards track 15:00 - break 15:30 - Standards Issues and Actions o PPP Options o CMOT o DRAFT-UCL-KILLE-NETWORKADDRESSES-00.PS.1 -> Proposed Standard o DRAFT-UCL-KILLE-PRESENTATIONADDRESS-00.PS.1 -> Proposed Standard o SUPDUP RFC-734 -> Draft Standard [Note 1] o Finger RFC-742 -> Draft Standard [Note 1] o Hostname RFC-953 -> Historical [Note 1] o RLP Resource Location Protocol RFC-887 -> Historical [Note 2] o SFTP Simple File Transfer Protocol RFC-913 -> Historical [Note 2] Note 1: It has been suggested this remain a Proposed Standard, pending further review by IESG. Note 2: It has been has suggested this become Experimental rather than Historical. 17:00 - Adjourn Braden [Page 24] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX B: ACTTION ITEM DISPOSITION IAB ACTION ITEMS The following list shows the status of action items after the June 1990 IAB meeting, with additional comments. Continuing Actions from prior to April 1990: OBE: Cerf/IAB: Send out NAS bias forms/Fill them out. It was determined that the National Academy of Sciences Bias Reporting Forms were inappropriate. The PWG has been tasked to create a new form. DONE: Clark: Coordinate with Dave Mills and convene a Working Party to consider network time as a basic Internet service. Braden reported that this has been done within the context of the End-to-End Research Group. DONE: Gross: Provide IAB with statistics on IETF WG membership. Gross presented statistics on IETF participation later in the meeting. ACTION: Gross: Forward minutes of IESG meetings to IAB. Continuing action. None have been forwarded so far, since the IESG had not met formally since its public meeting at the last IETF meeting. DONE: Gross: Re-charter IETF WG's as necessary, and publish all current charters in an RFC. The IETF rechartering effort is done. The revised charters for all working group are posted in the IETF directories. ACTION: Cerf: Write up concerns on Operational Infrastructure. Still pending. New Actions from April 1990 Meeting: Braden [Page 25] Minutes of June 1990 IAB Meeting October, 1990 DONE: Leiner: Place on the agenda of CCIRN meeting an indication of Internet interest in European collaboration on OSI experi- mentation. ACTION: Cerf: File claim for Internet name with trademark office. ACTION: Gross: Send message to IAB on how to use IETF WG data- base. The IETF database at CNRI is available in preliminary form. Instructions will be sent to the IAB when the user interface becomes stable. DONE: Leiner: Determine up to 10 names between RARE and CCIRN to receive the IETF Quarterly Proceedings. DONE: Cerf: Send out a procedure memo to IAB Policy Working Group. OBE: ExecD: Publish future IAB minutes as RFC's. DONE: Cerf: Pass journal-of-record issue to Policy Working Group. DONE: Postel: Split the Internet Monthly into two sections, Opera- tions and Research. Postel has begun the task of splitting the Internet monthly, and his intention is that the next issue will be split. ACTION: Postel: Produce a first draft of a "Principles of the Internet" document. DONE: Cerf: Recommend to the FNC that they tolerate widespread interconnectivity in the short-term, and develop policy-based routing in the long term. The Policy Working Group has recommended a connectivity policy to the IAB. Discussion is scheduled later in the agenda. DONE: Cerf: Ask PWG to draft recommendation on distributed IP address assignment. The PWG has recommended a distributed IP address assignment statement. Discussion is scheduled for later in the agenda. Braden [Page 26] Minutes of June 1990 IAB Meeting October, 1990 DONE: Gross: Ask Hinden to organize a review of inter-AS routing, prior to IAB meeting in June. The meeting was held at MIT. Clark and Hinden are scheduled to report on it later in the agenda. DONE: Chapin: Send a copy of the revised ANSI work statements to the IETF and the IAB. DONE: Cerf: Send a letter in behalf of the IAB to X3S3.3 chairman (Chapin) concerning handling of the core protocols. DONE: Postel: publish agreed-upon RFC procedure chart in the IAB Official Protocol Standards RFC. [See RFC-1140.] ACTION: Vint: Write a letter to OSF inviting them to IETF meet- ings. The letter to OSF answering their request to submit protocols to the IAB for standardization has been pending a policy by the IAB on vendor contributed protocols. ACTION: Cerf: Send letters to Sun and Microsoft explaining requirements for Internet standard status. The letters to Sun and Microsoft about NFS and Lan Manager are pending the IAB's policy on vendor contributed protocols. DONE: ExecD: Draft appropriate warning labels and other appli- cability statements, and poll the IAB. The following new actions were added: NEW ACTION: Gross: Send 5 copies of the IETF Proceedings to each of the Chairs of RARE and CCIRN. NEW ACTION: Phill Gross: Add a "How to Order IETF Proceedings" section to the IETF Proceedings. NEW ACTION: Gross: Publish international interconnection guide- lines as an RFC. NEW ACTION: Leiner: Publish the charter ("Terms of Reference") and ethics statements of the CCIRN as an RFC. Braden [Page 27] Minutes of June 1990 IAB Meeting October, 1990 NEW ACTION: Lauck: Report at next IAB meeting on status of OSI registration procedures and authorities. NEW ACTION: Lauck: Write down the actions that the IAB could take on testing. NEW ACTION: Braden: Summarize E2E RG work on architecture limits for IAB. NEW ACTION: Gross: Present to the Engineering and Operations Working Group (EOWG) of the FNC the IAB recommendations on changes to connected status and on distributed IP network number assignnements. NEW ACTION: Postel: Get statistics on the rate of IP network number consumption by class. NEW ACTION: ExecD: Put on next IAB meeting agenda a further dis- cussion of the IP address space problem. NEW ACTION: Lynch: Write to COS to encourage their participation in IETF and their suggestions for joint projects. NEW ACTION: Gross: Encourage Noel Chiappa to release the results of the Hale and Dorr liability studies. NEW ACTION: Kent: Provide a document specifying the configuration needed to run the PEM software. NEW ACTION: Kent: Get current RSD/DSI greement text for IAB review. NEW ACTION: Gross: Ask IESG for document describing subset of BGP that is currently being implemented. NEW ACTION: Cerf: Get a note from Microsoft that the Lan Manager MIB effort is accepted and supported. NEW ACTION: Gross (Hobby): Obtain better RFC on finger and have some working group reexamine SUPDUP. NEW ACTION: Kent: Resolve PPP Options problem. [DONE: RFC-1172]. Braden [Page 28] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX C: IEPG TERMS OF REFERENCE Intercontinental Engineering Planning Group (IEPG) PURPOSE The Intercontinental Engineering Planning Group (IEPG) is a technical engineering group working under the auspices of the Coordinating Com- mittee for Intercontinental Research Networking (CCIRN). Whereas the CCIRN is a policy-level coordinating body, the IEPG provides the technical and engineering planning to implement the CCIRN policy decisions. MEMBERSHIP Just as the CCIRN is composed of representative national and con- tinental member organizations (e.g., NACCIRN for North America, Euro-CCIRN for Europe), the IEPG is composed of representatives from national and continental technical planning bodies (e.g., EEPG for Europe, FEPG for the Engineering and Operations Working Group (EOWG) of the U.S. Federal Networking Council) Specific representatives will be selected by the appropriate national or continental CCIRN body. TASKS AND ACTIVITIES The IEPG will act to: o Coordinate the planning of new intercontinental connections among CCIRN members to maximize economy and networking capabili- ties. o Survey existing intercontinental connections to provide a basis for future planning. o Propose possible integration and harmonization of existing con- nections with the goal of developing a more technically coordi- nated networking infrastructure in keeping with the spirit of the CCIRN. Braden [Page 29] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX D: IAB GOALS STATMENT FROM JULY 1989 PRINCIPAL FOCI OF EMPHASIS FOR INTERNET EVOLUTION 1989-1990 July 1989 Research/Development? 1. OPERATIONAL STABILITY o Internet Instrumentation/SWAT D - Fault isolation - Data gathering tools (cf. NOC-tools) - Data analysis tools for users and net operators o OSPF: Implement + test D - use multi-vendor RIG Testbed o Repair flaws in DNS (bind) D o Inter-AR Routing R&D - Review/select: EPG3, MIRA, BSP, OR. IESG initial action -> IAB recommendation o Topology management R&D 2. USER SERVICES o White pages - DNANS+X.500; QUIPU; profile; D&R - IAB recommendation to be prepared within 30 days. RFC 1107 = WG majority report; IAB recommendation will refine + sharpen RFC-1107. - DNS option (TBD) o Private Email o Email connectivity to public, private, International D o Application Support tools R&D 3. TESTBED FACILITIES o DRI Resource within NNT - Terrestrial WB subsystem to support video/voice R&D conf'ing, shared workspace teleconferencing, some aspects of collaboration technology. Braden [Page 30] Minutes of June 1990 IAB Meeting October, 1990 - "RIG TB" (use RIGS and other Gateways) D . Multivendor gateway testing . OPSF testing . Net management interoperability . Multi-protocol routing/forward - Open Arch GW Testbed (eg E2E proposals) R + support of experimental applications. 4. GETTING *BIG* o Large scale Internet architectures R - AR requirement RFC (10**6) - 150 Million terminations o Naming, addressing, routing, navigation R 5. OSI COEXISTENCE o Multiprotocol Gateways D o X.400/RFC 822 gateways [public email, Europe...] D o X.500 Pilot Projects D o Registration facilities D [NIST cooperation] MIB, Email 6. GETTING *FAST* o Enough effort appears to be under way. R&D o Limits to Internet protocol architecture at high R speeds + varying latency. 7. LIAISON FRICC RARE (IXI) CCIRN RIPE NIST TELCOS (TBD) Military Commercial Vendors ANSI FARNET Braden [Page 31] Minutes of June 1990 IAB Meeting October, 1990 ANOTHER LIST OF ISSUES FROM JULY 1989 The following list was developed during the meeting, and summarized by Dave Clark. 1) Getting FAST o Transmission Technology -- SEP (Some Else's Problem) o Switching Technology -- SEP o Limits of "Internet architecture", i.e., -Stateless switches -Window flow control, cumulative ACK o New protocols: transport and (inter)network - Hide delay, achieve bandwidth o Increased host performance o Working over new transmission technology - Telco stuff - Wavelength division - Dynamic circuits 2) Getting BIG o Good management tools o Multiple administrations o Fault isolation and damage control o Directory Services and navigation tools o Planning for topology, growth, and overall architecture 3) Getting Better Service - Allocate resources o TOS/QOS support, policy-based allocation o Congestion control o Robustness/Authentication - New Transport & Network Services o Transactions o Realtime o Multicasting o Mobile Hosts - New Application Support o Authentication & access control to end user o Directory service o End-node charge recovery o Presentation standards - New Applications, e.g., Braden [Page 32] Minutes of June 1990 IAB Meeting October, 1990 o Document/paper management/retrieval o Teleconferencing Braden [Page 33] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX E: IETF OVERVIEW The Internet Engineering Task Force (IETF) has grown into a large open community of network designers, operators, vendors, and researchers concerned with evolution of the Internet protocol archi- tecture and the smooth operation of the Internet. The IETF began in January 1986 as a forum for technical coordination by contractors working on the ARPANET, DDN, and the Internet core gateway system. The IETF mission includes: o Specifying the short and mid-term Internet protocols and architecture for the Internet, o Making recommendations regarding Internet protocol standards for IAB approval, o Identifying and proposing solutions to pressing operational and technical problems in the Internet, o Facilitating technology transfer from the Internet Research Task Force, and o Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, and network managers. Technical activity on any specific topic in the IETF is addressed within working groups. All working groups are organized roughly by function into eight technical areas. Each is led by an area director who has primary responsibility for that one area of IETF activity. These eight technical directors with the chair of the IETF compose the Internet Engineering Steering Group (IESG). The current areas and directors, which compose the IESG, are: IETF and IESG Chair: Phill Gross/ NRI Applications: Russ Hobby/ UC-Davis Host and User Services: Craig Partridge/ BBN Internet Services: Noel Chiappa/ Consultant Routing: Robert Hinden/ BBN Network Management: Dave Crocker/ DEC OSI Integration: Rob Hagens/ U-Wisc and Ross Callon/ DEC Operations: Phill Gross/ NRI (interim) Security: Steve Crocker/ TIS Braden [Page 34] Minutes of June 1990 IAB Meeting October, 1990 IESG Secretary: Greg Vaudreuil/ NRI The working groups conduct business during plenary meetings of the IETF, during meetings outside of the IETF, and via electronic mail on mailing lists established for each group. The IETF holds quarterly plenary sessions composed of working group sessions, technical presentations and network status briefings. The meeting are currently three and one half days long and includes an open IESG meeting. Meeting reports, charters (which include the working group mailing lists), and general information on current IETF activities are avail- able on-line for anonymous FTP from several Internet hosts including nnsc.nsf.net. Information and logistics about upcoming meetings of the IETF are distributed on the IETF mailing list. To join the list or for gen- eral inquiries about the IETF, send a request to ietf- request@isi.edu. IETF WORKING GROUPS: Applications Domain Name System DNS Network Printing Protocol NPP TELNET TELNET Network FAX NETFAX Host and User Services Distributed File Systems DFS Dynamic Host Configuration DHC Internet User Population IUP TCP Large Windows TCPLW User Documents USERDOC User Services USWG Network Information Services Infrastructure NISI User Connectivity UCP Special Host Requirements SHR Internet Services Connection IP CIP IP MTU Discovery MTUDISC IP over FDDI FDDI IP over Switched Megabit Data Service SMDS Braden [Page 35] Minutes of June 1990 IAB Meeting October, 1990 Point-to-Point Protocol Extentions PPPEXT Router Discovery RDISC Router Requirements RREQ IP over Appletalk APPLEIP Network Management Alert Management ALERTMAN DECnet Phase IV MIB DECNETIV Management Services Interface MSI OSI Internet Management OIM Simple Network Management Protocol SNMP Transmission Mib TRANSMIB FDDI MIB FDDIMIB Internet Accounting ACCT OSI Integration Assignment of OSI NSAP Addresses OSINSAP OSI General OSIGEN OSI-X.400 OSIX400 OSI X.500 OSIX500 Operations Benchmarking Methodology BMWG Network Joint Management NJM Topology Engineering TEWG Installation Checklist CHECK Routing ISIS for IP Internets ISIS Interconnectivity IWG Multicast Extentions to OSPF MOSPF Open Systems Routing ORWG Private Data Network Routing PDNROUT Security IP Authentication IPAUTH Internet Security Policy SPWG SNMP Authentication SNMPAUTH Site Security Policy Handbook SSPHWG Braden [Page 36] Minutes of June 1990 IAB Meeting October, 1990 APPENDIX F: STATUS OF PROTOCOL STANDARDS The following summary of recent actions on the status and states of Internet protocols reflects the changes made by the June 28-29, 1990 meeting. PROTOCOL STANDARDS STATUS -- June 30, 1990 _______________________________________________________________ Document Protocol Name IESG recommendations IAB Action ------------------------------------------------ Grandfathered Protocols... RFC 407 RJE - Remote Job Entry Historical *** HISTORICAL RFC 569 NETED - Network Standard Text Editor Historical *** HISTORICAL RFC 734 SUPDUP Draft Standard *** PRPOSED STANDARD RFC 742 Finger Draft Standard *** PRPOSED STANDARD RFC 818 RTELNET - Remote Telnet Historical *** HISTORICAL RFC 887 RLP - Resource Location Protocol Historical *** EXPERIMENTAL RFC 913 SFTP - Simple File Transfer Protocol Historical *** EXPERIMENTAL RFC 937 POP2 - Post Office Protocol, V. 2 Historical *** HISTORICAL RFC 953 Hostname Historical *** HISTORICAL RFC 954 NICNAM - WhoIs Draft Stanard *** DRAFT STANDARD RFC-977 NNTP - Network News Transfer Protocol Proposed Standard *** PROPOSED STANDARD Braden [Page 37] Minutes of June 1990 IAB Meeting October, 1990 RFC 996 STATSRV - Statistics Server Historical *** HISTORICAL RFC 1037 NFILE (No IESG recommendation) *** (Awaiting recommendation) RFC 1045 VMTP Experimental *** EXPERIMENTAL RFC 1056 PCMAIL (No IESG recommendation) *** (Awaiting recommendation) RFC 1057 Sun Remote Procedure Call Proposed Standard *** Information Only RFC 1058 Routing Information Protocol Proposed Standard *** DRAFT STANDARD RFC1081, 1082 POP3 (No IESG recommendation) *** (No IAB action required) RFC 1090 SMTP over X.25 Experimental *** (No IAB action required) RFC 1094 Sun Network File System Proposed Standard *** Information Only - _________________________________________________________________________ Other Protocols: RFC 1006 ISO Transport on TCP Draft Standard *** DRAFT STANDARD RFC 1059 NTP (prior to IESG) *** STANDARD, Recommended RFC 1065 SMI - Structure for Managed Information Standard *** STANDARD RFC 1066 MIB 1 - Management Information Base Standard *** STANDARD RFC 1098 SNMP - Simple Network Management Protocol Standard *** STANDARD RFC 1131 OSPF Proposed Standard *** PROPOSED STANDARD RFC-1134 PPP - Point-to-Point Protocol Braden [Page 38] Minutes of June 1990 IAB Meeting October, 1990 Draft Standard *** DRAFT STANDARD, Note [1] RFC-1139 CLNS Echo Proposed Standard *** PROPOSED STANDARD RFC-1144 Header Compression *** PROPOSED STANDARD Internet Draft PPP Initial Configuration Options Proposed Standard *** Pending Internet Draft MIB 2 Proposed Standard *** PROPOSED STANDARD Internet Draft SNMP OSI MIB Experimental *** Published; No IAB action required. Internet Draft SNMP over OSI Experimental *** Published; No IAB action required Internet Draft An Interim Approach to Network Addresses [Kille] Proposed Standard *** Remanded to IESG Internet Draft A String Encoding of Presentation Address [Kille] Proposed Standard *** Remanded to IESG Internet Drafts BGP -- Border Gateway Protocol Proposed Standard *** PROPOSED STANDARD Internet Draft LAN Manager MIB Proposed Standard *** PROPOSED STANDARD, Note [2] ____________________________________________________________________________ Note 1: PPP approved with understandings: (1) References to link-level encryption to be deleted from PPP basic RFC. (2) IAB to formulate and publish a policy for assignment of PPP identifiers that will meet the needs of mixing non-IETF standard protocols and proprietary protocols over a PPP link. Note 2: Approval of LAN Manager MIB subject to requirements: (1) It will not enter Proposed Standard state UNTIL the IAB chair has received appropriate release letter(s) or equivalent assurances from the possible proprietary owner(s). Braden [Page 39] Minutes of June 1990 IAB Meeting October, 1990 (2) Anything that smacks of an advertisement for the LAN Manager will be purged from the text of the RFC. (3) The Status of Memo will include a sentence saying that standardizing the MIB does not constitute an endorsement of the proprietary product. "This specification extends the public portion of the Management Information Base and is used to manage a (set of) proprietary protocol(s). This MIB extension has been developed as a public effort, and is not itself proprietary. This MIB extension is not intended to constitute an endorsement of the managed proprietary protocol(s)." Braden [Page 40]