Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group E. Huizer Request for Comments: 2031 SURFnet ExpertiseCentrum bv Category: Informational October 1996

                       IETF-ISOC relationship

Status of this Memo

 This memo provides information for the Internet community.  This memo
 does not specify an Internet standard of any kind.  Distribution of
 this memo is unlimited.


 This memo summarises the issues on IETF - ISOC relationships as the
 have been discussed by the Poised Working Group. The purpose of the
 document is to gauge consensus on these issues. And to allow further
 discussions where necessary.


 The Internet Engineering Task Force (IETF) is the body that is
 responsible for the development and maintenance of the Internet
 Standards. Traditionally the IETF is a volunteer organization. The
 driving force is dedicated high quality engineers from all over the
 world. In a structure of working groups these engineers exchange
 ideas and experience, and through discussion (both by e-mail and face
 to face) they strive to get rough consensus. The engineers then work
 on building running code to put the consensus to the test and evolve
 it into an Internet Standard.
 The growth of the Internet has also led to a growth of the IETF. More
 and more people, organizations and companies rely on Internet
 Standards. The growth of responsibility as well as amount of
 participants has forced the IETF to more and more structure its
 processes. Non technical issues, such as legal issues, liaison issues
 etc., have become an undesirable but a seemingly unavoidable part of
 the IETF organization. To address these issues the IETF established
 the Poised95 working group. The working group is now trying to
 structure and document the IETF processes in such a way as to keep
 the maximum flexibility and freedom for the engineers in the IETF to
 work in the way the IETF has always been most successful, and to
 honour the IETF credo: "Rough consensus and running code".
 One of the more obvious recommendations that came out of the Poised
 WG was to move all non technical issues that can be moved safely, to
 another related organization. The Poised WG finds that the Internet

Huizer Informational [Page 1] RFC 2031 IETF-ISOC Relationship October 1996

 Society (ISOC) is the obvious choice for this task. A straw poll at
 the open plenary session of the IETF in december 1995 in Dallas
 clearly confirmed this notion.
 However, since this is an issue that is crucial to the functioning of
 the IETF as a whole it is necessary to get a broad (rather than a
 rough) consensus on this issue. At the same time it is necessary to
 clearly indicate the extend of the relationship between the IETF and
 ISOC. So both the IETF participants and the ISOC board of trustees
 get a clear picture on the division of responsibilities.
 The details of the Poised WG recommendations on the IETF - ISOC
 relationships can be found in the appropriate places in a series of
 Poised documents in progress: - The IETF Standards Process - The IETF
 organizational structure - The IETF charter - The Nomcom procedures -
 The Appeals procedures
 The current document is meant to summarize the Poised WG
 recommendations in order to gauge the consensus. This document does
 not have, and is not intended to get, a formal status. The current
 and upcoming working documents of the Poised WG will become the
 formal documents. Readers who are interested in the nitty gritty
 details are referred to these working documents of the Poised WG.

Main boundary condition

 The IETF remains responsible for the development and quality of the
 Internet Standards. The ISOC will aid the IETF by facilitating legal
 and organizational issues as described below. Apart from the roles
 described below, the IETF and ISOC acknowledge that the ISOC has no
 influence whatsoever on the Internet Standards process, the Internet
 Standards or their technical content.
 All subgroups in the IETF and ISOC that have an official role in the
 standards process should be either:
 - open to anyone (like Working Groups); or
 - have a well documented restricted membership in which the
   voting members are elected or nominated through an open process.
 The latter means that within the IETF the IAB and the IESG need to be
 formed through a nomination process that is acceptable to the IETF
 community and that gives all IETF participants an equal chance to be
 candidate for a position in either of these bodies. For the ISOC this
 means that the Board of Trustees should be elected by the ISOC
 individual membership, where all individual members have an equal
 vote and all individual members have an equal opportunity to stand as
 a candidate for a position on the Board of Trustees.

Huizer Informational [Page 2] RFC 2031 IETF-ISOC Relationship October 1996

 ISOC will, like the IETF use public discussion and consensus building
 processes when it wants to develop new policies or regulations that
 may influence the role of ISOC in the Internet or the Internet
 Technical work. ISOC will always put work related to Internet
 standards, Internet technical issues or Internet operations up for
 discussion in the IETF through the IETF Internet-drafts publication

The legal umbrella

 To avoid the fact that the IETF has to construct its own legal
 structure to protect the standards and the standards process, ISOC
 should provide a legal umbrella. The legal umbrella will at least
 - legal insurance for all IETF officers (IAB, IESG, Nomcom and WG
 - legal protection of the RFC series of documents; In such a way
   that these documents can be freely (i.e. no restrictions
   financially or otherwise) distributed, copied etc. but cannot
   be altered or misused. And that the right to change the document
   lies with the IETF.
 - legal protection in case of Intellectual property rights disputes
   over Internet Standards or parts thereof.

The standards process role

 ISOC will assist the standards process by
   - appointing the nomcom chair
   - approving IAB candidates
   - reviewing and approving the documents that describe the standards
     process (i.e. the formal Poised documents).
   - acting as the last resort in the appeals process

Security considerations

 By involving ISOC into specific parts of the Standards process, the
 IETF has no longer absolute control. It can be argued that this is a
 breach of security. It is therefore necessary to make sure that the
 ISOC involvement is restricted to well defined and understood parts,
 at well defined and understood boundary conditions. The Poised WG
 attempts to define these, and they are summarised in this document.
 There are three alternatives:
  1. Do nothing and ignore the increasing responsibility and growth; the

risk here is that the IETF either becomes insignificant, or will be

   suffocated by US law suits.

Huizer Informational [Page 3] RFC 2031 IETF-ISOC Relationship October 1996

  1. The IETF does everything itself; this keeps the IETf in control,

but it would distract enormously from the technical work the IETF

   is trying to get done.
  1. The IETF finds another organization than ISOC to take on the role

described above. But why would another organization be better than

 All in all a certain risk seems unavoidable, and a relationship with
 ISOC, under the restrictions and boundary conditions as have been
 described above, seems more like an opportunity for the IETF than
 like a risk.

Acknowledgement and disclaimer

 The author is chair of the Poised 95 WG. The author has tried to
 summarise e-mail and face to face discussions in the WG. All the good
 ideas in this paper are the result of the WG, all the mistakes and
 errors are probably due to the author or his lack of command of the
 American language as well as the American legal system.
 The author is a member of the Internet Society.

Author's Address

 Erik Huizer
 SURFnet ExpertiseCentrum bv
 P.O. Box 19115
 3501 DC  Utrecht
 The Netherlands
 Tel: +31 302 305 305
 Fax: +31 302 305 329

Huizer Informational [Page 4]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2031.txt · Last modified: 1996/10/25 23:00 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki