IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE AUGUST 15TH, 1991 Reported by: Greg Vaudreuil, IESG Secretary This report contains - Meeting Agenda - Meeting Attendees - Meeting Notes Please contact IESG Secretary Greg Vaudreuil (iesg-secretary@nri.reston.va.us) for more details on any particular topic. ^L A. Meeting Attendees Almquist, Philip / Consultant Borman, David / CRAY Callon, Ross / DEC Chiappa, Noel / Consultant Crocker, Dave / DEC Crocker, Steve / TIS Coya, Steve / CNRI Davin, Chuck / MIT Gross, Philip / ANS Hobby, Russ / UC-DAVIS Hinden, Robert / BBN Vaudreuil, Greg / CNRI Regrets Estrada, Susan / CERFnet Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet B. Agenda 1) Administrivia - Bash the Agenda - Approval of Minutes - July 25th - July 30-Aug 2nd - August 8th 2) Review of Action Items 3) Protocol Actions - MIB 2 - Concise MIB - Network Time Protocol - Multi-protocol interconnect over Frame Relay - Inverse ARP 4) RFC Editor Actions - Message Send Protocol 2 - SNMP over OSI 5) Technical Management Issues - TCP Large Windows extensions - Many MIBs - Distinguished Names - Five Full-Day IETF Meetings 1. Administrivia 1.1 Approval of the Minutes 1.1.1 July 25th. The Minutes of the July 25th Teleconference were approved pending changes to be sent to Vaudreuil by Monday. 1.1.2 Plenary Meetings. These minutes were approved by the IESG pending changes to be send to Vaudreuil by Monday. The Chairman later asked that these be delayed pending his review and approval. 1.1.3 August 8th. These minutes were not approved by the IESG. They will be read, corrected, and resubmitted for the next teleconference. The IESG discussed the imminent release of the minutes beginning with the plenary session meetings. The preferred distribution mechanism was chosen to be a sister directory to the ietf and internet-drafts, with an announcement sent to the IETF mailing list of their availability. ACTION: Vaudreuil -- Make a new distributed directory for the IESG minutes. Insure that mail access is available at the NIC.DDN.MIL 2. Review of selected action items. (89) Apr 25 [Russ Hobby] Resolve the conflict with the two version of the IMAP protocol. There is slow progress being made. One party is now willing to change the name of the protocol and declare a split. The other party is talking in good faith to resolve this issue and may also agree to a name change. (170) Aug 08 [Phill Gross] Communicate the opinion of the IESG concerning the Interactions of BGP with IGP's to the authors of the BGP Usage document and integrate the useful Interaction information into the document. Phill Gross has been in contact with Yackov Rekhter and is awaiting comments on the latest version of the document. The IAB is continuing to send mixed signals on the BGP usage document. After significant discussion, the IESG determined that it has done all it can to address the IAB's concerns on this document. Specific objections were raised about the lack of a routing architecture document for BGP. While the IESG agrees that there is a pressing need for an unified routing architecture, it feels that this document is not required for specific routing protocols, and imposing this requirement on the BGP protocol designers would unduly delay the well deserved advancement of the BGP protocol. The IESG agreed to send the current set document to the IAB as soon as all the authors are polled. If at that point the IAB still has objections, these should be send to the IESG and IETF in the form of an explicit rejection notice. ACTION: Gross -- Send a note the IAB soliciting final comments on the BGP documents. Explain that the IESG is satisfied with the current BGP documents expects to make a public recommendation in the near future. (168) Aug 08 [Phill Gross] Write a statement to the IAB expressing the need felt by the IESG for a public response to the public IESG recommendations to the IAB. This action is still pending. The IESG discussed and reiterated the need for these formal exchanges and notification of standards actions. 3. Protocol Actions 3.1 Management Information Base II The IESG approved the recommendation elevating MIB II to full Standard status. MIB II is widely implemented in network devices and management stations. 3.2 Concise MIB Definitions The IESG approved the recommendation elevating the Concise MIB definitions to Draft Standard. This new compact machine readable syntax is used in all recent MIBs written, including MIB II. 3.3 Network Time Protocol Version 3 The IESG approved the recommendation for the Network Time Protocol Version 3 for Proposed Standard. While there was sentiment within the IESG for skipping the proposed standard state for this particular protocol, wowever it was feared that figuring out the rational for an exception in the understood practice may take far longer than the 6 months the protocol would otherwise remain in the Proposed Standard state. 3.4 Multi-protocol Interconnect over Frame Relay The IESG discussed this document, and found it to be a good specification. One policy concern was raised, and should be communicated with the author. Historically the IAB has standardized IP on top of networking technologies and has avoided standardizing protocols for running other protocols over these networking technologies. An exception has been made for the point to point protocol where no other standard multi-protocol point to point protocol was available. In this case the IAB will assign protocol numbers and will likely standardize the specification of third party protocols over PPP. In the case of Frame Relay, it is not clear who "owns" the specification. Normally the IAB would standardize only IP over Frame Relay. In addition to specifying IP over Frame Relay, this document also specifies the general case of Foo over Frame Relay. Given the uncertain ownership of the frame relay specification, and the need for multi-vendor interoperation, the IESG has no problem with this specification. It is recommended that the title be changed to reflect the more traditional standardization emphasis of IP over Foo, such as "IP and other protocols over Frame Relay". ACTION: Vaudreuil -- Talk to author of the Multi-protocol Interconnect document about the name of this document; report results to IESG. 3.5 Inverse ARP The IESG discuss this document. While the protocol accomplishes that specific task it was written to, it is not clear from the document why a new protocol was needed. Other address resolution mechanisms exist. The IESG has been convinced that the Inverse ARP protocol is in fact a good way to proceed with the specific requirement posed by Frame Relay networks. The IESG recommends to the author that a section documenting the design criterion and rational for this new protocol be written to capture the reasoning behind this novel extension of the architecture. ACTION: Vaudreuil -- Talk to the author of the Inverse ARP protocol about the need for a section documenting the design criterion and rational for the Inverse ARP protocol. ACTION: Vaudreuil -- Encourage the writing of a rational section for the Inverse ARP document. MAYBE-POSITION: A rational should be captured in Internet Drafts. Need to avoid a making this a major burden. It helps capture for future readers who may not know the word of mouth history. 4. RFC Editor Actions 4.1 Message Send Protocol The RFC editor sent the IESG an experimental protocol, the Message Send Protocol for review and comment on August 13th. The IESG found the document interesting but members did not have time to review this before todays meeting. This protocol may impact the SMTP extensions work with regard to the SEND command. ACTION: Hobby -- Review the Message Send Protocol for the RFC Editor before August 27th. 4.2 Finger The RFC Editor has received a new version of the Finger protocol. This revision corrects inconsistencies between the protocol and common implementations. Hobby reviewed the protocol and found the protocol to be consistent with current practice, and recommends republication at the current Draft Standard State. The RFC Editor forwarded to the IESG a message from an implementor of the protocol who has identified several other minor points that could use clarification. ACTION: Hobby -- Look at the list of enhancements for the Finger protocol and determine if these should be corrected in this re-release. 4.3 SNMP over OSI Marshall Rose has submitted a new version of the SNMP over OSI experimental protocol specification. The intent is in part to provide a template for future authors to use in writing SNMP over Foo protocol documents. The question was raised about whether these SNMP over FOO are in fact experimental or Standards Track specifications. The Network Management Directorate clearly believes that SNMP should be run only over UDP, and has enunciated that position in Internet Draft . The question remains as community support for using SNMP over proprietary network technology grows. Due to lack of time, the IESG was unable to discuss this in greater depth. ACTION: Vaudreuil -- Schedule time in a future teleconference to discuss the wisdom of running SNMP only over UDP. 5. Technical Management Issues 5.1 Multitude of MIBs There is a half a dozen MIB's that have been reported out of the working group and are now being reviewed by the Network Management Directorate. The IESG Secretary has been tracking these as IESG protocol actions. This newly improved MIB tracking has made clear an element of confusion. MIBs generally receive their Network Management Directorate review after the relevant WG has reached closure on the MIB. Confusion arises when WGs chartered outside the NM area submit MIBs directly to the IESG without first submitting them for NM review. This confusion leads to an increasing number of situations in which the directorate is asked to conduct hasty reviews in order that the perceived timetable of IESG business not be unduly delayed, rather than conducting these reviews as part of the normal, 4-month cycle of NM directorate business. The NM AD expressed the view that, for tracking purposes, the NM review should be regarded as a distinct step between WG closure on a MIB and its submission to the IESG. In this way, time invested for the NM review would be accounted as part of routine progression of the document, and the quality of the review itself would not suffer from the time pressures of being a part of the IESG consideration of the document, which often has very different requirements. 4.2 TCP Large Windows Dave Borman gave a review of the TCP Extensions for Large Windows protocol situation. The current status is a bit unclear at this time. It appears that Braden, acting as the executive director of the IAB rejected the protocol for proposed standard for the IAB and has reassigned control for further evolution of the protocol to the End to End research group of the IRTF. This situation is not normal. Borman discussed the specific technical problems with the extensions, and discovered that both the CRAY implementation and the LBL implementation of this protocol interpret the documents differently. Borman feels that the protocol needs a bit more engineering, but is essentially functional as demonstrated by the error free interoperation between the two independent implementations. A question was raised about the proposed standard status. There was the notion that a proposed standard needs a credible specification, but does not need to be perfect. Changes are expected as experience with implementation and testing is gained prior to draft standard. Several things are unclear. Braden is one of the authors of the documents, as is Van Jacobsen. It is unknown whether Jacobsen in fact desires to delay the standardization of these protocol extensions. If both authors wish to withdraw the specification from consideration, the IESG agreed that is should not push the specification forward. There are now two other proposals for extending the TCP sequence space, one of which is under discussion in the End to End Research group. A new proposal from UCL has been circulated privately. If there are in fact competing proposals, there may be need to resurrect the TCP Large Windows working group. ACTION: Borman -- Get a copy of the UCL TCP proposal and distribute it to the IESG. 4.3 Distinguished Names A preliminary discussion of the need for a Distinguished Name Service in the Internet demonstrated immediately the need for a lengthy technical discussion of this issue. There is great need for such a service, and several platforms from which it may be built. A separate teleconference was planned, to be led by Steve Crocker and Russ Hobby. ACTION: Hobby, S. Crocker -- Organize an agenda for the Distinguished Name Teleconference. Work with Vaudreuil to schedule an appropriate time. 4.4 Full Five Day IETF meetings. The IESG received many comments during the last plenary session in Atlanta Georgia about the need to reduce the number of simultaneous working group sessions, and the need for more time to meet. In response to this need, and with the sense of the open plenary, the IESG agreed to adjust the schedule of the next meeting to include an additional working group session and extend the schedule to run to 3:30. Action: Coya -- Work with the IETF Chairman to plan a revised IETF plenary agenda to include one additional working session.