INTERNET ENGINEERING STEERING GROUP (IESG) 20 October 1994 Reported by: John Stewart, IESG Secretary This report contains IESG meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. For more information please contact the IESG Secretary at . ATTENDEES --------- Bradner, Scott / Harvard Halpern, Joel / Newbridge Networks Klensin, John / MCI Knowles, Stev / FTP Software Mankin, Allison / NRL Mockapetris, Paul / ISI O'Dell, Mike / UUNET Rekhter, Yakov / IBM (IAB Liaison) Rose, Marshall / DBC Stewart, John / CNRI Topolcic, Claudio / BBN Regrets ------- Coya, Steve / CNRI Huitema, Christian / INRIA (IAB Liaison) Huizer, Erik / SURFnet Reynolds, Joyce / ISI Schiller, Jeff / MIT 1. The minutes of the 6 October IESG teleconference were approved. 2. Protocol Actions o The IESG approved moving "Gateway Requirements" to Historic. o The IESG approved "BGP4/IDRP for IP---OSPF Interaction" for the status of Proposed Standard. o Pending a modified protocol write-up by Erik Huizer, the IESG approved: - "Uniform Resource Locators (URL)" for the status of Proposed Standard. The IESG also recommends to the RFC Editor that: - "Functional Requirements for Internet Resource Locators" - "Requirements for Uniform Resource Names" be published as Informational RFCs. The motivation behind modifying the write-up is so there is an official record for the community, including the working group and [a possibly different] IESG, of issues which need to be addressed before elevating the documents from Proposed to Draft Standard. The comments are attached to the end of these minutes. ACTION(Klensin): Contact Erik Huizer about adding some text to the protocol write-up. 3. Management Issues o A request has been made to have a BOF in San Jose to review the current revision to the standards process (draft-iab- standards-processv3-00.txt). This is very relevant to POISED, so, as the responsible IESG member, Paul Mockapetris will approach the POISED Chairs about their time-table on reviewing the Internet-Draft. It was noted that a firm decision has not yet been made on the question of term lengths for interim appointees, and as long as POISED is being approached, they should be asked this question as well. ACTION(Mockapetris): Ask Steve Crocker and Mel Pleasant about their plans for (1) reviewing the current revision to the standards process and (2) deciding on the term-length question. o The IESG agreed that during the host requirements effort, the tradition of 'modularizing' the documents into upper and lower layers should be kept. It was noted that at the upper layers, there would probably be a separate document for each major application (e.g., FTP, 822/[E]SMTP/MIME, TELNET, etc.). In addition, the IESG agreed that the host requirements documents should contain clarification, explanation *and* A/S-directive material (i.e., as opposed to separating that material out into different documents). o The IESG agreed to the following clarification of procedures for Internet-Drafts: - Anyone may publish anything under their own name. - When a submission is made in the name of a working group, the Secretariat will forward the submission to the chair of the working group. The chair then has the right to prevent the Internet-Draft from being announced as a product of the working group (though the author may have it announced as an individual submission). - If a chair allows a document to be announced, but the responsible area director disagrees, the area director can have the document renamed to become an individual submission (not associated with the working group). Attachment: Issues UR* Documents Need to Address Before Elevation To: uri@bunyip.com Subject: generic IESG comments Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Fri, 04 Nov 1994 09:34:30 +0100 From: "Erik Huizer (SURFnet BV)" While these documents represent major steps forward in the definition and standardization of information resource location and identification, they do not address at least two issues that will become increasingly important as the Internet continues to grow. The necessity for solving these problems is generally understood in the community and it is usually assumed that the solution lies in URNs/URCs, but the URN requirements document does not yet cover them. Resolution of the issues will be a precondition for moving of the standards-track documents to Draft Standard. The issues are: --> Scaling and replication. URLs point, or seem to point, to absolute locations on named hosts in the DNS. While a number of "proxy" and "caching" schemes have been proposed (and some have been deployed), Internet experience has been that these problems are best solved by having multiple places in which to look, not just caches of things found once already. Caches improve performance, but do nothing for robustness. A long-term solution that provides the ultimate client (or its proxy) multiple locations to look for the resource is a requirement, just as the ability to support multihomed hosts and multiple-preference MX records is a requirement for the DNS. Whether this should be done through a modified URL, some URN construction, or some other mechanism requires further definition and development. --> Protocol-dependence. The URL model involves a tuple of a protocol, a domain, and a protocol-and-domain-specific string. A given resource might reasonably be expected to be accessible via several protocols, and a server supporting several protocols for one resource might rationally construct the protocol-specific form of that resource on the fly during protocol negotiation. Such a server would then want to advertise as many different URLs for the same resource as the number of protocols it supported. This leads to rapidly growing aggregate record sizes for the information that might be returned in response to a query. Whether this represents a problem should be the subject of testing and examination while the documents are in Proposed Standard status. More important, the owner of the server might then make all resources on that server accessible via a new protocol simply by installing a handler/converter for it. But the model set forth in these documents provides no model by with existing records that point to the resource might be updated to the new protocol information. This may be a significant point of incompleteness in the model and proposed protocol. The mechanism for propagating a new retrieval method from a multi-method repository/server here must be resolved before the resource location documents move to Draft Standard.