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.

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.

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.

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.

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.

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?

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.

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:

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.

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.

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:

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.

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:

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.

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:

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.

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.

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.

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.

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.

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,

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.

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:

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