Minutes of IAB Meeting
Minutes of IAB Meeting
Teleconference April 26, 1990
The Internet Activities Board (see RFC-1160 for a general description) holds four meetings each year, including two one-day video teleconferences. This RFC contains minutes of the IAB teleconference held on April 26, 1990, among the four sites: BBN, DARPA, ISI, and SRI.
The agenda of the meeting will be found in Appendix A. The attendees were:
Bill Bostwick, DOE
John Cavallini, DOE
Steve Goldstein, NSF
Mark Pullen, DARPA
Ira Richer, DARPA
Tony Villasenor, NASA
Greg Vaudreuil, NRI
These minutes were prepared by Greg Vaudreuil of NRI, and by Bob Braden in his role is “Executive Director” (ExecD) of the IAB. We have endeavored to accurately reflect the content and thrust of the discussions. In many cases, we have included our paraphrases of remarks by individual IAB members; these are not quotes, and they represent only a summary or sampling of the key points in extended discussions. Although the IAB has reviewed the results, we must take responsibility for any unintentional misrepresentation.
1. REVIEW ACTION ITEMS
The meeting began with a review of action items from previous meetings.
NEW ACTION: Leiner: Place on the agenda of CCIRN meeting an indication of Internet interest in European collaboration on OSI experimentation.
Clark’s action to initiate a study of network time as a basic Inter- net service is incomplete, so it was continued.
Cerf has discharged his action to discuss with the chairman of Inter- net, Inc., their registered trademark on “Internet”; however, the resulting meeting made no progress towards resolution of the con- flict.
NEW ACTION: Cerf: File claim with trademark office for “Inter- net” name.
Gross had an action to provide the IAB with statistics on the degree of overlap among membership of different IETF working groups. As an overview, there are now over 200 people attending the IETF plenary, and over 40 working groups. There are approximately eight working groups meeting at a time, with a good bit of overlap between working groups. This action is continued.
Gross has not been able to discharge his action to send IESG minutes to the IAB, because there have been no IESG minutes to forward.
Postel had an action to change the title of the “Official Protocols” RFC so it won’t be confused with the IAB Official Protocol Standards” RFC. A new title will be selected before the next edition. It was suggested that “Official Protocols” be discontinued in light of the Host and Router requirements RFC’s, but it was noted that the docu- ment is still needed to document experimental RFC’s.
Gross had the following action:
ACTION: Gross: Re-charter IETF WG’s as necessary, and publish all current charters in an RFC. As new IETF WG’s are formed, publish their charters as RFC’s in a timely fashion.
Gross noted that assembling the WG charters has become a major effort. When it is complete, the charters may be published in con- densed form as an RFC, perhaps in July 1990. NRI is building a database that should be available for anonymous login in the near future. This is a continuing action.
NEW ACTION: Gross: Send message to IAB on how to use IETF WG database.
It was suggested that selected members of RARE and CCIRN could be added to the complimentary IETF Proceedings list.
NEW ACTION: Leiner: Identify up to 10 recipients, between RARE and CCIRN, who are not normally able to attend IETF meetings, to receive the IETF Quarterly Proceedings.
Gross had an action to cause publication of an RFC on international interconnection policy. An RFC was drafted by Scott Brim, but it has not yet been published. Bostwick pointed out the need to ensure that this RFC does not conflict with the CCIRN statement of interconnec- tion policy, and suggested two different RFC’s, one on US connec- tions, the other on policies; the latter should await the next CCIRN meeting.
Braun held an action to facilitate submission of the BGP architecture document and BGP protocol RFC to the RFC editor. The BGP protocol RFC has been edited to incorporate results of a thorough review by Bob Hinden and others, and is ready to go to the IESG. Braun pointed out the urgent need to move BGP forward, because the current inter- domain architecture based upon EGP is starting to seriously break in several places.
Appendix B contains a list of new and continued action items from this meeting.
2. IAB PROCEDURES AND ORGANIZATION
2.1 IAB Policy Working Group
Cerf described his plan to create an IAB subcommittee, the “Policy Working Group” (PWG) to draft specific policy statements for IAB consideration. It was agreed that FNC members could be observers to the FNC. Initial PWG members are: Cerf, Chapin, Braun, Lynch, and ExecD, with Goldstein and Bostwick as FNC observers.
NEW ACTION: Cerf: Send out organizational memo to IAB PWG.
2.2 International Members.
Vint Cerf proposed adding one or more international (i.e., non-US) members to the IAB. It was noted that the IETF is becoming increasingly international, and that international IAB members could add valuable perspectives to IAB considerations. Discussion focused on the pragmatic concerns of conducting business (e.g., video teleconferencing) with some members outside the US.
This matter was tabled for further consideration.
2.3 Internet Proceedings.
A proposal was made at the last meeting to expand the IETF Proceedings to include IAB and IRTF news, and to possibly make it an IAB “journal-of-record”. The current Internet Monthly is inap- propriate for this important function.
After some discussion, the proposal was tabled pending a complete review of IAB publications. Several different ways to package the publications were suggested, e.g., combine “IAB Official Protocol Standards” with J-of-R; or create a new sub-series of RFCs (analogous to FYIs) for IAB official statements.
The group decided that IAB minutes should be published as RFC’s in the future.
NEW ACTION: ExecD: Publish future IAB minutes as RFC’s.
NEW ACTION: Cerf: Pass journal-of-record issue to Policy Working Group.
NEW ACTION: Postel: Split the Internet Monthly into two sec- tions, Operations and Research.
2.4 Principles of the Internet.
Jon Postel proposed a document to lay down the “principles of the Internet”. For example, this will help to clarify what we mean when we talk about a “multi-protocol Internet”. [Is this an oxymoron?]
Cerf: do you mean the (Capital-)Internet or all the (lower-case)internets?
This led to a broad philosophic discussion.
Postel, Leiner: Focus should be on “i”nternets.
Clark: The IAB should focus on the protocols, regardless of where they are applied, and should not assume that the (Capital-)Internet dominates. Note that the two have dif- ferent preoccupations: the (Capital-)Internet is concerned about questions of scaling and management, while the (lower-case)internets are more concerned about developing new applications.
Chapin: As more and more nets use the same technology, the dis- tinction will get smaller, and the IAB needs to be concerned with both. The (Capital-)Internet is the focus of the tech- nology and the main driver for scaling issues; it feels prob- lems with the protocols first.
NEW ACTION: Postel: Produce a first draft of a “Principles of the Internet” document.
2.5 Federal Networking Council (FNC)
At this point, Bill Bostwick, who had to leave shortly, presented a brief overview of the new Federal Networking Council. He noted that FNC membership has expanded beyond the original FRICC members to include other agencies — e.g., NOAA, USGS — and also an OSTP observer and an OMB representative. A draft charter is expected in about a month.
After the presentation, questions were raised about the mechanisms for interaction between the FNC and the IAB/IETF. Bostwick responded: the FNC presently interacts with IETF via the FEPG. He further expressed a desire for close coordination with the IAB. Cerf cautioned that careful crafting of the relationship will be necessary to avoid unneeded legal restrictions on the IAB.
3. INTERNATIONAL INTERNET
The Federal national backbone networks are being asked to recognize increasing numbers of non-US networks. This has raised two important issues: (1) “connected status”, and (2) IP address assignment. In both cases, a more decentralized style of operation may be appropri- ate. The FNC is seeking advice on these issues.
3.1 Connected status for Non-US networks
Cerf: connection approval procedures need to be more distributed. Postel: Long-haul transmission service for the Internet is currently provided by the US government agencies. A “con- nected” network is one that is recognized as serving US interests and is allowed to pass traffic on the national backbones. Gross: as we incorporate more non-government and non-US facili- ties, the idea that the United States government must approve all connections in all countries ceases to be a workable pol- icy. Lynch: commercial carriers already pose a problem we cannot solve with the current protocols; we have to go on trust. Clark: we must have policy-based routing (PBR). Its urgency depends upon how anxious the US government agencies are, but in the long run, the situation will melt down without PBR. Leiner: When we began PBR work two years ago, our concern was interconnecting US government agencies to share resources. We have outgrown this simple set of concerns, and we now need to address the broader issues. Clark: X.25 solves these issues by CHARGING. Chapin: Charging may be necessary but it is not sufficient; also need enforcement of (policy) routing rules (gave analogy from telephone network). Clark: If we don’t have a coherent PBR architecture, things will be a mess. Pullen: The problem is authority vs. responsibility. The Euro- pean connections are taking the distribution of responsibil- ity a good deal farther than in the past! It was noted that some networks are being linked in without “con- nected status” (a term used by SRI NIC for permission for an IP network to be connected to the Internet).
Leiner pointed out that there are three issues in new connections: 1) Is the organization allowed to connect? 2) How to allocate resources — bandwidth, IP addresses, etc. 3) Topological effects of the proposed connections. General agreement was reached on a two-pronged approach: (1) For the short term, the FNC should be asked to tolerate widespread connectivity based on delegated responsibility and informal controls. (2) For the long term, a general PBR architecture must be developed and deployed. In particular, it was agreed that time should be allocated on the June meeting agenda to review policy ranges and technical solu- tions for PBR. Hinden, the IETF Area Director for routing, will be asked to set this up.
NEW ACTION: Cerf: Recommend to the FNC that they tolerate widespread interconnectivity in the short-term, and develop PBR in the long term.
NEW ACTION: Gross: Ask Hinden to organize a review of inter- AS routing, prior to IAB meeting in June.
The IAB and an FNC member also pointed out the continuing urgent need for the IESG to prepare an Internet routing architecture document.
3.2 IP address assignments
IP address assignments appear to be US-centric since they are made by the DDN NIC. This is a rapidly growing concern internation- ally. The IAB agreed that the IP address assignment procedures should be more distributed. Some progress has been made toward decentralized administration through block assignments to particu- lar countries.
There was concern that the allocation be independent of the current Internet sponsors. Lauck: We will eventually need an organization that is perceived to be international for distribut- ing numbers. It is not trivial to decentralize this; the IP number space is not large enough.
It was pointed out that currently there is less concern over who assigns the addresses than over the administrative complexity of the process. However, the group felt the issue was sufficiently troublesome to merit further consideration.
A proposal for an international NIC (InterNIC) was made. The IP address space is a scarce resource. Currently it is allocated by the DDN NIC, which is funded by DCA for the FNC. The InterNIC should be non-military, non-profit, and an internationally recog- nized authority. Pullen: This is a question that the FNC should and will take on.
NEW ACTION: Cerf: Ask Policy Working Group to draft recommen- dation on distributed IP address assignment.
4. ANSI-STANDARD INTERNET PROTOCOLS
The core Internet protocols — IP, ICMP, TCP, and UDP — have been proposed to ANSI for standardization. Other Internet protocols have also been submitted to ANSI: OSPF, Dual IS-IS, and BRP (BGP for OSI protocols). ANSI X3S3.3 will vote on these work items at the next meeting in Boston on June 27th.
The group discussed the likely results of ANSI standardization of the Internet protocols. There was some concern that ANSI might try to modify the core protocols, but Chapin assured the group that ANSI X3S3.3 was very unlikely to devote their resources to reworking the protocols.
The lack of a single document describing each protocol was seen as an obstacle. However, rewriting the current protocol documents would be a major job, and there is little financial support for it, so the submissions must be “stapled” groups of RFC’s. It was suggested that the Host Requirements and upcoming Router Requirements RFC’s be included; Chapin agreed.
It was agreed that the IAB chair should send a letter to the X3S3.3 chairman (Chapin), making two points:
- the ANSI document should be assembled from the existing RFC’s without rewriting them; and
- any technical problems or NO votes should be remanded to the IAB for correction.
NEW ACTION: Chapin: Send a copy of the revised work statements to the IETF and the IAB.
NEW ACTION: Cerf: Send a letter in behalf of the IAB to X3S3.3 chairman (Chapin) concerning handling of the core protocols. [DONE]
In the case of non-core Internet protocols, Chapin recommended that only stable, full standards be submitted to ANSI for standardization. We should not assume that all IETF output needs to get fed into ANSI.
Dual IS-IS was seen as a possible exception, because the Dual IS-IS protocol is an enhancement of a protocol currently under work in ANSI. Joint work should be encouraged where appropriate. BRP is based on BGP, but is intended for OSI inter-AD routing, an effort unrelated to the TCP/IP protocol standards process.
5. PROTOCOL STANDARDS PROCEDURES
5.1 RFC Procedures
Postel presented a proposed revision to his RFC publication pro- cedure chart. The processing depends on who submitted it, and the desired status.
One issue was raised. The procedure as proposed was asymmetric with respect to the IESG and the IRSG, but it was felt that notif- ication of experimental protocols should be the same for the IETF and the IRTF. The issue was resolved by giving the RFC editor discretion in notification to both the IESG and the IRSG.
NEW ACTION: Postel: publish agreed-upon RFC procedure chart in the IAB Official Protocol Standards RFC. [DONE: see RFC- 1140. ExecD]
5.2 Vendor Proprietary Protocols
Several times recently, the IAB has been asked to move a proprietary vendor protocol through the standards process. There is a policy question about whether it is appropriate to make a proprietary protocol an Internet standard.
A central question was: What does it mean for a protocol to be called an Internet Standard? The weak-standard view is that a standard merely defines a way to do a particular task, without any endorsement; “if you claim to do X, this is the way to do it in the Internet.” The strong-standard view is that an Internet stan- dard is implicitly or explicitly a recommendation by the IETF and IAB.
Lauck: The IAB has no business sanctifying someone else’s work. If we want to take over a vendor’s protocol, and if they are wil- ling to grant control over protocol changes to the IAB/IETF, OK; otherwise, don’t make it an Internet standard. Chapin: It would be an error to publish ANY proprietary protocol as a standard. Just because a protocol is in use does not mean the IAB has to endorse it. There is a legal liability assumed by endorsing a protocol, and this liability is significantly reduced if the pro- tocol is developed in an open forum. Postel: could publish as “information-only” or “vendor-contributed”.
Two criteria were agreed upon for protocols to become Internet standards:
- The IETF and IAB believe such a standard is needed for opera- tion and evolution of the Internet.
- The standard must be under IETF/IAB control. Otherwise, the proprietor might later change it for competitive or other reasons; we would be left supporting an unsupported protocol, which would be intolerable.
The group then discussed in particular the submission by the Open Software Foundation (OSF). Cerf noted that OSF intends to intro- duce these protocols into standards-making bodies, so submitting it to the IAB for Internet standardization is consistent. But if these are not developed in an open forum, the IAB should not introduce them into the Internet standards track. It was agreed that OSF representatives should be invited to IETF meetings to talk about their protocols.
NEW ACTION: Vint: Write a letter to OSF inviting them to IETF meetings.
5.3 Requiredness Levels.
The IAB has been struggling for the past six months with the attribute of a standard that indicates its applicability. This attribute, which has had one of the values: Required, Recommended, Elective, or Not Recommended, has been dubbed the “requiredness level” (aka “status”) of the document.
Postel pointed out that “Not Recommended” has in the past been used in two senses: to actively dissuade people from using the protocol, or simply an absence of a recommendation (e.g., on experimental protocols). To remove this ambiguity, he has added a new status value, “Limited Use”, so that in the future “Not Recom- mended” will be used only to dissuade.
This simple categorization has at times been simply inadequate and led to nonsensical results, such as have two Recommended network management standards. It has also led to a great deal of confu- sion, and vendors have asked for better guidance on what they should implement. The Host Requirements RFC went a great deal deeper into what is required.
At the last meeting, the IAB agreed to change the meaning of the requiredness level on Proposed Standard and Draft Standard docu- ments, from the current level to the anticipated level. This solved only a few of the problems.
Although the discussion at this teleconference was truncated by lack of time, the following is a summary of recent email discussion of this subject:
Some advocate removing ALL requiredness level or other applicability specification from the Internet standards documents themselves, and write separate profile documents on requirements, e.g., the Host Requirements RFC. The opposing viewpoint is that there are an awful lot of standards, and we will never write profile RFCs for all of them; thus, it is claimed that the current status values convey the “high-order bits” of the desired information.
[There is an implicit assumption by the advocates of the status quo that the Internet community is composed of highly-intelligent, energetic people who are quite capable of sorting out the obvious from the various sources of information. The advocates of a complete reformation feel that while this may once have been true, the great expansion of the vendor and user communities has meant that some now need very simple, explicit, unambiguous statements about what to implement and how. ExecD]
It was agreed that it will be necesssary to give the Internet community a lot of advance notice for any significant change in the treatment of requiredness levels. The matter was passed to the Policy Working Group for further discussion, and was tabled.
6. INTRA-AS ROUTING POLICY
Gross introduced the IESG recommendation on Intra-AS routing protocol standards (see Appendix C). The IAB accepted the recommendations and accordingly entered the OSPF protocol (RFC-1131) into the standards track as a Proposed Standard.
7. STANDARDS ACTIONS
A number of pending standards actions were taken up.
- SMI RFC-1065 -> Standard, Recommended [Reissued as RFC-1155]
- MIB I RFC-1066 -> Standard, Recommended [Reissued as RFC-1156]
- SNMP RFC-1098 -> Standard, Recommended Rreissued as RFC-1157]
- MIB II -> Proposed Standard [Reissued as RFC-1158]
- LANManager MIB -> Proposed Standard
- Sun RPC RFC-1057 -> Draft Standard
- Sun NFS RFC-1094 -> Draft Standard
- VMTP RFC-1045 -> Experimental status
- NICNAME RFC-954 -> Draft Standard
- RIP RFC-1058 -> Draft Standard
- RFC-1006 -> Draft Standard
NEW ACTION: ExecD: Draft appropriate warning labels and other applicability statements, and poll the IAB.
[The IAB generally tries to reach timely agreement on standards recommendations from the IESG via email. However, when a serious issue arises, the matter must be deferred to the next meeting].
In order to make progress on pending standards issues, the group agreed to leave the requiredness level unspecified at present. [How- ever, levels and appropriate applicability statements were adopted subsequent to the teleconference: ExecD].
The following were promoted to full Internet Standard state, with Requiredness Level of Recommended:
The following was entered into Proposed Standard state:
The following protocols raised a problem because they are proprietary. Following the earlier discussion, action on these was tabled, and Cerf agreed to contact the proprietors to explain the problem.
NEW ACTION: Cerf: Send letters to Sun and Microsoft explaining requirements for Internet standard status.
The IAB agreed to the following changes, after some discussion. It was agreed that a strong warning label should be attached to RIP.
There was concern that advancing RFC-1006, while unquestionably worthy, must not discourage others from developing full OSI stack implementations for operation across a future multi-protocol Inter- net. It was therefore agreed to advance RFC-1006 to Draft Standard, but attach a statement that there will be other ways to do OSI within the (multi-protocol) Internet in the future.
8. NEXT MEETING
The next meeting will be held on June 28-29, 1990 at BBN. It was noted that the ANSI meeting that will vote on the core protocol work items is to be on June 27, also in Boston, and IAB members were encouraged to attend.
APPENDIX A — MEETING AGENDA FOR TELECONFERENCE
April 26, 1990
9:00A|12:00N - Review Action Items  (:10) 9:10A|12:10N - IAB Procedures and Organization A. Subcommittee on Policy -- Introduction (:10) Purpose: Develop draft statements of IAB policy positions. B. International member(s) (:10) C. INTERNET PROCEEDINGS (:15) Proposal: rename the IETF Quarterly the INTERNET PROCEEDINGS, and include in it material from the IAB, IESG/IETF, and IRSG/IRTF. Presumably, this would be the IAB "journal-of-record". [It might even be possible to make this available under a subscription arrangement and to create an account from which funds could be allocated to support Internet activities.] D. "Principles of the Internet" -- JBP  (:10) 10:00A|1:00P - International Internet  (:30) o Connection Approval Vint: I would like to obtain a consensus opinion from the IAB to convey to the FNC and CCIRN the need for agreement at the CCIRN level on approval procedures for Internet connections. My present view is that a body in each country should have the responsibility for such approval and that the national organizations in each country should accept the decision of foreign authorities. o Distributed Administration of IP numbers; "Connected Status" 10:30A|1:30P - Break (:15) 10:45A|1:45P - ANSI Standard Internet Protocols (:30) 11:15A|2:15P - Standards Procedures o RFC Procedures -- JBP  (:10) o What should become Internet standard? (:15) [~12:00|3:00P - 10 min Break (:10) o Requiredness Level (:25) o Open Software Foundation (OSF) DCE Protocols  (:30) 12:45P|3:45P - Intra-AS Routing Protocol Policy and Action  (:15) 1:00P|4:00P - Standards Actions  o SMI -> Standard, Recommended o MIB I -> Standard, Recommended o SNMP -> Standard, Recommended o MIB II -> Proposed Standard, Recommended o LAN Man MIB ->Proposed Standard, Elective o Sun RPC -> Draft Standard o Sun NFS -> Draft Standard o VMTP -> Experimental status o NICNAME -> Draft Standard o RIP -> Draft Standard o RFC-1006 -> Draft Standard o DRAFT-UCL-KILLE-NETWORKADDRESSES-00.PS.1 -> Proposed Standard o DRAFT-UCL-KILLE-PRESENTATIONADDRESS-00.PS.1 -> Proposed Standard 3:00P|6:00P - Adjourn FUTURE MEETINGS: * June 28-29, 1990 at BBN. * October 11, 1990 in San Jose @InterOp '90. * January 8-9, 1991 at ISI.
APPENDIX B — ACTION ITEM SUMMARY
ACTION: Cerf/IAB: Send out NAS bias forms/Fill them out.
ACTION: Clark: Coordinate with Dave Mills and convene a Working Party to consider network time as a basic Internet service.
ACTION: Gross: Provide IAB with statistics on IETF WG member- ship.
ACTION: Gross: Forward minutes of IESG meetings to IAB.
ACTION: Gross: Re-charter IETF WG’s as necessary, and publish all current charters in an RFC. As new IETF WG’s are formed, publish their charters as RFC’s in a timely fashion.
ACTION: Cerf: Write up concerns on Operational Infrastructure for June meeting.
ACTION: Leiner: Place on the agenda of CCIRN meeting an indica- tion 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.
ACTION: Leiner: Determine up to 10 names between RARE and CCIRN to receive the IETF Quarterly Proceedings.
ACTION: Cerf: Send out organizational memo to IAB PWG.
ACTION: ExecD: Publish future IAB minutes as RFC’s.
ACTION: Cerf: Pass journal-of-record issue to Policy Working Group.
ACTION: Postel: Split the Internet Monthly into two sections, Operations and Research.
ACTION: Postel: Produce a first draft of a “Principles of the Internet” document.
ACTION: Cerf: Recommend to the FNC that they tolerate widespread interconnectivity in the short-term, and develop PBR in the long term.
ACTION: Gross: Ask Hinden to organize a review of inter-AS rout- ing, prior to IAB meeting in June.
ACTION: Cerf: Ask Policy Working Group to draft recommendation on distributed IP address assignment.
ACTION: Chapin: Send a copy of the revised work statements to the IETF and the IAB.
ACTION: Cerf: Send a letter in behalf of the IAB to X3S3.3 chairman (Chapin) concerning handling of the core protocols.
NEW ACTION: Postel: publish agreed-upon RFC procedure chart in the IAB Official Protocol Standards RFC. [DONE: see RFC-1140. ExecD]
ACTION: Vint: Write a letter to OSF inviting them to IETF meet- ings.
NEW ACTION: Cerf: Send letters to Sun and Microsoft explaining requirements for Internet standard status.
ACTION: ExecD: Draft appropriate warning labels and other appli- cability statements, and poll the IAB.
APPENDIX D — IESG RECOMMENDATION ON INTRA-AS ROUTING PROTOCOLS
To: the IAB
From: the IESG
Subject: Standardization of Intra-AS routing protocols
- General Recommendation on Standardizing Routing Protocols
There is a pressing need for a high functionality *open* Intra-AS Interior Gateway Protocol (IGP) for the TCP/IP protocol family. Users and network operators have also expressed a strong need for routers from different vendors to interoperate.
Based on these two requirements, the IESG hereby recommends that one high functionality routing protocol be designated as the “Recommended” Standard IGP for routers in the Internet. Other routing protocols may also be designated as “Elective” standards.
It is the intent that all developers of Internet routers make the “Recommended” standard IGP available in their products. However, it is not the intent to discourage the use of other routing protocols in situations where there may be sound technical reasons to do so. This recommendation is meant to *enable* multi-vendor router interoperation with a modern high functionality routing protocol. It is not otherwise meant to dictate what routing protocol can be used in a private environment.
Therefore, developers of Internet routers are free to implement, and network operators are free to use, other “Elective” Internet standard routing protocols, or proprietary non-Internet-standard routing protocols, as they wish.
Reference: see RFC 1140, “IAB Official Standards” (replaces RFC 1130) for a description of the Internet standards process esta- blished by the IAB.
- Recommendation on Specific Intra-AS Routing Protocols
During the February 6-9 IETF meeting at Florida University (specifically at the IESG meetings of February 8th and 9th), the IESG discussed the question of standardizing Intra-AS (ie, IGP) routing protocols for the TCP/IP protocol family. The two protocols under discussion were the Dual IS-IS and OSPF. Both protocols use the SPF routing algorithms.
OSPF was developed by the IETF OSPF Working Group. The OSPF specification was published as RFC 1131 in October 1989. There is a publicly available implementation for Berkeley Unix, and there is at least one vendor product which is now undergoing deployment in several regional networks.
IS-IS (ISO Draft Proposal 10589) is an OSI proposed protocol for Intra-As routing. IS-IS products are not widely available, but variations of DP 10589 are being used operationally by at least two vendors.
Dual IS-IS is an enhancement of DP 10589 to support IP in tandem with CLNP. Dual IS-IS is being developed by the IETF IS-IS Work- ing Group. The current specification of the Dual IS-IS is available in the Internet-Draft directories as file DRAFT-IETF-ISIS- SPEC-00.PS. There are plans in progress to develop a publicly available implementation for Berkeley Unix.
The IESG decided that both protocols need substantial operational experience before either could be made full Internet standards or recommended to the IAB as the “Recommended” IGP for the TCP/IP protocol family.
The practice within the IETF has been to allow a protocol to begin the standards process (i.e., be given the designation “Proposed Standard”) prior to gaining field experience, but extensive field experience *is* required prior to advancing to either “Draft Stan- dard” or full Internet Standard.
Therefore, the IESG is recommending that OSPF be designated a Proposed Standard at this time. Further review and advancement as an Internet standard will await the outcome of current ongoing field trials.
The IETF and IESG have expressed interest in the integrated rout- ing that is promised by the Dual IS-IS, but also expressed concern about potential complexity and side-effects. Such issues can only be resolved through extensive field experience. The IESG will re-examine the issue of standardizing Dual IS-IS when the Dual IS-IS specification matures to the point of being published as an RFC and has had some field experience.
Phill Gross IESG Chair