idnits 2.17.1 draft-klensin-iaoc-member-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4071, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4071, updated by this document, for RFC5378 checks: 2004-11-18) -- 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 11, 2016) is 2987 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) ** Obsolete normative reference: RFC 4071 (ref. '1') (Obsoleted by RFC 8711) ** Obsolete normative reference: RFC 4371 (ref. '2') (Obsoleted by RFC 8714) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft February 11, 2016 4 Updates: 4071 (if approved) 5 Intended status: Best Current Practice 6 Expires: August 14, 2016 8 Revised IAOC Membership 9 draft-klensin-iaoc-member-01.txt 11 Abstract 13 The original specification of the membership of the IAOC included the 14 IETF and IAB Chairs as voting members. While probably desirable 15 initially, this has turned out to have unfortunate side effects. 16 This document discusses those side effects and replaces those 17 specific individuals with liaisons from the IAB and IESG. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 14, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The IAB and IETF Chairs and the IAOC . . . . . . . . . . . . 3 56 4. Reasons for IAB and IETF Chair Membership in the IAOC and 57 IETF Trust . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. BCP 101 Modifications . . . . . . . . . . . . . . . . . . . . 6 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 9.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Other Obvious Questions About Choices . . . . . . . 7 66 A.1. How About the ISOC President/CEO? . . . . . . . . . . . . 7 67 A.2. The Trust-IAOC Relationship . . . . . . . . . . . . . . . 8 68 A.3. Changing the appointment mechanism for IAOC members 69 selected from the community by the IAB and IAOC . . . . . 8 70 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8 71 B.1. History and Changes from version -00 to -01 . . . . . . . 8 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The original specification of the membership of the IAOC in BCP 101 77 [1] included the IETF and IAB Chairs as voting members. While 78 probably desirable initially, this has turned out to have unfortunate 79 side effects. This document discusses those side effects and 80 replaces those specific individuals with liaisons from the IAB and 81 IESG. 83 Note in Draft: This working draft contains a considerable amount of 84 explanatory material about the various choices, both to make the 85 intent more clear and to facilitate community discussion of those and 86 other options. If the draft is approved in principle, those 87 materials should probably either be moved to appendices or deleted 88 entirely. Also, in response to several comments made on the IETF 89 list, it is worth noting that this document is about IASA and the 90 IAOC (and, peripherally, the IETF Trust) and only incidentally about 91 how the IAB and IESG organize themselves and determine their 92 representation on other bodies. 94 2. History 96 [[CREF1: RFC Editor: please remove this section if the document 97 reaches you. ]] 99 The original version of this document was posted in July 2009 and got 100 absolutely no traction, indeed one or two key members of the IESG 101 made it clear informally that they had no interest in it and that 102 there was no point even trying to discuss it. In February 2016, a 103 draft [3] was posted by some IAB members that seems to have 104 [re]started the discussion. After repeated requests that a draft be 105 posted, this one has been updated to reflect changed context and list 106 discussion. It is posted as a contribution to the discussion. 108 The concept of "liaisons" is from the original version of this draft 109 and is a third alternative to recent suggestions of "observers" or 110 ex-officio IAB and IESG members who are not necessarily the chair. 111 While the author prefers a liaison model for reasons discussed below, 112 the distinction may be minor and there would be little objection to 113 one or the other substitution if the community favored it. 115 As noted above, the author has produced this draft in the hope that 116 it will provide a useful starting point and alternative for the 117 community. If it is useful enough in that role to justify revision, 118 a co-author, or an effort to merge parts of it with the Hardie et al 119 draft [3], would be welcomed. 121 3. The IAB and IETF Chairs and the IAOC 123 While BCP 101 specified that the IAB and IETF Chairs should serve on 124 the IAOC (and now as Trustees of the Internet Trust [2]), there does 125 not appear to be a strong motivation for having those particular 126 Chair roles expanded to include the considerable additional workload 127 that comes with the IAOC and Trustee roles. There were some good 128 reasons associated with transition at the time the IASA (and IAOC) 129 were established, but the transition to the IASA (and Trust) 130 arrangements are now in the distant past and at least the original 131 set of reasons no longer apply. It is clearly important that the 132 IAOC and Trustees have direct and ongoing input from the IAB and 133 IESG, but that responsibility need not be performed by the two 134 Chairs. There are disadvantages associated with having the Chairs in 135 the Trustee and IAOC roles, which include: 137 Workload and full-time positions 138 To a considerable extent, each additional task we permanently 139 assign to the IAB or IETF Chair positions narrows the number of 140 people who will have the bandwidth and support needed to take on 141 those roles. It also assumes a wider range of skills. Those 142 requirements make the positions harder to fill, reduce the number 143 of volunteers, and increase the risk that the IAB or Nomcom, 144 respectively, will be placed into the position of selecting 145 someone "least bad" among a small range of candidates. Absent 146 really compelling arguments to the contrary (see Section 4), it 147 also puts us in a position in which the two Chairs are personally 148 essential rather than leaders who are responsible to consensus 149 within their bodies and the community. As others have pointed 150 out, that is inconsistent with our claimed "no kings" model. 152 A different way to look at almost the same issue is that 153 circumstances change. The IAB should be able to determine its 154 priorities, and how the time of the Chair should be allocated, and 155 to do so dynamically rather than assuming that the IAOC is always 156 a high and inescapable priority. 158 Skill set 159 Section 4 of BCP 101 [1] provides guidance about the IAB and IESG 160 (non-ex-officio) appointments to the IAOC and indicates 162 "people with some knowledge of contracts and financial 163 procedures, who are familiar with the administrative support 164 needs of the IAB, the IESG, or the IETF standards process." 166 The "Principles" described in Section 2.2 of RFC 4071 make it 167 entirely clear that the IAOC (and the IASA structure in general) 168 are intended to provide for and support the administrative needs 169 of the IETF and related organizations (including the IAB and, now, 170 the IETF Trust). At least according to that document and the 171 other documents that make up BCP 101, the IAOC is not a policy 172 body. The strongest arguments that have been advanced for 173 requiring in-person participation by the IAB and IETF Chairs all 174 appear to be related to IAOC policy-making of to the IETF Trust 175 (see below and Appendix A.2. If the community does not intend 176 such policy-making to occur in the IAOC, it may be better to have 177 the IAOC membership selected for a higher degree of skill and 178 interest in its actual role. 180 Similar issues apply to the IETF Trust role (unless the IAOC and 181 Trustee roles are ultimately separated): doing the job well 182 requires an ability and willingness to understand the realities of 183 Intellectual Property Rights (IPR) law and regulations and to work 184 effectively with lawyers and other advisers who are IPR 185 specialists. 187 The appeals chain 188 RFC 4071 also defines an appeals model for IAOC actions that takes 189 appeals to the IAB. Specifically for that IAB role, it would 190 probably be better to not require that the IAB Chair be personally 191 involved in the IAOC as a voting member. 193 In addition, it is useful to clarify the role of the IAB and IESG 194 representatives by making them non-voting liaisons. This reduces the 195 requirement that IAB and/or IESG members be selected for the specific 196 types of expertise needed on the IAOC and Trustees. If they cannot 197 explain IESG and IAB requirements and perspectives to the voting IAOC 198 and Trustee members and persuade them as needed or cannot explain 199 IAOC and Truetee matters to the IAB (or IESG) as needed, we have far 200 more serious problems than whether or not those two people vote. It 201 may be worth noting that reporting on and explaining portions between 202 the two bodies is exactly consistent with our expectations for IAB/ 203 IETF liaisons to completely external bodies. 205 4. Reasons for IAB and IETF Chair Membership in the IAOC and IETF Trust 207 As discussed above, when the community approved BCP 101, it was 208 approving a fundamentally administrative activity. That was 209 motivated, at least in part, by a desire to replace earlier 210 arrangements if which administrative activities for the IETF were run 211 entirely by an external body. However, it was equally important to 212 be sure that those detailed administrative functions did not fall on 213 the IESG or IAB in order that those bodies could continue to do their 214 primary jobs. At the beginning, there were strong arguments for 215 including the IAB and IETF Chairs in the IAOC in order to facilitate 216 the transition and because they had been, de facto, the primary 217 liaisons and contact points for the earlier arrangements. RFC 4071 218 is now well into its tenth year, we have a stable environment that is 219 working at least moderately well (modulo some issues about 220 responsiveness to the community and conformance with the transparency 221 requirements of the RFC with which the presence of the two Chairs as 222 voting members does not appear to be helping), and those transitional 223 requirements no longer apply. 225 The issues with the IETF Trust [2] are a bit different. It is much 226 more a policy body than the IAOC. The reasons for making the IAOC 227 members the Trustees of the IETF Trust were, again, dictated by some 228 transition concerns in which the appearance of the Chairs of the IAB 229 and IETF being directly involved was important. But, again, the IETF 230 Trust has entered its second decade, is stable, and appears to be 231 working relatively well. If Trust considerations argue against 232 making the changes outlined in this document, that may be a stronger 233 reason for the community to review the composition of the Trustees 234 than to preserve the status quo in the IAOC. (See further discussion 235 on this topic in Appendix A.2. 237 Nothing in this document should be construed as prohibiting either 238 the IETF or IAB Chairs from serving in the liaison roles. The IAB 239 Chair, who is chosen for that role by an IAB selected largely or 240 entirely for skills not related to the IAOC or the IETF Trust (and 241 who serves at the pleasure of that body), will often not be the 242 optimal liaison. By contrast, the IETF Chair, who is selected by the 243 Nomcom for skills that will often be more relevant, may more often be 244 the best choice for liaison. However, it seems more reasonable to 245 leave those decisions to the IAB and IESG and the individuals 246 involved rather than building them rigidly into a BCP, if only to 247 better allow for changing circumstances. 249 5. BCP 101 Modifications 251 BCP 101 is hereby modified by changing "eight" to "six" in the first 252 sentence of Section 4 of RFC 4071, deleting the bullet items from 253 that section that read "The IETF Chair (ex officio);" and "The IAB 254 Chair (ex officio);", and adding, after the bullet list, "The IAB and 255 IESG shall appoint liaisons from their own membership to the IAOC. 256 Those liaisons shall function as full members but without vote. 258 6. Acknowledgments 260 The original (2009) version of this draft emerged from a number of 261 community discussions and discussions about variations in the match 262 between the skills and interests of various IAB and IETF Chairs over 263 the years, noting that the skills and interest needed to effectively 264 serve on the IAOC had rarely been identified as primary, or even 265 high, on the list of IAB or Nomcom criteria for people selected to 266 those leadership posts. 268 The current, 2016, version was stimulated by a draft being circulated 269 for IAB comment [3] and IETF list discussion of it. One of the 270 authors of that draft challenged those in the community who had 271 different views or proposals to produce a draft that specified a 272 practical alternative. This draft is a response to that request; the 273 author thanks the IAB member authors of the other draft and many 274 contributors to the on-list conversation for the new ideas and 275 rationale that appear here, while understanding that some of them may 276 not agree with the way in which this draft utilizes their views and 277 insights. Comments from Brian Carpenter, Dave Crocker, Ted Hardie, 278 Mike St. Johns, and Andrew Sullivan were particularly helpful in that 279 regard. 281 7. IANA Considerations 283 [[CREF2: RFC Editor: Please remove this section before publication.]] 285 This memo includes no requests to or actions for IANA. 287 8. Security Considerations 289 This document makes an adjustment to an IETF and IASA procedural 290 document. It has no Internet security implications beyond those 291 described in the relevant base documents. 293 9. References 295 9.1. Normative References 297 [1] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 298 IETF Administrative Support Activity (IASA)", BCP 101, 299 RFC 4071, DOI 10.17487/RFC4071, April 2005, 300 . 302 [2] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 303 IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, 304 January 2006, . 306 9.2. Informative References 308 [3] Hardie, T., Sullivan, A., and R. Housley, "Updating the 309 ex-officio member of the IAB in the IAOC", February 2016, 310 . 312 Appendix A. Other Obvious Questions About Choices 314 A.1. How About the ISOC President/CEO? 316 As specified in RFC 4071, there are three ex-officio voting positions 317 on the IAOC. This document eliminates two of those positions, 318 replacing them with non-voting liaisons appointed by the relevant 319 body. The preference remains to have the IETF Chair actually serve 320 on the IAOC unless there are reasons to not do so while the 321 preference about the IAB Chair is much less strong (and the reasons 322 less compelling). That leads to an obvious question as to why the 323 requirement that the ISOC President and CEO serve directly, ex- 324 officio, on the IAOC (and the IETF Trust, see below) should be 325 retained. The reason is that RFC 4071 makes it quite clear that IASA 326 is an ISOC function, carried out for the IETF community, that the IAD 327 is an ISOC employee, that ISOC is expected to be the actual signatory 328 to relevant contracts, and so on. That combination of factors gives 329 ISOC line responsibility (as well as ultimate budgetary 330 responsibility) and having the ISOC President and CEO serve directly 331 on the IAOC is important to those relationships and accountability 332 for them. 334 A.2. The Trust-IAOC Relationship 336 When the IETF Trust was established, it was critically important, as 337 an initialization and transition matter, that the Trustees and the 338 IAOC have the same membership. At this point, a decade on, the 339 importance of having the IAOC serve the administrative oversight 340 function (for which it was named) remains clear. The IETF Trust and 341 its Trustees have, by contrast, assumed more of a policy function. 342 At this point, the reasons for keeping the two memberships the same 343 (including an early, now-expired, constraint about not being able to 344 make changes without external approval) have largely disappeared. 345 This document does not specify separating the two, but such an action 346 would be compatible with it, noting that there is almost certainly a 347 much stronger argument for keeping the IETF and IAB Chairs as 348 Trustees than there is for keeping them as IAOC members. 350 A.3. Changing the appointment mechanism for IAOC members selected from 351 the community by the IAB and IAOC 353 Several suggestions have been made lately for shifting the IAB and 354 IESG appointment responsibilities for community members to serve as 355 voting IAOC members to the Nomcom, allowing the Nomcom to appoint all 356 such members other than the one appointed by ISOC. This document 357 does not address that possibility, but it would be compatible with 358 what is proposed here. As with the role of the IAB and IETF Chairs 359 (see above), there is probably a stronger case to me made for the IAB 360 and IESG appointing Trustees than for their appointing IAOC members. 362 Appendix B. Change Log 364 [[CREF3: RFC Editor: Please remove this section before publication.]] 366 B.1. History and Changes from version -00 to -01 368 As discussed above, version -01 of this document is a 2016 rewrite of 369 the 2009 version -00. There are few if any changes to the 370 substantive proposal but a good deal of discussion has been added to 371 reflect more recent considerations. 373 Author's Address 375 John C Klensin 376 1770 Massachusetts Ave, Ste 322 377 Cambridge, MA 02140 378 USA 380 Phone: +1 617 245 1457 381 Email: john+ietf@jck.com