Internet Activities Board
Meeting Minutes — June 18-19, 1992
Kobe, Japan (INET ’92 Meeting)
CONTENTS/AGENDA
1. ACTION ITEM REVIEW
2. IAB AND ISOC
2.1. ISOC Board review of IAB charter
2.2. IAB Operating procedures3. IEPG PLAN OVERVIEW
4. ROUTING AND ADDRESSING (I)
4.1. IESG Recommendation
4.2. Discussion5. STANDARDS PROCEDURES
5.1. Postscript RFCs
5.2. Proposed changes in Standards Procedures document
5.3. Balloting procedures
5.4. Joint sponsorship of security activities with IEEE.6. PENDING STANDARDS ISSUES
7. ROUTING AND ADDRESSING (II)
8. INTERNATIONALIZATION
8.1. CCIRN Report — Leiner
8.2. IAB/IETF relationship to REC/RTC.
8.3. IETF internationalization
8.4. ITU9. FUTURE MEETINGS
10. ROUTING AND ADDRESSING (III)
APPENDIX A: ACTION ITEM STATUS SUMMARY
APPENDIX B: PROPOSED POLICY: POSTSCRIPT FOR STANDARDS DOCUMENTS
FOREWARD
This document contains minutes of the meeting of the Internet Architecture Board (IAB) held on June 18-19, 1992 at the International Conference Center in Kobe, Japan, in conjunction with the Internet Society conference INET ’92. In keeping with the new status of the IAB as a part of the Internet Society, this was an open meeting.
The meeting agenda will be found in Appendix A. The attendees were:
IAB Members:
Bob Braden, ISI
Vint Cerf, CNRI
Lyman Chapin, BBN
Phill Gross, ANS
Christian Huitema, INRIA
Steve Kent, BBN
Barry Leiner, ADS
Dan Lynch, Interop
Guest:
Geoff Huston, AARNet
Observers:
Bob Hinden, Sun Microsystems
Frode Greisen, SURFnet
Carl Malamud, Consultant
1. ACTION ITEM REVIEW
The IAB meeting was called to order at 14:00 on Thursday June 18, 1992. Action items were reviewed, with the results summarized in Appendix A. Some issues resulted in new action items, reported here.
In an earlier meeting, it was suggested that the standards process could be aided if working groups had a checklist or template of questions and issues to be addressed in connection with submitting a standards action request. Gross requested IAB input on this.
[ACTION 6/19/92]: IAB: Send suggestions to Gross for WG standards action request template items.
The IAB Executive Director (ExecD) reported that he had failed to get reports from the group chairs at the Architecture II retreat. He agreed to cause at least a short summary RFC to be published.
[ACTION 6/19/92]: ExecD: Try to get group reports from IAB Architecture II retreat, by July 6, and create summary RFC.
Cerf had an action from 1/7/92 to reconsider a draft letter to IEEE concerning overlapping standards activities. This is now a matter for the ISOC Board rather than the IAB. Cerf agreed to redraft the letter from the ISOC viewpoint and to give the IAB a chance to review it before it is sent.
[ACTION 6/19/92]: Cerf: (Re-)draft letter on overlapping standards activities for ISOC Board, and allow IAB to review.
Gross had a 1/7/92 action to publish an RFC defining the structure of the IETF. It was ageed that a broader task is required, to revise RFC-1160 to define the entire ISOC, IAB, and IETF structures. Cerf took this action item.
[ACTION 6/19/92]: Cerf: Revise RFC-1160 to define structure of ISOC, IAB, and IETF.
Huitema and Lauck had a 1/7/92 action item to draft a statement of technical concerns about RIP II. Huitema reported that they had produced one internal statement; he agreed to distribute this to the IAB.
[ACTION 6/19/92]: Huitema: Distribute draft statement of technical concerns about RIP II.
2. IAB AND ISOC
2.1. ISOC Board review of IAB charter
Cerf and Chapin reported that the Board of Trustees of the Internet Society (ISOC), meeting in Kobe, Japan, on June 15, 1992, had voted to accept a recommendation from the Internet Activities Board to bring the IAB and all of its activities into the Internet Society. The IAB will serve as a technical advisory group of the ISOC, with the new name “Internet Architecture Board”. The IETF will continue to pursue standards-setting and other engineering activities under this new umbrella, and the IRTF will continue to pursue research questions of importance to the Internet.
2.2 IAB Operating procedures
Chapin distributed hard copies of the final IAB charter. He noted that application of the charter had revealed some operational difficulties, which he and Cerf need to iron out. Further discussion of this agenda item was deferred.
[ACTION 6/19/92]: Chapin & Cerf: Debug IAB Charter.
[ACTION 6/19/92]: Chapin: Submit IAB Charter for RFC publication.
3. IEPG PLAN OVERVIEW
Geoff Huston of AARnet presented a plan being constructed by the Intercontinental Engineering and Planning Group (IEPG) for the management of Internet interconnection. He made the following points:
The IEPG used to manage physical links between Autonomous Domainss (ADs), but now must coordinate the logical links, as defined by the exchange of AD connectivity data. Furthermore, physical interconnect gets muddy with the advent of wide-area public data networks.
The number of ADs and networks is growing so large that manage- ment of the interconnections between ADs (i.e., allowed paths) is becoming infeasible. Operational coordination and organiza- tion are needed, but current technology for managing routing cannot support both scale and complexity at the same time.
Global connectivity suffers when unmanaged (non-coordinated) inter-AD paths cause routing gaps.
Even in the absence of Acceptable-Use Policies (AUPs), the existing net is so big that existing routers (using BGP) cannot exchange the full set of routing data. BGP constrains which nets are advertized between ADs, and the decisions on what to advertize are manually managed. The situation is worse because AUPs do exist, since some potential routes are disallowed for policy reasons.
Conclusion: simplify the problem to fit the tools, by imposing discipline on routing topology.
Technical objectives should be: (a) Maximum connectivity, (b) stability, (c) cost-effective transit service, (d) high-quality routine, (e) scalability, (f) manageability, and (g) accounta- bility.
Proposed solution is to bring ADs together at one or more hub interconnections called Global Internet Exchanges (GIXs), analo- gous to the FIXs, CIXs, etc. A GIX could include multiple interconnected LANs, used for address and (optinally) data exchanges.
To avoid n**2 routing exchanges, a GIX would need a route server. This would connect regional and transit ADs, i.e., re- introduce the “core” concept. Route server would assist in route dissemination, provides default routes, acts as authorita- tive source of all net/AD bindings.
To further reduce routing anarchy, need global route registry of authorized advertizements.
GIX would have no AUP, i.e., it would be policy-neutral. It would allow all subscribers (regional/transit) nets to establish whatever AD exchanges they want, so long as they were con- sistent. This will help avoid AUP-induced connectivity gaps.
The IEPG wants to quickly establish a U.S. East Coast GIX, using an FDDI LAN, to be expanded to multiple sites over next year.
Engineering efforts are needed: route servers, CIDR routing tools, and source/destination routing tools.
Leiner reported that this proposal was submitted to the CCIRN, which supports it, although some on the CCIRN believe we should start with multiple GIXs. The CCIRN will ask the IEPG to work with IETF to do the engineering and flesh out the plan. The CCIRN will then wrestle with the global management issues.
Cerf: the ISOC has been asked to act as a point of adjudication of topology issues. Leiner: it has been suggested that ISOC form an Internet operational coordination body.
Cerf made two comments: (1) commercial elements must be considered, and (2) it is unclear where the bottlenecks will be.
[ACTION 6/19/92]: Leiner: Ask CCIRN for technical paper on on IEPG “hub” topology proposal, when it becomes available.
4. ROUTING AND ADDRESSING (I)
4.1 IESG Recommendation
The IETF Chair, Phill Gross, presented a summary of the recommen- dation on routing and addressing being prepared by the IESG.
CIDR is recommended, to conserve class B addresses and to slow the growth of routing tables.
Cerf, Huitema, Kent, and Postel (via Chapin) expressed strong reservations about CIDR. Until the administrative aspects of address assignment are thoroughly articulated, we cannot be confident that CIDR really constitutes a solution to the address space exhaustion problem. Cerf also suggested that the GIXs may aid heirarchical assignments.
The IESG cannot recommend TUBA (TCP/UDP with Bigger Addresses, (formerly known as Simple CLNP) without more work. Ask supporters of TUBA for more information at November IETF meeting.
Develop selection criteria for the eventual decision.
Explore other alternatives.
The schedule suggested by the IESG would be:
June 92: Issue call for proposals and distribute selection criteria.
July 92: Convene working groups.
November 92: Present findings at IETF meeting.
December 92: IESG forward recommendation to IAB.
Subsequent discussion led to the identification of requirements in addition to those exhibited by Gross: (a) security (Kent), (b) incremental deployment (Cerf), (c) routing management as discussed earlier by Huston (Leiner), (d) avoiding renumbering of existing hosts (Huitema), and (e) development of administrative procedures for address assignment (Cerf).
4.2 Discussion
The group began to discuss these issues. The notes on this dis- cussion here and below attempt to record the discussion as it developed.
In discussing TUBA, which proposes using CLNP in place of IP, several important limitations of CLNP were brought up: the way it embeds routing hierarchy in the addresses (Huitema), and the even- tual need to support realtime service (Braden). Cerf proposed a principle: if CLNP were to be adopted for use in the Internet, the IAB/IETF must retain flexibility for its evolution in the Internet context. It was suggested that we call the new Internet layer “IP v7”, to make clear that the intent is to use only the CLNP format and that the IETF “owns” the spec. Kent suggested that change control be explicitly cited as one selection criterion.
This led to the question of whether changes made in CLNP as an IPv7 would be adopted back into OSI CLNP. Chapin: Only the Inter- net has an agenda for CLNP; there is no other context locking in its development. Cerf: Maybe calling it “CLNP” at all is a mis- take. Chapin: Avoiding the name “CLNP” would give up a potential advantage.
Braden: the IESG statement did not address the “long-term” or research dimension of the problem. Chapin: The premise was that sometime in the future there must be a great leap forward, which we cannot design yet.
Chapin emphasized the urgency of providing leadership to the com- munity. He was concerned about people who have not yet bought into the Internet who need reassurance about its future. He feels that leaving the planning to December is too late. He futhermore believes we are missing an opportunity by not taking a pro-CLNP position. Kent: Judging from the ROAD experience, we can’t do it any faster.
Lynch noted that the vendor community makes most of its money from selling hardware and software to the NON-CONNECTED Internet. Thus, they and their users have less of a concern about the abil- ity to scale or about many of the other critical problems that apply to the global Internet. It would be better for them if the Internet kludged along, until the great leap forward is ready. Leiner suggested that we provide feedback to the IESG: proceed with their process but also go ahead engineering a CLNP (TUBA) solution, without committing to it.
Huitema: It will be nice if CIDR works out; this depends upon address assignment discipline.
Cerf made two points. First, he observed that when Piscitello took IP to ISO and tried to convince them it represented a piece missing from their architecture, ISO felt comfortable with chang- ing IP to make CLNP. All we are asking for now is “reciprocity”! Secondly, in response to Lynch, it is true that vendors are sel- ling to isolated internets today, but when the telecomm vendors start selling TCP/IP services, it will all be connected, and the scaling problems will hit everybody; it is the IAB’s job to make sure it will work.
Kent noted that address filtering, one common security mechanism, fails on CLNP because of the lack of well-known ports.
The group agreed to recast the next day’s agenda to spend most of the time on the routing and addressing issue. The meeting then adjourned for the day at 18:00.
5. STANDARDS PROCEDURES
The meeting was called to order again at 09:15 on Friday, June 19.
5.1 Postscript RFCs
On May 28, 1992, the IAB sent to the IETF mailing list for comment a proposal to change the policy on the use of Postscript for specifications in the standards track. In essence, the proposed policy would continue to allow a standards document to exist in Postscript form, but would require that it also exist in ASCII form and the ASCII form would be primary.
Many comments were received, and although there were a few strenu- ous dissents, the great majority were highly favorable. The IAB therefore decided to adopt this new policy.
[ACTION 6/19/92]: ExecD: Announce IAB decision on Postscript for standards documents: primary must be ASCII.
5.2 Proposed changes in standards procedures document
The ExecD distributed a draft update to the Standards Procedures document, RFC-1310. Cerf provided a marked-up copy with suggested changes, reflecting chartering of IAB by ISOC and the IAB name change. Further consideration of this document was postponed to a future meeting.
[DONE 6/19/92]: ExecD: Update Standards Procedures document with Cerf changes.
5.3 IAB Balloting procedures
The IAB generally adopts IESG recommendations of standards actions by formal email ballot, administered by the ExecD and his staff support. In case of a problem, an IAB member can request a dis- cussion of the problem within the IAB or with the IESG and/or the working group. These discussions sometimes have taken a long time. The meeting talked about the process, and whether it could be improved.
Huitema: It’s very difficult to get consensus by email. Conflict resolution requires need person-person communication, not more procedures. Gross: The problem is that we often are unsure who has the “token”. Braden: it would help if the IAB dealt with the particular area director responsible, rather than with the IESG as a whole; then the token would rest with an individual.
To help track issues that have been delayed a long time, the ExecD agreed to include the initiation date on each open ballot issue listed in the weekely summary sent to the IAB.
Chapin noted that although individual IAB members cannot vote “NO”, the IAB may collectively reject a seriously flawed action.
[ACTION 6/19/92]: ExecD, Gross, Chapin: Develop written state- ment of IAB balloting proceures.
[ACTION 6/19/92]: ExecD: Provide statistics on DISCUSS votes.
5.4 Joint sponsorship of security activities with IEEE.
The ISOC Board will be the initiator of future liaison activities with other standards bodies (although it may be the task of the IAB to execute them). Therefore, this agenda item was deferred.
6. PENDING STANDARDS ISSUES
The IAB agreed to make the SNMP Security specification a Proposed Standard. This had been held up for several months to resolve secu- rity issues raised by Kent.
[DONE 6/19/92]: ExecD: Announce passage of SNMP Security ballot.
[ACTION 6/19/92]: Kent & Gross: Define “token” holder for PPP Authentication standards action.
7. ROUTING AND ADDRESSING (II)
The group then returned to the issue of routing and addressing.
Chapin provided input from Braun, who could not attend: we need a further strategic direction if we move ahead with CIDR, about which Braun has doubts.
Chapin stated his own position. First, it is vital to decide on a strategy now. Second, he believes the tasks can be structured into three categories:
- “Engineering” — use current IPv4
CIDR
- “Development” — bigger addresses but same architecture.
TUBA [simple CLNP]
ENCAPS [->IPAE]- “Research” — new architecture.
NIMROD
PIP
UNIFY
etc.Many of the more far-reaching proposals (listed under “Research”) cannot be deployed in time to avert disaster in class B assignment, although we should push strongly for R&D on them. Finally, Chapin takes it as given that no form of NAT (Network Address Translation) is acceptable, because of the need for globally-unique addresses.
An argument was advanced against TUBA: its development would not help advance the longer-term research.
Chapin’s 3-part framework was used as the basis for the subsequent discussion. The development phase came to be understood as “IPv7”.
Chapin suggested that selecting TUBA (CLNP) as IPv7 is an opportunity to do away with protocol wars, and to assert Internet hegemony over wide-scale internetworking.
Huitema: likes idea that selecting CLNP could shorten process by 6 months, but there are engineering questions to be answered for TUBA: (1) Can we “reuse” the IP address space? (2) What routing protocol should be used, IS-IS or existing IPv4 protocols?
Huitema: we must [ultimately] solve two problems in the addresses: (1) remove the tight coupling between address and the routing hierar- chy, and (2) include a punctuation mark in the new larger address to mark off the prefix.
Cerf: Thinks use of name “CLNP” would be serious mistake. He noted that we want to be able to run TCP and UDP over IPv7, with at most a thin convergence layer, preferably none.
Huitema: IPV7 should perform the same functions as IPv4, but carry larger addresses. Furthermore, the existing IPv4 address space should be a subset of the new IPv7 address space.
Kent: Adopting only CLNP from the OSI suite might be OK, but which NSAP address format should be used? We need all the choices defined before we make a decision. Chapin: we do not have to stick to the current NSAP address assignment schemes.
Leiner: This is not an evolutionary plan; we need the entire plan and the complete architecture. We should pursue some specific plan in detail, understanding that the plan may change as we learn more. Gross: there are lots of questions to be answered for both CIDR and TUBA. He does not agree with Chapin’s proposal for endorsement of TUBA at this stage.
Huitema summarized the situation in a pithy slide:
32 bits 1) CIDR: <-------------> + Mask "L" (Address) X bits 2) TUBA: <-------...--> + Mask "L" (Address)That is, CIDR adds masks to determine what to part of address is used for routing; TUBA moves to variable-length addresses. Within this framework, we can ask what packet format IPv7 should use (e.g., CLNP or a direct revision to IPv4). IETF working groups need to incorporate the mask into assignment and routing.
After further discussion of this picture, it was agreed that variable-length addresses are fundamental to any approach to IPv7, and there should be work to incorporate them into existing routing protocols — OSPF, BGP, … It was also agreed that the idea of decoupling addressing from hierarchical topology (also referred to as indirection) requires research, so it falls into the longer-range category.
Gross requests clarification: is it the case that the IETF would have full evolutionary control over an IPv7 based upon IP? Agreement that the answer is unqualified “yes”. Chapin: I hope that it will be pos- sible to use the CLNP format without change, but to interpret its semantics (e.g., TOS) differently than OSI has specified. Kent: this is a drawback; there would be a big gain if we could adopt CLNP exactly. Chapin: many vendors have told him that simply adopting the CLNP format would be a real relief. Huitema: it would be nice to have a single routing space for IPv7 and CLNP
<> Leiner: suppose a working group is formed to nail down the details of IPv7; it will not be identical to CLNP. Gross: We are trying to have it both ways. Kent suggests the words, “We are adopting CLNP version 1 as the starting point for an evolutionary process”. Braden: we need to revisit Host Requirements.
Chapin: we should not waste time changing the packet format. Braden: CLNP must include extensions for Deering multicast. Chapin: agreed.
Leiner suggests that we propose the use of CLNP (1) with IETF change control over its further evolution and (2) performing all functions currently in IPv4, and ask a working group to identify all the issues involved in doing this.
Huitema: QOS is a problem; must add IP QOS to CLNP. Should also incorporate current 4-byte addresses. Chapin: there will be lots of pressure discouraging gratuitous changes.
Gross asks about the potential political fallout of announcing an intention to “hijack” CLNP. Chapin: Dancing in the streets. Gross: What about the longer term? Chapin: It can be sold.
Kent: Calling the new protocol IPv7 would be transparently false. We should say, “We have decided to adopt CLNP, but we are not happy with the details of the protocol. We are currently planning to use the existing protocol, but in the future we expect to explore [at least?] different address formats”. Chapin: We can make clear that we intend to suggest that any changes we make to CLNP for IPv7 be incorporated into CLNP in OSI.
Huitema: Wants to allow all existing protocols at other layers, with the only change a larger address field. Chapin: we can tailor it sufficiently using options.
Cerf makes two comments:
We are proposing to adopt/use one piece of the OSI protocol suite.
It sounds as if we will not be adopting the exact semantics, only adopting the format of CLNP. What about other para- phenalia, e.g., ICMP? Will we need to redefine or add error messages?
There are lots of technical ramifications. We must assume that IPv7 and CLNP will be two parallel stacks, since IPv7 will differ from CLNP. This reduces the vendor gain a lot.
Leiner: If we incorporate CLNP into the IP architecture, do we change CLNP or the IP architecture?
Cerf: the time and expense is in the upper layers; have to modify all those programs to allow wider addresses.
Kent: those mods can be done on a different day than the kernel mods.
Huitema: Wider fixed-length addresses do not buy you so much; bottleneck is memory/cache, so want the IP header to be no longer than necessary. Should start up working groups soon to look at implications of variable-length addresses.
Leiner: Given that we need a larger address space, I don’t see arguments against using CLNP.
Cerf: but then we don’t get any new functionality.
Braden: I am concerned about impact of realtime changes; they may come sooner than we think.
Cerf: Maybe the larger header of CLNP will help?
Braden: As this goes forward, we need a person or oversight group to maintain architectural coherence.
Cerf: the IAB has to take respon- sibility for the architecture. We will need to redo ALL of the docu- ments.
Lynch: Christian and I believe in driving to wider addresses, changing whatever is necessary.
Leiner: Some will ask: what does CLNP buy above merely expanding IP addresses? Cerf: CLNP allows more room for options. Others: it shortcuts the time to develop a new header.
[DONE 6/19/92]: IAB Members: Contribute written material on pro- posed R&Addr position paper.
[DONE 6/19/92]: Braden: With input from other IAB members, create draft of R&Addr position paper.
Discussion was suspended at this point to deal with other issues, and returned later to this topic.
8. INTERNATIONALIZATION
8.1. CCIRN Report
Leiner noted that he had distributed to the IAB a report of the last CCIRN meeting. The CCIRN has made two requests of the IAB:
Document the procedures for top-level domain registration.
Document fairness policies for assignment of top-level domains.
These are both action items for Postel as IANA.
8.2. IAB/IESG Relationship to REC/RTC
Chapin noted that we need to establish a procedure allow cross- chartering of working groups between the RARE Technical Committee (RTC) and the IETF.
Leiner will discuss with the CCIRN how communication can be improved.
[ACTION 6/19/92]: Gross: Discuss joint working group sponsor- ship with Tomaz Kalin, Secretary General of RARE.
[ACTION 6/19/92]: Leiner: Discuss enriched IAB/CCIRN communica- tion with CCIRN.
8.3. IETF Internationalization
Cerf said that there have been proposals for local chapters of ISOC; however, the necessary organization is too much for ISOC to take on during 1992.
Huitema, who is a member of RTC, noted that:
RARE plans to budget travel expenses for some Europeans attending IETF meetings.
RARE does not believe it should be in the standards game.
However, some RARE working groups are well equipped to resolve IETF-related issues. Examples are X.400 issues and national character sets. These should set these to be joint with the IETF and therefore open to US membership.
The group agreed that the issues of how to scale up and to inter- nationalize IETF are extremely important and should be surfaced in the next IETF meeting. It was agreed to hold a BOF on the sub- ject, and afterwards to talk about it at an open IAB meeting.
[ACTION 6/19/92]:Huitema: Provide minutes of 30 June RTC meeting.
[ACTION 6/19/92]: Gross: Set up BOF at Boston IETF, on subject of internationalization and growth.
[ACTION 6/19/92]: ExecD: Set up IAB meeting on Friday July 17, 1992 at Boston IETF.
8.4. ITU
[my notes don’t contain anything for this topic – ExecD]
9. FUTURE MEETINGS
The following future meetings were agreed to:
Monday July 6, 1992: teleconference.
Friday July 17, 1992 at Boston IETF meeting
Thursday October 29, 1992 at Interop in San Francisco.
The following slots were reserved for meetings:
November 20, 1992 at Washington D.C. IETF.
February 17-18, 1993 at Brussels, overlapping CCIRN.
May 10-13, 1993 in Trondheim, at JENC meeting.
10. ROUTING AND ADDRESSING (III)
The meeting now returned to routing and addressing. An IAB statement on this issue would need three parts:
A statement of strategic direction
The background rationale
Based upon ROAD work, IESG/IETF work, and discussing alterna- tives
A program of work
The group then developed an outline of the elements of the proposed IPv7 architecture. [Subsequent email discussion expanded this list].
Wider addresses [and nothing but]
Aggregation [Huitema’s masks]
Extensibility – basis for extension [future enhancements]
Distributed management of address assignment
Accept requirement for topology discipline (management) and corresponding address assignment discipline.
Retain multicasting
Tools: work/principle.
Cerf: “All routing protocols are on the table”, modulo variable- length address and mask. He is assuming that we will retain current AD-oriented routing architecture.
The following issues must be left for research or are othogonal: (1) Decoupling address assignment from topology; (2) policy routing; and (3) QOS control and selection (e.g., resource reservation).
Huitema: today we have 2000-3000 ADs; what is the design target for IPv7? Leiner: what is the lower limit on topology constraints? Huitema: Suggests should have a maximum of O(1000s) top-level routing entities world-wide. This requires that network operators exercise discipline in topology and that address assignment authorities exer- cise discipline in assignment. Cerf: need high fanout to reduce hierarchical levels.
The ExecD agreed to edit a statement of direction based upon this discussion, and Huitema promised to provide an initial draft. Chapin reinterated the urgency of getting this done as soon as possible. It was agreed to try to hold a teleconference with the IESG to discuss it on July 6.
[DONE/OBE 6/19/92]: IAB Members: Contribute written material on proposed R&Addr position paper.
[DONE 6/19/92]: Braden: With input from other IAB members, create draft of R&Addr position paper.
The meeting adjourned at 17:30.
APPENDIX A: ACTION ITEM STATUS SUMMARY
New Actions:
[DONE 6/19/92]: ExecD: Update Standards Procedures document with Cerf changes.
[DONE 6/19/92]: ExecD: Announce passage of SNMP Security ballot.
[ACTION 6/19/92]: Leiner: Ask CCIRN for technical paper on on IEPG “hub” topology proposal, when it becomes available.
[DONE/OBE 6/19/92]: IAB Members: Contribute written material on proposed R&Addr position paper.
[DONE 6/19/92]: Braden: With input from other IAB members, create draft of R&Addr position paper.
[ACTION 6/19/92]: ExecD: Announce IAB decision on Postscript for standards documents: primary must be ASCII.
[ACTION 6/19/92]: ExecD, Gross, Chapin: Develop written statement of IAB balloting proceures.
[ACTION 6/19/92]: ExecD: Provide statistics on DISCUSS votes.
[ACTION 6/19/92]: Kent & Gross: Define “token” holder for PPP Authentication standards action.
[ACTION 6/19/92]: Gross: Discuss joint working group sponsorship with Tomaz Kalin, Secretary General of RARE.
[ACTION 6/19/92]: Leiner: Discuss enriched IAB/CCIRN communication with CCIRN.
[ACTION 6/19/92]:Huitema: Provide minutes of 30 June RTC meeting.
[ACTION 6/19/92]: ExecD: Set up IAB meeting on Friday July 17, 1992 at Boston IETF.
[ACTION 6/19/92]: Gross: Set up BOF at Boston IETF, on subject of internationalization and growth.
[ACTION 6/19/92]: Chapin & Cerf: Debug IAB Charter.
[ACTION 6/19/92]: Chapin: Submit IAB Charter for RFC publication.
[ACTION 6/19/92]: IAB: Send suggestions to Gross for WG standards action request template items.
[ACTION 6/19/92]: ExecD: Try to get group reports from IAB Archi- tecture II retreat, by July 6, and create summary RFC.
[ACTION 6/19/92]: Cerf: (Re-)draft letter on overlapping standards activities for ISOC Board, and allow IAB to review.
[ACTION 6/19/92]: Cerf: Revise RFC-1160 to define structure of ISOC, IAB, and IETF.
[ACTION 6/19/92]: Huitema: Distribute draft statement of technical concerns about RIP II.
Pending Actions:
[ACTION 5/21/92]: Chapin: Send out proposal for statement of direction on routing and addressing.
[ACTION 3/16/92]: Chapin: Forward DNS policy statement, and submit it as Informational RFC.
[ACTION 3/16/92]: Chapin: Post OSPF AS as I-D, and submit it for publication as an RFC.
[ACTION 3/16/92]: ExecD: Inform WGC of future IAB meetings.
[ACTION 3/16/92]: Gross: draft a standards action template for use by WGs.
[ACTION 3/16/92]: Chapin: Draft statement of architectural requirements on an inter-AD routing protocol for use with CIDR.
[ACTION 2/27/92]: Postel: Draft description of what he will do as IRTF chair, including possible research deliverables.
[ACTION 1/7/92]: Postel (IANA): Coordinate network number assign- ment policy with the NIC, and then publicize policy.
[ACTION 1/7/92]: Gross, Leiner: Document steps being taken to move towards internationalization of IETF and IAB activities.
[ACTION 1/7/92]: Gross: Develop proposal for handling IETF growth.
[ACTION 1/7/92]: Gross: Develop proposal for IETF internationali- zation.
[ACTION 10/91]: Postel [IANA]: Publicize policy on non- discriminatory assignment of top-level DNS names and a pro- cedure for settling disputes.
[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/90]: Gross/Coya: Send message to IAB on how to use IETF WG database.
[ACTION 4/90]: Postel: Draft “Principles of the Internet [Archi- tecture]” document.
Completed Actions [Note: “OBE” means “Overtaken by Events”]:
[DONE 5/21/92]: ExecD: Collect and organize proposed changes to RFC-1310.
[DONE 5/21/92]: IAB Members: Send Postel a brief statement of dom- inant architectural issues for routing and addressing.
[DONE 5/21/92]: Chapin: Send out routing&addressing source material list.
[DONE 5/21/92]: Gross: Furnish IESG recommendation on routing and addressing.
[DONE 4/21/92]: Gross: Resend ROAD Report Draft to IAB.
[DONE 5/21/92]: Cerf: send proposed IAB charter changes to Chapin.
[DONE 5/21/92]: Chapin: Produce new draft of IAB charter
[DONE 5/21/92]: ExecD & Cerf: Coordinate online list of standards actions.
[DONE 5/21/92]: Braun: Write his views on CLNP deployment.
[DONE 4/21/92]: Kent: Send message to JRD, cc: IESG, summarizing status of SNMP Security revision.
[DONE 4/21/92]: Cerf: ask IESG Secretariat (Coya) to periodically probe for completion of SNMP Security revision.
[DONE 4/21/92]: ExecD: Redraft Prototype proposal.
[DONE 3/16/92]: Chapin: Informal presentation of proposed IAB charter to ISOC Board of Trustees.
[DONE 3/16/92]: Kent: Discuss issues with authors of SNMP security spec.
[DONE 2/27/92]: Gross: Institute Internet Draft boilerplate.
[DONE 1/7/92]: Cerf: Write summary of his instructions to patent and copyright attorneys.
[DONE 1/7/92]: ExecD: Update Standards Procedures RFC with obvious changes, and circulate result to IAB and IESG prior to publica- tion.
[DONE 1/7/92]: ExecD: Arrange BOF at March ’92 IETF, to discuss standards procedures.
[DONE 1/7/92]: ExecD: Announce Proposed Standard state of Ethernet MIB.
[DONE 1/7/91]: ExecD: Draft announcement of User-Friendly-Naming status.
[DONE 1/7/92]: ExecD: Re-send question concerning BGP Next-Hop- SNPA to IESG.
[DONE 1/7/92]: ExecD: Draft a message relaying concerns and ques- tions for the two X.400 standards (X.400(88) Downgrading and X.400-822 Mapping) and send to the IESG.
[OBE 12/19/91]: Chapin: Draft statement concerning IAB charter and context for second ISOC newsletter.
[DONE 11/91]: RFC Editor: Publish STD RFC.
[DONE 11/91]: Cerf: Get an attorney’s advice on statement regard- ing reproduction to be included on RFCs.
[DONE 11/91]: Cerf: Get an attorney’s advice on copyright issues for Internet-Drafts.
OBE: [ACTION 12/19/91] Gross: Prepare draft of address assignment policy statement for Jan 92 IAB meeting.
DONE/OBE: [ACTION 12/19/91] Postel (IANA): Prepare draft of domain name assignment policy statement for Jan 92 IAB meeting.
DONE: [ACTION 12/19/91] Chapin, ExecD: Plan agenda for 2-day architecture retreat in Boston.
[DONE 11/91]: Cerf: Produce a (non-RFC) document suggesting an appropriate policy favoring universal use of the DNS.
DONE: [ACTION 11/91]: Chapin: Draft subsection on intellectual property.
DONE: [ACTION 11/91]: ExecD: Update and publish Future Internet Architecture document.
DONE: [ACTION 11/91]: Huitema and Kent: Respond to IESG and Steve Hardcastle-Kille with a summary of the IAB’s reservations on UFN, mentioning that there was considerable discussion.
DONE: [ACTION 11/91]: Leiner: Ask CCIRN for permission to publish CCIRN news in IAB or ISOC publication, e.g., the IMR.
DONE: [ACTION 11/91] Cerf: Send to the IAB members the current descriptive information and the proposed bylaws of ISOC.
[OBE 11/91]: Cerf, Kent: Draft appropriate statement about the use of X.500 in the future.
[OBE 10/2/91]: Gross, Leiner: Re-edit Informational document on OSPF as common IGP, to strengthen case.
[DONE 6/91]: Kent: Send his draft on user authentication to WGC.
[OBE 5/29/91]: Gross: Draft a general statement of IAB policy on standardization of encapsulations within IP.
[OBE 10/90]: Postel: Try to publish all acceptable-use policies.
APPENDIX B: PROPOSED POLICY: POSTSCRIPT FOR STANDARDS DOCUMENTS
Since 1989, the Internet policy set by the IAB has allowd Postscript RFC’s but required that parallel ASCII versions exist as well. The ASCII versions of Postscript have been allowed to be substandard, e.g., missing diagrams and not meeting the customary standards on format.
Experience has shown that that the results have been less than satis- factory, and the IAB is now amending the policy in the following manner: RFCs that document standards-track specifications MUST have their reference text in ASCII. That is, the ASCII version of standards-track specifications must be complete and properly format- ted. A secondary version in Postscript is still allowed, but its Status of Memo will note that it is not primary.
No policy can be universal. If the drafters of a standards specifi- cation RFC feel they have a legitimate need for using Postscript for the reference version of a specification, they should discuss this with the IESG, preferably early in the process. Exceptions will not be granted lightly, but nothing is impossible.
This policy change affects only standards-track specifications; other RFC’s will continue to follow the former rules.
HISTORY
In 1989, there was a raging discussion on the question of Postscript RFCs, both on public mailing lists and within the IAB. Based upon the public discussion, the IAB at its July 1989 meeting agreed upon a dual-version policy. This was reflected in the Instructions for RFC Authors and announced in the IAB REPORT [Internet Monthly Report, October 1989]:
“The IAB has noted the intense concern in the community about Postscript-only RFC’s; unfortunately, there is no ideal solution for this problem. Until ODA or its equivalent is widely available, some combination of ASCII and Postscript is the best we can do. The IAB has instructed the RFC Editor to obtain an ASCII version from the author of any Postscript-only document whenever possible, and both versions are to be made publically available. Although the dual versions may cause significant extra work for both authors and editor, this appears to be the only feasible compromise.”
In the succeeding three years, the situation has not improved. ODA has not saved us, and the drawbacks of Postscript noted in July 1989:
printing capability is not universal,
difficult to cut and paste,
difficult to search,
file sizes are too large, and
unable to view from a terminal,
are unchanged. Typically, we have found that the ASCII versions of Postscript specifications have been derived mechanically, with minimal or no editorial effort. The result has been unreadability at best and at worst typographic errors in specifications where precision is required and expected.
What has changed in three years is the economic significance of the Internet standards process. As a result, the Internet com- munity in general and the IAB in particular have lavished a great deal of time and effort to improve the quality of our standards process while attempting to preserve its manifest vir- tues.
There is no question in anyone’s mind that Postscript documents are prettier and may be easier to read than corresponding ASCII documents. However, we believe that other issues are paramoun- for the formal specification of protocols and procedures. In particular, a reference specification must be universally print- able, and it must be possible to cut-and-paste machine- processable program fragments from the text. When fancy expla- natory diagrams are desired, it may be appropriate to create two documents, an introductory document in Postscript and the formal specification in ASCII.
We have a great deal of experience with using ASCII to effec- tively document Internet protocols and procedures, and we believe that a carefully written ASCII document can convey the desired imformation clearly and precisely. It may be hoped that the restriction to a single font will encourage authors to make every word count.
Internet Activities Board
Meeting Summary — June 18-19, 1992
Kobe, Japan (INET ’92 Meeting)
FUTURE MEETINGS
Friday July 17, 1992 at Boston IETF meeting
(Subject: IETF internationalization and growth).
Thursday October 29, 1992 at Interop in San Francisco
RESERVED SLOTS:
November 20, 1992 at Washington D.C. IETF.
February 17-18, 1993 at Brussels, overlapping CCIRN.
May 10-13, 1993 in Trondheim, at JENC meeting.
ACTION ITEM STATUS SUMMARY
New Actions:
[ACTION 6/19/92]: Leiner: Ask CCIRN for technical paper on on IEPG “hub” topology proposal, when it becomes available.
[ACTION 6/19/92]: IAB Members: Contribute written material on proposed R&Addr position paper.
[ACTION 6/19/92]: Braden: With input from other IAB members, create draft of R&Addr position paper.
[ACTION 6/19/92]: ExecD: Announce IAB decision on Postscript for standards documents: primary must be ASCII.
[ACTION 6/19/92]: ExecD: Develop written statement of IAB balloting proceures.
[ACTION 6/19/92]: ExecD: Provide statistics on DISCUSS votes.
[ACTION 6/19/92]: Kent & Gross: Define “token” holder for PPP Authentication standards action.
[ACTION 6/19/92]: Gross: Discuss joint working group sponsorship with Tomaz Kalin [head of RARE]
[ACTION 6/19/92]: Leiner: Discuss enrichedd IAB/CCIRN communication with CCIRN.
[ACTION 6/19/92]:Huitema: Provide minutes of 30 June RTC meeting.
[ACTION 6/19/92]: ExecD: Set up IAB meeting at Boston IETF.
[ACTION 6/19/92]: Gross: Set up BOF at Boston IETF, on subject of internationalization and growth.
[ACTION 6/19/92]: Chapin & Cerf: Debug IAB Charter.
[ACTION 6/19/92]: Chapin: Submit IAB Charter for RFC publication.
[ACTION 6/19/92]: IAB: Send suggestions to Gross for WG standards action request template items.
[ACTION 6/19/92]: ExecD: Try to get group reports from IAB Architecture II retreat, by July 6, and create summary RFC.
[ACTION 6/19/92]: Cerf: (Re-)draft letter on overlapping standards activities for ISOC Board, and allow IAB to review.
[ACTION 6/19/92]: Cerf: Revise RFC-1160 to define structure of ISOC, IAB, and IETF.
[ACTION 6/19/92]: Huitema: Distribute draft statement of technical concerns about RIP II.
Pending Actions:
[NOTE: When we went over the action items, we left a number of them for later discussion, which we never had. So they are still on the Pending list. ExecD]
[ACTION 5/21/92]: Chapin: Send out proposal for statement of direction on routing and addressing.
[ACTION 3/16/92]: Chapin: Forward DNS policy statement, and submit it as Informational RFC.
[ACTION 3/16/92]: Chapin: Post OSPF AS as I-D, and submit it for publication as an RFC.
[ACTION 3/16/92]: ExecD: Inform WGC of future IAB meetings.
[ACTION 3/16/92]: Gross: draft a standards action template for use by WGs.
[ACTION 3/16/92]: Chapin: Draft statement of architectural requirements on an inter-AD routing protocol for use with CIDR.
[ACTION 2/27/92]: Postel: Draft description of what he will do as IRTF chair, including possible research deliverables.
[ACTION 1/7/92]: Postel (IANA): Coordinate network number assignment policy with the NIC, and then publicize policy.
[ACTION 1/7/92]: Gross, Leiner: Document steps being taken to move towards internationalization of IETF and IAB activities.
[ACTION 1/7/92]: Gross: Develop proposal for handling IETF growth.
[ACTION 1/7/92]: Gross: Develop proposal for IETF internationalization.
[ACTION 10/91]: Postel [IANA]: Publicize policy on non- discriminatory assignment of top-level DNS names and a procedure for settling disputes.
[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/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.
IAB REPORT — June 1992
A. IAB/IETF NOW PART OF ISOC
Meeting in Kobe, Japan, on June 15, 1992, the Board of Trustees of the Internet Society voted to accept a recommendation from the Internet Activities Board to bring the IAB and all of its activities into the Internet Society, with the IAB serving as a technical advisory group of the ISOC. The IETF will continue to pursue standards-setting and other engineering activities under this new umbrella, and the IRTF will continue to pursue research questions of importance to the Internet.
The IAB was renamed the Internet Architecture Board.
B. IAB PROPOSAL ON ROUTING AND ADDRESSING
-
The ROAD group’s work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate; they represent a clear and present danger to the future successful growth of the worldwide Internet.
The IAB was therefore unwilling to postpone development of a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin soon, and it is imperative that the efforts of the Internet community be focussed on a common goal.
-
The IETF should aggressively pursue the work to engineer CIDR (“classless inter-domain routing”, described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm.
-
Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for development and deployment of a new version of IP, which the IAB has dubbed “IP version 7” (IPv7).
-
Based upon an analysis of the architectural requirements, the IAB furthermore proposes using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses variable-length addresses that may be up to 20 bytes long) as the starting point for developing IPv7. RFC-1347 contains an initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications. However, further engineering will be required to meet the Internet requirements of efficiency and functionality.
It is important to understand that this does NOT mean “adopting OSI” or “migrating to OSI” or “converting the Internet to use GOSIP protocols”. The IAB recommends only that a new version of IP (IPv7), with much wider addresses and a more extensible header, be based on the existing CLNP. IPv7 is intended to be deployed within the current Internet TCP/IP architecture, not as part of an “OSI stack”.
-
CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic).
During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed the draft report of the ROAD group concerning the problems of “running out of IP network numbers” and “Internet routing table size explosion”, and a companion report from the IESG, “IESG Deliberations on Routing and Addressing”.
The IAB’s analysis of the many possibilities led to the following conclusions, which are documented in an Internet-Draft entitled “IP Version 7”:
There are, of course, many issues that must be resolved before CIDR and IPv7 could actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwithstanding the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year.
In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket “condemnation” of the alternative proposals that have been floated in various parts of the IETF. However, the IAB believes that the normal IETF process of “let a thousand [proposals] bloom”, in which the “right choice” emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston.
– Lyman Chapin
IAB chair
C. NEW POLICY ON POSTSCRIPT FOR STANDARDS DOCUMENTS
- printing capability is not universal
- difficult to cut and paste
- difficult to search
- file sizes are too large
- unable to view from a terminal
Since 1989, the Internet policy set by the IAB has allowed Postscript RFC’s but required that parallel ASCII versions exist as well. The ASCII versions of Postscript have been allowed to be substandard, e.g., missing diagrams and not meeting the customary standards on format.
Experience has shown that that the results have been less than satisfactory, and the IAB is now amending the policy in the following manner: RFCs that document standards-track specifications MUST have their reference text in ASCII. That is, the ASCII version of standards-track specifications must be complete and properly formatted. A secondary version in Postscript is still allowed, but its Status of Memo will note that it is not primary.
No policy can be universal. If the drafters of a standards specification RFC feel they have a legitimate need for using Postscript for the reference version of a specification, they should discuss this with the IESG, preferably early in the process. Exceptions will not be granted lightly, but nothing is impossible.
This policy change affects only standards-track specifications; other RFC’s will continue to follow the former rules.
HISTORY AND BACKGROUND
In 1989, there was a raging discussion on the question of Postscript RFCs, both on public mailing lists and within the IAB. Based upon the public discussion, the IAB at its July 1989 meeting agreed upon a dual-version policy. This was reflected in the Instructions for RFC Authors and announced in the IAB REPORT [Internet Monthly Report, October 1989]:
-
“The IAB has noted the intense concern in the community about Postscript-only RFC’s; unfortunately, there is no ideal solution for this problem. Until ODA or its equivalent is widely available, some combination of ASCII and Postscript is the best we can do. The IAB has instructed the RFC Editor to obtain an ASCII version from the author of any Postscript-only document whenever possible, and both versions are to be made publically available. Although the dual versions may cause significant extra work for both authors and editor, this appears to be the only feasible compromise.”
In the succeeding three years, the situation has not improved. ODA has not saved us, and the drawbacks of Postscript noted in July 1989:
are unchanged. Typically, we have found that the ASCII versions of Postscript specifications have been derived mechanically, with minimal or no editorial effort. The result has been unreadability at best and at worst typographic errors in specifications where precision is required and expected.
What has changed in three years is the economic significance of the Internet standards process. As a result, the Internet community in general and the IAB in particular have lavished a great deal of time and effort to improve the quality of our standards process while attempting to preserve its manifest virtues.
There is no question in anyone’s mind that Postscript documents are prettier and perhaps easier to read than corresponding ASCII documents. However, we believe that other issues are paramount for the formal specification of protocols and procedures. In particular, a reference specification must be universally printable, and it must be possible to cut-and-paste machine-processable program fragments from the text. It should be possible to easily search for desired text.
When fancy explanatory diagrams are desired, it may be appropriate to create two documents, an introductory document in Postscript and the formal specification in ASCII. We have a great deal of experience with using ASCII to effectively document Internet protocols and procedures, and we believe that a carefully written ASCII document can convey the desired information clearly and precisely. It may be hoped that the restriction to a single font will encourage authors to make every word count.
This policy was proposed to the IETF on May 28, 1992, and was very extensively discussed on the IETF mailing list. The great majority of comments received by the IAB were strongly in favor of this change. Therefore, it was formally adopted by the IAB at its Kobe meeting.
D. STANDARDS ACTIONS
-
SNMP Administrative Model
-
Proposed Standard
-
RFC-1351, “SNMP Administrative Model”, July 1992
-
SNMP Security Protocols
-
Proposed Standard
-
RFC-1352, “SNMP Security Protocols”, July 1992
-
SNMP Security MIB
-
Proposed Standard
-
RFC-1353, “Definitions of Managed Objects for Administration of SNMP Parties”, July 1992
-
TFTP — Trivial File Transfer Protocol
-
Standard
-
RFC in preparation.
-
PCMAIL
-
Informational
-
RFC-1056, “PCMAIL – A Distributed Mail System for Personal Computers”, June 1988
-
SUPDUP
-
Historic: June 1992
-
RFC-734 “SUPDUP Protocol”, October 1977
-
SFTP — Simple File Transfer Protocol
-
Historic: June 1992
-
RFC 913 “Simple File Transfer Protocol”, September 1984
-
Hostname Server
-
Historic: June 1992
-
RFC-953 “Hostname Server”, October 1985
-
NFILE
-
Historic: June 1992
-
RFC 1037 “NFILE – a File Access Protocol”, December 1987
The following list shows the protocol standards actions approved by the IAB during the month of June, 1992.
E. RFC’S PUBLISHED IN JUNE FOR PREVIOUSLY-ANNOUNCED ACTIONS
-
IP Forwarding Table MIB
-
Proposed Standard (: February 1992 *)
-
RFC-1354, “IP Forwarding Table MIB”, July 1992
-
IP Type of Service
-
Proposed Standard (: February 1992 *)
-
RFC-1349, ” Type of Service in the Internet Protocol Suite”, July 1992.
*Note: For determination of minimum time-in-grade, the date of RFC publication should be used.
F. STANDARDS ACTIONS PENDING ON JULY 1, 1992
-
‘Multiprotocol Interconnect on X.25 and ISDN in Packet Mode’ to Proposed Standard
-
Architectural issue under review.
-
‘PPP Authentication Protocols’ to Proposed Standard
-
Awaiting further information.
-
‘Echo Function for ISO 8473’ remain Proposed Standard
-
Clarification requested from IESG.
-
‘RIP I’ to Standard
-
Under consideration by the IAB.
-
‘IDPR’ to Proposed Standard
-
Under consideration by the IAB.