idnits 2.17.1 draft-ietf-poised95-ietf-orgs-00.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-25) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 210 has weird spacing: '...working group...' -- 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 (February 1996) is 10297 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) == Missing Reference: 'F' is mentioned on line 173, but not defined == Missing Reference: 'G' is mentioned on line 184, but not defined ** Obsolete normative reference: RFC 1603 (ref. 'A') (Obsoleted by RFC 2418) ** Obsolete normative reference: RFC 1602 (ref. 'B') (Obsoleted by RFC 2026) -- Possible downref: Non-RFC (?) normative reference: ref. 'C' ** Obsolete normative reference: RFC 1601 (ref. 'D') (Obsoleted by RFC 2850) -- Possible downref: Non-RFC (?) normative reference: ref. 'E' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Richard Hovey 2 Internet Draft Digital Equipment Corporation 3 Scott Bradner 4 Harvard University 5 February 1996 7 The Organizations Involved in the IETF Standards Process 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes the organizations involved in the IETF. This 32 includes descriptions of the IESG and Working Groups and the 33 relationship with the Internet Society. 35 1. Internet Standards Organizations and Roles 37 The following organizations and organizational roles are involved in 38 the Internet standards process. Contact information is contained in 39 Appendix A. 41 1.1 Internet Engineering Task Force 43 The Internet Engineering Task Force (IETF) is an open international 44 community of network designers, operators, vendors and researchers 45 concerned with the evolution of the Internet architecture and the 46 smooth operation of the Internet. It is the principal body engaged 47 in the development of new Internet Standard specifications. 49 1.2 IETF Working Groups 51 The technical work of the IETF is done in its Working Groups, which 52 are organized by topics into several Areas (e.g., routing, network 53 management, security, etc.) under the coordination of Area Directors. 54 Working Groups typically have a narrow focus and a lifetime bounded 55 by completion of a specific task. 57 IETF Working Groups display a spirit of cooperation as well as a high 58 degree of technical maturity because IETF participants recognize that 59 the greatest benefit for all members of the Internet community 60 results from cooperative development of technically superior 61 protocols and services. 63 For all purposes relevant to the Internet Standards development 64 process, membership in the IETF and its Working Groups is defined to 65 be established solely and entirely by individual participation in 66 IETF and Working Group activities. Participation in the IETF and its 67 Working Groups is by individual technical contributors rather than by 68 formal representatives of organizations. 70 Anyone with the time and interest to do so is entitled and urged to 71 participate actively in one or more IETF Working Groups and to attend 72 IETF meetings which are held three times a year. In most cases 73 active Working Group participation is possible through electronic 74 mail alone. Internet video conferencing is also being used to allow 75 for remote participation. 77 To ensure a fair and open process, a participant in the IETF and its 78 Working Groups must be able to disclose, and must disclose to the 79 Working Group chair, any current or pending intellectual property or 80 other rights which are relevant to the technical specifications under 81 development by the Working Group. Such disclosures are restricted to 82 intellectual property rights which are reasonably and personally 83 known to the participant. 85 A Working Group is managed by one or more Working Group chairs (see 86 section 1.9) and may also include editors of documents that record 87 the group's work (see section 1.10). New Working Groups are 88 established within the IETF by explicit charter. The guidelines and 89 procedures for the formation and operation of IETF working groups are 90 described in more detail in [A]. 92 1.3 IETF Secretariat 94 The administrative functions necessary to support the activities of 95 the IETF are performed by a Secretariat consisting of the IESG 96 Secretary and his or her staff. The IESG Secretary is the formal 97 point of contact for matters concerning any and all aspects of the 98 Internet standards process, and is responsible for maintaining the 99 formal public record of the Internet standards process [B]. 101 1.4 Internet Society 103 The Internet Society (ISOC) is an international organization 104 concerned with the growth and evolution of the worldwide Internet and 105 with the social, political, and technical issues that arise from its 106 use. The ISOC is an organization with individual and organizational 107 members. The ISOC is managed by a Board of Trustees elected by the 108 worldwide individual membership. 110 The ISOC exercises oversight of Internet standardization though the 111 Board of Trustees, which is responsible for ratifying the procedures 112 and rules of the Internet standards process. 114 The way in which the members of the ISOC Board of Trustees are 115 selected, and other matters concerning the operation of the Internet 116 Society, are described in the ISOC By Laws [C]. 118 1.5 Internet Engineering Steering Group 120 The Internet Engineering Steering Group (IESG) is chartered by the 121 Internet Society with responsiblty for the management of the IETF 122 technical activities. It administers the Internet Standards process 123 according to the rules and procedures defined in [B]. The IESG is 124 responsible for the actions associated with the progression of 125 technical specification along the "standards track" including the 126 initial approval of new Working Groups and the final approval of 127 specifications as Internet Standards. The IESG is composed of the 128 IETF Area Directors and the chair of the IETF, who also serves as the 129 chair of the IESG. 131 The members of the IESG are nominated by a nominations committee (the 132 Nomcom) and are approved by the IAB. See [E] for a detailed 133 description of the Nomcom procedures. Other matters concerning the 134 IESG organization and operation are described in the IESG charter 135 [does not yet exist]. 137 1.6 Internet Architecture Board 139 The Internet Architecture Board (IAB) is chartered by the Internet 140 Society to provide oversight of the architecture of the Internet and 141 its protocols. 143 The IAB approves the IETF chair and is responsible for approving 144 other IESG candidates put forward by the Nomcom. The IAB assists in 145 the IESG review of the charters of new Working Groups that are 146 proposed for the IETF. The IAB oversees the creation of Internet 147 Standards and serves as an appeal board for complaints of improper 148 execution of the standards process [B]. In general it acts as source 149 of advice to the IETF, the ISOC and the ISOC Board of Trustees 150 concerning technical, architectural, procedural, and policy matters 151 pertaining to the Internet and its enabling technologies. 153 The membership of the IAB consists of members selected by the Nomcom 154 process [A] and the IETF chair sitting as an ex-officio member. The 155 members of the IAB are approved by the ISOC Board of Trustees. Other 156 matters concerning IAB organization and operation are described in 157 the IAB charter [D]. 159 1.7 Internet Assigned Numbers Authority 161 Many protocol specifications include numbers, keywords, and other 162 parameters that must be uniquely assigned. Examples include version 163 numbers, protocol numbers, port numbers, and MIB numbers. The 164 Internet Assigned Numbers Authority (IANA) is responsible for 165 assigning the values of these protocol parameters for the Internet. 166 The IANA publishes tables of all currently assigned numbers and 167 parameters in RFCs entitled "Assigned Numbers" [E]. The IANA 168 functions as the "top of the pyramid" for DNS and Internet Address 169 assignment establishing policies for these functions. 171 The functions of the IANA are performed by one or more individuals or 172 organizations selected in accordance with the procedures defined by 173 the IANA charter [F]. 175 1.8 Request for Comments Editor 177 The RFC publication series [B] is managed by an Editor (which may in 178 practice be one or more individuals) responsible both for the 179 mechanics of RFC publication and for upholding the traditionally high 180 technical and editorial standards of the RFC series. 182 The functions of the RFC Editor are performed by one or more 183 individuals or organizations selected in accordance with the 184 procedures defined by the RFC Editor charter [G]. 186 1.9 Working Group Chair 188 Each IETF Working Group is headed by a chair (or by co-chairs if a WG 189 so decides) with the responsibility for directing the group's 190 activities, presiding over the group's meetings, and ensuring that 191 the commitments of the group with respect to its role in the Internet 192 standards process are met. In particular, the WG chair is the formal 193 point of contact between the WG and the IESG, via the Area Director 194 of the area to which the WG is assigned. 196 The proposed chair(s) of a new Working Group is (are) identified in 197 the proposed WG charter when it is submitted to the IESG for review. 198 The IESG, with advice from the IAB, is responsible for approving the 199 appointment of the WG chair(s) in conjunction with its approval of 200 the proposed WG charter. The IESG may remove a WG chair if and when 201 the IESG determines that the Working Group would benefit 202 significantly from the appointment of a different chair (or chairs). 204 1.10 Document Editor Most IETF Working Groups focus their efforts on a 205 document, or set of documents, that capture the results of the 206 group's work. A Working Group generally designates a person or 207 persons to serve as the Editor for a particular document. The 208 Document Editor is responsible for ensuring that the contents of the 209 document accurately reflect the decisions that have been made by the 210 working group. 212 As a general practice, the Working Group Chair and Document Editor 213 positions are filled by different individuals to help ensure that the 214 resulting documents accurately reflect the consensus of the Working 215 Group and that all processes are followed. 217 1.11 Internet Research Task Force The Internet Research Task Force 218 (IRTF) is not directly involved in the Internet standards process. 219 It investigates topics considered to be too uncertain, too advanced, 220 or insufficiently well-understood to be the subject of Internet 221 standardization. When an IRTF activity generates a specification 222 that is sufficiently stable to be considered for Internet 223 standardization, the specification is processed through the IETF 224 using the rules in this document. 226 The IRTF is composed of individual Working Groups, but its structure 227 and mode of operation is much less formal than that of the IETF, due 228 in part to the fact that it does not participate directly in the 229 Internet standards process. The organization and program of work of 230 the IRTF is overseen by the Internet Research Steering Group (IRSG), 231 which consists of the chairs of the IRTF Working Groups. 233 1.12. Nominations Committee (Nomcom) 235 The members of the IESG and IAB are nominated by a nominations 236 committee (the Nomcom) and are approved by the IAB and ISOC Board of 237 Trustees respectively. See [E] for a detailed description of the 238 Nomcom procedures. 240 2. The IETF Standards Process 242 The process used by the Internet community for the standardization of 243 protocols and procedures are described in [B]. That document defines 244 the stages in the standardization process, the requirements for 245 moving a document between stages and the types of documents used 246 during this process. It also addresses the intellectual property 247 rights and copyright issues associated with the standards process. 249 3. Security Considerations 251 Security is not addressed in this memo 253 4. References 255 [A] Huizer, E., D. Crocker, "IETF Working Group Guidelines and 256 Procedures", RFC 1603, March 1994 258 [B] Bradner, S. (Ed.), "The Internet Standards Process -- Revision 259 3", RFC 1602bis (in prep) 261 [C] ISOC By Laws 263 [D] Huitema, C., and IAB, "Charter of the Internet Architecture Board 264 (IAB)", RFC1601, March 1994 266 [E] nomcom RFC - in prep 268 5. Author's Addresses: 270 Richard Hovey 271 Digital Equipment Corporation 272 1401 H Street NW 273 Washington DC 20005 275 email: hovey@wnpv01.enet.dec.com 276 phone: +1 202 383 5615 278 Scott Bradner 279 Harvard University 280 1350 Mass Ave. Rm 813 281 Cambridge MA 02138 283 email: sob@harvard.edu 284 phone: +1 617 495 3864 286 Appendix A - contact information 287 IETF - ietf@cnri.reston.va.us 289 IESG - iesg@cnri.reston.va.us 291 IAB - iab@isi.edu