Internet Architecture Board

RFC2850

IAB Minutes 1990-06-28

Home»Documents»Minutes»Minutes 1990»IAB Minutes 1990-06-28

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:

    • 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.

    • 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.

    • 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 consideration. The Policy Working Group was convened for the first time on June 27th and produced its first recommendations for this meeting.

    • 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 (Coordinating 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.

        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 organization 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 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”.

    3.1 Operational Stability

      In the process of reviewing the list, the detailed bullets were somewhat modified and expanded to the following.

      • Internet Instrumentation

        Fault isolation, data gathering and analysis.

      • 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.

      • Domain Name Server/Resolver repair

      • Inter-Autonomous Region routing

      • Topology Management

      • 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 problems that will show up out in the leaves of the connectivity tree.

      • 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 architectural 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:

      • White Pages/Knowbot Information Services

      • Private Electronic Mail

      • Public, Private, International Email Links.

      • 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

    • Multi-Protocol Gateways

      There now exist some multi-protocol gateways, but the IAB should actively encourage development and deployment of more of them.

    • X.400/RFC 822 Relays

    • X.500 Pilot Projects

    • Registration Facilities

      Major issue: Privacy-Enhanced Mail needs good registration and directory services. Some progress has been made towards 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

      • Multi-vendor gateway testing: to test network management and multi-protocol routing and forwarding.

      • 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

      • Large Scale Internet Architectures

        Need a long-term architectural plan for Internet.

      • Naming, Addressing, Routing, Navigation

        Issues are: size of routing tables and updates, quality of routing metrics.

    3.6 Getting Fast

      • Limits to Internet architecture?

        Braden pointed out that his End-to-End Research Group has been thinking about the limits of the Internet architecture, and this has resulted in RFC-1072 [and RFC-1185: ExecD].

      • High speeds and latency

      • Internet use of gigabit technology

      • Improve TCP implementation and functionality

        NEW ACTION: Braden: Summarize E2E RG work on architecture lim its for IAB.

    3.7 Major New Initiatives

      • 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
      • 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 “Recommended Policy Change to Internet ‘Connected Status'” prepared by its 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.

      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.

      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.

    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 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 decision 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.

    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 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 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.

    • 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).

    • 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:
      1. Impose policy, or
      2. 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.

    • 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.

    • One suggested starting point: there is a basic requirement that routing always work; however, not everyone agrees on this.

    • Accepted principle: must be able to compose a route using par tial knowledge, obtaining a route that is correct but not neces sarily optimal.

    • 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.
    • 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.

    • The general conclusions of the meeting were:

        BGP is what we ought to do NOW; IDPR is research.

    • 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 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:

      • 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.

      • A standard needs to have a requirement, and this requirement needs to be published, if not with the specification, then often and accurately.

      • 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”.

      • 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.

      • Requirements documents do not change very fast. Could publish applicability document, just short lists, more often.

      There might be three kinds of documents defining applicability and requirements for protocols:

      • A terse list of protocols and recommendations — this is the existing IAB Official Protocols RFC. This RFC can refer to other elaboration documents.

      • Requirements documents, e.g., the Host Requirements and Router Requirements documents.

      • 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.

      • There must be a requirement or applicability statement for a protocol when it becomes a standard.

      • 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.

    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 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 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 requirements 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 requirements document might not adequately address the differences between hosts and gateways. This is a touchy architectural issue.


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:

    • CCIRN/IEPG – Bostwick, Gross, Leiner
    • 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

    • Endorse FEPG recommendation to the FNC, to decouple naming from routing.
    • [International] Connectivity Procedures
    • 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

    • COS
    • General policy

    16:45 – IAB Administration

    • Future Meetings
    • Scribe
    • Adopt minutes
    • Role of PWG: conference vs. executive committee?

    17:15 – Adjourn

    FRIDAY 6/29 — IESG Attending

    9:00 AM – BRIEF Status Reports

    • IETF/IESG – PG
    • IRTF/IRSG – DDC
    • NSFnet – HWB
    • Dartnet – Richer, Braden
    • Private Email – Kent

    10:30 – break

    10:45 – Routing

    [12:00 – lunch]

    13:00 – Standards Procedures

    • Requirements Level for standards
    • Moving standards OFF the standards track

    15:00 – break

    15:30 – Standards Issues and Actions

    • PPP Options CMOT Proposed Standard
    • DRAFT-UCL-KILLE-PRESENTATIONADDRESS-00.PS.1 -> Proposed Standard
    • SUPDUP RFC-734 -> Draft Standard [Note 1]
    • Finger RFC-742 -> Draft Standard [Note 1]
    • Hostname RFC-953 -> Historical [Note 1]
    • RLP Resource Location Protocol RFC-887 -> Historical [Note 2]
    • 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


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:

      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.

      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.

      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].


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:

      • Coordinate the planning of new intercontinental connections among CCIRN members to maximize economy and networking capabilities.

      • Survey existing intercontinental connections to provide a basis for future planning.

      • 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.

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.
    
    
    
                 - "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
    
    
    
    
    
    
    
    
    
         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.,
    
               o  Document/paper management/retrieval
    
               o  Teleconferencing
    
    

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 architecture 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:

    • Specifying the short and mid-term Internet protocols and architecture for the Internet,

    • Making recommendations regarding Internet protocol standards for IAB approval,

    • Identifying and proposing solutions to pressing operational and technical problems in the Internet,

    • Facilitating technology transfer from the Internet Research Task Force, and

    • 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
       

      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 available 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 general 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
          
           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

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
    IESG recommendations
    Protocol Name
    IAB Action

    Grandfathered Protocols…

    RFC 407
    Historical
    RJE – Remote Job Entry
    *** HISTORICAL

     

    RFC 569
    Historical
    NETED – Network Standard Text Editor
    *** HISTORICAL

     

    RFC 734
    Draft Standard
    SUPDUP
    *** PROPOSED STANDARD

     

    RFC 742
    Draft Standard
    Finger
    *** PROPOSED STANDARD
    RFC 818
    Historical
    RTELNET – Remote Telnet
    *** HISTORICAL

     

    RFC 887
    Historical
    RLP – Resource Location Protocol
    *** EXPERIMENTAL

     

    RFC 913
    Historical
    SFTP – Simple File Transfer Protocol
    *** EXPERIMENTAL

     

    RFC 937
    Historical
    POP2 – Post Office Protocol, V. 2
    *** HISTORICAL

     

    RFC 953
    Historical
    Hostname
    *** HISTORICAL

     

    RFC 954
    Draft Standard
    NICNAM – WhoIs
    *** DRAFT STANDARD

     

    RFC-977
    Proposed Standard
    NNTP – Network News Transfer Protocol
    *** PROPOSED STANDARD

     

    RFC 996
    Historical
    STATSRV – Statistics Server
    *** HISTORICAL

     

    RFC 1037
    (No IESG recommendation)
    NFILE
    *** (Awaiting recommendation)

     

    RFC 1045
    Experimental
    VMTP
    *** EXPERIMENTAL

     

    RFC 1056
    (No IESG recommendation)
    PCMAIL
    *** (Awaiting recommendation)

     

    RFC 1057
    Proposed Standard
    Sun Remote Procedure Call
    *** Information Only

     

    RFC 1058
    Proposed Standard
    Routing Information Protocol
    *** DRAFT STANDARD

     

    RFC1081, 1082
    (No IESG recommendation)
    POP3
    *** (No IAB action required)

     

    RFC 1090
    Experimental
    SMTP over X.25
    *** (No IAB action required)

     

    RFC 1094
    Proposed Standard
    Sun Network File System
    *** Information Only

     


    Other Protocols:

     

    RFC 1006
    Draft Standard
    ISO Transport on TCP
    *** DRAFT STANDARD

     

    RFC 1059
    (prior to IESG)
    NTP
    *** STANDARD, Recommended

     

    RFC 1065
    Standard
    SMI – Structure for Managed Information
    *** STANDARD

     

    RFC 1066
    Standard
    MIB 1 – Management Information Base
    *** STANDARD

     

    RFC 1098
    Standard
    SNMP – Simple Network Management Protocol
    *** STANDARD

     

    RFC 1131
    Proposed Standard
    OSPF
    *** PROPOSED STANDARD

     

    RFC-1134
    Draft Standard
    PPP – Point-to-Point Protocol
    *** DRAFT STANDARD, Note [1]

     

    RFC-1139
    Proposed Standard
    CLNS Echo
    *** PROPOSED STANDARD

     

    RFC-1144
    Proposed Standard
    Header Compression
    *** PROPOSED STANDARD

     

    Internet Draft
    Proposed Standard
    PPP Initial Configuration Options
    *** Pending

     

    Internet Draft
    Proposed Standard
    MIB 2
    *** PROPOSED STANDARD

     

    Internet Draft
    Experimental
    SNMP OSI MIB
    *** Published; No IAB action required.

     

    Internet Draft
    Experimental
    SNMP over OSI
    *** Published; No IAB action required

     

    Internet Draft
    Proposed Standard
    An Interim Approach to Network Addresses [Kille]
    *** Remanded to IESG

     

    Internet Draft
    Proposed Standard
    A String Encoding of Presentation Address [Kille]
    *** Remanded to IESG

     

    Internet Draft
    Proposed Standard
    BGP — Border Gateway Protocol

    *** PROPOSED STANDARD

     

    Internet Draft
    Proposed Standard
    LAN Manager MIB
    *** 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).
    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).”