Skip to main content

Minutes interim-1994-iesg-07 1994-04-26 15:30
minutes-interim-1994-iesg-07-199404261530-00

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 1994-04-26 15:30
Title Minutes interim-1994-iesg-07 1994-04-26 15:30
State (None)
Other versions plain text
Last updated 2024-02-23

minutes-interim-1994-iesg-07-199404261530-00
											
Minutes of the IESG Teleconferences

    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
    <iesg-secretary@cnri.reston.va.us>.

    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.