IAB MEETING JANUARY 3-4, 1990 USC/Information Sciences Institute SUMMARY A. The IAB reaffirmed its policy that an RFC published in Postscript must, if at all possible, be accompanied by a version in plain ASCII text. B. The IAB modified the Internet standards procedures and the nomenclature for the protocol specification documents. These changes were intended to: (1) clarify the meaning of the "requirement level" (Required, Recommended, Elective, etc) of a standard; (2) define more formal procedures for advancing standards through the "standards track"; (3) require IESG recommendation and IAB approval for each step in the standards track (Proposed Standard, Draft Standard, and Standard); and (4) institute minimum times at each step, to aid vendors in planning products. [However, the IESG subsequently raised further questions on this procedure, so the issue is probably not finally settled]. C. The IAB decided that IAB meeting minutes will be published to the Internet community. D. The IAB approved the following general policy on intra-AS routing protocols ("IGPs") for the Internet: there will be one primary standard protocol, which will be RECOMMENDED, but there may be other standard protocols which will be ELECTIVE. All general- purpose Internet gateways will be expected to support the primary standard; support of any of the other standard protocols will be optional. MINUTES 1. ATTENDEES IAB: Bob Braden, ISI Hans-Werner Braun, Merit Vint Cerf, NRI Lyman Chapin, DG David Clark, MIT Phill Gross, NRI Steve Kent, BBN Tony Lauck, DEC Barry Leiner, RIACS Dan Lynch, Interop, Inc. Jon Postel, ISI Visitors: Bill Bostwick, FRICC Paul Mockapetris, ISI Mark Pullen, DARPA Ira Richer, DARPA 2. REVIEW ACTION ITEMS: Cerf The Executive Director distributed hard copies of the agenda, the minutes of the last meeting, and a status summary of old action items. The group reviewed the old action items. The company Internet, Inc. of Reston, VA is trying to trademark the name "Internet". Cerf will discuss with them the sensitivity of this issue. The group discussed the issue raised by the FRICC of "exotic locations" for IAB and IETF meetings. Richer said that the concern is travel time and expense, not exoticness. Clark pointed out that Canada is not considered foreign travel. Gross observed that the recent decision to reduce IETF meetings to 3 per year should help. 3. ORGANIZATION REPORTS A. IESG/IETF: Gross Presented set of overheads outlining the 8 areas and 34 working groups (WGs) within the IESG/IETF. a)IESG Areas and Directors. 1) Applications: Russ Hobby/UC Davis (2 WGs) 2) Security: Steve Crocker/TIS (2 WGs) 3) Operations: Phill Gross/NRI (interim) (2 WGs) 4) Host and User Services: Craig Partridge/BBN (5 WGs) 5) Internet Services: Noel Chiappa/Consultant (9 WGs) 6) Routing: Bob Hinden/BBN (6 WGs) 7) Network Management: Dave Crocker/DEC (6 WGs) 8) OSI Integration: Rob Hagens/U Wisc and Ross Callon/DEC (2 WGs) b) IESG meetings and subgroups. c) IETF meetings, presentations and highlights. It was pointed out that an IETF area director must make a major time commitment, even though many IESG meetings do not require extra travel. d) Final agenda of the 15th IETF (Oct 31 - Nov 3, 1989). e) Number of WGs per area. A new WG to develop encapsulation of IP over SMDS will be chaired by George Clapp (Ameritech) and Mike Fidler (OSU). There is a new WG to update RFC-1009 (gateway requirements), chaired by Jim Forster (Cisco) with Phil Almquist (BARRNET) as editor. Noel Chiappa spawned six new WGs in the Internet Services area; a newly formed IS-IS group, as well as an Open Distance Vector group. Four groups are winding down, four others need help to wind down, while six others need to be formed, do not have a chairperson, or have not met yet. Concerning participation in IETF, meeting attendance at Hawaii was 180, down from 220 at Stanford. There are >500 entries on mailing list, and about 60 active WG participants. A concern was raised that we are stretching these 60 too thin, and Gross was asked to report on the extent of overlapping WG membership. f) IETF WG summary by area. g) Future IETF meeting sites. o Winter 1990: February 6-9, 1990, Florida State University, Host: Ken Hays. o Spring 1990: May 1-4, 1990, Pittsburgh Supercomputer Center, Host: Gene Hastings. o Summer 1990: July 31-August 3, 1990, University of British Columbia, Host: John Demco. Braden suggested more formality in the relationship between IESG and IAB: the IESG should specifically state the issues on which they want IAB response. Gross promised to provide list of IESG recommendations to IAB. It was suggested that IAB members could be on IESG and IRSG mailing lists, but it was decided that IESG should be allowed to keep their mail private. Gross, the IESG chair, and Cerf, an ex-officio member of the IESG, can forward IESG messages when they think appropriate and after asking the original sender. Gross distributed a report on the IESG and its activities. B. IRSG/IRTF: Clark The IRSG held a one day meeting in Austin, TX, and agreed on three activities: 1) Hold workshops. 2) Write an annual "State of Research" report. 3) Foster WG meetings. Craig Partridge is organizing a workshop on gigabit networks. While activity (2) is worthy in abstract, in reality it has proven difficult to orchestrate. Clark is accepting advice on how to achieve this. One of the WGs should own the "getting big" problem. We need to make sure that Deborah Estrin's ANRG and the proposed RG on Naming/Addressing don't overlap in this area. Discussion ensued about keeping the IRSG/IRTF healthy, when there is a shortage of funding for network research. Richer observed that the July IAB meeting created a list of important research areas, and that a one-level-deeper description would be helpful. C. OPEN GATEWAY TESTBED STATUS: Braden Braden presented a set of overheads on the planning of the proposed open gateway testbed. Two issues have been: finding a gateway platform with open software, and setting up a network operation center to keep track of versions and updates. We expect one platform to support all experiments, but will expect experimentors to take turns. Braden has organized teleconferences with vendors to determine which would be most appropriate; we are currently awaiting more vendor information. DARPA has asked ISI to run the NOC. Two levels of experiments are planned: IP-level and application level. The application experiments (e.g., multimedia teleconferencing) will be important to create real traffic for testing the IP level. The group discussed the problem of creating adequate test traffic. Lauck pointed out that artificial traffic, even if constructed with the same statistics as real traffic, will not behave the same under load as real traffic, because of feedback: the addition of new traffic changes previous traffic characteristics. Clark said that there is particular interest in looking for oscillations caused by this feedback. D. NSFNET: Braun Braun presented a set of graphs showing NSFNET statistics. a) T-1 data network #2 -- physical routing. b) Number of regional, state, and local networks linked -- 897 as of December 1989. c) Monthly traffic in packets. Gathered using the NNStat tool. Traffic definitely still increasing, and migration to T3 rates is already being considered. Kent suggested that Merit consult BBN network analysis folks for insight into how much traffic can increase before severe congestion begins. d) Monthly summaries of major NSFNET application distribution examples. o Interactive data (telnet, rlogin) - 25% o File transfers (FTP) - 21% o Name service - 15% o Electronic mail (SMTP) - 32% o Other services - 7% Although traffic grew enormously, the profile of the traffic distribution remained roughly the same. e) Three month comparison of traffic. f) 3-D graphs of traffic during days of the week. Only packets are counted, not bytes. Braden noted that byte counts have been added to NNStat/statspy. Mockapetris can now send bad hosts warnings. g) Where packets originate - collected by Internet network number and sorted by traffic - identified high traffic examples: Stanford and Berkeley. OSI CLNP was demonstrated at InterOp but is not yet deployed in the backbone. NSF wants T3 speeds, and Braun hopes to see them in 1990. NSF hopes to have a T1 line into CERN by March. Postel suggested that we raise the default maximum segment size from 576 to 1500 bytes. However, later discussion led to the conclusion that this must await MTU Discovery development. 4. RFC STATUS AND PROCEDURES A. STATUS REPORT ON RFC PUBLICATIONS: Postel As RFC Editor, Postel distributed hard copies of a draft message on policy for RFCs in Postscript, of a status report on RFC publication prepared by Joyce Reynolds, and a draft of the next version of the "IAB Official Protocol Standards" RFC. Six RFCs have been published in Postscript so far. Two have been converted to text; Mills' RFC will probably can't be; others are pending. B. POSTSCRIPT RFCs, DRAFT STATMENT: Postel The IAB discussed the draft statement on Postscript and agreed to it, with the addition that the source of every document is needed. It should also recommend using Postscript only for RFCs containing diagrams. C. STANDARDS PROCEDURES There was a lengthy and thorough discussion of Internet standard procedures. o It was proposed and rejected that the Proposed Standard stage was unnecessary and could be dropped. o It was reiterated that Internet drafts have a 6 month maximum lifetime. Gross noted that Internet drafts will have only a Summary section, but no Status of Memo; the RFC editor will add the latter when the draft becomes an RFC. o It was agreed that minimum times should be specified for each stage in the standards process. o It was agreed that IESG and IAB action will be required for a protocol specification to enter the Proposed Standard, Draft Standard, or Standard status. Chapin suggested publication of an RFC announcing scopes of IETF WG's. Gross took an action item to do this. Gross presented a proposal for modification to the classification of RFCs, which he felt would make the process clearer to the world. Under this proposal, the "Requirement Level" (RL) of an RFC would really only apply to a full standard. For proposed standards and draft standards, the RL would state the INTENDED requirement level when it becomes a standard. A. In the new scheme, each Internet protocol specification has two attributes: a state (or status) of Experimental, Historical, Proposed Standard, Draft Standard, or Standard, and a requirement level (RL) of Not Recommended, Elective, Recommended, or Required. The requirement level is to be assigned as follows: State Requirement Level (RL) _____ ___________________ Experimental Not Recommended Historical Not Recommended Proposed Standard Draft Standard Standard Elective, Recommended, or Required A specification in the Proposed Standard or Draft Standard state is said to be in the standards track. B. A new specification enters in either the Experimental or the Proposed Standard state. The possible state transitions are then as follows: o Experimental -> Proposed Standard o Proposed Standard -> Draft Standard o Draft Standard -> Standard o Any state -> Historical C. A protocol specification can enter Proposed Standard, Draft Standard, or Standard state only with the recommendation of the IESG and the approval of the IAB. D. An Internet protocol specification which the IESG and IAB enter into the standards track may have been originated by a Working Group of the IETF, by a Research Group of the IRTF, or by an outside source. E. A protocol specification that enters the Proposed Standard state must remain there at least 4 months, and in the Draft stage at least 6 months. F. Raising the requirement level on a Proposed, Draft, or full Standard will require an additional waiting period, to give vendors an opportunity to react and to adjust their planning. Specifically, raising the RL of a protocol spec in the Proposed/Draft stage will force the 4/6 months "clock" to be restarted. Raising the RL of a full Standard will cause the protocol specification to reenter the standards track at the Draft Standard stage, inserting a delay of at least 10 months before the new RL can take effect. G. Protocol specifications may be published in Experimental or Historical state at the discretion of the RFC Editor, and with appropriate review. The IAB tentatively agreed to this plan, subject to some further email discussions. During this discussion, Chapin supplied much useful and interesting information about the ANSI standard process. It became clear that the IAB's standards problem differs from ANSI's in important ways. Chapin also brought up an important concept, the "Journal of Record", and suggested that the IAB needs one; "it gets you off the hook for a lot". It was suggested that the IAB publish a newsletter, that would also serve as a Journal-of-Record, as an RFC at least once per quarter. It would include the IAB news currently included in the Internet Quarterly and a summary of RFCs published and protocol status changes. Chapin pointed out that publication of this RFC would synchronize the advance of the standards "clock". The Internet Monthly was discussed. It should be split into two newsletters, one operational in orientation and the other continuing to cover research, perhaps including future gigabit research activities. 5. COORDINATION WITH OTHER GROUPS A. OSF: Open Software Foundation. IAB is happy to accept ideas and input from OSF, but no official affiliation with OSF is appropriate at this time. Since OSF makes money selling particular software, there was concern that they are rather like a vendor, and are not a parallel standards organization. B. NMF: Network Managment Forum. No conclusions were reached. 6. IAB ORGANIZATION AND ISSUES: Cerf A. CONFLICT OF INTEREST The dilemma is how to make the IAB more open and yet preserve its efficacy. Comparisons were made with ANSI, IEEE, NAS, and government organizations. Since the IAB is concerned with broader issues than just standards and is informally constituted, no simple analogies could be drawn. It was decided that minutes of IAB meetings will be published, and the Executive Director was instructed to perform this task. IAB members delivered oral statements of potential conflict of interest; there were no surprises. Cerf will ask all IAB members to fill out an NAS (National Academy of Sciences) bias-report form, and the results will be circulated to all IAB members B. STANDARDS SUMMIT A meeting scheduled for February 20-22 will be held in Fredericksburg, Virginia to discuss management of standards-making procedures around the world, particularly in view of the explosion of groups with various special interests in the area. The former chief scientist of the ITU arranged an invitation for the IAB to participate. Expecting 100-150 people to attend. Cerf looking for another volunteer participant besides himself. C. FORMER SCIENTIFIC REQUIREMENTS TASK FORCE At Barry Leiner's recommendation, the IAB agreed that the former Scientific Requirements task force should be formally disbanded, but could continue as an informal group under Leiner's care. Members will be encouraged to join appropriate IETF WGs, e.g., in the User Services and Applications areas. D. DISCUSSION OF IRTF The IRTF was discussed, and it was agreed that it is functioning effectively. 7. INTERNATIONAL COOPERATION: Leiner A. CCIRN: Leiner Leiner, the official IAB representative to the ICB and to RARE, reported on activities of these groups. This led to a general discussion of the high level of IP-related activity in Europe, the roles of the CCIRN, RIPE, and RARE, and cooperation between these groups and the IAB and its task forces. Points which came up included: o The CCIRN endorsed Brim's recommendations on international connections: international links forming part of the general infrastructure should be connected into the national backbones. The IAB felt that the FRICC ought to announce this policy officially, and Gross took an action to cause the drafting of an RFC for this purpose. o The North American and European members of the CCIRN, to provide for more continental coordination prior to meetings of the CCIRN, respectively formed the NACCIRN and EuroCCIRN. Leiner agrred to provide documentation on the charters for each of these groups. o Gross announced out that the FEPG and RARE will hold US/European workshops on CONS/CLNS gateways. Prime movers include Rose, Hagens, and NIST. The first meeting will be in DC or at IETF Talahassee meeting. Cerf suggested these workshops should be used as springboards for future cooperation with RARE. B. Multiprotocol Internet Leiner raised the issue of the role of the IAB with respect to non-IP internets. Cerf answered that it is our intent to build an egalitarian multiprotocol Internet, parts of which will not be IP-based. Leiner and Braun then questioned whether the IAB is addressing the multi-protocol issues aggressively enough. Gross said that our intent here needs to be more widely broadcast, and that the statement again should come from the FRICC. Leiner suggested that if the Europeans felt we were seriously addressing parallel operation and interoperability of protocols, they would be more anxious to be involved in IETF WGs. Gross pointed out that IETF has an entire new area, OSI Integration, appropriate for them to join; this area already works with a RARE group on X.400 addressing issues. Clark and Cerf summarized the IAB's role as follows: (1) The IAB speaks for IP *protocols*. (2) The IAB fosters development of *infrastructure* in US. (3) The IAB is concerned with the *architecture* for the future multiprotocol Internet. Although it is not our responsibility to make the OSI protocols evolve, we care how the combination works together and interoperates. C. ICB Report: Leiner The next ICB meeting will be the end of February. Nothing has changed on the fat-pipe to Europe. The ICB targets addressing defense issues, while the CCIRN is concerned with academic research. The fat-pipe will be an ICB-driven pipe (i.e., used for military cooperation), although CCIRN may use it. D. CA*Net: Braun Canadian is building CA*Net as a sparse, 56Kbps backbone. Funding will come from the National Research Council and from regional (provincial) networks, with contributions from IBM Canada, which will supply routers using NSFnet technology, and Integrated Network Services (INSINC), which will supply the lines. CA*NET presents "interesting" routing issues at multiple access points to US backbones. There is a Canadian Council for Research Networking (CCCRN). 8. PRIVACY AND SECURITY ISSUES: Kent A. INTERNET USER CERTIFICATE REGISTRATION Kent distributed a draft of "Internet User Certificate Registration", describing the proposed rules for obtaining certificates from RSADSI Inc. for use of private email. Gross took an action item to find or create an IETF working group to address the problem of electronic signature registration. Kent led the meeting through the proposed agreement, pointing out all the problems and the issues still under negotiation. There was a discussion of the handling of expired certificates and revoked certificates ("bad boy lists", which need to be in located in a directory service). Another issues concerned the controversial restriction that only RSADSI can issue certificates. There was also some discussion of expanding the use of these certificates beyond private email; for example, Kent pointed out that they are exactly what is needed for gateway authentication. The question was asked: why do we fully trust RSADSI? Kent answered: (1) Since only RSADSI maintains keys, an obvious audit trail will be left if bogus certificates are found. (2) RSADSI has obvious economic incentive as well as the necessary expertise to protect information; "there are lots of built-in safeguards." The discussion led to several issues for Kent to take to an impending meeting with RSADSI, to refine the draft procedures. Kent asked Pullen about an Internet connection for RSADSI; Pullen will take action. It is taking longer than expected to get out the private email software. TIS had promised the software for November 30, 1989, but they didn't realize how long it would take for the software to mature. They now expect a prototype version in January 1990. This version uses public keys and X.509 but requires a highly centralized key managment facility (to be provided by NIST). Because there is no support for notaries, they do not want to propagate this initial version too widely. A more complete version is projected for initial testing in April 90, with general use hopefully in mid 1990. The RFC status is Draft Standard, Elective. Another issue was raised: what organization will act as the certificate-granting authority for the U.S. government? NIST and GSA were mentioned as possibilities. B. Security Bug Reports: Gross Gross introduced a proposed procedure for handling reports of security-related software bugs. It could be used by the current CERT and other similar groups that may be formed in the future (e.g., a CERT for MS/DOS). Gross' proposal resulted from the concern that vendors might not cooperate and that people might fail to report bugs due to potential liability. A Washington, D.C. law firm has critiqued the proposal. With small changes, the writeup satisfies all the criteria they set out to achieve. Lauck asked: What is the confidentiality of bug reports? Instead of broadcasting the bugs, we could encourage a vendor to fix it in the next system release, and in the meantime only give the bug report to certain companies and government agencies. Cerf replied that this is an instance of the standing debate: is it more harmful to broadcast security bug reports or to keep them secret? Also, how do we protect the reporter; if a bug report is not truthful, a vendor could have grounds for a law suit. The goal of the proposed procedure is to notify the community, without harming the vendors or risking defamation. The proposal contains a multi-step procedure, first reporting the bug only to the vendor, but in later steps broadcasting the report to a successively wider audience. The procedure would require positive acknowledgments at all the early steps, and would use RFC-1113 private email for these broadcast reports. One piece of legal advice was to put vendor on record as supporting the procedure or not. If a vendor refuses to be on the mailing list to receive and acknowledge security bug reports, then archive the vendor's refusal! 9. IGP: Gross Gross discussed the current serious candidates for a standard IGP: OSPF, IS-IS, and an Open Distance Vector (ODV) protocol to be developed. 1) OSPF is a Proposed Standard. A public domain version of it is now available for alpha testing from the University of Maryland, and it will be incorporated into GATED. Proteon has an independent implementation. OSPF resulted from an official IAB/IETF effort started 18 months ago, and it is derived from IS-IS with modifications appropriate for the Internet. However, there has been little operational experience with it so far, and questions have been raised about its documentation. 2) IS-IS was DEC-developed; there is lots of experience with a subset of it in the NSFNET backbone, and DEC has developed the full protocol for DECNET Phase V. Extensions would be necessary in order to handle the Internet (e.g., subnetting). 3) The ODV WG was announced in July and met for the first time in Hawaii. The WG expressed unwillingness to start from Cisco's IGRP, because Cisco has patented the algorithm. Gross recommended the following policy, which was adopted by the IAB: "The following is the general IAB policy on intra-AS routing protocols ("IGPs") for the Internet: there will be one primary standard protocol, which will be RECOMMENDED, but there may be other standard protocols which will be ELECTIVE. All general-purpose Internet gateways will be expected to support the primary standard; support of any of the other standard protocols will be optional." The IESG will be considering this issue at an open meeting in Tallahasee, and will later make a recommendation to the IAB. The IAB did not want to preempt the IESG recommendation, but it did discuss the issue at painful length, in the context of the meta-question: can we designate a time when the choice will be made? It was suggested that setting the date now would reduce the possibility of claims of unfairness. Unfortunately, the choice of time frame probably prejudices the result, since the different protocols are in different development stages. Therefore, the IAB took no further action on this issue pending an IESG recommendation, and wished the IESG lots of luck! The following points were made in the discussion: o We want to wait until operational experience has been gained with interoperation of multiple independent implementations. (CMOT was brought up as a painful example of adopting a standard before sufficient testing had occurred). o On the other hand, it is important to make the choice as soon as possible; an earlier decision will result in earlier vendor products. o Lauck spoke in favor of IS-IS. He said that there would be no problem with making the necessary IP-specific extensions to IS-IS, and that having a single underlying routing protocol for both OSI and IP would save significant vendor effort. o Pullen said that if it's a question of technical quality, then simply pick one. However, absent clear technical superiority, "it is imperative to maintain an open path to OSI". 10. WHITE PAGES: Pullen About a year ago, the FRICC decided to make White Pages a priority item, and in particular to support X.500. DARPA & NFS spearheaded this activity for the FRICC. Clark, Leiner, and IAB came up with a strawman list of potential activities to accomplish this, given the global resources available. In particular, the IAB plan urged multiple, interoperable pilot X.500 implementations. Pullen particularly acknowledged the work that Clark [RFC-1107] contributed to the planning effort. Pullen outlined his approach to bringing X.500 service to the Internet. The proposed applications are White Pages and privacy-enhanced mail; other applications are possible. 11. NREN MANAGEMENT: Pullen Pullen described plans being put together for management committees for the NREN. This is expected to include a broader and more formalized version of the FRICC, and a broad-based advisory committee. 12. INTER-AUTONOMOUS DOMAIN ROUTING: Gross, Braun The candidate inter-AD routing protocols are: o EGP2 o EGP3 o BGP o ORWG protocols It was stated that EGP3 appears to be essentially dead, although an RFC may be published some day. BGP is an interim effort, created by Cisco, IBM, and Merit, with considerable other support. The ORWG work continues to be the long-range hope, but it is not a short-term solution. BGP development is being overseen by the Interconnectivity Working Group (IWG). Gross discussed his plans to create a Topology Engineering Working Group (TEWG) to perform the more operational function that IWG was originally chartered to do. The need to ensure a link between FARNET and the TEWG was brought up. Braden expressed a concern that the BGP RFC describes a protocol but not an architecture; Braun replied that the architecture document is in the mail to Jon Postel, for publication as an RFC. He distributed copies of an early draft. Richer raised his concern about the continuing failure to produce a routing architecture document, promised by the IAB last July. He indicated that funding for routing research might await such a document. 13. OPERATIONAL INFRASTRUCTURE: Cerf Cerf pointed out that there are still many unsolved issues that attend the evolution of the Internet, such as accounting and access control. He agreed to write up his concerns for discussion at the next IAB meeting. 14. FUTURE MEETING SCHEDULE * April 24, 1990 Teleconference. * June 28-29, 1990, Boston, MA. * October 11, 1990, San Jose, CA, at InterOp '90. * January 8-9, 1991, ISI, Los Angeles, CA.