INTERNET ENGINEERING STEERING GROUP (IESG) RETREAT 26-27 April 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 Chapin, Lyman / BBN Coya, Steve / CNRI Halpern, Joel / Network Systems Huizer, Erik / SURFnet Klensin, John / UNU Knowles, Stev / FTP Software Mankin, Allison / NRL Mockapetris, Paul / ISI O'Dell, Mike / UUNET Reynolds, Joyce / ISI Rose, Marshall / DBC Schiller, Jeff / MIT Stewart, John / CNRI Topolcic, Claudio / BBN 1. Sun ONC The IESG was concerned about several specific issues related to this, most of which are general problems that need to be solved: (a) Sun had spoken to too many people on the ISOC/IESG/IETF side. It was agreed that from now on, the only person allowed to talk to Sun (or other "entities" in similar situations) is the "Executive Director of the IETF Secretariat" as RFC 1602 states. (It should be noted for clarity that the ExecDir has the prerogative to ask others to be involved in the communication.) ACTION(Mockapetris): Convey the above to everyone who has been "in the loop" on the Sun negotiations. (b) The IESG was concerned about ISOC preparing a letter and discussing it with Sun people without including the IESG. (c) The IESG agreed that no guarantees should be made to Sun that ONC will, in fact, be standardized. The IESG must be accountable to Sun in fulfilling its part of the bargain (completing the working group charter), but one acceptable result of the working group should be that the protocol isn't suitable for standardization. (d) In order for IETF work on ONC to be fruitful, the IETF must have *exclusive* change control so that nobody else (including Sun) can develop competing technology. (e) It seemed reasonable to the IESG for Sun to establish a time-limit, and if after that time-limit the IETF has not completed its part of the bargain, Sun should be able to revoke IETF's rights. (f) Sun's removal of NFS from the deal is a serious issue. ACTION(Schiller): Make a list of the items that the IESG feels it needs in an agreement with Sun. ACTION(Rose): Use Schiller's list to edit the letter, and circulate to the IESG. The IESG should comment on this letter by Friday 6 May. ACTION(Coya): Once the IESG is happy with Rose's letter, get ISOC counsel to review the letter, let the IESG see any changes, and then send it to Sun. 2. Liability ISOC counsel's comments on the Internet Standards Process document had mostly to do with clarity of language. One request for clarity was made in the section that describes the appeals process: it needs to be explicit about what the top of the appeals hierarchy is. A substantive suggestion was that the description of the RFC Editor's position and its appointment needs to be explained. The IESG wants to make sure that the liability coverage goes down to the level of the working group chair, since the chair makes many decisions that effect the work that the working group produces. Apparently the Board of Trustees agrees with this view. ACTION(Bradner): Communicate to the ISOC Trustees that the IESG feels that this should be done as soon as possible. ACTION(Mockapetris): Communicate to all people involved with the standards process (ISOC, IAB, POISED, etc.) to make sure that everyone is synchronized. 3. Prototype Because of the lack of a clear line between Experimental and Prototype, and the complete lack of use of Prototype, Prototype status will be removed from the next version of the Internet Standards Process document. ACTION(Mockapetris): See that Prototype is removed from the next version of the Internet Standards Process document. 4. OSI Moratorium The moratorium will be lifted. The announcement must be worded carefully so that no one will misinterpret the action as having anything to do with IPng. ACTION(Stewart): Send Rose (1) the text of the announcement of the moratorium, and (2) Bradner's proposed wording announcing the end of the moratorium. ACTION(Rose): Draft an announcement of the end of the moratorium and send to the IESG list. 5. SMTP Extensions Robert Ullman replied to the SMTP Extensions Last Call with an objection to their moving to Draft Standard for the following reasons: (a) The specifications are incompetent and introduce failure modes that don't exist now; (b) The working group summarily rejected an alternative proposal; and (c) The working group ignored experience gained by commercial vendors of e-mail--related products. Halpern had an e-mail exchange with Ullman, but was still not certain of the grounds of Ullman's complaints. It is possible that the only implementations that are having a problem with new failure modes are those that are non- conformant. Unless he was referring to "just send 8 bits" (which is inadequate), no one knew about an "alternative proposal." ACTION(Huizer): Draft a response to Ullman's complaints to ask for clarification, and send to the IESG list. 6. One Area Director per Working Group ACTION(Stewart): Send a list of working groups to each set of co-area directors to find out which area director is responsible for which working group. 7. OSF Mockapetris called Rich Salz at OSF to "start afresh," and he said they would get back to him, but they have not done so yet. 8. Security Most of the discussion centered around licensing of RSA technology. The original DNS security work was meant primarily to "make DNS secure," but the major thrust now is to use DNS for key management. There are non-trivial licensing differences between applying RSA to "secure DNS" and applying it to "general key management." The IESG agreed that the best result would be a statement from RSA that permitted the use of RSA technology with DNS for key management in the Internet (as opposed to a specific agreement with the Internet Society). ACTION(Schiller): Work with Coya about talking to RSA about the above licensing issues. 9. Professional Behavior The IESG agreed that it is not acceptable for an IETF participant to behave in such a way the s/he turns others away, even if the misbehaving individual is an important contributor. 10. Router/Host Requirements The IESG agreed that the Router and Host Requirements documents should both be better maintained so that other groups don't create incompatible "profiles" of Internet standards (e.g., MIL-STD). The existence of the Router Requirements Working Group solves the first problem, but the second one needs attention. Everything at the Transport layer and below in the Host Requirements will not be dealt with until after the IPng decision has been made. The IESG felt that it would not be appropriate to have *one* working group deal with *all* of the remaining pieces of Host Requirements. ACTION(Huizer,Klensin): Review the current Host Requirements document (RFC 1123) and create the appropriate working groups to work on the various sections of a new version. 11. IETF Charter The Chair of the POISED Working Group has noted that the POISED effort cannot complete its charter unless there is a charter for the IETF. ACTION(Mockapetris): Draft an IETF charter and send it to the IESG list for review. 12. IESG Organization There are several open questions here: (a) Are IESG members at-large or area specific (is the IESG made up of too many specialists, and not enough generalists); (b) How are IESG slots created/organized; (c) The IESG has traditionally made itself larger; (d) How many area directors should there be per area; (e) There is a double-standard for candidates publicly announcing their candidacy (depending on whether or not they are already sitting on the IAB/IESG); It was noted that these issues are within the purview of the POISED effort, so it isn't very fruitful for the IESG to discuss them. It was also noted, however, that since the sitting IESG will be authoring the first draft of the IESG/IETF charter and giving it to the POISED group for review, the charter should describe things the way the sitting IESG wants them. 13. Integrated Information Architecture Area A proposal for this area came out of the discussion on "one area director per area." The proposal was to move some working groups from the Applications and User Services Areas into IIA, but keep the inter-area coordination. The advantages of creating such an area are that it would make the work more visible, and it would identify more clearly who is responsible for managing II-type work in the IETF. The disadvantages of the proposal have to do with the management of the working groups which would go to IIA (e.g., keeping them focused), the effect on the Applications Area, and the timing relative to the October IAB retreat on this very issue. The issue was tabled until after the IAB retreat. 14. Coordination of II Work It was noted that several different organizations are doing work on, for example, security in the WWW area. The IESG felt that even if these organizations didn't work within the IETF, it would be good *for the community* if the work were coordinated so that incompatible solutions don't get created. ACTION(Huizer,Klensin,Reynolds): Discuss the best way for the IESG to get the type of work discussed above coordinated. If the result involves talking to people at, for example, NCSA, then Huizer et. al. should make sure that there is a primary contact (i.e., Vint Cerf has already spoken to someone at NCSA; if Mockapetris is asked to talk to them as well, then Cerf should be "de-asked"). 15. Patent Problem with PPP Compression A PPP Working Group participant has claimed that Motorola has two patents that apply to the PPP Compression Control Protocol. According to RFC 1602, the document cannot enter the standards track until the patent issue is resolved. ACTION(Coya): Work with Fred Baker and talk to Motorola. Find out what their wishes are, and let them know that the Internet standards process won't allow PPP-CCP on the standards track unless they make the technology available on "reasonable and non-discriminatory" terms. 16. IETF/ISOC Relationship Although ISOC provides the "legal cover" for the standards process, the standards process itself explicitly says that the official contact point for standards-related issues is "the Executive Director of the IETF Secretariat." It is necessary that *all* parties, including the ISOC Trustees, understand this and *not* negotiate directly with any organizations. 17. IPng The IPng effort is still on schedule for announcing a decision in Toronto.