Minutes of IAB Meeting — June 28-29, 1990
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
- 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.
A detailed list of old action items will be found in Appendix B. The following significant points emerged from the discussion:
2. BRIEF MEETING REPORTS
- 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.
- 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.
- 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.
- The CCIRN has agreed to the proposed international intercon nection guidelines developed by the IEPG. Gross will publish these guidelines as an RFC.
- 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].
- The CCIRN has responded positively to the IAB decision to extend the Internet to support multiple protocols.
- 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.
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.
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:
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
- 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
- White Pages/Knowbot Information Services
- Private Electronic Mail
- Public, Private, International Email Links.
- Application Support Tools/ Protocols
- Digital Library Services
- Distributed Processing
- Video Conferencing
- Collaboration Research
- Security Services
- 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.
- Multi-vendor gateway testing: to test network management and multi-protocol routing and forwarding.
- Open architecture gateway testbed: DARTNET.
- 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.
- 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
- 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”)
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.
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:
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:
3.3 OSI Integration
NEW ACTION: Lauck: Report at next IAB meeting on status of OSI registration procedures and authorities.
3.4 Testbed Activities
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
3.6 Getting Fast
NEW ACTION: Braden: Summarize E2E RG work on architecture lim its for IAB.
3.7 Major New Initiatives
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
- 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 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:
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
- How fast are we consuming numbers?
- How long will they last?
- Is this a real problem, or will we run out of router capacity first?
- Are the 16 bits for AS number enough, or much too little?
We could run out of IP addresses. There are approximately 18,000 IP numbers assigned currently.
Several questions were raised.
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
- 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.
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 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 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.
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:
10. ROUTING
- 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:
- Impose policy, or
- 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:
- Preserve existing functionality.
- Don’t modify the hosts.
- 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.
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.
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
- 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.
- 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 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.
- 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.
- A protocol specification documents will include a statement of motivation or intent of the protocol.
- There will be a new class of profile documents, terse statements of the protocols required to build an X.
- 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.
- 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.
- 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.
- 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.
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:
There might be three kinds of documents defining applicability and requirements for protocols:
There are timing issues involved in the update cycle of these documents.
The meeting agreed upon the following:
DECISIONS:
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:
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:
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 following grand-fathered protocols will remain as Proposed Standards for the present: SUPDUP (RFC-734) and Finger (RFC 742).
- 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).
- The Hostname protocol (RFC-953) will be moved to Historical.
- 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.
- 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.
The IAB decided upon the following standards actions.
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
- CCIRN/IEPG – Bostwick, Gross, Leiner
- ANSI Meeting – Cerf
- Endorse FEPG recommendation to the FNC, to decouple naming from routing.
- [International] Connectivity Procedures
- Role of EETF vs. IETF vs. FEPG ?
- COS
- General policy
- Future Meetings
- Scribe
- Adopt minutes
- Role of PWG: conference vs. executive committee?
- IETF/IESG – PG
- IRTF/IRSG – DDC
- NSFnet – HWB
- Dartnet – Richer, Braden
- Private Email – Kent
- Requirements Level for standards
- Moving standards OFF the standards track
- 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.
JUNE 28-29, 1990
BBN, Cambridge, MA
THURSDAY 6/28
9AM – Review Action Items
10:00 – BRIEF Meeting Reports:
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
13:30 – Multi-protocol Internet
14:45 – The IP address-space problem
[15:00-15:15 – break]
16:15 – External Relations
16:45 – IAB Administration
17:15 – Adjourn
FRIDAY 6/29 — IESG Attending
9:00 AM – BRIEF Status Reports
10:30 – break
10:45 – Routing
[12:00 – lunch]
13:00 – Standards Procedures
15:00 – break
15:30 – Standards Issues and Actions
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
- 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.
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:
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
- 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.
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:
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
- References to link-level encryption to be deleted from PPP basic RFC.
- 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.
- 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).
- Anything that smacks of an advertisement for the LAN Manager will be purged from the text of the RFC.
- 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).”
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.
| 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:
Note 2: Approval of LAN Manager MIB subject to requirements: