RFC 2031

IETF-ISOC relationship ✨

okay bestie, this one is an Informational RFC 🎀 by E. Huizer from SURFnet ExpertiseCentrum bv, dated October 1996. It's part of the Network Working Group series, and it's Request for Comments: 2031. The title block has no "obsoletes" or "updates" line, so it doesn't replace or update anything listed there 💅.

---

Status of this Memo 🌸

this memo gives info to the Internet community 🫶. it does not specify an Internet standard of any kind, and distribution of it is unlimited ✨.

Abstract 🦋

this memo summarises the issues on IETF-ISOC relationships, as they've been discussed by the Poised Working Group. the point is to gauge consensus on these issues, and to allow further discussion where needed 💜.

Introduction 🧚

okay so the Internet Engineering Task Force (IETF) is the body that handles the development and maintenance of Internet Standards 👑. traditionally it's a volunteer org, and the driving force is dedicated, high quality engineers from all over the world 🌈. in working groups they swap ideas and experience, and through discussion (by e-mail and face to face) they go for rough consensus 💅. then they build running code to test the consensus and evolve it into an Internet Standard 🔥.

the Internet grew, so the IETF grew too 😭. more and more people, organizations and companies rely on Internet Standards, and the responsibility and the number of participants forced the IETF to structure its processes more and more. non technical stuff (legal issues, liaison issues etc.) became an undesirable but seemingly unavoidable part of the IETF organization 💀. to deal with this, the IETF set up the Poised95 working group 🍓. the WG is trying to structure and document the IETF processes so that the engineers keep maximum flexibility and freedom, so the IETF can keep working the way it's always been most successful, and honour the IETF credo: "Rough consensus and running code" ⭐.

one of the more obvious recommendations from the Poised WG was to move all non technical issues that can be moved safely to another related organization 🎀. the Poised WG thinks the Internet Society (ISOC) is the obvious choice, and a straw poll at the open plenary session of the IETF in december 1995 in Dallas clearly confirmed this notion 🙈.

but since this issue is crucial to how the IETF works as a whole, it needs a broad (rather than a rough) consensus 🔥. at the same time, the extent of the relationship between the IETF and ISOC has to be clearly indicated, so both the IETF participants and the ISOC board of trustees get a clear picture of the division of responsibilities 💖.

the details of the Poised WG recommendations on the IETF-ISOC relationships can be found in the right 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

this document summarises the Poised WG recommendations to gauge consensus 🌈. it doesn't have, and isn't meant to get, a formal status 🫶. the current and upcoming working documents of the Poised WG will become the formal documents, and anyone who wants the nitty gritty details is sent to those working docs 🧚.

Main boundary condition 👑

the IETF stays responsible for the development and quality of the Internet Standards ✨. ISOC helps the IETF by facilitating legal and organizational issues, as described below. apart from the roles described below, the IETF and ISOC acknowledge that 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 the IETF community finds acceptable, and that gives all IETF participants an equal chance to be a candidate for a position in either body 🎀. for ISOC, the Board of Trustees should be elected by the ISOC individual membership, where all individual members have an equal vote and an equal opportunity to stand as a candidate for a position on the Board of Trustees 🌸.

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 process 💜.

The legal umbrella ☂️

to avoid the IETF having to build its own legal structure to protect the standards and the standards process, ISOC should provide a legal umbrella 🫶. the legal umbrella will at least cover:

• legal insurance for all IETF officers (IAB, IESG, Nomcom and WG chairs);
• 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 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 💀

⚠️ this part is serious, so read it carefully. by involving ISOC in specific parts of the Standards process, the IETF no longer has absolute control 😭. it can be argued that this is a breach of security. so it's necessary to make sure ISOC's 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're summarised in this document 🙈.

there are three alternatives:

• do nothing and ignore the increasing responsibility and growth; the risk here is that the IETF either becomes insignificant, or gets suffocated by US law suits 💀.
• 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 😩.
• the IETF finds another organization than ISOC to take on the role described above. but why would another organization be better than ISOC? 🤔

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

Acknowledgement and disclaimer 🎀

the author is chair of the Poised 95 WG 💅. the author tried to summarise the e-mail and face to face discussions in the WG 🫶. all the good ideas in this paper are the result of the WG, and all the mistakes and errors are probably due to the author, or to 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
E-mail: Erik.Huizer@sec.nl