INTERNET ENGINEERING STEERING GROUP (IESG) August 13, 1998 Reported by: Steve Coya, IETF Executive Director ATTENDEES --------- Alvestrand, Harald / Maxware Bradner, Scott / Harvard Carpenter, Brian / IBM (IAB Liaison) Coltun, Rob / Fore Systems Coya, Steve / CNRI Leech, Marcus / Nortel Marine, April / Raytheon STX Moore, Keith / U of Tennessee Paxson, Vern / Lawrence Berkeley Laboratory Schiller, Jeff / MIT Wijnen, Bert / IBM Regrets ------- Baker, Fred / Cisco Systems Burgan, Jeff / @home Faltstrom, Patrik / Swipnet Narten, Thomas / IBM Klensin, John / MCI (IAB Liaison) Reynolds, Joyce K. / ISI (IANA Liaison) Minutes ------- 1. The minutes of the July 30 teleconference were approved. Steve to place in public archives. 2. The IESG approved publication of Inverse Address Resolution Protocol as a Draft Standard. Steve to send announcement. 3. The IESG approved reclassifying the following set of Telnet Option RFCs to Historic: RFC0652 Telnet output carriage-return disposition option RFC0653 Telnet output horizontal tabstops option RFC0654 Telnet output horizontal tab disposition option RFC0655 Telnet output formfeed disposition option RFC0656 Telnet output vertical tabstops option RFC0657 Telnet output vertical tab disposition option RFC0658 Telnet output linefeed disposition Steve to send announcement. 4. The IESG approved publication of Proposed TLA and NLA Assignment Rules as an Informational RFC. Steve to send announcement. 5. In light of the comments Harald sent to the author of Armenian Character Sets: Implementation Guide , the IESG will recommend that the existing document not be published as an updated document is anticipated. Steve to convey to RFC Editor 6. The IESG felt that The ESP Stream Transform document should be brought into the IETF for formal review, possibly to be assigned to an IETF WG. As such, the IESG believes publication would be inappropriate at this time. Steve to convey to RFC Editor. 7. The IESG believes that The ID-based Key Management System should not be published as an RFC. This document defines a key management scheme that is based on new, and largely unproven cryptographic algorithms, and that the document was written as if to be submitted to a journal. The IESG believes that is the more appropriate venue for this article. Steve to convey to RFC Editor. 8. The IESG deferred action on Building Directories from DNS: Experiences from WWWSeeker to provide more time to review. Steve was asked to dig through his aging memory cells to identify who reviewed the initial submission. Steve to request an extension from the RFC Editor. 9. The IESG deferred action on TCP Window Probe Deadloc as more review time was needed. Steve to request an extension from the RFC Editor. 10. The IESG believes that the Internet-Draft Proxy Mail Address Protocol should not be published at this time. Keith is collecting comments from a number of folks, and will send these on to the document author. Steve to notify RFC Editor. 11. The IESG had no problem with the publication of Dublin Core Metadata for Resource Discovery as an Informational RFC, but wanted Patrik's input prior to notifying the RFC Editor. Keith to track down Patrik. 12. The IESG reiterated its belief that The Coherent File Transport Protocol should not be published as the document fails to comply with the technical criteria given in Section 5 of RFC 2357, "IETF Criteria For Evaluating Reliable Multicast Transport Protocols". It does not adequately analyze or provide any supporting evidence of the protocol's scaling properties and, because of extreme vagueness in discussing the use of "ACK concentrators" to deal with NACK implosion, will very likely not scale to large numbers of receivers. There is literally no discussion of congestion control, which renders it completely inappropriate for use in the public Internet; no discussion of security considerations; and no discussion of mechanisms for confining the scope of the protocol to those limited environments where it will not cause undue damage. Steve to convey to RFC Editor. Vern will send the above to the document author. 13. Keith raised the issue of tracking/reporting more state conditions in Steve's summaries of IESGers opinions on the various documents under consideration by the IESG for status track publication (this may be one of the longest run-on sentences in IESG minutes. Examples of the above include a request to DISCUSS that does not contain the topic/reason for discusssion, or differentiating between an IESGer who request more time to review vs. one who has simply not conveyed an opinion. Steve suggested that examples of such situations be sent to him, and he will consolidate for review and discussion during one of the IESG early morning meetings at the Chicago IETF.