Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/iesg/iesg.94-04-26

Text File | 1994-07-06 | 11KB | 282 lines

         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
<[e-mail]>.

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.