Internet Activities Board
Meeting Minutes — January 8-9, 1991
FOREWARD
This document contains minutes of the meeting of the Internet Activities Board (IAB) held on January 8-9, 1991 at the USC Information Sciences Institute in Marina del Rey, CA. The Internet Engineering Steering Group (IESG) participated in the entire meeting, which featured an extended discussion of architectural directions for the Internet.
The meeting agenda will be found in Appendix A. The attendees were:
IAB Members:
-
Bob Braden, ISI
Vint Cerf, CNRI
Lyman Chapin, BBN
David Clark, MIT LCS
Phill Gross, CNRI
Christian Huitema, INRIA
Steve Kent, BBN
Tony Lauck, DEC
Barry Leiner, ADS
Dan Lynch, Interop, Inc.
Jon Postel, ISI
IESG Members:
-
Ross Callon, DEC
J. Noel Chiappa, Consultant
David Crocker, DEC
Steve Crocker, TIS
Chuck Davin, MIT LCS
Phillip Gross, CNRI
Robert Hagens, U-WISC
Robert Hinden, BBN
Russell Hobby, UC-Davis
Joyce Reynolds, USC/ISI
Gregory Vaudreuil, CNRI
FNC Visitors:
Ira Richer, DARPA
Scribe:
Gregory Vaudreuil, CNRI
These minutes were prepared by Greg Vaudreuil of CNRI and edited by Vint Cerf, Chair of the IAB, and by Bob Braden, the IAB Executive Director (ExecD). We have endeavored to accurately reflect the content and thrust of the discussions. Although the IAB has reviewed the results, we must take responsibility for any unintentional misrepresentation.
-
Bob Braden
Vint Cerf
Greg Vaudreuil
1. AGENDA AND ACTION ITEMS
- Testability defined into protocol definitions.
- Tools and test suites.
- Testing procedures.
- Political aspects — who tests and approves.
The agenda is contained in Appendix A.
Vint Cerf welcomed Christian Huitema of INRIA, France as the newest IAB member.
Action Items from earlier meetings were reviewed; the disposition will be found in Appendix B. The discussion led to the following new actions:
NEW ACTION: Gross: Document Terms of Reference of IEPG.
NEW ACTION: Lauck: Publish ANSI’s registration procedures for OSI.
Lauck summarized the major issues in testability of protocols:
Lauck has an action item to elaborate on these points.
2. EXTERNAL RELATIONS
2.1 Internet Registry and Connected Status
The policies recommended by the IAB in RFC-1174 (“IAB Recommended Policy on Distributing Internet Identifier Assignment, and IAB Recommended Policy Change to Internet ‘Connected’ Status”, August 1990) were approved by the Federal Networking Council (FNC). See Reference [1] in Appendix C. However, the Defense Communications Agency (DCA), which funds the DDN NIC, was not willing to change the registration procedures while a procurement action was in progress to select a follow-on contractor.
Subsequently, NSF agreed to consider for sponsorship any networks that wish to be registered under the RFC-1174 rules. NSF cannot provide a “blanket” sponsorship, since each instance has to be validated against existing US government policies. Once the pro- curement action has been completed, the implementation of RFC-1174 will be somewhat easier, since the global Internet registry func- tions now performed by the DDN NIC will have been separated from the DDN registration functions to be performed under the new contract. The details of implementation are still being worked out, but the IAB is confident that the matter is well in hand.
The IAB reaffirmed that the RFC-1174 registration process is necessary for global registration, to support an increasingly international Internet.
2.2 OTA Conference on NREN
The OTA is conducting a computer moderated conference to gather information on NREN technology. Vint Cerf, who is a participant in the conference, reported that it totals some 60KB of messages per day! He has found that some of the information on the list is technically inaccurate, and he is not convinced that OTA is being well informed. It was the sense of the IAB that as recognized authorities on Internet technology, the IAB should contribute to the OTA effort. Several approaches were discussed, and the fol- lowing were agreed.
NEW ACTION: Cerf: (1) Send RFC-1167 to the OTA panel as a sub- mission on NREN. (2) Offer to comment on the final document when it is available.
3. Internationalization
- Make our international agenda clear both within and outside the IAB.
- Increase the non-US membership of the IAB, as previously announced.
- Solve the logistic problems of holding international meetings without too much expensive travel.
The IAB discussed ways to acquire a better international perspective. It was agreed that the ITU Standards Summit Meeting to be held 11-13 March in Nice, France, is a good opportunity to call attention to our intention of making the Internet support both OSI and TCP/IP. The the IAB will be represented there by Dan Lynch and Lyman Chapin.
It was agreed that the IAB needs to:
The group discussed (3) in particular. Video and telephone confer- ences can be used, perhaps with the aid of BBN’s mmconf software, in lieu of face-to-face meetings. The technical features of mmconf were discussed. Richer pointed out that Forsdick of BBN is working on ruggedizing mmconf and adding tablet support; he suggested waiting until July 1, 1991 to use it. There was some dismay that we have waited so long and tried so often to make progress in this area.
NEW ACTION: Kent: Discuss IAB needs with the mmconf group at BBN, and report on configuration requirements.
For the present, we will simply include Huitema in telephone confer- ence calls, setting the time to make it reasonable for him to parti- cipate.
NEW ACTION: Cerf & ExecD: Decide upon mode for April 3, 1991 meeting [DONE].
4. Privacy and Security
- On April 25, 1991, Trusted Information Systems (TIS) is scheduled to make an initial release of PEM, with support for the MH mail system and its close relatives.
- There are five implementations under development: MIT, TIS, DEC, ConTel, and Fisher International. MIT will integrate PEM with Gnu EMACS.
- The certificate “postage meter” development is making good progress; Kent handed around a prototype board.
4.1 IPSO Status
The DoD IP security option (IPSO) has a long and interesting his- tory; it was assigned an RFC number (RFC-1108) but never pub- lished. The need for that option is now great, and a group was convened to complete the RFC. Steve Kent rewrote the document to address many of the shortcomings of the original.
There is a more general problem with IPSO: for historical reasons, the IPSO is specific to the US DoD. A more general approach is required for commercial security and for international use. IPSO does include an extended security option, which in principle would allow arbitrary extensions, but DCA (as opposed to the IANA) currently assigns extended option numbers; this would be a problem for vendors using the protocol for their own purposes.
There is another security option in the works which promises to be more useful to commercial and international users; this is known as CIPSO (Commercial IP Security Option).
NEW ACTION: S. Crocker, Kent: Complete IPSO document and pub- lish is as an Internet Draft [DONE].
4.2 PEM Status
Kent distributed a PERT chart for the release of Privacy Enhanced Mail (PEM) software.
Steve Crocker pointed out that there will be a “start point”, after which keys will be parmanent. This will happen when RSA creates the root certificate, from which all others are derived.
4.3 Export Control Policy
The Federal Networking Council (FNC) is exploring possible changes to the export rules for cryptographic technology, specifically DES and RSADSI.
Huitema noted that there is a problem in France, where a World War I law prohibits encryption on any electromagnetic communication channel, except as allowed by the military. In practice, only banks and other financial institutions are allowed to perform encryption.
NEW ACTION: Kent: Revise his summary of the export control pol- icy, to include DEC comments.
4.4 Authentication
This agenda item was omitted for lack of time.
5. Architectural Issues
The meeting devoted the afternoon of the first day and the morning of the second day to an extended discussion of the future directions for Internet architecture. This discussion will be reported separately.
The meeting did an excellent job of laying out the architectural issues and alternatives, but made little progress towards deciding on future directions. The group therefore decided to schedule a future 3-day “architecture workshop” for the IESG and IAB. All participants should come prepared with papers, and be prepared to compromise; get- ting an agreement is most important. This workshop is scheduled for June 11-13, 1991.
6. OSI ISSUES
- NSAP structure (i.e., the format of the low-order part)
- NSAP administration
- The “care and feeding” of NSAPs: how do we map their hierarchy into the Internet, and what does an administrator do?
- How will we assign OR names? OR addressing is expected to disappear as soon as X.500 is deployed.
- Building an Infrastructure. There is a lack of deployed software and little incentive to use what exists. (No multi- media support, awkward addressing)
- Management issues; how do PRMD’s communicate? How do they coor- dinate routing? Technical agreements and routing coordination are needed.
6.1 NSAP Format
Callon briefed the meeting on NSAP issues. He distinguished three issues:
He presented the structure recommended by the IETF NSAP working group. The IETF group further proposed that regional networks be tasked to serve as addressing authorities for their client networks. NSAPS will be tagged to the regional to take advantage of hierarchy.
The issue was complex, and the IAB was unable to endorse the option chosen by the IETF working group without further consideration.
6.2 X.400 briefing
Hagens briefed the meeting on the current state of X.400 deployment in the Internet.
Major Issues:
6.3 X.500 Pilot Project
Rob Hagens briefed the IAB on the current status of the X.500 effort.
The X.500 pilot program currently lists 13 countries, 400 organiza- tions, and 350,000 entries. Most of the current usage is lookup of US names. The goals of the X.500 effort in the Internet is to provide White Pages service, OSI applications support, and storage of security certificates.
There continue to be significant problems in the deployment of X.500, including missing standards for schema, replication, and security, and resolution of incompatible lower layers (1006/CLNP/X.25). The IETF is working on interim solutions for the missing elements of X.500. The group plans to identify holes, document solutions, and deploy on a large scale starting this year.
Kent pointed out the need for a definition of distinguished names for use in PEM. He will ask Steve Kille to check the PEM draft.
NEW ACTION: Kent: Ask Kille to review distinguished names as defined in PEM.
7. Standards Formalization
- It has been a year since this debate began.
- The Router Requirements Working Group needs a recommendation to incorporate into their document.
- OSPF will shortly be raised to Draft Standard. There is pressure to address the “requiredness” of that protocol.
- The trade press is gearing up for the debate and decision, by pub- lishing profiles and deployment schedules.
- It may be more important for the health of the Internet as a whole to make a choice, even if it not demonstrably optimal.
- Are there real technical differences between the protocols?
Callon: yes; these differences stem from different basic assump- tions about the environment.
Huitema pointed out that IS-IS as applied in OSI handles a routing domain that is roughly equivalent to one subnetted class B IP net- work; as applied in TCP/IP, IS-IS is used for a much larger aggre- gation.
- Should the IAB pick the protocol based on information from the first deployed protocol or wait to gather information from both protocols?
- Can the IAB issue a mixed recommendation: e.g., OSPF for pure IP environments, and Dual IS-IS for mixed environments.
- Is it appropriate to make a Draft Standard a Recommended protocol?
- Should the IAB resolve the differences in architecture and environ- ments implied by the two protocols?
- Is an IAB decision important, considering that in reality every vendor will probably end up implementing both protocols?
Dave Crocker reported on a close interaction with the IAB’s Policy Work- ing Group to merge suggested standards practices and procedures. There are still details to be worked out.
7.1 Interior Gateway Protocols
The Phill Gross summarized the current state of the standards-track IGPs, OSPF and IS-IS. A year ago, the IAB decided that there should be one IGP recommended for universal implementation. The question to be resolved is: “how do we pick the recommended IGP?” The original IESG recommendation suggested that the IAB choose when one protocol has sig- nificant operational experience. The IESG has considered waiting for information on both protocols to do a complete technical evaluation; however, the community is expressing increasing urgency to make the decision soon.
Several issues were raised.
No conclusions were reached on these questions. However, the group agreed on the importance of setting an objective set of criteria for advancing a routing protocol towards a standard. Hinden agreed to draft such a list.
NEW ACTION: Hinden: Draft a set of criteria for advancing routing protocols to Draft Standard.
APPENDIX A — AGENDA
IAB MEETING — JANUARY 8-9, 1991
USC-ISI, Los Angeles, CA
AGENDA
9:00 Agenda and Action Items — Cerf
9:30 External Relations
o Internet Registry and Connected Status [1]
o OTA Workshop on NREN
10:00 Break
10:30 Internationalization
o Strategy
o Practical issues
12:00 Lunch
13:30 Privacy & Security
o IPSO
o PEM status
o Export Control policy
o Authentication framework
14:30 Break
15:00 Architecture I
o Dave Clark: Introduction (.5 hr)
o Detailed discussion of topics (2 hr)
17:30 Adjourn
WEDNESDAY, JANUARY 9, 1991
9:00 Architecture II
o Detailed discussion of topics, continued (1.5 hrs)
10:30 break
o Conclusions (2 hrs)
[12:00 lunch]
13:30 OSI Issues
o NSAP format (1 hr)
o X.400 & X.500 progress (.5 hr)
15:00 Break
15:30 Standards Issues
o Standards Procedures
o High-speed TCP
16:00 IGP Decision (OSPF vs. IS-IS)
16:50 Future Meetings
17:00 Adjourn
18:30 IAB & IESG Joint dinner —
China Palace Restaurant
3905 Sepulveda Boulevard
Culver City 391 8389
APPENDIX B — ACTION ITEM SUMMARY — JANUARY 10, 1991
Continued Actions from Previous Meetings:
OBE: Cerf: Write up concerns on Operational Infrastructure.
OBE: Gross: Report on distribution of IETF members among WG activi- ties.
DONE: Lynch: Write to COS to encourage their participation in IETF and their suggestions for joint projects.
DONE: Kent: Provide a document specifying the configuration needed to run the PEM software.
OBE: Lauck: Report on status of OSI registration procedures and authorities.
OBE: Cerf: Get a note from Microsoft that the Lan Manager MIB effort is accepted and supported.
OBE: ExecD: Send out list of IETF areas and gather signups from IAB members for standards interest.
DONE: Gross: Ask Steve Kille to take Braun’s draft of the X.500 RFC and add a rationale section to it.
DONE: Cerf: Draft an RFC containing general recommendations about acceptable use of services such as mailing lists.
DONE: Cerf: Discuss crypto export rules with FNC.
DONE: Cerf, Leiner: Chat offline about IAB role in global operational issues.
ACTION: Gross/Vaudreuil: Send message to IAB on how to use IETF WG database.
ACTION: Gross: Finish RFC on technical guidelines for international Internet connections.
ACTION: Postel: Draft “Principles of the Internet [Architecture?]” document.
ACTION: Cerf: Send letter to Sun and Microsoft explaining require- ments for Internet standards.
***My notes say: Need copies for IAB. I don’t recall if this means Vint already sent the letters, or not: ExecD ****
ACTION: Gross: Publish the charter (“Terms of Reference”) and ethics statements of the CCIRN and IEPG as RFCs.
ACTION: Lauck: Write down elaboration of his brief summary of proto- col testing issues.
ACTION: Gross: Obtain document describing subset of BGP that is currently being implemented.
ACTION: Cerf: Form a working party to construct straw-person bylaws for an “Internet society”.
ACTION: ExecD: Check whether any earlier action items for the PWG have fallen through the crack.
ACTION: Postel: Try to publish all acceptable-use policies.
ACTION: IAB: Review VCerf’s RFC-1167 on the NREN.
ACTION: Cerf: Write a more in-depth version of RFC-1167 on the NREN, for later OTA submission.
ACTION: VCerf, DClark, PGross, JPostel: Caucus on an Internet Visions document.
New actions from this meeting:
NEW ACTION: Gross: Document Terms of Reference of IEPG.
NEW ACTION: Lauck: Cause publication of ANSI registration procedures.
NEW ACTION: Cerf: (1) Send RFC-1167 to the OTA panel as a submission on NREN. (2) Offer to comment on the final document when it is available.
NEW ACTION: Kent: Discuss IAB needs with the mmconf group at BBN, and report on configuration requirements.
DONE: S. Crocker, Kent: Complete IPSO document and publish as an Internet Draft.
DONE: Cerf & ExecD: Decide upon mode for April 3, 1991 meeting.
NEW ACTION: Kent: Revise his summary of the export control policy, to include DEC comments.
NEW ACTION: Kent: Ask Kille to review distinguished names as defined in PEM.
NEW ACTION: Hinden: Draft a set of criteria for advancing routing protocols to Draft Standard.
APPENDIX C — REFERENCES
[1] INTERNET REGISTRY AND RFC-1174
DDN Information Bulletin #80 contains:
- Effective immediately, applicants wishing to obtain IP network numbers must use the application dated 7/90 (later applications will be returned to the applicants with a request for further information). This application is online on the NIC.DDN.MIL host as NETINFO:INTERNET-NUMBER-TEMPLATE.TXT. Applicants wishing connected status for their networks must identify a government sponsor authorizing their connection.
- Information regarding unconnected networks and Autonomous System Numbers (ASNs) will no longer be available through WHOIS.
- The NIC will contact people who registered networks or inverse addressing (IN-ADDR) information from the end of September to the present in order to ascertain their status according to the change in policy. If such networks are unconnected or do not have government sponsors, their data will no longer be available via WHOIS.
RFC 1174 recommended eliminating the distinction between “connected” and “unconnected” networks, i.e. between those networks connected to the DDN and Internet, and those that are not. Although the NIC had made some procedural changes in order to comply with the recommendations of RFC 1174, it is now necessary to reinstate the previous IP network number registration polices. This reinstatement of the former methods is taken to provide time for a more thorough investigation into the impact and cost of such changes. In order to accomplish this reinstatement, the distinction of “connected” and “unconnected” networks must be re-established. The following changes are being made to restablish this distinction: