idnits 2.17.1 draft-weeb-research-to-internet-stds-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2011) is 4612 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-eggert-successful-bar-bof-06 -- Obsolete informational reference (is this intentional?): RFC 4677 (Obsoleted by RFC 6722) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eardley 3 Internet-Draft BT 4 Intended status: Informational L. Eggert 5 Expires: March 12, 2012 Nokia 6 M. Bagnulo 7 UC3M 8 R. Winter 9 NEC Europe 10 September 9, 2011 12 How to Contribute Research Results to Internet Standardization 13 draft-weeb-research-to-internet-stds-03 15 Abstract 17 The development of new technology is driven by scientific research. 18 The Internet, with its roots in the ARPANET and NSFNet, is no 19 exception. Many of the fundamental, long-term improvements to the 20 architecture, security, end-to-end protocols and management of the 21 Internet originate in the related academic research communities. 22 Even shorter-term, more commercially driven extensions are oftentimes 23 derived from academic research. When interoperability is required, 24 the IETF standardizes such new technology. Timely and relevant 25 standardization benefits from continuous input and review from the 26 academic research community. 28 For an individual researcher, it can however by quite puzzling how to 29 begin to most effectively participate in the IETF and - arguably to a 30 much lesser degree - in the IRTF. The interactions in the IETF are 31 much different than those in academic conferences, and effective 32 participation follows different rules. The goal of this document is 33 to highlight such differences and provide a rough guideline that will 34 hopefully enable researchers new to the IETF to become successful 35 contributors more quickly. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. This document may not be modified, 41 and derivative works of it may not be created, except to format it 42 for publication as an RFC or to translate it into languages other 43 than English. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on March 12, 2012. 57 Copyright Notice 59 Copyright (c) 2011 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Is the IETF the right venue? . . . . . . . . . . . . . . . . . 5 76 3. How to get the IETF to start work on your proposal? . . . . . 7 77 3.1. Identify the right part of the IETF . . . . . . . . . . . 7 78 3.2. Build a community . . . . . . . . . . . . . . . . . . . . 7 79 3.3. Outline your protocol . . . . . . . . . . . . . . . . . . 8 80 3.4. Establish a new WG . . . . . . . . . . . . . . . . . . . . 9 81 4. How to increase the chances that the IETF successfully 82 standardises your proposal . . . . . . . . . . . . . . . . . . 9 83 4.1. Commit enough time, energy and perseverance . . . . . . . 9 84 4.2. Be Open and focus out . . . . . . . . . . . . . . . . . . 10 85 4.3. Seek resolution not perfection . . . . . . . . . . . . . . 11 86 4.4. Implement . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 5.1. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 12 89 5.2. Congestion Exposure . . . . . . . . . . . . . . . . . . . 13 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 8. Note to RFC Editor . . . . . . . . . . . . . . . . . . . . . . 14 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 94 10. Informative References . . . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 97 1. Introduction 99 In telecommunications, standards are essential. More often than not, 100 technology interoperability requires an agreement on a single 101 standard for a given problem. However, unlike most research, 102 standards developments are driven by particular real-world problems 103 and require solutions that are not only theoretically correct, but 104 need to be implementable with state of the art technology in a cost- 105 effective manner, and must be incrementally deployable in the actual 106 Internet by the involved stakeholders. In other words, standards 107 should be both theoretically correct and practically applicable. In 108 the academic world, the former is often more important than the 109 latter! 111 In the IETF, a practically applicable solution that has some well- 112 defined and acceptable deficiencies trumps a theoretically complete 113 and optimal solution that cannot be deployed. Likewise, a solution 114 to an interesting theoretical problem that does not exist in the 115 deployed Internet at large does not require urgent standardization. 116 Finally, standardization oftentimes focuses on piecemeal improvements 117 to existing technology in order to enhance secondary aspects, which 118 does not excite an academic researcher looking to solve juicy 119 problems. 121 These differences between academic research and Internet 122 standardization are the main reason why many researchers initially 123 struggle when they begin to participate in the IETF. Symptoms of 124 this struggle occur, for example: 126 o for ideas that are too far outside the IETF's areas of current 127 work 129 o for ideas that are too high-level for the IETF to begin protocol- 130 level work on 132 o for proposals that solve problems that are not expected to arise 133 for a very long time 135 o if there is a reluctance to give others a say in how a research 136 idea is being made concrete, or giving over change control 137 entirely 139 o if there is a feeling that the IETF "does not listen" to them or 140 does not have "the right people" 142 o if there seems to be no working group or other venue to bring the 143 work to 145 o if the researchers are not interested in topics such as security, 146 performance and operational management - topics that the IETF will 147 consider carefully 149 o when the process seems too time consuming 151 o when the researchers do not have the resources to keep the IETF 152 effort active for an extended period of time 154 o if there is not a convincing enough argument for the IETF to start 155 working on something, despite great simulation results 157 o if the research idea is just not implementable in today's Internet 159 This document attempts to give some basic advice that researchers 160 might want to take into account when deciding to approach the IETF 161 with their ideas, in order to improve their success probability. It 162 is intended to complement the more general advice in [RFC4144] about 163 "How to gain prominence and influence in standards organizations". 164 Other, more general advice and detailed explanations of the structure 165 and inner workings of the IETF can be found in the The Tao of IETF 166 [RFC4677]. 168 The authors have been involved in several research projects, 169 including collaborative ones, which have sought to standardize some 170 of their results at the IETF, and we hope to pass on some advice 171 (sometimes that we have learnt the hard way!). The advice is split 172 into three groups: before you approach the IETF; how to get the IETF 173 to start work on your proposal; and finally how to increase the 174 chances of success once work has begun. 176 2. Is the IETF the right venue? 178 A researcher should consider whether the IETF is the right venue 179 before bringing a proposal to it. A way to do that is to imagine 180 that the IETF has standardized your proposal and it has been 181 deployed, and ask yourself two questions: 183 1. How would the Internet be better? 185 2. What Internet nodes would have been upgraded? 187 It is very important to have a clear explanation about the motivation 188 for your proposal - What would its benefits be? What problem does it 189 solve? Many ideas do not bring a clear benefit to the Internet in 190 the near term (of course they may still be fine pieces of research!). 191 In the past the IETF has often developed protocols that ended up not 192 being used, so it now thinks harder about the benefits before 193 starting new work and makes sure that it solves a current, 194 significant problem rather than one that may theoretically arise in 195 the future. It is best to be specific about what improvement your 196 proposal would make and the use cases in which this would be seen. 198 It is also important to have a simple description of what additions 199 or changes are needed and to which nodes (be they end-hosts, routers, 200 middleboxes etc). Is it substituting for an existing IETF protocol 201 or supplementing one? Again, it is best to be specific - Do both 202 ends need to adopt the new protocol? Can it fall-back or 203 interoperate with the existing IETF protocol? Do the "first movers" 204 (the first nodes that include your protocol) get an improvement, or 205 do the "last movers" gain most? What assumptions do you make about 206 the network or host (perhaps that the host is multi-homed or there 207 are no middleboxes on the path)? While thinking about these things, 208 it is also worthwhile considering operational practices and business 209 models. If you will likely break some of these, you will inevitably 210 face some opposition in the IETF. 212 If it is hard to answer these questions, it may indicate that the 213 idea is too high-level or abstract for the IETF. Then it may be 214 better to approach the IRTF (the research arm of the IETF); the IETF 215 needs a specific protocol-level proposal before it can begin work, 216 whilst the IRTF considers work that is not yet mature enough for 217 standardization. Another danger is that the IETF is the wrong 218 standards body, as a different one would need to standardize your 219 proposal. 221 If your idea involves replacing several IETF protocols and/or 222 upgrading several types of node simultaneously, it is probably best 223 to re-think: the IETF finds it almost impossible to handle radical, 224 "clean slate" proposals that change lots of things at once. Perhaps 225 you can trim off a subset of your idea that's a smaller initial step 226 requiring only an incremental change to an existing protocol, but is 227 still useful? 229 Finally, before bringing a proposal to the IETF you need to be aware 230 that there are intellectual property implications. For example, it 231 will affect any patents you want to file. Less obviously, you grant 232 the IETF the right to publish your contribution and you should inform 233 the IETF if your proposal is covered by a patent. The best thing is 234 to read the IETF's "Note Well" [NoteWell] and the documents linked 235 from there. 237 3. How to get the IETF to start work on your proposal? 239 Having decided that the IETF is the right venue, you now need to 240 persuade the IETF to start work on your idea. We discuss three steps 241 that should help - they can be done in parallel - and then briefly 242 how to form a new WG, if that is necessary. 244 3.1. Identify the right part of the IETF 246 The IETF is a large organization; therefore you need to communicate 247 with the right part of it. The IETF is organized in areas such as 248 routing, security or transport. Within those areas, working groups 249 are responsible for a specific topic. The IETF consists of over 100 250 of those working groups (WGs). So a good step is to identify whether 251 there is already a WG where your work would fit. 253 If yes, then join the WG's mailing list and send email and perhaps 254 write an Internet-Draft. A WG's current set of specific items is 255 defined in its "Charter"; be aware that if your proposal falls 256 outside the WG's current charter, then it would have to be extended 257 before formal work could begin. Most WGs think about re-chartering 258 every year or two, although most are OK for some limited discussion 259 on items outside their current charter. 261 If there isn't a relevant WG, then you should identify the right 262 Area. The WGs are clustered into "Areas" with a common theme such as 263 security, with one or two Area Directors in charge of each Area. You 264 may have to get a new WG created within the most relevant Area; this 265 is a significantly difficult step (see below). 267 Finding the right WG is akin to finding the right conference or 268 journal to submit to. Whilst a poor choice of conference will get 269 your paper rejected as irrelevant, the IETF is friendlier as most WG 270 Chairs and Area Directors will try and redirect your work to a better 271 WG, if you choose poorly. However, ending up with the right "venue" 272 is critical, as only then will you collaborate with the right group 273 of people. 275 3.2. Build a community 277 Standards require agreement and approval by a wide range of people. 278 Therefore you need to persuade others of the merits of your idea. In 279 practice you need to go further and persuade others to do work - at a 280 minimum this will be to thoroughly review your proposal and 281 preferably it will be to develop and test it with you. The IETF 282 community needs to see evidence of wider support, interest and 283 commitment - a lack of reaction means work will not go forward 284 (silence is not consent!). At an early stage support could be 285 demonstrated through comments on the mailing list. It is a very good 286 idea to have some Internet-Drafts jointly authored with people from 287 beyond your research team, perhaps an industry player - for example, 288 you could develop a "use cases" document with a "user", such as an 289 operator. 291 Working with others has the extra benefit that it will help to 292 clarify your idea and explain better its benefits and how it works. 293 There are many experts at the IETF who can help stress test the idea 294 technically and advise about process and culture. You need to get 295 some of them involved as early as possible. 297 It may well be worth trying to hold an informal session at an IETF 298 meeting - this can help build a community of interest for your idea; 299 see the advice in [I-D.eggert-successful-bar-bof]. 301 3.3. Outline your protocol 303 You also need to describe your proposal in a way that others can 304 understand. Your initial document should outline the protocol - it 305 is counter-productive to detail every aspect, unless the protocol is 306 incredibly simple. Firstly, too much detail swamps people with 307 information that they cannot process - most people understand things 308 by learning about them several times at increasing levels of detail. 309 Secondly, providing only an outline makes people feel that they have 310 a chance of making worthwhile suggestions and changes, so they are 311 more likely to actively engage with you. Thirdly, working out 312 details is generally something that a wider group of people is better 313 at than an isolated individual. Fourthly, in order for the IETF to 314 start work, it is more important to convince the IETF that there is a 315 problem that it needs to solve than to convince it about the merits 316 of your solution. 318 A good idea is to document a "protocol model", as described in 319 [RFC4101]: "a short description of the system in overview form ... to 320 answer three basic questions: 1. What problem is the protocol trying 321 to achieve? 2. What messages are being transmitted and what do they 322 mean? 3. What are the important, but unobvious, features of the 323 protocol?" 325 It is best to send your contributions in the form of an Internet- 326 Draft (I-D). Whilst it may seem a burden to convert your nice paper 327 or slides into the idiosyncratic format of an I-D, this is the format 328 that IETF people are used to reading. Also, extracting the IETF- 329 relevant parts of publications into an I-D will often help to 330 identify aspects that need more work by the IETF, such as protocol 331 details glossed over. 333 3.4. Establish a new WG 335 You only need to establish a new WG if the idea falls outside the 336 scope of existing WGs. Establishing a new WG nearly always requires 337 a specific session, called a "BoF" (Birds of a Feather), at one of 338 the IETF's face-to-face meetings. Here the pros and cons of the 339 proposed WG are debated. As part of the preparation for the BoF you 340 need to: 342 o Build a community (see above) 344 o Document the benefits - for example, a problem statement and/or 345 use cases 347 o Document the architecture - for example covering assumptions and 348 requirements on a solution 350 o Suggest specific work items for the proposed WG - typically the 351 protocol to be standardized and the supporting informational 352 documents 354 Getting approval to hold a BoF and running a successful BoF meeting 355 are both quite difficult. It is highly recommended to work with 356 someone experienced and to read the guidance in [RFC5434]. 358 4. How to increase the chances that the IETF successfully standardises 359 your proposal 361 Congratulations, you have got the IETF to agree to start working on 362 your proposal. Now it only remains to do the actual work! In this 363 section we give some advice about ways of working that will increase 364 the chances that the standardization runs smoothly. 366 4.1. Commit enough time, energy and perseverance 368 Those new to standards bodies may be surprised how long and how much 369 effort it takes to standardize something. 371 Success at the IETF requires active participation - to convince 372 others your idea is worthwhile, to build momentum, to gain consensus. 373 Although IETF work is done mainly through mailing lists, in practice 374 face-to-face time is critical, especially for new or substantial work 375 - if possible go to the three IETF meetings a year. 377 It takes quite a long time for a proposal to turn into an IETF 378 standard - even if the proposal is mature when it is first presented. 379 There are many steps: building a community of interest, convincing 380 the IETF to start work, working through suggestions from technical 381 experts and incorporating their improvements, gaining consensus, 382 getting detailed reviews (any IETF publication gets significantly 383 more reviews than an academic publication), going through the formal 384 IETF approval process and so on. Even if you can work full time on 385 the proposal, effort is required from other people who can't. Also, 386 the IETF tends to work in intensive bursts, with activity 387 concentrated in the run-up to and then at the IETF meetings, with 388 lulls of low activity in-between. 390 The IETF proceeds by "rough consensus" - unlike some other standards 391 bodies, there is no voting and no top-down process from requirements 392 to architecture to protocol. The downside of this is that the IETF 393 is not good at making decisions. Hence you need to persevere and 394 guard against decisions unwinding. On the other hand, if the 395 consensus is to reject your proposal or there is little interest in 396 it, persevering is likely to be a waste of time - probably you should 397 give up or re-start at Section 2. 399 All this means that it takes a considerable length of time to 400 complete something at the IETF. Two years is probably a minimum. 401 So, although a typical 3 year research project sounds like plenty of 402 time to do standardization, if you haven't already raised the idea 403 within the first year, you're probably too late to complete before 404 your project ends. Therefore, since it's quite likely that the IETF 405 won't be finished when your project ends, it is particularly 406 important to convince others to help, so that the work is more likely 407 to complete afterwards. 409 4.2. Be Open and focus out 411 It is helpful to come to the IETF with an open mind-set. 413 Co-authorship is good. Some standards bodies value trophy authors, 414 who indicate their support but don't actually do any work. In the 415 IETF, it is much better if co-authors are actually investing cycles 416 on developing the proposal, whereas simple indications of support can 417 be made on the mailing list or at the meetings. 419 In particular, if the IETF is going to standardize something, then in 420 effect it takes ownership of it - it is no longer "yours". Indeed a 421 good milestone of success is when your individual document becomes a 422 WG draft, as then it is owned by the WG. The research mentality is a 423 bit different, as it prizes authorship and confidentiality-until- 424 publication. 426 It is very important to be open to working with others. 428 One specific reason is to get help on aspects beyond your expertise 429 or beyond what you've had time to think about - perhaps how to make 430 your protocol more secure, or how to ensure it is congestion- 431 friendly, or how it impacts network management. The IETF ensures 432 that any protocol it standardises has thought carefully about such 433 aspects. 435 Also, the IETF works by collaboration. For example, there may be two 436 proposals to solve a problem. In academia their proponents may treat 437 each other as rivals and for example write "related work" sections 438 that point out flaws and shortcomings of the opposition. At the IETF 439 they will soon work together on a common document, typically a 440 synthesis of the competing proposals, and be sensitive to each other 441 in order to help build consensus. You will also have to get support 442 - or at least not vehement opposition - from IETF people working on 443 other topics. So you need to be aware what else the IETF is doing 444 (in case your proposal conflicts) and what other problems exist in 445 the Internet today (in case your proposal exacerbates them). 447 Finally, collaborative research projects sometimes find it difficult 448 to be open to working with others. Firstly, such projects typically 449 have a consortium agreement about confidentiality - it must not 450 prevent you engaging properly day-to-day with people outside the 451 project. Secondly, you may have to spend considerable effort on 452 intra-project coordination - but an individual researcher only has so 453 much energy and enthusiasm for collaborating, so if you spend a lot 454 of time liaising between different groups within your project, then 455 you have little left for working with the IETF. 457 4.3. Seek resolution not perfection 459 The research mind-set is often to investigate very thoroughly all 460 possible details about an idea - to seek perfection - sometimes with 461 no particular deadline. The IETF mind-set is to get something done 462 and out there that works, albeit imperfectly; if people find it 463 useful, then there'll be another iteration to improve it, probably to 464 meet needs that only become apparent on widescale deployment. The 465 philosophy is to find a reasonable solution to the problem that 466 currently exists - time spent over-optimizing may simply mean that 467 the solution has been superseded (perhaps the problem has been solved 468 in some other way, or perhaps the problem was so significant that a 469 different approach had to be found to avoid the problem). 471 4.4. Implement 473 The IETF is very impressed by actual implementations: "running code". 474 It helps smooth the standards process, it helps people believe it 475 really works, and it helps you and others discover any issues. 477 An implementation that others can download and try is extremely 478 helpful in getting your protocol actually deployed - and presumably 479 that is your real objective, not simply to get an IETF standard! In 480 the longer term, you may need to think how to get it incorporated in 481 the Linux kernel, for instance. 483 Overall it is very hard to get a protocol in actual widespread use. 484 There are far more IETF protocols on paper than in use. 486 5. Examples 488 In this section, we include some examples where the authors have been 489 deeply involved and have managed (we believe) to bring the research 490 output of a collaborative research project successfully into the 491 IETF. 493 5.1. Multipath TCP 495 Multipath TCP enables a regular TCP connection to use multiple paths 496 simultaneously. It extends TCP to allow the use of multiple IP 497 addresses by each endpoint. This work is one output of the Trilogy 498 research project which was brought to the IETF for standardization 499 and it is currently making good progress. We provide a brief 500 overview of the steps taken. 502 The first stage was doing some early socialization of the main ideas 503 of MPTCP. Presentations were made in several relevant WGs: the 504 Routing Research Group (July 2008) and the Transport Area Open 505 meeting (July 2008 and March 2009). In addition, a mailing list was 506 created, open to anyone who was interested in discussing Multipath 507 TCP related issues in the IETF context, and a public web page was 508 created containing Multipath TCP related material, including papers, 509 Internet Drafts, presentations and code. The feedback received was 510 encouraging enough to continue with the effort of bringing the work 511 to the IETF. 513 Once we had verified that the proposed ideas had potential traction 514 in the IETF, the next step was to identify the proper venue for the 515 proposed work. There were two choices, namely, to go for a BoF, with 516 a view to a new WG, or to try to add additional work items to an 517 existing WG, in particular TCPM seemed a good candidate. After 518 talking to the Area Directors, it seemed that having a BoF was the 519 right approach, at least for the initial discussion stage. So, a BoF 520 proposal was submitted to the Transport ADs for the IETF 75 meeting 521 held in Stockholm on July 2009. The initial BoF proposal was crafted 522 by Trilogy people, but was sent to the open mailing list for 523 discussion and modification from the rest of the community. The BoF 524 request was approved and the MPTCP BoF was held at the IETF 75 525 meeting. 527 The general feedback received during the BoF was that there was 528 enough interest and energy in the community to do this work within 529 the IETF. A first charter draft was posted on the mailing list for 530 comments a couple of months after the BoF. After a month or so of 531 charter discussion on the mailing list, the MPTCP Working Group was 532 created in October 2009. The charter includes deliverables due to 533 March 2011. 535 The MPTCP working group has, so far, made significant progress and 536 most of the milestones have been delivered on schedule [MPTCP]. 538 5.2. Congestion Exposure 540 Congestion Exposure enables sending end-hosts to inform the network 541 about the congestion encountered by previous packets on the same 542 flow. This allows the network devices to act upon the congestion 543 information and the perceived user behaviour. Like the MPTCP work, 544 it is an output of the Trilogy research project and has been 545 successfully brought to the IETF. We next describe the steps 546 followed to do so. 548 In this case, early socialization included presentations at the 549 Internet Congestion Control Research Group and the Internet Area 550 meeting at the IETF 75 meeting in July 2009, the creation of an open 551 mailing list to discuss Congestion Exposure related issues in the 552 IETF and posting the related materials such as papers, Internet 553 drafts, and code in a public web page. In addition, an informal, 554 open meeting (sometimes called a Bar-BoF in IETF parlance) was held 555 during the IETF 75 meeting. 557 After processing the feedback received in the Bar-BoF, a BoF proposal 558 was submitted to the Internet Area ADs for the IETF 76 meeting in 559 November 2009. The BoF was accepted and was held as planned. While 560 the feedback received in the BoF was positive, the IESG was uncertain 561 about chartering a Working Group on this topic. (The IESG is the 562 IETF's management body and consists of all the Area Directors.) In 563 order to address the remaining concerns of the IESG, another BoF was 564 held at the following IETF meeting. 566 After much debate, the CONEX WG was approved by the IESG but the 567 scope of its charter was limited compared with the original proposal. 568 This was due to some concerns regarding the proposed allocation of 569 the last bit in the IPv4 header. The CONEX WG serves as a good 570 example to illustrate the kind of compromise that is necessary when 571 research aspiration meets Internet standardization. The CONEX WG 573 [CONEX] held its first meeting at the IETF 78 meeting in July 2010. 574 Its charter contains deliverables up to November 2011. 576 6. IANA Considerations 578 This document raises no IANA considerations. 580 [Note to the RFC Editor: Please remove this section upon 581 publication.] 583 7. Security Considerations 585 This document has no known security implications. 587 [Note to the RFC Editor: Please remove this section upon 588 publication.] 590 8. Note to RFC Editor 592 The IESG discussed whether this document needs the RFC Editor /IESG 593 note typical of an Independent submission. 595 [Note to the RFC Editor: Please remove this section upon 596 publication.] 598 9. Acknowledgments 600 Part of this work was funded by the Trilogy Project [TRILOGY], a 601 research project supported by the European Commission under its 602 Seventh Framework Program. 604 Similar material was accepted for publication in ACM CCR, July 2011 605 [CCR]. 607 10. Informative References 609 [CCR] Bagnulo, M., Eardley, P., Eggert, L., and R. Winter, "How 610 to Contribute Research Results to Internet 611 Standardization", ACM CCR July, July 2011. 613 [CONEX] "Congestion Exposure working group", 614 http://tools.ietf.org/wg/conex/. 616 [I-D.eggert-successful-bar-bof] 617 Eggert, L. and G. Camarillo, "Considerations for Having a 618 Successful "Bar BOF" Side Meeting", 619 draft-eggert-successful-bar-bof-06 (work in progress), 620 August 2011. 622 [MPTCP] "Multipath TCP working group", 623 http://tools.ietf.org/wg/mptcp/. 625 [NoteWell] 626 "Note Well", http://www.ietf.org/about/note-well.html. 628 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 629 June 2005. 631 [RFC4144] Eastlake, D., "How to Gain Prominence and Influence in 632 Standards Organizations", RFC 4144, September 2005. 634 [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's 635 Guide to the Internet Engineering Task Force", RFC 4677, 636 September 2006. 638 [RFC5434] Narten, T., "Considerations for Having a Successful Birds- 639 of-a-Feather (BOF) Session", RFC 5434, February 2009. 641 [TRILOGY] "Trilogy Project", http://www.trilogy-project.org/. 643 Authors' Addresses 645 Philip Eardley 646 BT 647 Adastral Park, Martlesham Heath 648 Ipswich 649 England 651 Phone: 652 Email: philip.eardley@bt.com 653 URI: 655 Lars Eggert 656 Nokia Research Center 657 P.O. Box 407 658 Nokia Group 00045 659 Finland 661 Phone: +358 50 48 24461 662 Email: lars.eggert@nokia.com 663 URI: http://research.nokia.com/people/lars_eggert/ 665 Marcelo Bagnulo 666 Universidad Carlos III de Madrid 667 Av. Universidad 30 668 Madrid 669 Spain 671 Phone: 672 Email: marcelo@it.uc3m.es 673 URI: 675 Rolf Winter 676 NEC Europe 677 Heidelberg 678 Germany 680 Phone: 681 Email: rolf.winter@neclab.eu 682 URI: