INTERNET ENGINEERING STEERING GROUP (IESG) June 6, 1996 Reported by: Steve Coya, IETF Executive Director 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-9528103 ATTENDEES --------- Alvestrand, Harald / Uninett Baker, Fred / cisco Bradner, Scott / Harvard Burgan, Jeff / Baynetworks Carpenter, Brian / CERN (IAB Liaison) Coya, Steve / CNRI Elz, Robert / U of Melbourne (IAB Liaison) Halpern, Joel / Newbridge Networks Kastenholz, Frank / FTP Software Kostick, Deirdre / AT&T Bell Labs Mankin, Allison / Information Sciences Institute Moore, Keith / U of Tennessee O'Dell, Mike / UUNET Reynolds, Joyce / ISI Schiller, Jeff / MIT Minutes ------- 1. The IESG approved the minutes of the May 23 teleconference. Steve to place in shadow directories. 2. The IESG approved publication of SMTP Service Extension for Remote Message Queue Starting as a Proposed Standard after deleting the following text from section 2, paragraph 1, sentence 2: "This is an attempt to fix the security problems with the TURN by creating a new command ETRN that places the emphasis on the server instead of the connection." Steve to incorporate into the announcement. 3. The IESG felt that examples would greatly improve the quality of Uniform Resource Locators for Z39.50 and decided to return the document to the author for revision. 4. The IESG approved the publication of Implications of Various Address Allocation Policies for Internet Routing as a BCP Document. Consensus was as rough as can be defined, and the IESG Note to the RFC Editor was revised to read: The addressing constraints described in this document are largely the result of the interaction of existing router technology, address assignment, and architectural history. After extensive review and discussion, the authors of this document, the IETF working group that reviewed it and the IESG have concluded that there are no other currently deployable technologies available to overcome these limitations. In the event that routing or router technology develops to the point that adequate routing aggregation can be achieved by other means or that routers can deal with larger routing and more dynamic tables, it may be appropriate to review these constraints. Jeff Schiller was not happy with the issuance of this document, and does not believe it to be a good thing. 5. The IESG approved publication of Definitions of Managed Objects for APPC as a Proposed Standard. Steve to send announcement. 6. The IESG approved publication of The PPP Multilink Protocol (MP) as a Draft Standard. There was one small typo that needs to be changed, at the top of page 2: The differences between the current PPP Multilink specification (RFC 1717) and this memo are explained in Section 10. Any system ^^^^^^^^^^^ Section 10 should be Section 11. Steve to add to the Protocol Action writeup before sending the announcement. 7. The IESG approved publication of PPP Link Quality Monitoring as a Draft Standard. Steve to send announcement. 8. The IESG approved publication of PPP Challenge Handshake Authentication Protocol (CHAP) as a Draft Standard, once Reference 4 was removed, and the text pointing to it modified. Joyce agreed that this was editorial in nature, and that a new Internet-Draft would not be required. Steve to incorporate these edit requests into the announcement. 9. The IESG opted to split the two PGP documents apart, treating each one separately. Further action was to: a. Return MIME Security with Pretty Good Privacy (PGP) to the author with items to be added (definition of must, security considerations, and the authors contact information) b. Approved publication of PGP Message Exchange Formats as an Informational RFC. 10. The IESG approved publication of the following five Mobile IP Internet-Drafts as Proposed Standards: a. IP Mobility Support b. IP Encapsulation within IP c. Minimal Encapsulation within IP d. Applicability Statement for IP Mobility Support e. The Definitions of Managed Objects for IP Mobility Support Steve to send announcement. 11. After a slight revision to the updated charter, the IESG approved the creation of the Electronic Data Interchange-Internet Integration (ediint) Working Group in the Applications Area. Steve to send announcement. 12. The IESG approved publication of Catalogue of Network Training Materials as an Informational RFC. Steve to send announcement. 13. The IESG approved publication of The Nimrod Routing Architecture as an Informational RFC. Steve to send announcement. 14. The IESG approved publication of the following two Internet-Drafts as Proposed Standards: 1. Incremental Zone Transfer in DNS 2. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) 15. The IESG had no problem with the publication of Enhanced Trivial File Transfer Protocol (ETFTP) as an Experimental Protocol, but request that the document title be changed to: Experiments with a Simple File Transfer Protocol for Radio Links 16. The IESG has no problem with the publication of GPS-Based Addressing and Routing as an Experimental Protocol. 17. The IESG decided to ask that Ascend Tunnel Management Protocol - ATMP not be published as this time as the will invite the author to submit his document to the PPPEXT working Group. 18. The IESG felt that A Clarification of STATUS , along with the latest set of documents submitted by Dave Perkins (one of which was an update to the STATUS submission), should not be published, but reviewed at the SMI BOF to be held during the Montreal IETF meeting. 19. The set of documents submitted by Dan Bernstein were discussed, and the following responses defined: a. draft-bernstein-eplf-00.txt: do not publish. Author will be invited to participate in a new FTP Working Group. If author declines the invitation, the IESG will request the following note be added: This extension is certainly "legal" as an output format for LIST. However, it breaks compatibility with existing (UNIX) listings, is not negotiable or identifiable, and does not address the question of internationalization, which is another pressing need in FTP. b. draft-bernstein-hcmssc-00.txt: request document not be published. There is an competing proposal, and the IETF should review both. c. draft-bernstein-mail-loops-war-00.txt: request document not be published, author will be invited to bring work into the IETF. If author declines, the IESG will request the following note be added: This document has not been reviewed by any IETF working group. The IESG believes that it is not a complete protection against mail loops, and that some of its analysis is insufficiently detailed to ascertain its correctness. d. draft-bernstein-netstrings-00.txt: no problem with publication as an Informational document. e. draft-bernstein-nrudt-00.txt: do not publish. Plan is to invite author to submit to the RECEIPT WG. If the author declines the invitation, the IESG will request the following note be added: This document duplicates work presently being done in the IETF RECEIPT working group. The IESG believes that the format described here is insufficient for the purpose; in particular, its response format is not machine parsable. f. draft-bernstein-pirp-00.txt: No problem with publishing as an Informational Document (though some wondered who would consider implementing), but the IESG will request the following note be added: This document has not been reviewed in the IETF, nor is it a product of any IETF working group. g. draft-bernstein-qsbmf-00.txt: No problem with publication as an Informational Document, but the IESG will request the following note be added: This protocol defined in this document duplicates functionality of RFC 1892-1894, but is incompatible with those RFCs, and does not give a machine parsable format for error messages. Implementation will require that users and UAs be able to parse multiple new response formats, which will harm interoperability. 20. The IESG had no problem with the publication of HP Patents as an Informational document. 21. The IESG felt that IP Clustering for Load Balancing and Fault Resilience should not be published as an RFC, as the author would be invited to hold a BOF in the Routing Area to determine the level of interest in forming a Working Group. 22. Steve reported on a phone conversation with John Klensin who had noted that a number of WGs either do not announce (via the charter) the location of WG Email archives, or have invalid (i.e. old) locations. Steve mentioned that John said he'd be sending a list of "non-existent" archives at some point in the future. Steve pointed out that the archives take on new importance with the acceptance of the Poised95 documents as those archives are declared to be part of the official record (so they better exist and be accessible). An inconsiderate, il-timed suggestion was made that Steve check them all out. His response was lost due to loud interference on the line (which someone suggested sounded like paper being crushed right next to the phone - though no one knew who would use such a cowardly technique. 23. A discussion on the topic of how to handle/process individual submissions was attempted, but as the teleconference had already exceeded the time allotment, and after Steve pointed out there was only ONE non-WG document that might be on next week's agenda, the discussion was deferred.