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
<[email protected]>.

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.

You are viewing proxied material from infinitelyremote.com. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.