home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2031.txt < prev    next >
Text File  |  1996-10-24  |  9KB  |  228 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         E. Huizer
  8. Request for Comments: 2031                  SURFnet ExpertiseCentrum bv
  9. Category: Informational                                    October 1996
  10.  
  11.  
  12.                          IETF-ISOC relationship
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This memo summarises the issues on IETF - ISOC relationships as the
  23.    have been discussed by the Poised Working Group. The purpose of the
  24.    document is to gauge consensus on these issues. And to allow further
  25.    discussions where necessary.
  26.  
  27. Introduction
  28.  
  29.    The Internet Engineering Task Force (IETF) is the body that is
  30.    responsible for the development and maintenance of the Internet
  31.    Standards. Traditionally the IETF is a volunteer organization. The
  32.    driving force is dedicated high quality engineers from all over the
  33.    world. In a structure of working groups these engineers exchange
  34.    ideas and experience, and through discussion (both by e-mail and face
  35.    to face) they strive to get rough consensus. The engineers then work
  36.    on building running code to put the consensus to the test and evolve
  37.    it into an Internet Standard.
  38.  
  39.    The growth of the Internet has also led to a growth of the IETF. More
  40.    and more people, organizations and companies rely on Internet
  41.    Standards. The growth of responsibility as well as amount of
  42.    participants has forced the IETF to more and more structure its
  43.    processes. Non technical issues, such as legal issues, liaison issues
  44.    etc., have become an undesirable but a seemingly unavoidable part of
  45.    the IETF organization. To address these issues the IETF established
  46.    the Poised95 working group. The working group is now trying to
  47.    structure and document the IETF processes in such a way as to keep
  48.    the maximum flexibility and freedom for the engineers in the IETF to
  49.    work in the way the IETF has always been most successful, and to
  50.    honour the IETF credo: "Rough consensus and running code".
  51.  
  52.    One of the more obvious recommendations that came out of the Poised
  53.    WG was to move all non technical issues that can be moved safely, to
  54.    another related organization. The Poised WG finds that the Internet
  55.  
  56.  
  57.  
  58. Huizer                       Informational                      [Page 1]
  59.  
  60. RFC 2031                 IETF-ISOC Relationship             October 1996
  61.  
  62.  
  63.    Society (ISOC) is the obvious choice for this task. A straw poll at
  64.    the open plenary session of the IETF in december 1995 in Dallas
  65.    clearly confirmed this notion.
  66.  
  67.    However, since this is an issue that is crucial to the functioning of
  68.    the IETF as a whole it is necessary to get a broad (rather than a
  69.    rough) consensus on this issue. At the same time it is necessary to
  70.    clearly indicate the extend of the relationship between the IETF and
  71.    ISOC. So both the IETF participants and the ISOC board of trustees
  72.    get a clear picture on the division of responsibilities.
  73.  
  74.    The details of the Poised WG recommendations on the IETF - ISOC
  75.    relationships can be found in the appropriate places in a series of
  76.    Poised documents in progress: - The IETF Standards Process - The IETF
  77.    organizational structure - The IETF charter - The Nomcom procedures -
  78.    The Appeals procedures
  79.  
  80.    The current document is meant to summarize the Poised WG
  81.    recommendations in order to gauge the consensus. This document does
  82.    not have, and is not intended to get, a formal status. The current
  83.    and upcoming working documents of the Poised WG will become the
  84.    formal documents. Readers who are interested in the nitty gritty
  85.    details are referred to these working documents of the Poised WG.
  86.  
  87. Main boundary condition
  88.  
  89.    The IETF remains responsible for the development and quality of the
  90.    Internet Standards. The ISOC will aid the IETF by facilitating legal
  91.    and organizational issues as described below. Apart from the roles
  92.    described below, the IETF and ISOC acknowledge that the ISOC has no
  93.    influence whatsoever on the Internet Standards process, the Internet
  94.    Standards or their technical content.
  95.  
  96.    All subgroups in the IETF and ISOC that have an official role in the
  97.    standards process should be either:
  98.    - open to anyone (like Working Groups); or
  99.    - have a well documented restricted membership in which the
  100.      voting members are elected or nominated through an open process.
  101.  
  102.    The latter means that within the IETF the IAB and the IESG need to be
  103.    formed through a nomination process that is acceptable to the IETF
  104.    community and that gives all IETF participants an equal chance to be
  105.    candidate for a position in either of these bodies. For the ISOC this
  106.    means that the Board of Trustees should be elected by the ISOC
  107.    individual membership, where all individual members have an equal
  108.    vote and all individual members have an equal opportunity to stand as
  109.    a candidate for a position on the Board of Trustees.
  110.  
  111.  
  112.  
  113.  
  114. Huizer                       Informational                      [Page 2]
  115.  
  116. RFC 2031                 IETF-ISOC Relationship             October 1996
  117.  
  118.  
  119.    ISOC will, like the IETF use public discussion and consensus building
  120.    processes when it wants to develop new policies or regulations that
  121.    may influence the role of ISOC in the Internet or the Internet
  122.    Technical work. ISOC will always put work related to Internet
  123.    standards, Internet technical issues or Internet operations up for
  124.    discussion in the IETF through the IETF Internet-drafts publication
  125.    process.
  126.  
  127. The legal umbrella
  128.  
  129.    To avoid the fact that the IETF has to construct its own legal
  130.    structure to protect the standards and the standards process, ISOC
  131.    should provide a legal umbrella. The legal umbrella will at least
  132.    cover:
  133.    - legal insurance for all IETF officers (IAB, IESG, Nomcom and WG
  134.       chairs);
  135.    - legal protection of the RFC series of documents; In such a way
  136.      that these documents can be freely (i.e. no restrictions
  137.      financially or otherwise) distributed, copied etc. but cannot
  138.      be altered or misused. And that the right to change the document
  139.      lies with the IETF.
  140.    - legal protection in case of Intellectual property rights disputes
  141.      over Internet Standards or parts thereof.
  142.  
  143. The standards process role
  144.  
  145.    ISOC will assist the standards process by
  146.      - appointing the nomcom chair
  147.      - approving IAB candidates
  148.      - reviewing and approving the documents that describe the standards
  149.        process (i.e. the formal Poised documents).
  150.      - acting as the last resort in the appeals process
  151.  
  152. Security considerations
  153.  
  154.    By involving ISOC into specific parts of the Standards process, the
  155.    IETF has no longer absolute control. It can be argued that this is a
  156.    breach of security. It is therefore necessary to make sure that the
  157.    ISOC involvement is restricted to well defined and understood parts,
  158.    at well defined and understood boundary conditions. The Poised WG
  159.    attempts to define these, and they are summarised in this document.
  160.  
  161.    There are three alternatives:
  162.  
  163.    - Do nothing and ignore the increasing responsibility and growth; the
  164.      risk here is that the IETF either becomes insignificant, or will be
  165.      suffocated by US law suits.
  166.  
  167.  
  168.  
  169.  
  170. Huizer                       Informational                      [Page 3]
  171.  
  172. RFC 2031                 IETF-ISOC Relationship             October 1996
  173.  
  174.  
  175.    - The IETF does everything itself; this keeps the IETf in control,
  176.      but it would distract enormously from the technical work the IETF
  177.      is trying to get done.
  178.  
  179.    - The IETF finds another organization than ISOC to take on the role
  180.      described above. But why would another organization be better than
  181.      ISOC?
  182.  
  183.    All in all a certain risk seems unavoidable, and a relationship with
  184.    ISOC, under the restrictions and boundary conditions as have been
  185.    described above, seems more like an opportunity for the IETF than
  186.    like a risk.
  187.  
  188. Acknowledgement and disclaimer
  189.  
  190.    The author is chair of the Poised 95 WG. The author has tried to
  191.    summarise e-mail and face to face discussions in the WG. All the good
  192.    ideas in this paper are the result of the WG, all the mistakes and
  193.    errors are probably due to the author or his lack of command of the
  194.    American language as well as the American legal system.
  195.  
  196.    The author is a member of the Internet Society.
  197.  
  198. Author's Address
  199.  
  200.    Erik Huizer
  201.    SURFnet ExpertiseCentrum bv
  202.    P.O. Box 19115
  203.    3501 DC  Utrecht
  204.    The Netherlands
  205.    Tel: +31 302 305 305
  206.    Fax: +31 302 305 329
  207.    E-mail: Erik.Huizer@sec.nl
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Huizer                       Informational                      [Page 4]
  227.  
  228.