IAB Minutes 1992-10-29 | Internet Architecture Board

Home»Documents»Minutes»Minutes 1992»IAB Minutes 1992-10-29

Meeting Minutes of Internet Architecture Board

San Francisco, CA, October 29, 1992

(in conjunction with Interop ’92)

CONTENTS/AGENDA

1. ACTION ITEM REVIEW
2. FORMAL CHANNEL OF COMMUNICATION WITH IAB
3. ICD FOR INTERNET
4. STANDARDS ISSUES
5. STATUS OF ROUTING AND ADDRESSING
6. STANDARDS PROCEDURES
7. LIAISON WITH OTHER ORGANIZATIONS
8. INTERNATIONALIZATION
APPENDIX A: ACTION ITEM STATUS SUMMARY — OCTOBER 30, 1992
APPENDIX B: BACKLOG OF ITEMS IN STANDARDS TRACK

This document contains minutes of the meeting of the Internet Architecture Board (IAB) held on October 29, 1992 in the St. Francis Hotel in San Francisco, CA. This was an open meeting. The IAB attendees were:

IAB Members:

[Absent members: Christian Huitema, Phill Gross, Dan Lynch]

MINUTES

The meeting was convened at 8:40 AM.

1. ACTION ITEM REVIEW

Pending action items were reviewed; the results are summarized in Appendix A. This led to the following new action items:

[NEW 10/29/92]: Chapin, Cerf, Gross: Develop list of template items for WG standards actions.

[NEW 10/29/92]: Cerf: Revise RFC-1160, defining structure of ISOC, IAB, IETF, and IRTF, and send text as input to poised Working Group.

[NEW 10/29/92]: Chapin, Postel: Publish DNS policy statement as Informational RFC.

[NEW 10/29/92]: Cerf: Forward ITU, CCITT letters to RFC Editor for publication as RFC’s, and to Leiner for CCIRN.

It also led to more extended discussions of several topics:

1.1 GIX Proposal

[ACTION 6/19/92]: Leiner: Ask CCIRN for technical paper on IEPG “hub” topology proposal, when it becomes available.

Braun noted that a prototype GIX is being built in the Washington, D.C. area. Leiner reported that the CCIRN responded to the IESG initiative by asking for more details, but so far these have not been provided.

1.2 RIP II

[DONE 6/19/92]: Huitema: Distribute draft statement of technical concerns about RIP II.

At earlier meetings, several IAB members had expressed concern about the architectural implications of mixing link state and distance vector routing protocols within the same AD, with the implication that pursuing RIP II might not be in the best long- term interest of the Internet. At the current meeting, comments invited from the audience suggested some pragmatic reasons why RIP II may be not only inevitable but in fact desirable. Some comments were:

Peter Ford: RIP II is needed to make CIDR work. Also note that 60% of the world’s routers use IGRP, a Distance Vector protocol.
Lauck: RIP II is a *new* protocol, and its development seems to undercut OSPF. This is a bad precedent for the future.
Hinden: The Working Group argued that there are many small environments where RIP II is useful.
Chapin: This illustrates that in the Real World, there are many sides to an issue.

Dave Crocker observed that usage recommendations would be more useful than “good”/”bad” comments. People don’t generally under- stand the limitations of the routing protocols they use, and it would be useful to have a document on the issues and tradeoffs in interior routing. Rehkter: We need such a document for CIDR.

This led to the beginning of a discussion on timelines for routing and addressing solutions; this discussion was truncated as it belonged to a later agenda item.

The meeting took a break at 10:15, to allow three IAB members to make presentations at Interop ’92 sessions, and for lunch. The meeting reconvened at 1:40 PM.

2. FORMAL CHANNEL OF COMMUNICATION WITH IAB

Cerf suggested that we need to have a formal channel though which any IETF member can communicate with the IAB as a whole. This formal channel, distinct from the existing (and very useful) informal chan- nels to individual IAB members, would imply a formal committment to respond. It was agreed that this might be useful. The ExecD agreed to set up such a mechanism, including a tracking procedure.

[NEW 10/29/92]: ExecD]: Set up formal channel for communicating with IAB.

3. ICD FOR INTERNET

It has been suggested by a number of people that “…the ISOC or the IAB should apply for and obtain an ICD OID assignment from BSI under { 1 3 } for The Internet (IETF)” [Stefferud in recent message]. Pos- tel reported that the IANA (Internet Assigned Numbers Authority) has requested exactly such an ICD, using ISOC letterhead.

