idnits 2.17.1 draft-ietf-poisson-appts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 1999) is 9201 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) ** Obsolete normative reference: RFC 2282 (Obsoleted by RFC 2727) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF B. Carpenter, IBM 2 Internet Draft 3 February 1999 5 Procedures for IETF appointments to the Protocol Supporting 6 Organization 8 draft-ietf-poisson-appts-01.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This memo describes the procedures by which the IETF appoints 38 representatives to the various bodies of the Internet 39 Corporation for Assigned Names and Numbers (ICANN) and to 40 the Protocol Supporting Organization (PSO) related to ICANN. 42 1. Introduction 44 The Internet Corporation for Assigned Names and Numbers (ICANN) 45 depends for some of its activities on the Protocol Supporting 46 Organization (PSO). The PSO is required to appoint three members 47 of the ICANN Board of Directors, and to appoint a Protocol Council 48 to give appropriate advice to ICANN. 50 ^L 51 As a member of the PSO, the Internet Engineering Task Force (IETF) 52 is required to 54 - appoint up to three members to the PSO Board 55 - nominate members to the ICANN Board 56 - nominate members to the PSO/ICANN Protocol Council 58 This memo defines the IETF procedures for these appointments. 60 2. Members of PSO Board 62 The PSO Board has limited duties, mainly oversight of appointments 63 to the ICANN Board and Protocol Council based on nominations from 64 the PSO members, and financial oversight of payments from PSO 65 members to ICANN. For this reason an elaborate procedure 66 for appointing the PSO Board members is unnecessary, as long as 67 they are individuals answerable to the IETF under [RFC 2282]. 69 The IETF members of the PSO Board shall be the current IETF Chair, 70 the current Chair of the Internet Architecture Board (IAB), and 71 one other current member of the IAB or of the Internet Engineering 72 Steering Group (IESG), appointed by consensus of the IAB and IESG. 73 In the event that the IETF is required to appoint only two 74 members of the PSO Board, these shall be the IETF Chair and 75 IAB Chair. In the event that the IETF is required to appoint 76 only one member of the PSO Board, the IETF Chair and the IAB 77 Chair shall decide which one of them it shall be. 79 3. Members of ICANN Board of Directors 81 These are important policy-making positions and the 82 nominees should be selected by a specific open process. 84 Each year, the IETF Nominating Committee shall nominate 85 the required number of persons to terms on the ICANN 86 Board, using as much as possible the procedures defined 87 in [RFC 2282]. 89 The number of persons and their terms will be defined 90 by the by laws of ICANN and the PSO. However, in normal 91 circumstances the nominations shall take place according 92 to the timetable established by [RFC 2282], in anticipation 93 of known vacancies on the ICANN Board. 95 The nominees are subject to a subsequent election by the 96 members of the PSO as defined by its by laws. 98 IETF nominees to the ICANN Board are subject to the recall 99 procedures defined in [RFC 2282]. 101 ^L 103 4. Members of the Protocol Council 105 The Protocol Council is intended to act as a technical 106 advisory body for ICANN and as such it is necessary and sufficient 107 for the IETF nominees to be recognised as experts by the IETF 108 and answerable to the IETF under [RFC 2282]. 110 The IETF nominees for the Protocol Council shall be the thirteen 111 current voting members of the IAB. If additional nominees 112 are necessary, the IAB shall choose them from a pool 113 consisting of all current IESG members and all current IETF 114 working group chairs. Note that working group chairs are 115 answerable to the IESG. 117 The nominees are subject to a subsequent election by the 118 members of the PSO as defined by its by laws. 120 5. Security considerations 122 This memo does not impact the technical security of the Internet. 124 Acknowledgements 126 Comments by members of the IETF POISSON working group are 127 gratefully acknowledged. 129 References 131 [RFC 2282] IAB and IESG Selection, Confirmation, and Recall Process: 132 Operation of the Nominating and Recall Committees. J. Galvin. 133 February 1998. (Also BCP0010) 135 Author's Address 137 Brian E. Carpenter 138 Internet Division 139 IBM United Kingdom Laboratories 140 MP 185, Hursley Park 141 Winchester, Hampshire S021 2JN, UK 143 Email: brian@hursley.ibm.com 145 ^L 147 Full Copyright Statement 149 Copyright (C) The Internet Society (1999). All Rights Reserved. 151 This document and translations of it may be copied and furnished to 152 others, and derivative works that comment on or otherwise explain it 153 or assist in its implementation may be prepared, copied, published 154 and distributed, in whole or in part, without restriction of any 155 kind, provided that the above copyright notice and this paragraph are 156 included on all such copies and derivative works. However, this 157 document itself may not be modified in any way, such as by removing 158 the copyright notice or references to the Internet Society or other 159 Internet organizations, except as needed for the purpose of 160 developing Internet standards in which case the procedures for 161 copyrights defined in the Internet Standards process must be 162 followed, or as required to translate it into languages other than 163 English. 165 The limited permissions granted above are perpetual and will not be 166 revoked by the Internet Society or its successors or assigns. 168 This document and the information contained herein is provided on an 169 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 170 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 171 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 172 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 173 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 175 ^L