Internet Activities Board
Meeting Minutes — October 10, 1991
This document contains minutes of the meeting of the Internet Activities Board (IAB) held on October 10, 1991 at the Fairmont Hotel (during the Interop ’91 conference) in San Jose, CA.
The meeting agenda will be found in Appendix A. The attendees were: IAB Members: Bob Braden, ISI Hans-Werner Braun, SDSC Vint Cerf, CNRI Lyman Chapin, BBN David Clark, MIT Phill Gross, ANS Steve Kent, BBN Tony Lauck, DEC Barry Leiner, ADS Dan Lynch, Interop Jon Postel, ISI IESG Members: Robert Hinden, BBN D. Crocker, DEC Russ Hobby, UC, Davis Phil Almquist, Barrnet Guests: Bob Aiken, NSF Paul Mockapetris, DARPA Steve Hardcastle-Kille, UCL Yakov Rekhter, IBM Scribe: Kim Claffy, SDSC/UCSD
1. STATUS REPORTS
1.1 Privacy Enhanced Mail (PEM)
Steven Kent discussed the status of PEM. The PEM demo booth at Interop has been very heavily visited. [Jon Postel came into the meeting late waving a PEM certificate -- the first piece of PEM mail at the conference that day.] The TIS reference implementation runs on BSD platforms and on SUN Sparcs; it also runs on PCs and MACs using POP3 to access the server. It interoperated with the Frontier Technologies PEM implementation at Interop. BBN software and hardware is acting as an Organizational Notary.
The PEM Working Group is still active, working out the implications of the new model of multiple certification authorities.
There is an issue about how to do the software distribution, without violating US export control laws. RSA doesn’t feel that even the MIT Kerberos release procedure gives sufficient assurance against export control violations. One possibility is to implement the RSA core modules separate from the cryptography procedures. This would make it possible to anonymously ftp all but the cryptography procedures. However, this may not satisfy the formal requirements for a signed piece of paper saying that the code will not be exported.
Vint Cerf had discussed a number of problems with Jeff Schiller and Jim Bidzos. MIT wants two Certification Authorities (CAs): a limited-assurance CA (e.g., for an academic environment), and a full-assurance CA using RSA. He wants the certificate generation box to be open. Other issues concern the Internet Society acting as the international CA; how many different policies will it need to support? How will CAs be vetted to make sure they are capable of following the rules?
There was some discussion on the royalty rights of, for example, RSA, since their patents are restricted to the U.S. It was clear that this is a critical issue right now, and that if we cannot solve the problems, multiple de facto standards will likely emerge.
It was noted that in certain cases, the transport of material (vs. materiel) across a border, even an encrypted certificate, may be a violation of export restrictions.
Leiner asked whether there were issues here to be raised with the CCIRN. None were forthcoming.
1.2 DARTnet Status Report
Constrained by time limitations, the group decided to defer this discussion. But when 15 minutes opened up around 16:45, Braden provided a brief slide presentation.
2. ARCHITECTURAL RETREAT — RESULTS AND PLANS
2.1 Routing and Addressing
Cerf: There is a critical need to put together a small task group to generate at least one feasible proposal for large-scale Routing and Addressing in the Internet. Its output will be a contribution to an anticipated IETF WG, which will review the issues and converge on a plan for updating Internet routing and addressing.
The group specified that minutes from this task group’s meetings must be freely available, and its work results would be available as an Internet Draft. The target of this group would be to define a feasible solution by March 1992, in time for the San Diego IETF.
After some discussion on the structure and makeup of the task group and the division of the leadership responsibilities, the consensus was that there should be three specific separate leadership roles: meeting chairperson, document editor, and “floor manager” to coordinate the activities.
NEW ACTION: Cerf: Talk to principals and convene first meeting of Routing & Addressing task group.
Cerf reported that SP3 has been renamed NLSP (Network Layer Security Protocol), and SP4 has been renamed TLSP (Transport Layer Security Protocol). It would be possible for these protocols to be independent of particular protocol suites, but this has not been the goal of the work. An earlier SP3 provision for suite- independence has been lost in subsequent compromises. Chapin suggested that it’s not too late to raise this issue.
Like SP4, TLSP has two modes: connectionless and connection- oriented. The connectionless version is independent of protocol suite, but the connection-oriented version is not.
Vint Cerf suggested an IETF working group to profile, implement, and test connectionless TLSP in the Internet.
NEW ACTION: Gross ask Security Area Director to pursue testing of connectionless TLSP in the Internet.
Cerf: is multiprotocol security architecture a research issue for Kent’s Privacy and Security Research Group (PSRG), or should it be pursued in the IETF? Kent: The PSRG should be involved in high- level design, but the details ought to be worked out in IETF WGs. There is a big matrix of implementation of security type X for service Y.
Hobby: the first order of business is to define data interchange formats; later we can design the applications.
Hot area is teleconferencing, since (1) end user hardware is now available, and (2) there is a real demand for teleconferencing service. A teleconferencing WG is starting.
Clark: Picking from among current image standards is a bad idea; we need a research effort here. There was agreement that we need both engineering (in IETF) and research (in IRTF), in parallel. Cerf: limiting this discussion of standards to the Internet as the bearer of videoconferencing capabilities will constrain its usefulness, since ISDN and other services exist.
2.4 Traffic Control and State
Consideration was deferred due to lack of time. At a future teleconference, Braden will summarize his meta-plan for introducing real-time service into the Internet.
3. INTERNATIONAL ISSUES
3.1 CCIRN Issues: (Barry Leiner)
The IAB/IETF is effective at engineering, but operational policy is sometimes a problem. There is no good forum for policy questions concerning Internet operations. Common question is: who in country X is responsible for Y? It is currently unclear whether the Internet Society will fill this gap.
There was a discussion of naming issues in the international Internet. Cerf proposed that when more than one organization comes to the Internet Assigned Number Authority (IANA) and asserts authority over the same part of the name space, then we should turn to the CCITT/ITU representative in the country for resolution. Postel: The IANA should give the parties 1 month to work it out themselves, first; the threat of an imposed decision will encourage them to solve the problem among themselves.
Another issue is that namespace administration should be non- discriminatory. We can state US policy but cannot dictate such to other nations; the ITU does that by treaty. Thus, the usage of words such as “advocate” or “guideline” seems preferable to “policy”. However, the IAB should at least declare that we advocate non-discriminatory assignment of the name space.
NEW ACTION: Postel [IANA]: Publicize policy on non- discriminatory naming and how naming disputes will be resolved.
Vint Cerf discussed the role of transport level routing in a (not-distant future) world where commercial investment in the Internet finally exceeds government investment.
3.2 Meeting Sites
There was a lengthy discussion of how to internationalize the work of the IAB and the IETF. Three alternatives were discussed, none of which met with much favor:
- Hold meetings all over the world, as CCITT does, for example. This is expensive and is likely to significantly reduce attendance.
- Make multiple regional IETFs, and somehow coordinate them.
- Use formal balloting procedures, so that everyone has a vote even if they cannot attend the meetings.
Braden suggested the experimental introduction of balloting into a single IETF WG, to see how it goes. Gross thought it would create lot of problems. This issue was tabled for lack of time.
4. STANDARDS PROCEDURES DOCUMENT
Cerf noted that Section 5 of the Standard Procedures document, on patents and copyrights, needs serious review. The group agreed to publish the Standards Procedures now, while noting that Section 5 is still to be reviewed.
NEW ACTION: Cerf: Ask an attorney to review patent and copyright section.
A series of issues were raised about the Standards Procedures docu- ment.
- Can an Applicability Statement (AS) get ahead of the Technical Specifications (TSs) it governs, in the standards track? For example, can the Router Requirements document become a Standard and define requirements on TSs that are not yet Standards?
After extensive discussion, it was agreed that the answer to these questions is “NO”.
- Does the document set up a structure that is too rigid, so that application of the rules might sometime force the adoption of a technically unsound specification?
Postel noted that the document nowhere says that a Standard is required to be *technically* sound. The only criteria stated are constituency and stability [ExecD: this has been mended]. Cerf: if a technically unsound spec should become a Standard, we can always use an AS to prevent its use.
- Should we follow ANSI policy that it is improper to use a spec in a marketing claim until that spec has become a standard?
This seemed like a good idea, but it was decided not to address this issue in the current Standards Procedure document.
- How much review should this document receive?
It was agreed that it is important to provide serious review, but it was also important to get it published soon.
- Are there procedural changes in the IESG/IAB review process that could help foster mutual respect and collaboration on resolving standards issues?
Gross urged that the IAB formulate their concerns about stan- dards as comments and questions.
- The discussion of “Other Standards Bodies” does not mention “consortia”.
Agreed that this should be fixed in a later version of the pro- cedures, so we can publish the current one.
There was a discussion of IAB email ballots on standards issues. Although the email balloting procedure was originally conceived to be a strictly private mechanism to expedite standards actions within the IAB, ballots have tended to “leak” out (generally for good/reasonable reasons). Viewed from outside the intended IAB context, these bal- lots have caused unfortunate misunderstanding and some hostility. As an example, there has been a “NO” box on the ballot. IAB members understand that “NO” didn’t mean “NO, NEVER”; it generally meant “WAIT, WE NEED TO DISCUSS A SERIOUS POLICY OR ARCHITECTURAL ISSUE”. But outside the IAB context, it has been misunderstood.
NEW ACTION: ExecD: Revise email ballot form.
Gross: The IESG-secretary will provide the email addresses of the relevant AD and WG chair in each recommendation to the IAB.
NEW ACTION: ExecD: install Standards Procedures document as Inter- net Draft for a 30-day period [DONE].
5. STANDARDS ISSUES
Steve Hardcastle-Kille joined the meeting to discuss some sticky standards issues arising from the OSI-DS working group that he chairs.
5.1 Interim IP Address coding in NSAPs
Agreed that this is an “essential nasty hack”, needed primarily for RFC-1006 (and X.25-80). Cerf suggested amending the Status of Memo to reflect this restricted applicability. There was a consensus to move ahead with this document as a Proposed Standard.
NEW ACTION: RFC Editor, Hardcastle-Kille: Retitle and revise Status of Memo to indicate restricted applicability of interim IP address encoding in NSAPs.
5.2 Presentation Address Encoding
The IAB was concerned that this appeared to be standardizing a user interface, and there were some strong feelings that as a general policy, standardizing user interfaces is a bad idea. Hardcastle-Kille agreed that this memo will have most of the desired effect as an Informational RFC, so it was agreed to publish it in this manner.
The IAB needs to clarify this issue of standardizing user interfaces. Gross noted that the IESG had written a statement on this issue; see Appendix C.
5.3 X.500 Interim Extensions for Replication, etc.
The IAB was concerned that these extensions are too Quipu-centric, and that X.500-92, due shortly, will obsolete them. Hardcastle- Kille presented the opinion of the OSI-DS Working Group, that we can’t wait for X.500-92 to move to widespread X.500 deployment in the Internet. He noted that there were several other X.500 vendors included in the working group.
After some discussion, it was agreed that this specification should enter the standards track, with the objective of introducing X.500 into the Internet as soon as possible, in order to gain useful operational experience. This interim approach will allow improvements and changes to occur.
5.4 X.500 User-Friendly Naming
Hardcastle-Kille noted that there are times when a standard string representation of names is useful. Again, the IAB was concerned about the chilling effect of standardizing a user interface. Huitema had also raised questions about the particular algorithm that was proposed.
Agreed to postpone action pending more careful investigation.
NEW ACTION: Kent, Huitema, Chapin: Work to articulate issues concerning user-friendly X.500.
Chuck Davin, Bob Hinden, Yakov Rekhter, and Phil Almquist joined the group for the following discussions.
5.5 Ethernet MIB
The IAB has agreed to publish the Ethernet MIB in the form originally presented by the Working Group (i.e., no variables deleted), presuming additional steps can be taken to coordinate with the IEEE. The IAB is very anxious to avoid “standards wars”. As Area Director for Network Management, Davin reported on the plans to form a new Working Group whose charter will explicitly meet the IAB concerns. As soon as the IETF members involved agree, the spec can be published.
5.6 Applicability Statement for OSPF as Common IGP
It was agreed that the Applicability Statement (AS) written by the ExecD should be balloted by the IAB, and that Gross’ statement should be published as an Informational RFC reflecting the IESG rationale. However, Leiner expressed concern that Gross’ document was subject to misinterpretation.
NEW ACTION: Leiner, Gross: Go over OSPF AS Background document and strengthen it.
NEW ACTION: ExecD: Reballot OSPF AS [DONE].
Rekhter and Braden reported that they had had a very productive discussion of the BGP documents the preceding day at Interop. Braden had suggested some changes to the documents to clarify some issues, and Rekhter was pleased to incorporate them.
Braden expressed concern about the coordination of policy configurations, since errors in configuring BGP policies can result in routing loops. Rekhter indicated that the place to solve this is in the BGP/IGP interface, and that the BGP/OSPF spec now in preparation will detect faulty routes resulting from faulty policies.
Clark reminded us that at the last IAB meeting, we had agreed that, since experience with BGP is entirely based upon using it as an EGP replacement without policy, we should advance BGP in a no- policy form. However, Rekhter pointed out that there has been some experience with policies, and that the documents specify a minimum set of policies that must be implemented. Braun said there were additional problems, but they relate to the architecture, not to the protocol.
The IAB agreed to advance the new BGP specs to Draft Standard.
5.8 Router Requirements
This topic had to be tabled due to lack of time. It will be discussed at a future teleconference.
6. FUTURE MEETINGS
- IETF in Santa Fe, Tuesday Nov. 19, 1991.
- BBN in Boston, Jan 7-8, 1992.
- IETF at SDSC, Monday March 16 PM & Tues March 17, 1992. (There was concern about not overlapping with Monday WG sessions, so it may run from Monday evening to all day Tuesday).
- RESERVED SLOT: May 5-6, 1992.
- TENTATIVE: IETF Meeting in Boston, July 27-31, 1992.
The IAB decided to schedule a biweekly teleconference slot, alternating with IESG conferences on Thursdays. The standard time will be 10:00 PT, 13:00 ET, and 18:00 FrT. The first conference will be October 24.
The proposed IAB meeting in Innsbruck in conjunction with the RARE meeting in March 1992 was dropped, due to the uncertainty of obtaining a quorum there.
Future face-to-face meetings are:
APPENDIX A — AGENDA
Board Room, Fairmont Hotel
San Jose, California
THURSDAY, October 10, 1991
10:30 Status Reports
o DARTnet – Braden
o PEM – Kent
10:45 Architecture Retreat — Results and Plans
11:30 International Issues
o CCIRN issues — Leiner
o Meeting sites
12:00 ISoc/IAB Relationship
13:00 IETF/IAB Relations
13:45 Standards Procedures
14:15 Standards Issues
o Interim IP address coding in NSAPs [H-K]
o Encoding Presentation Addresses: [H-K]
o X.500 Interim Extensions for Replication… [H-K]
o X.500 User-Friendly Naming [H-K]
15:15 Standards Issues II
o Ethernet MIB [Davin]
o Applicability Statement for OSPF [Hinden]
o BGP [Hinden, Rekhter]
o Router Requirements 
17:00 Future Meetings
APPENDIX B — ACTION ITEM SUMMARY — OCTOBER 9, 1991
Completed Actions [Note: "OBE" means "Overtaken by Events"]:
OBE: Clark, Chapin, Cerf, Braden, Hobby: One-slide summary of recommendations from their architecture working group.
DONE: ExecD: July 2 phone call agenda to include final summaries of architecture retreat.
DONE: ExecD: Include Hobby in July 2 phone call.
DONE: ExecD and Postel: Draft IAB statement of ISOC for Internet Monthly and ISoc announcement, for approval by IAB.
DONE: Chapin, Clark, Cerf, Davies: Work out scheduling of IAB Retreat report at IETF.
DONE: Cerf, Chapin, Clark, Braden, Hobby (IAB Retreat group chairs): prepare 1-2 page summary of their sessions.
DONE: Cerf, Chapin, Clark, Braden, Hobby (IAB Retreat group chairs): Prepare viewgraphs for IETF presentation and distribute to email@example.com list by July 12.
DONE: ExecD: Inform Russ Hobby of plans for IETF presentation.
DONE: Cerf, Clark, Braden, others: caucus at breakfast 7:30AM 7/16 at Gigabits Workshop in Washington.
DONE: ExecD: Draft announcement of IAB action of Ethernet MIB to IETF, and submit it to IAB for agreement.
DONE: ExecD: Draft AS statement on OSPF as common IGP.
DONE: ExecD: Produce new version of Standards Procedures and distribute it.
ACTION 4/90: Gross/Coya: Send message to IAB on how to use IETF WG database.
ACTION 4/90: Postel: Draft “Principles of the Internet [Architecture]” document.
ACTION 6/90: Lauck: Write down elaboration of his brief summary of protocol testing issues.
ACTION 10/90: Postel: Try to publish all acceptable-use policies.
ACTION 1/91: Gross: Document Terms of Reference of IEPG.
ACTION 1/91: Cerf: Revise summary of the export control policy to include DEC comments.
ACTION 1/29/91: Chapin, Huitema: Draft new IAB position paper on Whitepages service.
ACTION 4/29/91: Kent, Cerf, Braun, Lynch: Draft a document summarizing the IAB actions to promote Internet security.
ACTION 5/29/91: Gross: Put together a general statement of IAB policy on standardization of encapsulation in IP.
ACTION 5/29/91: Gross: Forward IEPG draft recommendation on number assignment as soon as available.
ACTION 6/91: Chapin: Cause publication of ANSI registration procedures.
ACTION 6/91: ExecD: Forward IAB recommendations on BGP to IESG.
ACTION 6/91: Gross: Redraft letter to IEEE on overlapping standards activities.
ACTION 6/91: Gross: Perform steps to publish policy on OSPF as common IGP.
ACTION 6/91: Cerf, ExecD, D. Crocker: Rework Standards Procedures document and publish as Internet Draft prior to July IETF meeting.
ACTION 6/91: Chapin, Lynch: Provide IAB with any material prepared for standards summit meeting.
ACTION 6/91: Cerf: Write summary of 3-day architecture retreat.
ACTION 6/91: Callon: Revise NSAP format draft to include clear warning on interim nature of document, and to fix ANSI facts.
ACTION 6/91: Kent: Send his draft on user authentication to WGC via Steve Wolff.
ACTION 6/91: Kent: Send edited Security Guidelines document to IAB and IESG.
ACTION 6/91: Kent, Cerf: Try one more time to get RFC-1108 approved by US government.
ACTION 6/91: Lauck: Draft DEC text on SPX release to IAB.
ACTION 6/91: ExecD: Supply Security Guidelines and Site Security Handbook to House Subcommittee on Technology and Competitiveness.
ACTION 7/2/91: IAB members: Read and comment on IESG 5-Year Plan.
ACTION 10/2/91: Gross: Re-edit Informational document on OSPF as common IGP.
ACTION 10/2/91: Chapin: Discuss ISO proposal for presentation address encoding with Steve Kille, and report.
ACTION 10/2/91: Cerf: Discuss email ballots #48 and #50 with Hardcastle-Kille.
ACTION 10/2/91: ExecD: Produce final version of Standards Procedures Document and distribute it.
New Actions from this Meeting:
NEW ACTION 10/91: Cerf: Talk to principals and convene first meeting of Routing & Addressing task group.
NEW ACTION 10/91: Gross ask Security Area Director to pursue testing of TLSP in the Internet.
NEW ACTION 10/91: Postel [IANA]: Publicize policy on non- discriminatory naming and how naming disputes will be resolved.
NEW ACTION 10/91: Cerf: Ask an attorney to review patent and copyright section.
NEW ACTION 10/91: ExecD: Revise email ballot form.
NEW ACTION 10/91: ExecD: install Standards Procedures document as Internet Draft for a 30-day period [DONE].
NEW ACTION 10/91: RFC Editor, Hardcastle-Kille: Retitle and revise Status of Memo to indicate restricted applicability of interim IP address encoding in NSAPs.
NEW ACTION 10/91: Kent, Huitema, Chapin: Work to articulate issues concerning user-friendly X.500.
NEW ACTION 10/91: Leiner, Gross: Go over OSPF AS Background document and strengthen it.
APPENDIX C — IESG STATEMENT ON STANDARDIZING USER INTERFACES
“The IESG has considered the question of whether the IETF should make Internet standards in the area of user presentation or formatting. In general, we feel that presentation and formatting issues are good subjects for product differentiation in the marketplace and therefore may not be appropriate subjects for standardization.
There are possible exceptions, however, in the case of proposals for a “commonly” used presentation format. This may be analogous to the case of proposing a “common” IGP in the routing area. In the routing case, we are not trying to mandate what [routing protocol] people must use, we are concerned that at least one high functionality routing protocol be commonly available to all users to promote interoperability.
In terms of the IAB/IETF standardization process, this is called an “Applicability Statement”. Statements of “applicability” are different from designation of standards status (ie, “Internet Proposed Standard”, “Internet Draft Standard” and “Internet Standard”). The intent is for Applicability Statements to designate whether the usage an Internet Standard (or the usage of any non- standard methodology in the Internet) is “Optional”, “Recommended”, or “Required” (see RFC 1250).
Similarly, in the case of a proposal for a commonly used presentation format, we may wish to issue an Applicability Statement designating its usage. Some possible examples of de facto “commonly” used presentation formats include the dotted 4 decimal digit notation for Internet network numbers and the DNS naming scheme.
We feel that issuing Applicability Statements in certain case may be entirely appropriate, and we will examine any such cases in the future on a case-by-case basis.”