There was a discussion of how these numbers might be managed. Erik Huizer reported that RARE has published European guidelines for managing an ICD. He agreed to publish these guidelines as an Infor- mational RFC. Braun urged that any Internet procedure for allocating numbers under the ICD be coordinated with NIST. It was agreed that formulation of a management plan falls to IESG Area Directors Huizer and Piscitello.

There was a spirited discussion among the IAB and IESG members present and others in the audience, concerning how an Internet ICD might be allocated and where it would be useful. It may be useful for MIB OIDs. Concerning its use for NSAP addresses, some expressed serious concern that these numbers will be redundant with NSAP addresses obtained through other channels, and might only cause con- fusion. Collalla noted that RFC-1237 already gives an NSAP alloca- tion scheme for the Internet. It was suggested that the new ICD be used in RFC-1237 in place of the UCL Telex address.

Chapin agreed to draft a recommendation, based on the discussion.

[NEW 10/29/92]: Chapin: Formulate IAB recommendation to affected area directors (Huizer and Piscitello) concerning Internet ICD.

4. STANDARDS ISSUES

4.1 Current pending ballots [1]

The outstanding ballots on standards issues were reviewed, and several IAB members indicated their intention of casting YES bal- lots. As a result, the following actions were passed:

Ethernet MIB to Draft Standard

PPP DECnet Phase IV Control Protocol (DNCP) to PS

SNMP MIB extension for LAPB to Proposed Standard

SNMP MIB extension for X.25 Packet Layer to Proposed Standard

PPP OSI Network Layer Control Protocol to Proposed Standard

PPP Appletalk Control Protocol to Proposed Standard

Consise MIB Definitions to Standard

The following more recent issues were deferred to email ballots.

SNMP over Various Protocols to Proposed Standard

#93 – Default Route Advertisement in the BGP to Proposed Standard

The ExecD asked those who had given verbal agreement to submit normal email ballots.

[NEW 10/29/92]: Chapin, Kent, Lauck: Submit email ballots for actions agreed to at 10/29 meeting.

4.2 Backlog of Proposed and Draft Standards [2]

There are almost 50 specifications in the standards track whose minimum time for advancement has been passed. The ExecD ques- tioned whether this huge backlog is the result of some fundamental procedural problem, and whether there is some measure that might help to reduce the backlog significantly.

It was pointed out from the audience that working group chairs are not generally aware of the 2 year limit in grade, after which a specification must be reviewed by the IESG for viability. It was suggested that giving an advance warning of this timeout to a working group chair might cause induce activity to advance a spec.

[NEW 10/29/92]: Cerf: Ask IETF Secretariat to actively remind appropriate IETF members to advance standards before expiration of 2 year reassessment timeout.

5. STATUS OF ROUTING AND ADDRESSING

Bob Hinden, the IETF Area Director for Routing, gave a brief informal report on the status of work to solve the routing and addressing problems, and in particular on what he expects to happen at the November IETF meeting.

Monday morning of IETF, there will be presentations on IPAE, Tuba, SIP, and PIP. There will be BOFs for various groups.
The open plenary Thursday evening will discuss the issues.
He hopes the meeting will gather a lot of good data, but does not expect that a concensus will emerge at this meeting.

There followed a spirited discussion among the IAB, the IESG members present, and other attendees. With names omitted (to protect the not-so-innocent), here are some of the key points that were made.

If not-CLNP is chosen, we will get CLNP anyway, so we end up with both.
The large companies don’t care what the IETF says. “[Company X] is driven by RFP’s, not by RFC’s”.
Some (not disinterested) persons urged that there is no point in choosing among the alternative solutions. Others felt strongly that failing to make a decision will lead to greatly increased costs for network operators and the possibility of large-scale loss of connectivity, hurting users.
The majority of users of the technology are not connected to the Internet; however, the direction taken by the Internet will have a strong psychological impact.

Among those who wanted a decision, there was a felt need for a decision process. The first step may be a meta-decision process, a process to decide upon the criteria for the decision. The final decision will require iteration between the criteria and the proposals.

Final comment (from a visitor): “We need to do something about the hostility level in the IETF”.

6. STANDARDS PROCEDURES

6.1 ITU Recognition of ISOC/IETF

Cerf, as ISOC President, has sent letters to both ITU and CCITT seeking recognition of the ISOC/IAB/IETF as an international standards-setting body. The IAB asked that these letters, and the responses, be published as RFCs.

[NEW 10/29/92]: Cerf: Publish letters to ITU and CCITT and responses as RFCs.

He was asked whether such recognition from CCITT implies reciprocal publication rights. He agreed to find out.

