idnits 2.17.1 draft-arkko-iesg-crossarea-03.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 (February 7, 2013) is 4089 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational February 7, 2013 5 Expires: August 11, 2013 7 Experiences from Cross-Area Work at the IETF 8 draft-arkko-iesg-crossarea-03 10 Abstract 12 This memo discusses the reasons for IETF work on topics that cross 13 area boundaries. Such cross-area work presents challenges for the 14 organization of the IETF as well as on how interested parties can 15 participate the work. The memo also provides some suggestions on 16 managing these challenges. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 11, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Examples of Cross-Area Work . . . . . . . . . . . . . . . . . 3 54 3. Rationale for Cross-Area Work . . . . . . . . . . . . . . . . 4 55 4. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Ten Recommendations . . . . . . . . . . . . . . . . . . . . . 8 57 6. Informative References . . . . . . . . . . . . . . . . . . . . 10 58 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 1. Introduction 63 This memo discusses IETF work that crosses area boundaries. Some 64 examples about such work are given in Section 2. The reasons for 65 initiating work that involves cross-area aspects are discussed in 66 Section 3. From the perspective of a participant interested in a 67 specific effort, the area designations matter little. If the work is 68 interesting, the necessary people come to the meetings and work on 69 the specifications. However, cross-area work does present some 70 challenges for the organization of the IETF as well as on how 71 interested parties can participate the work. These issues are 72 discussed in Section 4. Finally, Section 5 provides some suggestions 73 on managing these challenges in an effective way. 75 2. Examples of Cross-Area Work 77 Many IETF efforts cross area boundaries. Some recent examples of 78 such work include: 80 o The development of a routing-protocol based bridging model. This 81 work has been going on in the TRILL WG on the Internet Area and in 82 parallel in the ISIS WG on the Routing Area. 84 o The work that started in 2008-2009 to address impending IPv4 85 address runout and remaining needs for transition mechanisms to 86 support IPv6 deployment. This was worked on in the V6OPS WG on 87 the Operations and Management Area, in the BEHAVE WG on the 88 Transport Area, and in the SOFTWIRE WG on the Internet Area. 90 o The HOMENET WG is developing automatic provisioning tools for home 91 networks and will require assistance from, for instance, Routing 92 Area WGs to build the necessary routing protocol zero- 93 configuration extensions. 95 o The RENUM WG on the Operations and Management Area is addressing 96 renumbering issues, but will have to work with other areas if 97 changes or extensions to specific protocols are required. 99 o The allocation of a new private address space to employ a shared 100 address for multiple subscribers in networks employing NAT44 was 101 discussed in the INTAREA, OPSAREA, BEHAVE, and V6OPS WGs. 103 o The LWIG WG on the Internet Area is documenting existing practices 104 for creating lightweight implementations of the TCP/IP stack and 105 application protocols. Specific recommendations on transport and 106 application protocols obviously need participation from those 107 areas, however. 109 o The Routing Area, Transport Area, and Security Area have worked 110 together on security mechanisms and key management tools necessary 111 to secure BGP sessions carried on top of TCP. For instance, the 112 SIDR and KARP WGs are in the Routing Area, but they are clearly 113 focused on topics that are generally found in the Security Area. 115 o Many IETF topics involve operational aspects as well as protocol 116 development. For instance, issues with address selection policies 117 have been discussed in the V6OPS WG on the Operations and 118 Management Area, and solutions for these problems were taken up by 119 the 6MAN WG on the Internet Area. 121 3. Rationale for Cross-Area Work 123 From an IETF participant's point of view, it is important that there 124 is a working group where the technical topic that he or she is 125 interested in can be discussed. The area and the management 126 structure matters little for this, as long as the working group can 127 work on all of the relevant aspects. These aspects, may, however, 128 involve different types of expertise or topics commonly handled in 129 different groups of people at the IETF. Cross-area work is needed, 130 of course, in any situation where a particular technical problem does 131 not cleanly map to one organization. For instance, some problems may 132 be more about the entire system than any individual node or protocol 133 layer. The work done in the RENUM and LWIG WGs falls into this 134 category, for instance. 136 In other cases different types of individuals may have specific 137 expertise that is helpful to solve a problem. For instance, some 138 models of interworking between IPv4 and IPv6 required expertise from 139 the specialists on IPv6 on the Internet Area and the specialists on 140 translation tools on the Transport Area. A common form of providing 141 expertise from multiple areas involves operational aspects and 142 protocol development. Such work often happens in a sequential 143 manner. The operators first discuss practical problems, then provide 144 suggestions for operational ways to contain the problems, and 145 eventually may ask for new solutions to reduce these problems. The 146 actual solution work is then taken up by the relevant technical 147 community that works on the protocol that needs to be extended. 149 Another common example of a situation where two different areas of 150 expertise are needed is developing security features for a protocol. 151 The protocol specialists are needed to understand the application and 152 its requirements and the security specialists are needed to help with 153 understanding the possible security issues and potential solutions. 154 Such work is commonly not organized as cross-area work, however. 155 Typically, a "security advisor" is assigned to a protocol working 156 group. The advisor and other security experts merely attend the 157 group. The advisor model is used in other instances as well, 158 including MIB doctors and routing area expertise. However, in some 159 cases the need to work together goes beyond such individual 160 participation. For instance, the security mechanisms and their key 161 management tools necessary to secure BGP sessions carried on top of 162 TCP have led to the creation of significant efforts both in the 163 Routing and Security Areas. 165 Sometimes a large body of work is split into different parts merely 166 to spread the workload. The IPv6 transition topic has been so big 167 for the IETF that part of the reason for splitting the work to three 168 areas was to ensure there was enough participants, chairs, and area 169 directors to handle the workload. 171 4. Challenges 173 Cross-area work does present some challenges, however. Apart from 174 the advisor model there are no established practices and the 175 processes and division of responsibility differs from case to case 176 [RFC2026]. 178 Some of the issues include: 180 Fuzzy Hot Topics 182 Many recently proposed "hot" areas of work for the IETF have been 183 on vaguely defined topics that cover many possible areas. For 184 instance, work on new technologies for data centers or cloud 185 computing. In many cases it is unclear if the topic is truly a 186 cross-area topic for some fundamental reason, or if the IETF has 187 just not succeeded yet in teasing out concrete tasks from this 188 topic. For instance, operational and performance problems are 189 often discussed in Operations & Management area working groups. 190 Sometimes, after some analysis, these problems turn out to be 191 something where protocol modifications or extensions would help. 192 But as soon as such a conclusion is made, it typically falls on 193 other areas to make the actual modifications. Typically, there 194 are existing working groups that are responsible for the 195 technology in question. 197 Area Shopping 199 If the IESG does not manage the process in an coordinated manner, 200 this can lead to "area shopping" where a particular topic is being 201 discussed in several areas and working groups and may be taken up 202 in one area even if dismissed in others. This may be fine, if the 203 decision is made due to the topic fitting better an area. But it 204 is also possible that concerns raised in one forum are not 205 understood in another, and this can lead to an effort going 206 forward after finding the "lowest bar" forum to take it up. 208 Lack of Common IESG Vision 210 In many of the complex cross-area topics, the IESG has initially 211 had no strategy on how the work shall be divided, or even a common 212 set of goals. The IESG has also had several internal arguments 213 over some topics. Clearly, establishing a common vision between 214 the relevant ADs for how to proceed with a given topic is 215 essential for a successful outcome. Part of the problem here is 216 that IESG does not normally develop a master plan, but rather 217 individual documents and charter proposals are brought to the IESG 218 in a piecemeal fashion, one by one. This makes it hard to see 219 bigger trends and possibilities for colliding work. 221 Similarly, the yearly changes to the people on the IESG may change 222 the position that IESG members have on a topic, which can lead to 223 surprises to the community and new discussions in the IESG. 225 These problems exist both for specific efforts and the general 226 strategies for handling cross-area work. IESG members have had 227 varying opinions on whether to create specific, formally 228 recognized cross-area working groups or handle them in some other 229 way. 231 Problem Ownership 233 A more common issue is that the different organizations typically 234 have different motivations. A group of developers may be very 235 interested in solving, say, a bridging problem in a particular 236 way, and they are funded full-time by their employers to get this 237 work done. If this group is dependent on some other people on 238 making changes to a technology that they are in charge of, it is 239 likely that there is not a similar level of commitment. The other 240 people are unlikely to be able to spend all their time on this 241 project, for instance. This creates an eventual tussle between 242 different interests and may lead to frustration and different 243 expectations on the timelines necessary for the work. 245 Of course, the other side of the issue is that in most cases it 246 would not be a good idea to let the first group develop the 247 necessary changes by themselves either. Often the second group is 248 the true expert on the technology and needs to be involved in 249 order for a change to be done so that it does not cause breakage 250 elsewhere. 252 Rigid Topic Ownership 254 A related issue is that topic ownership should not necessarily be 255 static over time. Sometimes it makes sense to review and change 256 the area that is responsible for a particular topic. Many working 257 groups and topics have moved back and forth between Internet and 258 Routing or Applications and Transport areas, for instance. 259 Periodic review and re-assessment is healthy and encouraged. 261 Similarly, requests for cross-area review are relatively 262 infrequent or sent only to a particular subset of people in an 263 area (such as a directorate). For the regular participant it is 264 difficult to find out where there are important documents that 265 would deserve more review. 267 Attention Focus 269 It is natural for the leaders of an organization to develop a 270 closer relationship with work within their own part of the 271 organization. An AD may make a status check with his own WG 272 chairs, for instance, but not with those on neighboring areas 273 working on another half of some common topic. 275 Scheduling 277 Current IETF scheduling principle is centered around a sequences 278 of meetings of working groups in the same area. This makes it 279 possible for someone to follow all meetings in his or her area, 280 and enables the ADs to attend all the meetings they have to. 281 Cross-area work breaks this principle, as, for instance, technical 282 experts on some commonly used technology now may have to attend a 283 meeting from another area. The same applies to ADs and chairs. 284 This has been a practical problem for Internet Area ADs, for 285 instance, as they have to attend V6OPS and BEHAVE WG meetings in 286 addition to ones in their own area, but this is not readily 287 apparent to the people who perform scheduling. 289 Process vs. Substance 291 In recent years there has been a tendency to take up 292 organizational discussions in the precious few hours that we have 293 for face-to-face discussions at the IETF. The author believes 294 that it would be most useful to reserve the face-to-face 295 discussion time for the difficult technical topics, and the 296 relevant chairs and ADs should decide organizational matters off- 297 line after a consultation with the relevant mail list. 299 Cross-area and cross-WG work, duplicated presentations in multiple 300 forums, and formal messages between groups are usually not good 301 signs about the health of a standards organization. Too much time 302 may be spent on internal discussions, and too little on technical 303 substance, running code, and customer or user input. 305 Incentives 307 Ultimately, motivation determines the effort that IETF 308 participants will make toward topics that are not part of their 309 primary goals or day job requirements. The participants are 310 volunteers that do not have time to keep up with unlimited number 311 of mailing lists and documents. Some of them may end up following 312 some topics based on attending a meeting that they found 313 interesting. Some of them may end up doing something because 314 someone else requested them to look at a particular issue. And 315 some may dig into a topic based on hearing about in the hallways 316 of an IETF meeting. But in general, there is limited opportunity 317 and bandwidth for looking into new topics. 319 5. Ten Recommendations 321 There are no hard and fast rules for complex development efforts that 322 span multiple areas of expertise. However, the author believes that 323 experience has shown the following guidelines can improve the 324 situation in many cases. 326 1. Complex organizational structure should not be initiated 327 lightly. It should be reserved for situations that truly demand 328 it. Re-organization and moving responsibilities to one place 329 should be considered as alternatives. 331 2. People matter, organizations do not. The essence of most cross- 332 area work is getting the right expertise to the room and to the 333 mail list. This does not happen through mere organizational 334 forms, people have to be interested in the problem. 336 Example: The IPv6 transition problem has been such an 337 interesting issue for a large class of IETF contributors that 338 a significant number of key participants appear in the 339 relevant meetings no matter what area or working group they 340 are under. 342 3. Chair and advisor selection. Given that people matter, many 343 cross-area issues can be solved through assigning suitable 344 people to act as chairs and technical advisors. For instance, 345 many groups have one chair focused on protocol aspects and 346 another one focused on operational aspects. Typically, the 347 first type of a chair has protocol design and implementation 348 experience in the topic, and the second one may be operating 349 networks and may have an Operations and Management Area 350 background. 352 4. Cross-area review. Similarly, expertise is not brought in by an 353 area designation, it is brought through the right people 354 actually commenting on the specifications. Encouraging cross- 355 area review is therefore helpful, for instance through 356 directorates assigned to review important documents from other 357 areas. 359 5. Ensure that the IESG has a clear understanding of the topic area 360 and the plan ahead. It is recommended that the IESG discusses 361 the division of responsibilities and the plan for any major 362 cross-area effort upfront, and documents the agreed plan in 363 writing. Plans may naturally have to be revisited, as 364 understanding the needs for further work is a continuous 365 process. In addition, as the membership of the IESG evolves, it 366 is necessary to ensure that the new members support the plan. 368 6. As with every topic, the management (IESG and working group 369 chairs) need to clearly communicate the work plan to all 370 interested participants. Who is responsible for what? What is 371 in scope for a working group? Can additional items outside this 372 scope be taken elsewhere, and if so, where? When a working 373 group closes, where are remaining items and maintenance topics 374 expected to be handled? 376 The key tool for defining the scope is the working group 377 charter. When work is identified as cross-area, it is necessary 378 to to make this clear in the charter. The charter should also 379 provide guidance on the work scope and who is responsible for 380 what. This helps then later when it is necessary to assign area 381 advisors, get early cross-area review, and so on. 383 7. The best examples of successful cross-area work involve 384 combining two pieces of expertise, with both parties having an 385 incentive to complete the work. 387 8. One good model that has been used in the Internet Area employs a 388 protocol detail working group and a consumer working group. 390 This model has been used with work that touches upon the DHCP 391 protocol, for instance. There are always two working groups: 392 the protocol working group and the consumer working group. The 393 DHC WG is not chartered to develop any extensions except for 394 maintaining the DHCP infrastructure itself. Extensions for a 395 specific application purpose (such as delivering location 396 information) must be owned by some other working group that is 397 chartered to develop those applications (such as the GEOPRIV WG 398 in the Real-Time Applications Area). The role of this consumer 399 working group is to drive the development of the entire 400 application where a DHCP option may play a small role. 402 The role of the DHC WG is to ensure that the DHCP aspects of 403 these extensions are properly designed. It is often easy to see 404 how the DHCP experts are clearly better at designing the right 405 container and behavior model for the DHCP part, and how the 406 consumer working group experts clearly understand the semantics 407 and needs for the actual data much better. 409 Division of responsibilities in this manner is encouraged in 410 other situations as well. 412 9. Scheduling models for the IETF should take cross-area work into 413 account in a better way. Possible tools to improve this include 414 the ability to specify entire areas as conflicts in the meeting 415 request tool. One commonly occurring special case of such 416 conflicts is ADs from multiple areas that are interested in a 417 working group. However, it is perhaps more important to 418 consider the wider audiences, such as directorates. 420 10. In general, the ability to associate work with all the areas 421 that it relates to will be helpful not just for scheduling, but 422 also for participants following an area of work, review teams, 423 and so on. 425 6. Informative References 427 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 428 3", BCP 9, RFC 2026, October 1996. 430 Appendix A. Acknowledgments 432 The author would like to thank the IESG for inspiring discussions 433 around the IETF processes. In particular, Dan Romascanu, Adrian 434 Farrell, Russ Housley, Lars Eggert, David Harrington, Ron Bonica, 435 Ralph Droms, Brian Haberman, Robert Sparks, and Stewart Bryant have 436 shared their thoughts on this matter over the years. Nothing in this 437 draft should be interpreted as an IESG opinion, however, as the draft 438 is the author's opinion only. 440 The author would also like to thank Joel Halpern, Keith Moore, Paul 441 Hoffman, Samita Chakrabarti, Melinda Shore, Barry Leiba, JW Atwood, 442 Tom Petch, Wesley George, Thomas Narten, Tony Hansen, SM, and Dan 443 Wing for feedback. 445 Author's Address 447 Jari Arkko 448 Ericsson 449 Jorvas 02420 450 Finland 452 Email: jari.arkko@piuha.net