idnits 2.17.1 draft-ietf-poisson-pso-appointments-00.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: ---------------------------------------------------------------------------- ** 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? 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. ** The abstract seems to contain references ([RFC2282]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC2282, but the header doesn't have an 'Updates:' line to match this. 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 (May 21, 2001) is 8375 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2691 ** Obsolete normative reference: RFC 2282 (Obsoleted by RFC 2727) Summary: 7 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Internet Architecture Board (IAB) 2 Expires November 21, 2001 L. Daigle, editor 3 Category: Best Current Practice 4 draft-ietf-poisson-pso-appointments-00.txt 5 May 21, 2001 7 IETF ICANN Protocol Support Organization Appointments Procedures 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document specifies the process by which the IETF appoints its 2 34 representatives to ICANN's Protocol Support Organization's Protocol 35 Council (PSO-PC). Additionally, mechanisms that the IETF will adopt 36 for identifying candidates for the PSO's appointments to the ICANN 37 Board of Directors are specified. This process specification 38 reflects 2 years of IETF experience with ICANN, the PSO-PC and the 39 PSO organization, since their inception in 1999. 41 Updates [RFC2282]. 43 1.0 Introduction 45 The ICANN Protocol Support Organization (PSO) is defined by a 46 Memorandum of Understanding (PSO MoU), [RFC2691], which in turn 47 defines the structure and requirements of a "Protocol Council" (PSO- 48 PC) made up of representatives appointed by the PSO MoU signatory 49 organizations. The PSO MoU also stipulates that the PSO-PC will 50 nominate an ICANN Director each year. 52 Two separate selection/appointment roles are discussed here. The 53 reader is referred to the ICANN By-Laws (available from 54 http://www.icann.org) and the PSO MoU for the precise definitions of 55 the support organizations and roles. In short, ICANN has a "Protocol 56 Support Organization", which is an abstract entity made up of several 57 signatory standards development organizations. The IETF is one such. 58 To coordinate the communications and activities of the PSO, the 59 participating organizations appoint 2 people to the Protocol Council 60 (PSO-PC), which then acts as the communications nexus between the 61 participating organizations and ICANN. The first process discussed 62 here is for the selection of IETF members on the PSO-PC. 64 Separately from that, the PSO, through the PSO-PC, is tasked with 65 naming 3 members for the ICANN Board of Directors (1 per year, for 3 66 year terms, staggered). Individual participating organizations (such 67 as the IETF) can propose candidates for consideration. The second 68 process described in this memo is for the selection of potential 69 candidates for ICANN Board seats. 71 Therefore, this document specifies the processes by which the IETF 72 appoints its 2 PSO-PC representatives, and selects candidates for 73 consideration for the PSO ICANN Board of Directors appointment. 74 Insofar as the latter is seen as a task for the IETF Nominations 75 Committee, this document is an update of the IETF NomCom procedure 76 defined in [RFC2282]. 78 2.0 Experience -- PSO-PC members and ICANN Board appointments 80 Two years of experience with the PSO-PC as a functioning entity has 81 made it clear that the primary role of PSO-PC members is to act as 82 liaisons from their appointing organization. The PSO-PC itself does 83 not do technical deliberations or policy-making, beyond the actions 84 specified in the RFC 2691 and acting as a clearing house for PSO MoU 85 signatories' combined input and consensus. The PSO-PC currently 86 undertakes its activities through scheduled teleconferences, and 87 holds an annual general assembly, normally scheduled in conjunction 88 with one of the PSO signatories' meetings. 90 Originally, one of the IETF's PSO-PC appointees was an IAB member, 91 and the other was not. Subsequently, the latter was selected by the 92 IETF NomCom to serve on the IAB, which provided the opportunity to 93 evaluate whether direct communication with the IAB improved the 94 effectiveness in the PSO-PC role. The conclusion is that it's best 95 to have established communication links with the IAB/IAB members, 96 though IAB membership itself is not a requirement. 98 The role of a member of the ICANN Board of Directors is much the same 99 as that of any corporation, with the associated statutory 100 responsibilities. Additionally, the PSO as a whole aims to ensure 101 that ICANN has people with strong Internet technical knowledge on its 102 Board, and any IETF-proposed candidate should be chosen with that in 103 mind. The IETF's standard process for selection, through its 104 Nominations Committee ([RFC2282]), is considered the most appropriate 105 for soliciting candidate proposals and selecting the best fit with 106 these requirements. 108 3.0 IETF PSO-PC member appointment process 110 The primary role of a PSO-PC appointee is to participate in the PSO- 111 PC interactions with ICANN, as described in the PSO MoU. In acting 112 as a representative of the IETF's participation in the PSO, 113 appointees are responsible for liaising with the IAB on technical 114 matters requiring PSO input, and otherwise keeping the IAB up to date 115 on the state of the PSO. 117 As part of its mandate for appointing external liaisons for the IETF 118 (see [RFC2850]), the IAB is tasked with appointing PSO-PC members for 119 the IETF. 121 Normally, the IAB will appoint PSO-PC members for a 2 year term, with 122 each position coming up for renewal/replacement in alternate years. 123 The IAB may recall/change an appointment at its discretion. In 124 accordance with the PSO MoU, the IAB will consider any candidates 125 proposed as a result of the PSO-PC's/ICANN's call for nominations, 126 posted concurrently with the posting of notice of the date of the 127 annual meeting of the PSO General Assembly on the PSO Web Site. 129 4.0 IETF identification of potential ICANN Board member candidates 131 As an addition to the responsibilities of the IETF Nominations 132 Committee defined in RFC 2282, the NomCom shall also be responsible 133 for selecting the IETF's proposals for Board candidates to be 134 considered by the PSO-PC. This shall be done by the usual NomCom 135 procedure of a public call for nominations, discussion and selection 136 of the best candidate(s) matching the requirements defined by the PSO 137 MoU (e.g., geographic representation). The NomCom will use as much 138 as possible the procedures defined in RFC 2282. 140 The IAB shall be responsible for confirming the selection(s) of the 141 NomCom. If any or all of the NomCom's selections are not accepted by 142 the IAB, the NomCom shall select alternative(s). 144 The PSO-PC chooses one ICANN Board candidate annually, for a 3 year 145 term, in time for the candidate to take up their seat in October. 146 The NomCom's selection should be scheduled to coordinate with the 147 PSO-PC's call for candidates, typically in June of every year. 148 Therefore, the IAB will inform the NomCom chair as to the number of 149 candidates the IETF will put forward to the PSO-PC no later than 150 March 1. 152 If any PSO-appointed Board seat should be vacated early, the IAB may 153 call upon the standing NomCom to select candidates for consideration 154 as a replacement. 156 5.0 Security Considerations 158 As this document deals strictly with appointments processes, it is 159 not expected to have any impact on network security. 161 6.0 References 163 [RFC2691] Bradner, S., "A Memorandum of Understanding for an ICANN 164 Protocol Support Organization", RFC 2691, September 1999. 166 [RFC2282] Galvin, J., "IAB and IESG Selection, Confirmation, and 167 Recall Process: Operation of the Nominating and Recall 168 Committees", RFC 2282, February 1998. 170 [RFC2850] IAB, B. Carpenter (ed), "Charter of the Internet 171 Architecture Board (IAB)", RFC 2850, May 2000. 173 8.0 Authors' Addresses 175 Leslie L. Daigle (editor) 176 EMail: leslie@thinkingcat.com 178 Internet Architecture Board 179 EMail: iab@iab.org 181 Membership at time this document was completed: 183 Harald Alvestrand 184 Ran Atkinson 185 Rob Austein 186 Fred Baker 187 Brian Carpenter 188 Steve Bellovin 189 Jon Crowcroft 190 Leslie Daigle 191 Steve Deering 192 Sally Floyd 193 Geoff Huston 194 John Klensin 195 Henning Schulzrinne