idnits 2.17.1 draft-daigle-iasa-retrospective-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 document seems to lack a Security Considerations 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 5, 2017) is 2518 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4371 (Obsoleted by RFC 8714) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Daigle 2 Internet-Draft Thinking Cat Enterprises LLC 3 Intended status: Informational June 5, 2017 4 Expires: December 7, 2017 6 After the first decade: IASA Retrospective 7 draft-daigle-iasa-retrospective-01 9 Abstract 11 The IETF Administrative Support Activity was formally established and 12 undertaken as a project of the Internet Society in 2005. In the 13 following 10+ years, the IETF has grown and changed, as have the 14 responsibilities that fall to the IASA. 16 This document reflects on some of those changes and the implications 17 within the IASA structure, providing some areas for further 18 discussion to consider evolving the IASA and the IETF/ISOC 19 relationship. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 7, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Forming the IASA . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Evolution of IASA breadth . . . . . . . . . . . . . . . . . . 4 58 3.1. IASA coverage in 2005 . . . . . . . . . . . . . . . . . . 4 59 3.2. IASA coverage in 2017 . . . . . . . . . . . . . . . . . . 5 60 4. Evolution of Internet Society Partnership . . . . . . . . . . 8 61 5. Issues and Potential Next Steps for the IASA structure . . . 9 62 6. Closing remarks . . . . . . . . . . . . . . . . . . . . . . . 12 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 66 8.2. Informative References . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 In April 2005, BCP 101 ([RFC4071]) was published, formally creating 72 the IETF Administrative Support Activity (IASA). At the end of an 73 intense community discussion, the IASA was formed as an activity 74 housed within the Internet Society (ISOC), and BCP 101 defined the 75 roles of the IETF Administrative Oversight Committee (IAOC), and the 76 IETF Administrative Director (IAD). Together, these roles have 77 defined responsibilities for IETF's fiscal and administrative 78 support. 80 With the newly established IASA, the IETF was in a position to 81 formalize several activities that had been undertaken by other 82 organizations, on behalf of the IETF. This allowed the IETF take 83 responsibility of those operations. Through the 10+ years since the 84 inception of IASA, the operations and responsibilities have, however, 85 grown and requirements have evolved. Nor has the world stood still 86 -- at the same time, the Internet Society has grown and taken on a 87 broader role in Internet governance discussions and global 88 activities. 90 This document reflects on some of those changes and the implications 91 within the IASA structure, providing some areas for further 92 discussion to consider evolvingthe IASA and the IETF/ISOC 93 relationship. 95 2. Forming the IASA 97 In 2003, the IETF and IAB Chairs formed an IAB Advisory Committee 98 (AdvComm) to "review the existing IETF administration relationships 99 (RFC Editor, IETF Secretariat, etc.) and propose IETF management 100 process or structural changes that would improve the overall 101 functioning of the IETF" ([RFC3716]). The AdvComm identified several 102 stressors to the efficient and effective operation of the IETF 103 related to financial support, informality of relationships, and 104 opaqueness of decision making in administrative matters. 106 To address the identified stressors, the AdvComm developed a set of 107 requirements for any eventual solution: 109 o Resource Management 111 * Uniform Budgetary Responsibility (autonomy) 113 * Revenue Source Equivalence (ability to consider all sources of 114 income and apply them as appropriate across all functions, 115 which was not possible when the Internet Society was funding 116 the RFC Editor function and CNRI/Foretec was supporting the 117 Secretariat function 119 * Clarity in Relationship with Supporting Organizations (clear 120 contractual relationships between the IETF and each supporting 121 organization) 123 * Flexibility in Service Provisioning (ability to make choices) 125 * Administrative Efficiency (avoiding duplicate overhead across 126 multiple organizations) 128 o Stewardship (looking after the future as well as the present) 130 * Accountability for Change (i.e., accountability to the IETF 131 community) 133 * Persistence and Accessibility of Records 135 o Working Environment 137 * Service Automation (for administrative tasks and IETF 138 information flow management) 140 * Tools (development of more tools for IETF support) 142 The IETF followed up the AdvComm recommendations with discussions of 143 possible administrative structures to support the IETF and ensure its 144 continued ability to focus on its mission of making the Internet work 145 better. The eventual result was the IETF Administrative Support 146 Activity (IASA), defined in BCP101 ([RFC4071]) and formed in 2005. 148 The selected form of the IASA (as "an activity of the Internet 149 Society") meant that the IETF could focus on building out the pieces 150 of administration necessary to carry out its standards activities, 151 without having to instantly build general corporate overhead. That 152 is, the Internet Society was specifically tasked with providing any 153 additional needed clerical or financial support, and was identified 154 as solely responsible for obtaining sponsors for the IETF. The 155 latter also was intended to provide arms-length distance between 156 corporate donors and direction of the IETF's activities: the IETF 157 could not be "bought". 159 3. Evolution of IASA breadth 161 3.1. IASA coverage in 2005 163 In order to understand the evolution of the IASA, it is important to 164 describe the baseline -- what the IASA was when it was first formed. 166 o Secretariat -- the IETF Secretariat function was carried out by an 167 organization that had been a subsidiary of CNRI (which had 168 collected meeting fees and provided Secretariat services until the 169 creation of the IASA). In 2005, key personnel migrated to Neustar 170 to carry out the Secretariat function under contract with the 171 Internet Society (for IASA). This gave the IETF full control and 172 responsibility for picking meeting locations, as well as setting 173 and collecting meeting fees. 175 o Meeting planning -- A first priority was to establish meeting 176 dates, locations and contracts more than a year in advance, to 177 improve contract negotiating positions, costs, and provide clarity 178 for attendee planning. (Historical data point: the early 2004 179 Seoul IETF meeting did not have a hotel contract booked in 180 December of 2003). 182 o RFC Editor -- The RFC Editor function had been handled at USC/ISI 183 for many years (since Jon Postel moved to USC/ISI from UCLA in 184 1978). In the years leading up to the formation of the IASA, The 185 Internet Society had provided funding to ISI in the form of a 186 contract to carry out the work. With the creation of the IASA, 187 this contract was folded into the ISOC/IASA support. See 188 [RFC5540] for more details. 190 o IANA -- by the time the IASA was created in 2005, ICANN was well- 191 established and had been carrying out the Internet Assigned Names 192 Activity since 1998. The IETF had agreed on a Memorandum of 193 Understanding with ICANN on the handling of protocol parameters 194 for IETF standards ([RFC2860]), but it did not specify levels of 195 service or practical terms of agreement. (See more IANA detail at 196 http://www.internetsociety.org/ianatimeline ). 198 o Tools -- the Secretariat had developers on staff who had built 199 tools to support the workflow of the IETF (e.g., liaison manager). 200 The software was proprietary, and IETF community programmers had 201 no access or insight. At the same time, the IETF community being 202 what it is, there were community-driven tools that were built up 203 in an open source fashion. These were completely separate and 204 separately maintained. 206 o Meeting network support -- in 2005, standard meeting hosting 207 agreements included providing network connectivity to the meeting 208 hotel. This might have extended to include a terminal room for 209 attendees. 211 o Staff -- the IASA established that the IETF would have one full- 212 time employee (officially an employee of ISOC, as part of the 213 administrative arrangements). That one employee was the IETF 214 Administrative Director. 216 o The IAOC -- established as an administrative oversight body, the 217 IAOC was established with 3 voting and one non-voting ex officio 218 members (IETF Chair, IAB Chair, ISOC CEO and IAD, respectively), 219 one member appointed by the ISOC Board, and 4 appointees from the 220 community (2 from NomCom, 1 each appointed by the IESG and IAB). 222 3.2. IASA coverage in 2017 224 A little more than a decade later, things have changed substantially 225 in terms of the coverage of the responsibilities of the IASA. 227 o Secretariat -- the IASA put the Secretariat contract out for 228 competitive bid in 2007, establishing a contract with professional 229 association management company (Association Management Services) 230 in 2008, with key personnel moving to AMS. 232 o Meeting planning -- IETF meeting locations are now mostly 233 contracted two to three years in advance. At the same time, IETF 234 leadership and participants' expectations of meeting locations and 235 venues have evolved. The IETF now aims to meet regularly in Asia, 236 as well as Europe and North America. Meeting layout requirements 237 have evolved. The topic is sufficiently complex that the MTGVENUE 238 working group was created in 2016 to develop an IETF consensus 239 document on meeting venue requirements. 241 o RFC Editor -- the IAB split the RFC Editor function into separate 242 functions and these have been contracted out -- RFC Series Editor; 243 RFC Production, Independent Series Editor. These are collectively 244 overseen by an IAB-based, community-populated advisory board 245 (RSOC). The RFC Series continues to grow in terms of number of 246 documents published, and new features (e.g., ISSNs) and other 247 formats supported for the documents. (N.B.: The IASA is not 248 responsible for defining or driving any of that growth -- the IASA 249 role is limited to writing and managing the contracts for the work 250 defined by the IAB and RSOC). 252 o IETF Trust -- the IETF Trust was formed to hold IETF-related IPR 253 (marks, copyright, domain name registrations) after the IASA was 254 established. It was created in late 2005, by agreement between 255 the Corporation for National Research Initiatives (CNRI) and the 256 Internet Society (ISOC) as the Settlors, the IETF and the initial 257 trustees (IAOC members at the time). One provision of the Trust 258 Agreement was that, prior to July 1, 2010, the Trust could be 259 amended only by unanimous written consent of both the Settlors and 260 two-thirds of the Trustees. The Trust Agreement includes a list 261 of the initial assets contributed to the Trust, and they generally 262 included the IETF and IETF SECRETARIAT marks, relevant domain 263 names, and the content of the databases used to do the IETF's work 264 (including then-current Internet-Drafts). RFC 4371 ([RFC4371]) 265 updated RFC 4071 (BCP 101) to reflect the fact that there would be 266 an IETF Trust to hold the rights to IETF-relevant intellectual 267 property. Additionally, RFC 4748 updated RFC 3798 (the first 268 organization of IETF rights in contributions), and that RFC was 269 updated by RFC 5378 ([RFC5378]) to unify the IETF rights 270 definitions and Trust structure. 272 o IANA -- the IETF Trust holds the IANA IPR (IANA trademark and 273 iana.org and related domain name registrations). We now formally 274 contract with ICANN to do the work (which is an update over the 275 SLA that was established in the intervening decade) 277 o Tools -- the IETF's software tools are still a mix of things 278 developed spontaneously by community members and specific work put 279 out for hire. The latter is now handled through RFPs, and care is 280 made to ensure that tools upon which the community is dependent 281 can be maintained and supported for as long as needed. 283 o Meeting network support -- network support for IETF meetings has 284 grown in scope and expectation of uniformity of services in 285 meetings across the globe. This now encompasses a large scale 286 combination of NOC volunteers, hired support, in-kind donations of 287 equipment and specialized support for remote participation. The 288 following list of current meeting network support expectations 289 highlights not only the complexity of the support, but also the 290 increased issues in funding, contract management, and implications 291 for hotel contracts that land on the IASA plate: 293 * Support for pre/post events (ISOC BOT, Hackathon, etc.) 295 * Ubiquitous wireless with multiple SSIDS 297 * Hotel wireless with IETF SSIDs -- sometimes multiple venues 299 * V6 enabled throughout 301 * Increasing remote participation support 303 * Support for experiments 305 * Bits and Bites 307 * Core network management (ASN/ip addresses/DNS/monitoring/etc.) 309 * Storage, management and shipping of IETF-owned equipment (in- 310 kind donations) 312 o Comms -- Beyond simply having a reliable website, the IETF's use 313 of "communications" has extended in recent years. This ranges 314 from updates in the website itself, to work with social and 315 industry media and messaging to position the IETF in relevant 316 global discussions. Of late, the IETF has used the services of 317 ISOC's professional communications staff, helping deal with some 318 of the publicly visible issues such as the impacts of surveillance 319 revelations or the IANA transition. Starting from 2017, this 320 support is for the first time part of the IETF budget, whereas 321 previously the activity and its funding not visible at that level 323 o Sponsorship and funding -- even as the IETF retains its basic 324 operational structure, the industry around it changes. The last 325 decade has seen increased costs of meetings and productions, and a 326 greater reliance on corporate funding. Where once the IETF relied 327 on individual community members convincing their companies to step 328 up for the next meeting, the IETF now plans its meetings several 329 years in advance and needs to align funding expectations 330 accordingly. It takes expertise to update funding models, build 331 and implement programs for securing industry sponsorship. BCP 101 332 formally identifies that the IETF is not to fundraise on its own; 333 indeed, the IASA is not responsible for the sponsorship 334 development (just managing its impact on the IASA budget). The 335 IETF sponsorship models have evolved, and in 2017 they consist of 336 ISOC memberships, the Global Host program, meeting hosts and other 337 meeting sponsors, the Hackathon and Bits-n-Bites sponsorships, and 338 the IETF Endowment. The team helping with sponsors involves a 339 primary sponsorship person at ISOC, the IAD, the Secretariat, as 340 well as frequent help from the IETF leadership and their 341 connections. 343 o Staff -- the IASA still has exactly one permanent employee -- the 344 IETF Administrative Director. 346 o IAOC -- the structure of the IAOC remains unchanged since the 347 IASA's inception. 349 o IAOC Committees -- recognizing the need for more eyes and 350 specialized attention for different branches of work requiring 351 IAOC oversight, the IAOC expanded its support by creating 352 committees. Committees are dynamic -- formed and closed as needed 353 to focus on key areas of the moment, and often include members 354 from outside the IAOC. The committees do the heavy lifting on 355 background work for IAOC decisions. The IAOC is nonetheless 356 responsible for its decisions based on committee output and 357 recommendations. Example committees include: 359 * Finance Committee: reviews financial reports prepared by the 360 IAD (with support from ISOC Accounting staff), discusses budget 361 proposals before going to the whole IAOC. 363 * Meetings Committee: reviews candidate IETF meeting venues and 364 proposes selections for approval by the IAOC. 366 Further details about IAOC Committees, including the current list of 367 committees and membership, is available from https://iaoc.ietf.org/ 368 committees.html . 370 4. Evolution of Internet Society Partnership 372 When the IASA was formally created, the Internet Society had only 373 recently established a substantial and steady financial basis 374 (through its Public Interest Registry project). "Internet 375 Governance" was a relatively new global policy discussion topic, and 376 the Internet Society provided a much needed voice from the Internet 377 technical community. It had a very small staff (10 staff listed in 378 the 2004 annual report), a broad footprint of Chapters around the 379 globe, and a few, focused projects undertaken by staff. 381 Since 2005, the Internet Society has expanded significantly, 382 organizationally (reaching 90+ staff) and in its presence on the 383 world stage of Internet policy, development and technology. While it 384 remains committed to its role of support of the IETF, it becomes 385 increasingly challenging to maintain (and explain) the reality that 386 the Internet Society and the IETF are two separate organizations, 387 with independent roles and perspectives, while everything from the 388 hotel contracts to the MoU with ICANN (for IANA services) is signed 389 by the Internet Society (as the legal entity for the IETF). 391 5. Issues and Potential Next Steps for the IASA structure 393 Here are some issues that could use addressing in updates to the IASA 394 structure: 396 o The most general question: the effort involved in IASA-related 397 tasks has considerably risen during its existence, and the current 398 organisational arrangements may no longer be the perfect match for 399 the task. Are changes needed in the organisation? 401 o The 2017 IETF is more diverse and more international than it was 402 previously. Arranging meetings is a particular area that today 403 demands more work. In addition, the IETF community periodically 404 raises new requirements that must be met by venues. Local 405 conditions, invitation and visa processes, and hotel and network 406 facilities demand effort. While the IAOC has made some changes 407 regarding site selection, and ongoing IETF working group efforts 408 will help specify requirements more clearly, this remains a 409 sensitive and critical area. 411 o Sponsorship and hosting issues in particular are increasingly 412 difficult for meetings. While some operational changes are being 413 made to the sponsorship opportunities for the IETF, the IETF would 414 probably be served well by moving more towards a funding model 415 that is independent of the meetings. 417 o In the last couple of years, the IAOC and ISOC have worked to 418 ensure that contributions such as staff time and other support are 419 properly accounted for in the IETF budget. This increases 420 transparency and awareness. However, even with this progress, the 421 actual work is still organised within two separate organisations, 422 which makes it hard to have one decision point regarding where and 423 how to spend resources. 425 o Clarity of IETF representative communications: who is responsible 426 for determining the structure and message of the IETF's place on 427 the world stage, to potential sponsors, etc. The IASA role is to 428 ensure there are appropriate resources (expertise, materials), but 429 it is not currently clear to whom those should be provided, and 430 therefore, what the specification of the task is. 432 o Representation for sponsorship: The Internet Society is formally 433 responsible for IETF fund raising (per BCP101). The IASA is 434 responsible for aligning promised sponsor benefits with meeting 435 realities, and tracking the overall budget. Currently, the IASA 436 relies on the IETF Chair to take responsibility for managing 437 discussions required to vet any possible changes in 438 representation, but perhaps there are other models that would 439 scale more effectively. 441 o Clarity of role in the IETF Endowment: related to the question of 442 determining the shape of representative communications materials, 443 potential IETF Endowment contributors ask for a perspective of 444 where the IETF is going in the next decade, and how Endowment 445 money might be used. The future of the IETF is not for the IASA 446 to decide, but the IAOC's role in building and managing the IETF 447 budget make it a natural place to look for some of these answers. 448 This highlights three problems: 450 * It is ISOC that is pitching the IETF Endowment (because ISOC is 451 a legal organization; because the IETF is not supposed to do 452 fundraising, per BCP 101) and potential funders can be confused 453 why the IETF is not speaking directly. 455 * The obvious question, "Why doesn't ISOC just pay for it?" -- 456 which stems from a lack of perception of the different world 457 roles of the two organizations. 459 * In preparing the pitch for the IETF Endowment, ISOC naturally 460 turns to the "money manager" of the IETF to get answers to 461 questions, and it is confusing when the IAOC can neither 462 provide answers or identify the suitably responsible part of 463 the organization. 465 A better plan would be to have clarity about who the IETF thinks 466 is responsible for such discussions, and messaging that more 467 clearly to the rest of the world. 469 o Clarifying, and as necessary, updating the relationship between 470 the IETF and the Internet Society: in establishing the IASA in 471 2005, the IETF and the Internet Society determined the best 472 relationship was to have the IASA homed as an Internet Society 473 project. Is that still the best arrangement for all concerned? 475 o Staffing: The IASA was created with one full-time IETF staff 476 person -- the IETF Administrative Director. Some questioned 477 whether it would even be a full-time job. It always has been at 478 least a full-time job, and over the years the shortfall of 479 resources has been at least partially addressed by contributions 480 of Internet Society staff resources that are available (e.g., see 481 notes above about the IETF Communications plans, etc). The 482 problems are mismatch of talent, (lack of) resources for the IETF, 483 and unplanned impact on resources for the Internet Society that 484 has its own projects to pursue. It would be better that the IETF 485 should just manage its own staffing needs 487 o IAOC membership: The IAOC has 4 ex officio members (IETF Chair, 488 IAB Chair, ISOC CEO, IETF Administrative Director (non-voting)), 489 and 5 appointed members. One of 5 members is appointed by the 490 ISOC Board of Trustees, and is traditionally expected not to stand 491 for IAOC Chair. That leaves a small pool from which to select the 492 IAOC Chair (and the IETF Trust Chair, usually a different person), 493 and very few (2, by the time you've appointed Chairs) "worker 494 bees" for the IAOC. This is a functional model for handling those 495 review issues that can be put to the IAOC by the IAD and the 496 Committees and addressed in the IAOC monthly teleconference. 497 There is zero bandwidth for deep review or engagement on any 498 topic. Whle the IAOC was intended only ever to be oversight, and 499 the IAD does not need a huge flock of "bosses", the fact that this 500 shallowness has become a friction point suggests that something 501 structural needs to change, either within the IAOC or the IASA 502 staffing. 504 o IETF Trust Trustees: Since its inception, the Trustees of the IETF 505 Trust have been defined as the current sitting IAOC members. 506 While the Trust was being established, there was value in keeping 507 the process of identifying Trustees simple, especially if the 508 Trust did not persist beyond its minimum lifespan (July 1, 2010). 509 The Trust has become an integral part of the IETF support system 510 and seems to be here to stay. It could be useful to appoint 511 Trustees through some process independent of appointing IAOC 512 members, to reduce the level of role and committee overload 513 described elsewhere, and also to make the separation between the 514 Trust and the IETF clearer and better formalized. 516 o IETF participant engagement in IASA: Most participants in the IETF 517 demonstrate little interest in the work done by IASA, including 518 how things are administered and paid for, unless something goes 519 "wrong". (Consider the consistent lack of interest and short 520 volunteer lists for open IAOC positions, contrasted against the 521 e-mail evaluations of meeting venues at each and every IETF 522 meeting. Hmmm. Perhaps the latter dissuades potential 523 volunteers?!). This makes it difficult for the IAOC to identify, 524 pursue, or suggest changes that might ultimately be in the 525 organizations long term (or, sometimes, even short term) interest. 526 More consistent engagement might help. 528 6. Closing remarks 530 The creation of the IETF was a step in formalizing discussions among 531 engineers who were interested in the development of the 532 specifications of the technology to drive the Internet. Creating the 533 IASA was a logical step in bringing together the various 534 administrative functions that had been first offered by different 535 organizations involved in the work. As the world continues to evolve 536 around the IETF and the Internet, perhaps it is time for another 537 review of where we are and whether our administrative formalizations 538 fit the needs of the work at hand. 540 7. Acknowledgements 542 Special thanks to Harald Alvestrand, Brian Carpenter, Dave Crocker, 543 Lucy Lynch and Greg Wood for review and comments on an earlier 544 version of the document. 546 8. References 548 8.1. Normative References 550 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 551 Understanding Concerning the Technical Work of the 552 Internet Assigned Numbers Authority", RFC 2860, 553 DOI 10.17487/RFC2860, June 2000, 554 . 556 [RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the 557 IETF Administrative Support Activity (IASA)", BCP 101, 558 RFC 4071, DOI 10.17487/RFC4071, April 2005, 559 . 561 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 562 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 563 DOI 10.17487/RFC5378, November 2008, 564 . 566 8.2. Informative References 568 [RFC3716] IAB Advisory Committee, "The IETF in the Large: 569 Administration and Execution", RFC 3716, 570 DOI 10.17487/RFC3716, March 2004, 571 . 573 [RFC4371] Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for 574 IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371, 575 January 2006, . 577 [RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540, 578 DOI 10.17487/RFC5540, April 2009, 579 . 581 Author's Address 583 Leslie Daigle 584 Thinking Cat Enterprises LLC 586 Email: ldaigle@thinkingcat.com