INTERNET ENGINEERING STEERING GROUP (IESG) 26 May 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 --------- Chapin, Lyman / BBN Coya, Steve / CNRI Halpern, Joel / Network Systems Huitema, Christian / INRIA (IAB Liaison) Huizer, Erik / SURFnet Klensin, John / UNU Knowles, Stev / FTP Software Mankin, Allison / NRL Mockapetris, Paul / ISI O'Dell, Mike / UUNET Rekhter, Yakov / IBM (IAB Liaison) Rose, Marshall / DBC Schiller, Jeff / MIT Stewart, John / CNRI Topolcic, Claudio / BBN Regrets --------- Bradner, Scott / Harvard Reynolds, Joyce / ISI Internet Engineering Steering Group (IESG) Draft Agenda for the 26 May 1994 IESG Teleconference 1. The minutes of the 12 May IESG teleconference were approved. ACTION(Stewart): Place the minutes in the IETF "shadow directories." 2. The revisions to the POISED Working Group's charter were approved. It was noted that the progress of the group should be monitored closely -- especially for the first several goals. ACTION(Stewart): Announce the new POISED Working Group. 3. Working Group Informational Documents o The IESG approved "WAIS over Z39.50-1988" for publication as an Informational RFC. 4. RFC Editor Actions o The IESG feels that "Method for Coding Alphabetic Data Using Telephone keypad codes" needs more work before being published as an Experimental RFC. ACTION(Stewart): Send a message to the RFC Editor saying that the author intends to withdraw the document from the RFC Editor's queue. o The IESG had no objections to "Using Unicode with MIME" being published as an Experimental RFC. o The IESG had no objections to "UTF-7" being published as an Experimental RFC. 5. Management Issues o The IESG agreed that the Secretariat should allow Internet- Drafts to be announced in the name of a concluded working group if the purpose is to advance a specification through the standards track. If the Secretariat receives an Internet-Draft for a concluded working group, the IESG Secretary will check with the appropriate area directors before announcing the Internet-Draft. Note that if there is serious debate about the specification, then the working group should be formally re-activated. o The IESG agreed that documents which do not come from an | operating working group would be subject to a minimum of a four | week Last Call period (as opposed to a two week minimum in the | case of the document coming from an active working group). | o The IESG agreed to the following process for approving new working groups: - the charter agreed to by the prospective chair and the area director(s) will be sent to the IAB and IESG lists - the IAB has one week to make comments (no comments is to be interpreted as "no objections") - the IESG may approve the working group sometime after the IAB's one week comment period - the IESG approval can happen in a meeting (face-to-face or teleconference) or via ballot on e-mail o A revision of RFC1602bis is available to the IAB and IESG that incorporates all changes suggested (including the "working group creation" and "Last Call" changes requested during this teleconference). Several documents are needed describing the function of bodies such as the IANA and the RFC Editor. The hope is to get IESG closure on the document before the ISOC Board of Trustees meeting at INET in Prague 14-17 June. The IESG was concerned that it has not yet seen the lawyer's review of 1602. ACTION(Chapin): See if the IESG can see the lawyer's review of 1602. The issue of how much the IETF is a part of ISOC was brought up, and will be discussed at the next IESG teleconference. ACTION(Stewart): Put "IETF part of ISOC" on the agenda for the next teleconference. o There was concern in the IESG about some of the ATM work because it seemed that two ATM-related documents were going to be treated differently with respect to the standards-track (at issue was pointing to ATM Forum standards). The appropriate area directors resolved the issue -- both documents will be put on the standards-track. The future of the IP-ATM work is to complete the "framework" and "signaling" documents and then go dormant to "see what people do." In the meantime, the IP-ATM mailing list will be used as a forum for implementors.