IETF STEERING GROUP (IESG) REPORT FROM THE TELECONFERENCE AUGUST 29TH, 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. Meeting Attendees ----------------- Almquist, Philip / Consultant Borman, David / CRAY Callon, Ross / DEC Chiappa, Noel Crocker, Dave / DEC Crocker, Steve / TIS Coya, Steve / CNRI Davin, Chuck / MIT Estrada, Susan / CERFnet Gross, Philip / ANS Hobby, Russ / UC-DAVIS Hinden, Robert / BBN Reynolds, Joyce / ISI Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI Agenda ------ 1) Administrivia - Bash the Agenda - Review of the Minutes - July 30th - Aug 2nd. (Pending Gross's review) - August 8th (Pending Gross's review) - August 15th (pending 15th) 2) Review of Action Items 3) Protocol Actions - TCP Large Windows - BGP - IP Frame Relay - Inverse Arp - X.500 docs 4) RFC Editor Actions - Message Send Protocol (OK?) Minutes ------- 1. Administrivia 1.1 Agenda Bashing The Agenda was approved as is. 1.2. Approval of Minutes 1.2.1 July 30th - Aug 2nd. These minutes, the first to be release publicly have been approved by the IESG pending a review by the Chairman. 1.2.2 August 8th These minutes have been approved pending review by the Chairman, 1.2.3 August 15th Review of these minutes was not undertaken. 2. Review of Action Items A review of action items was conducted by E-mail. Actions were not reviewed in this meeting. 3. Protocol Actions 3.1 TCP Extensions for High Delay, High Throughput Paths. The IAB responded to a request from the IESG to outline the technical objections to the TCP extensions. The IESG agreed that these issues were important and decided by email prior to today's meeting to withdrawing the recommendation made June 16th to collectively make RFC-1072 and RFC-1185 collectively a Proposed Standard. The IESG reviewed and approved the notice withdrawing the IESG recommendation pending a final technical review by Dave Borman. ACTION: Vaudreuil -- Send the notice withdrawing the IESG recommendation elevating the TCP extensions to the IAB with a CC to the IETF. The IESG discussed and further affirmed the need for the IESG and IAB to communicate openly, preferably by sending notices to the IETF mailing list. In particular, in cases where technical deficiencies are found, they should be noted and publicized. The specific mechanism for this communication was the subject of preliminary debate, but due to lack of time, further discussion of process was deferred. 3.2 BGP The BGP protocol elevation is still pending the identification and resolution of IAB concern. A teleconference is planned to give a final opportunity to IAB members to raise specific concerns before the IESG recommendation is publicly sent to the IAB. If this meeting cannot be arranged before Interop, a face to face meeting will be called for Wednesday evening for this discussion. The revised BGP usage document resulting from the IESG editing session August 15th is not yet available on-line. ACTION: Gross -- Publish the latest draft of the BGP usage document as an Internet-Draft 3.3 IP over Frame Relay A discussion has begun between the IESG and the IAB about the procedure for standardizing IP over Frame Relay. The IESG has received a proposal from the IPLPDN working group which offers a technically sound proposal. Because the Frame Relay standards lack a mechanism for identifying the carried protocol, the working group was compelled to specify a mechanism. The sense the IESG gathered from the discussion was that the IETF should be aware that standardizing protocols which are in the domain of another standards body is a delicate matter. In the protocol specifications it needs to be made clear that the IAB is not standardizing a Frame Relay protocol, but is narrowly standardizing a mechanism for running IP over Frame Relay. The open issue is whether it is acceptable to specify a standard mechanism for running multi-protocols over Frame Relay for the "I"nternet. The mechanism and standard are needed now, and a specification has been provided. Three approaches have been suggested for dealing with this concern. 1) Publish the document as is, with a new title emphasizing the use of the multi-protocol mechanism as "I"nternet specific. This focus is aimed at reducing the perception that we are standardizing anything about Frame Relay proper, but rather a profile for the use of Frame Relay in the multi-protocol Internet. 2) Separate out the "Multi-protocol Interconnect" portion of the document into an appendix, where the multi-protocol portion is not strictly part of the standard, but is included for "information". 3) Publish two documents, one IP over Frame Relay as a Proposed Standard, and the second Multi-protocol interconnect as informational. Both Options 2 and 3 present the unfortunate situation where the IP over FR standard depends on a non-standard informational document. It is anticipated that this document would be sent to ANSI for standardization, but in any event, the standardization of what is likely a popular service will be delayed pending action of an external body. The IESG prefers option 1, which by limiting the scope of the multi-protocol mechanism to Internet use allows the document to be implemented, and advanced without time-delaying dependencies. If the IAB objects to this approach, the IESG will re-consider option 2 and 3. ACTION: Vaudreuil -- Send the IAB a query with this 3 step multiple choice. If no objections are raised, send the recommendation with the new title to the IAB Thursday the September 12th. 3.4 Inverse ARP The IESG was not completely happy with the new motivations section. The new text elaborates on the need for an mechanism for address resolution, but did not include discussion of the rationale for the decision to write Inverse ARP rather than use ARP, Reverse ARP, or some IP specific mechanism. ACTION: Vaudreuil -- Contact the author of the Inverse ARP document and relate the specific comments of the IESG, encouraging the writing of a more complete rationale section. 3.5 X.500 documents. Ross Callon sent a comprehensive list of X.500 documents that are ready for publication. These document include standards track, experimental, and informational documents. 3.5.1 ``Replication Requirements to provide an Internet Directory using X.500'' This document discusses the requirements for replication of X.500 information for use in the Internet. Some of these requirements are general to X.500 (e.g.; we need replication and the OSI standard is not done yet); some are specific to the Internet (the need to be able to operate over RFC1006). Callon suggested that this document be published as an informational document. The IESG agreed. Action: Vaudreuil -- Write a recommendation to publish as an Informational document. 3.5.2 ``Replication and Distributed Operations extensions to provide an Internet Directory using X.500'' This document outlines solutions to the replication requirements discussed above. These solutions are based on the current QUIPU implementation, with a few extensions. It must be understood that the mechanisms specified in this document are for INTERIM use only. In particular, it is anticipated that these mechanisms will be replaced by work that is currently ongoing in ISO. In addition, the mechanisms outlined in this paper, although important for use in current X.500 pilots, are not likely to be adequate for long term use. There is an issue relating to the fact that although this document is clearly interim, it is likely to be used for some time (the OSI work on replication does not seem to be about to be finalized). Thus it could be reasonably argued that this should be on the standards track. The IESG agreed that this document should become a standard, with the understanding that it will be superseded when the relevant ISO standard is defined. The IESG discussed in depth the issues involved with standardizing what is under development in other standards bodies, but agreed that in this case a standard is clearly needed now. There has been liaison between the FOX Directory Pilot and the RARE Cosine work. With coordination and a clear statement of intention in the status of the memo section, the IESG feels this should be a proposed standard for Internet use. POSITION: The IESG recognizes the need to make certain protocols Internet specific standards in the Interim until a standard is promulgated by an external standards body with the appropriate jurisdiction. ACTION: Vaudreuil -- Confirm that the FOX directory Pilot participants have been kept involved in the IETF directory efforts. ACTION: Vaudreuil -- Write a recommendation to publish as a Proposed Standard. 3.5.3 ``An interim approach to use of Network Addresses'' There is a need, for operation of OSI applications (including the directory service) over RFC 1006, to have a unique and unambiguous means for identifying IP addresses in OSI NSAP address fields. This document specifies a unique and easy to identify method for doing so. This mechanism ensures that anyone who has a valid IP address, "automatically" has a valid way to identify the IP address in an NSAP address field. The fact that the mechanism employed utilizes a relatively obscure part of the NSAP address space is not a problem, and may in fact be considered to be a useful feature. This document specifically applies to use of OSI applications over X.25, or over TCP/IP using RFC 1006. (ED note: What was the issue with this? A section needed renaming? why?) ACTION: Callon -- Insure that the relevant section of ``An interim approach to use of Network Addresses'' document referring to X.25 NSAP's be edited. (????) ACTION: Vaudreuil -- Write a recommendation to publish as a Proposed Standard. 3.5.4 ``A string encoding of Presentation Address'' This document provides a string encoding of OSI presentation addresses, which is appropriate for use in human interactions, for humans to write on paper, and for human to machine interfacing. It is important to recognize that the encoding specified here is not intended for internal storage inside the directory system. Ross Callon and the author Steve Hardcastle-Kille agreed that this should be a standards track document. A long discussion ensued about the appropriateness of standardizing user interfaces and presentation formats. The IESG was generally of the belief that a human exchange format like RFC 822 addresses was needed, but it was not clear whether they should be explicit standards or just common practice. The specification of a single "common" format gained significant support, but no consensus was reached. Other groups are beginning to standardize presentation formats, including the Operational statistics group, which is working on standard maps and standards reports. No resolution was reached on the status of this document. ACTION: Vaudreuil -- Schedule a discussion on the appropriateness of standardizing presentation formats. 3.5.5 ``Using the OSI Directory to achieve User Friendly Naming'' This document is of critical importance, and completes an important part of the directory/naming service which is a serious hole in the existing OSI standards. Solution to the problem of user friendly naming is critical to wide-spread acceptance and use of OSI Applications. The IESG agreed that this should be a proposed standard, but the IESG wanted a specific applicability statement which would designate this format as a "common" Internet format, where other local formats are acceptable. ACTION: Gross -- Write an applicability statement for ``Using the OSI Directory to achieve User Friendly Naming'' ACTION: Vaudreuil -- Write a recommendation to publish as a Proposed Standard. 3.5.6 ``The COSINE and Internet X.500 Schema'' This provides an important list of defined types of information which is to be stored in X.500 directories. Publication of an Internet Standard for these types is important to allow commonality across directories. For example, this is useful to avoid confusion, and is essential for searches across multiple DSAs. We understand that this document will grow and change over time as the schema is upgraded and more types of information are added to the directory. Nonetheless, this work is appropriate for standardization (In this one limited sense, this document may be somewhat analogous to the series of Internet Assigned Numbers RFCs). Also note that the document (appropriately) contains duplication of some details from the X.500 standard. This will also need to be updated in the future. This document is a joint effort with the RARE Cosine project. There was a question in the IESG about who has change control authority over the document. While the specific answer was not clear, Callon assured the IESG that an arrangement had been worked out between Postel, Hardcastle-Kille, and the Cosine representatives. The IESG approved this document for proposed standards status. ACTION: Vaudreuil -- Write a recommendation to publish as a Proposed Standard. 3.5.7 ``X.500 and Domains'' This provides a description of a possible way to store Domain Name Service information in an X.500 directory. This is very useful for sites which have need for both X.500 directories, and for the Domain Name Service, but which do not want to manage two independent name services. This is also useful to allow searching the DNS data stored in X.500. The IESG approved this document as an experimental protocol ACTION: Vaudreuil -- Write a recommendation to publish as a Proposed Standard. 4. RFC Editor Actions 4.1 Message Send Protocol. The RFC Editor sent a document to the IESG for a sanity check. This protocol is an enhancement to RFC 1159. Hobby had no objections to this document. S. Crocker pointed out that the protocol as defined leaves a rather large hole for nuisance, denial of service, and potentially file read and write access. The IESG agreed that this document as an experiment should be published, but that it should include a better description of the security implications of the protocol with guidelines to implementors on how to limit the security threat. The IESG began a discussion on the requirement to address security. Current practice is now for all protocols to include a discussion of their security limitations. Now that security technology in the Internet is maturing into a useful resource, the IESG will strive to make all new protocols have "real" security built in. POSITION: Specifications on the standards track must provide adequate security and/or not undermine existing security. Specifications not on the standards track should include a clear discussion of the security implications of the protocol. ACTION: Crocker -- Send a note to Postel and the author of the Message Send Protocol pointing out the IESG concerns about security, and include suggested text to satisfy the IESG. 4.2 Security Information Transfer Protocol This was not discussed, but Crocker communicated with Postel. It appears there is a constituency for this protocol and we have begun to review the protocol to determine what technical and political issues need to be dealt with.