idnits 2.17.1 draft-iab-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? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 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 (January 3, 2002) is 8149 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 2727 (Obsoleted by RFC 3777) Summary: 7 errors (**), 0 flaws (~~), 0 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Internet Architecture Board (IAB) 2 Expires June 3, 2002 L. Daigle, editor 3 Category: Best Current Practice 4 draft-iab-pso-appointments-00.txt 5 January 3, 2002 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/ietf/1id-abstracts.txt 28 Abstract 30 This document specifies the process by which the IETF appoints its 2 31 representatives to ICANN's Protocol Support Organization's Protocol 32 Council (PSO-PC). Additionally, the process for selecting candidates 33 for the PSO's appointments to the ICANN Board of Directors is 34 specified. This process specification reflects 2 years of IETF 35 experience with ICANN, the PSO-PC and the PSO organization, since 36 their inception in 1999. 38 1.0 Introduction 40 The ICANN Protocol Support Organization (PSO) is defined by a 41 Memorandum of Understanding (PSO MoU), [RFC2691], which in turn 42 defines the structure and requirements of a "Protocol Council" (PSO- 43 PC) made up of representatives appointed by the PSO MoU signatory 44 Standards Development Organizations (SDOs). The PSO MoU also 45 stipulates that the PSO-PC will nominate an ICANN Director each year. 47 Two separate selection/appointment roles are discussed here. The 48 reader is referred to the ICANN By-Laws (available from 49 http://www.icann.org) and the PSO MoU for the precise definitions of 50 the support organizations and roles. In short, ICANN has a "Protocol 51 Support Organization", which is an abstract entity made up of several 52 signatory standards development organizations. The IETF is one such. 53 To coordinate the communications and activities of the PSO, the 54 participating organizations appoint 2 people to the Protocol Council 55 (PSO-PC), which then acts as the communications nexus between the 56 participating organizations and ICANN. Section 3 of this memo sets 57 forth the process for selecting IETF appointees to the PSO-PC. 59 Separately from that, the PSO, through the PSO-PC, is tasked with 60 naming 3 members for the ICANN Board of Directors (1 per year, for 3 61 year terms, staggered). Individual participating organizations (such 62 as the IETF) can propose candidates for consideration. Section 4 of 63 this memo sets for the procedure for the selection of potential 64 candidates for ICANN Board seats. 66 Therefore, this document specifies the processes by which the IETF 67 appoints its 2 PSO-PC representatives, and identifies candidates for 68 consideration for the PSO ICANN Board of Directors appointment. 70 2.0 Experience -- PSO-PC members and ICANN Board appointments 72 Two years of experience with the PSO-PC as a functioning entity has 73 made it clear that the primary role of PSO-PC members is to act as 74 liaisons from their appointing organization. The PSO-PC itself does 75 not do technical deliberations or policy-making, beyond the actions 76 specified in the RFC 2691 and acting as a clearing house for PSO MoU 77 signatories' combined input and consensus. The PSO-PC currently 78 undertakes its activities through scheduled teleconferences, and 79 holds an annual general assembly, normally scheduled in conjunction 80 with one of the PSO signatories' meetings. 82 Originally, one of the IETF's PSO-PC appointees was an IAB member, 83 and the other was not. Subsequently, the latter was selected by the 84 IETF NomCom to serve on the IAB, which provided the opportunity to 85 evaluate whether direct communication with the IAB improved the 86 effectiveness in the PSO-PC role. The conclusion is that it is best 87 to have established communication links with the IAB/IAB members, 88 though IAB membership itself is not a requirement. 90 The role of a member of the ICANN Board of Directors is much the same 91 as that of any corporation, with the associated statutory 92 responsibilities. Additionally, the PSO as a whole is expected to 93 ensure that ICANN has people with strong Internet technical knowledge 94 on its Board, and any IETF-proposed candidate should be chosen with 95 that in mind. 97 3.0 IETF PSO-PC member appointment process 99 The primary role of a PSO-PC appointee is to participate in the PSO- 100 PC interactions with ICANN, as described in the PSO MoU. In acting 101 as a representative of the IETF's participation in the PSO, 102 appointees are responsible for liaising with the IAB on technical 103 matters requiring PSO input, and otherwise keeping the IAB up to date 104 on the state of the PSO. 106 As part of its mandate for appointing external liaisons for the IETF 107 (see [RFC2850]), the IAB is tasked with appointing PSO-PC members for 108 the IETF. 110 Normally, the IAB will appoint PSO-PC members for a 2 year term. 111 Each position is considered for renewal/replacement in April of 112 alternate years. The IAB may recall/change an appointment at its 113 discretion. 115 In accordance with the PSO MoU, the IAB will consider any candidates 116 proposed as a result of the PSO-PC's/ICANN's call for nominations, 117 posted concurrently with the posting of notice of the date of the 118 annual meeting of the PSO General Assembly on the PSO Web Site. 120 4.0 IETF identification of potential ICANN Board member candidates 122 The Internet technical community as a whole has a responsibility and 123 a right to identify qualified candidates for the PSO to nominate to 124 the ICANN Board of Directors. In its role as a signatory SDO to the 125 PSO, per the PSO MoU, the IETF may propose one or more candidates for 126 consideration by the PSO-PC. 128 There are 2 obvious approaches that could be followed here: 1) the 129 IAB could consider extending the role of the IESG/IAB Nominating 130 Committee (NomCom -- [RFC2727]) to research and review candidates 131 proposed by the IETF community at large; 2) alternatively, this could 132 be viewed as another "liaison" function for the IETF, to be filled by 133 the IAB. 135 In fact, neither approach suits perfectly. A position on the ICANN 136 Board is not a liaison position; any candidate appointed by the PSO- 137 PC is to act on behalf of ICANN, not any SDO that may have provided 138 an original nomination. On the other hand, the NomCom (acting on 139 behalf of the IETF) would not select the final Board candidate -- 140 merely a potential candidate to be considered by the PSO-PC. The 141 argument has been made that this is a fruitless duplication of 142 scrutiny and a potential distraction of the NomCom's efforts which 143 should be focused on filling IETF functions. 145 Therefore, as part of its liaison with the PSO-PC, the IAB will 146 select zero or more proposed candidates to be considered by the PSO- 147 PC each year, and will also publicize, within the IETF, the PSO-PC's 148 public call for nominations (see [RFC2691]), so that any interested 149 IETF participant may nominate someone, or be nominated, for 150 consideration by the PSO-PC in its appointment of an ICANN Board 151 member. 153 5.0 Security Considerations 155 As this document deals strictly with appointments processes, it is 156 not expected to have any impact on network security. 158 6.0 References 160 [RFC2691] Bradner, S., "A Memorandum of Understanding for an ICANN 161 Protocol Support Organization", RFC 2691, September 162 1999. 164 [RFC2727] Galvin, J., "IAB and IESG Selection, Confirmation, and 165 Recall Process: Operation of the Nominating and Recall 166 Committees", RFC 2727, February 2000. 168 [RFC2850] IAB, B. Carpenter (ed), "Charter of the Internet 169 Architecture Board (IAB)", RFC 2850, May 2000. 171 8.0 Authors' Addresses 173 Internet Architecture Board 174 EMail: iab@iab.org 176 Membership at time this document was completed: 178 Harald Alvestrand 179 Ran Atkinson 180 Rob Austein 181 Fred Baker 182 Brian Carpenter 183 Steve Bellovin 184 Jon Crowcroft 185 Leslie Daigle 186 Steve Deering 187 Sally Floyd 188 Geoff Huston 189 John Klensin 190 Henning Schulzrinne