[NEW 10/29/92]: Cerf: Investigate expected level of publication reciprocity with CCITT.

6.2 ANSI Accreditation of ISOC/IETF

Cerf reported that ANSI has recently approached ISOC asking that Internet standards be introduced into the ANSI process. During discussion, a number of reasons came up why this may not be in the very best interest of the Internet community. (1) Such an association with a particular national standards organization is incon- sistent with the internationality of ISOC. (2) The Internet standardization process might have to change in undesirable ways in order to achieve accreditation by ANSI. (3) The ANSI board would have final review, adding another hurdle to the process. (4) “ANSI has no concept of a standard that is not sold by ANSI”. (5) Industry has the impression that something with an ANSI label cannot be an international standard.

It was therefore agreed to recommend to the ISOC President (Vint Cerf) that ANSI accreditation not be pursued.

6.3 Dissemination of IAB members’ Comments on Standards

During the process of considering an IESG-recommended standards action, IAB member sometimes generate comments on related archi- tectural issues and/or specific document quality issues. The current procedure is for the ExecD to feed all such comments to the IESG Area Director responsible for the action, with the intent that the AD will forward them as appropriate to the Working Group. It had been suggested that these comments might be distributed more widely, to provide more community insight into the decision process. However, the IAB as a whole did not believe this to use- ful, and reaffirmed the present procedures.

6.4 STDs vs. RFCs

At an earlier meeting, the IAB decided that STD numbers should be assigned to all specifications in the standards track, rather than only when a specification reaches Internet Standard status. IESG members had urged this change, to ameliorate the “all RFC’s are standards” problem. The RFC Editor raised two issues with the change. (1) It will not facilitate the advance of specifications through the standards track; if every Proposed Standard has an STD number, there will be little incentive to go to Draft Standard or full Internet Standard status. (2) We have not given the current procedure (assigning STD numbers only to Standards) a chance.

However, most of the IAB members present felt that the early assignment of unique STD numbers will provide a “qualitative improvement” in the process, and the decision was reaffirmed.

There was a discussion of the additional information that may need to modify an STD number: (1) level in the standards track (DS, PS, or IS), (2) version (or date), and (2) component part, for multi- document specifications. The following examples were written down:

STD-37-1 DS (Draft Standard, component 1 of STD-37)
STD-37 (RFC-1426) (Component of STD-37 defined in RFC-1426)
STD-37:92 (1992 version of STD-37)

The RFC Editor agreed to formulate a set of proposed rules.

[NEW 10/29/92]: Postel: Formulate proposed rules for STD assignment.

6.5 Standards vs. Policies/Procedures

The IESG recently issued a last call on “Guidelines for Address Allocation”, indicating that it was considering entering this document into the standards track. However, there was doubt among some IAB members that standards track is appropriate for a policy or procedural document.

Lauck suggested that the standards track is defined by the pro- cess, not by the contents, and that any document that follows the process, whether it is a protocol, a procedure, or a policy, can legitimately be called a “standard”.

Chapin observed that ISO has a separate category of Technical Reports, which are explicitly *not* standards. This could be a way to document results that are not in the standards track. A new category of “Policy Recommendations” was suggested.

Leiner agreed to draft a statement about Policy Recommendations.

[DONE 10/29/92]: Leiner: Draft statement on Policy Recommenda- tions.

6.6 “Prototype” status [3]

The ExecD distributed copies of the current version of a revision to RFC-1310, defining the Internet standards process. It was agreed to make this an Internet-Draft and invite comments from the community.

[NEW 10/29/92]: ExecD: Publish 1310bis text as I-D after one week for input from IAB and IESG.

7. LIAISON WITH OTHER ORGANIZATIONS

7.1 Liaison with ISO/IEC JTC1/SC6

Chapin reported that SC6 recognizes that the Internet is currently the most important context for CLNP deployment, and that they would like feedback from the Internet community on any issues that arise. There was no discussion.

7.2 Liaison with ANSI-accredited standards committee T1M1

Chapin reported that the people who do Operations and Management for telecommunications would prefer it if the Internet used NSAP addresses as network addresses. There was no discussion.

[NEW 10/29/92]: Cerf: Respond to SC6 and T1M1 for IAB/ISOC.

7.3 Joint Work with IEEE on Security

This item was not discussed, for lack of time.

8. INTERNATIONALIZATION

This item was not discussed, for lack of time.

APPENDIX A — ACTION ITEM STATUS SUMMARY — OCTOBER 30, 1992

Pending Actions: