idnits 2.17.1 draft-ietf-poised95-isoc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Februari 1996) is 10353 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Erik Huizer 2 Network Working Group SURFnet ExpertiseCentrum bv 3 Februari 1996 5 IETF-ISOC relationship 6 8 Status 9 ------ 10 Distribution of this memo is unlimited. 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 This Internet-draft expires on August 15th 1996 30 Abstract 31 -------- 33 This memo summarises the isues on IETF - ISOC relationships as the have 34 been discussed by the Poised Working Group. The purpose of the document 35 is to gauge consensus on these issues. And to allow further discussions 36 where necessary. 38 Introduction 39 ------------ 40 The Internet Engineering Task Force (IETF) is the body that is 41 responsible for the development and maintenance of the Internet 42 Standards. Traditionally the IETF is a volunteer organization. The 43 driving force is dedicated high quality engineers from all over the 44 world. In a structure of working groups these engineers exchange ideas 45 and experience, and through discussion (both by e-mail and face to 46 face) they strive to get rough consensus. The engineers then work on 47 building running code to put the consensus to the test and evolve it 48 into an Internet Standard. 50 The growth of the Internet has also led to a growth of the IETF. More 51 and more people, organizations and companies rely on Internet 52 Standards. The growth of responsibility as well as amount of 53 participants has forced the IETF to more and more structure its 54 pocesses. Non technical issues, such as legal issues, liaison issues 55 the IETF organization. To addres these issues the IETF established the 56 Poised95 working group. The working group is now trying to structure 57 and document the IETF processes in such a way as to keep the maximum 58 flexibility and freedom for the engineers in the IETF to work in the 59 way the IETF has always been most successfull, and to honor the IETF 60 credo: "Rough consensus and running code". 62 One of the more obvious recommendations that came out of the Poised WG 63 was to move all non technical issues that can be moved safely, to 64 another related organization. The Poised WG finds that the Internet 65 Society (ISOC) is the obvious choice for this task. A straw poll at the 66 open plenary session of the IETF in december 1995 in Dallas clearly 67 confirmed this notion. 69 However, since this is an issue that is crucial to the functioning of 70 the IETF as a whole it is necessary to get a broad (rather than a 71 rough) consensus on this issue. At the same time it is necessary to 72 clearly indicate the extend of the relationship between the IETF and 73 ISOC. So both the IETF participants and the ISOC board of trustees get 74 a clear picture on the division of responsibilities. 76 The details of the Poised WG recommendations on the IETF - ISOC 77 relationships can be found in the appropriate places in a series of 78 Poised documents in progress: 79 - The IETF Standards Process 80 - The IETF organizational structure 81 - The IETF charter 82 - The Nomcom procedures 83 - The Appeals procedures 85 The current document is meant to summarise the Poised WG recommendations 86 in order to gauge the consensus. This document does not have, and is 87 not intended to get, a formal status. The current and upcoming working 88 documents of the Poised WG will become the formal documents. Readers 89 who are interested in the nitty gritty details are referred to these 90 working documents of the Poised WG. 92 Main boundary condition 93 ----------------------- 94 The IETF remains responsible for the development and quality of the 95 Internet Standards. The ISOC will aid the IETF by facilitating legal 96 and organizational issues as described below. Apart from the roles 97 described below, the IETF and ISOC acknowledge that the ISOC has no 98 influence whatsoever on the Internet Standards process, the Internet 99 Standards or their technical content. 101 All subgroups in the IETF and ISOC that have an official role in the 102 standards process should be either: 103 - open to anyone (like Working Groups); or 104 - have a well documented restricted membership in which the voting 105 members are elected or nominated through an open process. 107 The latter means that within the IETF the IAB and the IESG need to be 108 formed through a nomination process that is acceptable to the IETF 109 community and that gives all IETF participants an equal chance to be 110 candidate for a position in either of these bodies. For the ISOC this 111 individual membership, where all individual members have an equal vote 112 and all individual members have an equal opportunity to stand as a 113 candidate for a position on the Board of Trustees. 115 ISOC will, like the IETF use public discussion and consensus building 116 processes when it wants to develop new policies or regulations that may 117 influence the role of ISOC in the Internet or the Internet Technical 118 work. ISOC will always put work related to Internet standards, 119 Internet technical issues or Internet operations up for discussion in 120 the IETF through the IETF Internet-drafts publication process. 122 The legal umbrella 123 ------------------ 124 To avoid the fact that the IETF has to construct its own legal structure 125 to protect the standards and the standards process, ISOC should provide 126 a legal umbrella. The legal umbrella should cover: 127 - legal insurance for all IETF officers (IAB, IESG, Nomcom and WG 128 chairs); 129 - legal protection of the RFC series of documents; In such a way that 130 these documents can be freely (i.e. no restrictions financially or 131 otherwise) distributed, copied etc. but cannot be altered or misused. 132 And that the right to change the document lies with the IETF. 133 - legal assistance in case of Intellectual property rights disputes over 134 Internet Standards or parts thereof. 136 The standards process role 137 -------------------------- 138 ISOC will assist the standards process by 139 - appointing the nomcom chair 140 - approving IAB candidates 141 - reviewing and approving the documents that describe the standards 142 process (i.e. the formal Poised documents). 143 - acting as the last resort in the appeals process 145 Security considerations 146 ----------------------- 147 By involving ISOC into specific parts of the Standards process, the IETF 148 has no longer absolute control. It can be argued that this is a breach 149 of security. It is therefore necessary to make sure that the ISOC 150 involvement is restricted to well defined and understood parts, at well 151 defined and understood boundary conditions. The Poised WG attempts to 152 define these, and they are summarised in this document. 153 There are three alternatives: 154 - Do nothing and ignore the increasing responsibility and growth; the 155 risk here is that the IETF either becomes insignificant, or will be 156 suffocated by US law suits. - The IETF does everything itself; this 157 keeps the IETf in control, but it would distract enormously from the 158 technical work the IETF is trying to get done. 159 - The IETF finds another organization than ISOC to take on the role 160 described above. But why would another organization be better than 161 ISOC? 162 All in all a certain risk seems unavoidable, and a relationship with 163 ISOC, under the restrictions and boundary conditions as have been 164 described above, seems more like an opportunity for the IETF than like 165 Acknowledgement and disclaimer 166 ----------------------------- 167 The author is chair of the Poised 95 WG. The author has tried to 168 summarise e-mail and face to face discussions in the WG. All the good 169 ideas in this paper are the result of the WG, all the mistakes and 170 errors are probably due to the author or his lack of command of the 171 American language as well as the American legal system. 173 The author is a member of the Internet Society. 175 Author's address 176 ---------------- 177 Erik Huizer 178 SURFnet ExpertiseCentrum bv 179 P.O. Box 19115 180 3501 DC Utrecht 181 The Netherlands 182 Tel: +31 302 305 305 183 Fax: +31 302 305 329 184 E-mail: Erik.Huizer@sec.nl