RFC 6417

How to Contribute Research Results to Internet Standardization 🎀

Okay bestie, so this is an Informational document from the Independent Submission stream, published in November 2011 🍓. It was written by P. Eardley (BT), L. Eggert (Nokia), M. Bagnulo (UC3M), and R. Winter (NEC Europe). It's ISSN 2070-1721, and it doesn't list any RFCs it obsoletes or updates. It's giving research-meets-standards main character energy 💅✨

Abstract

Okay so, new tech comes from scientific research, and the Internet is no exception 🦋 Its roots go back to the ARPANET and NSFNet. A lot of the big, long-term upgrades to its architecture, security, end-to-end protocols, and management come from academic research communities. Even the shorter-term, more commercially driven extensions are often built on academic research. When interoperability is needed, the IETF standardizes the new tech. And standardization works best when it keeps getting input and review from the academic research community 🫶

For individual researchers, though, figuring out how to actually participate in the IETF can be kind of confusing 😭 And to a much lesser degree, the same goes for the IRTF. The IETF works very differently from academic conferences, so participating well follows different rules. This document is here to point out those differences and give a rough guideline, so researchers who are new to the IETF can become successful contributors more quickly. Bestie, it's a glow-up guide 🧚

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish this document at its discretion, and they make no statement about its value for implementation or deployment. Documents the RFC Editor approves for publication are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be found at http://www.rfc-editor.org/info/rfc6417.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document 📜

Table of Contents

   1. Introduction ....................................................3
   2. Is the IETF the Right Venue? ....................................4
   3. How to Get the IETF to Start Work on Your Proposal? .............6
      3.1. Identify the Right Part of the IETF ........................6
      3.2. Build a Community ..........................................6
      3.3. Outline Your Protocol ......................................7
      3.4. Establish a New Working Group ..............................8
   4. How to Increase the Chances that the IETF Successfully
      Standardizes Your Proposal ......................................8
      4.1. Commit Enough Time, Energy, and Perseverance ...............8
      4.2. Be Open and Focus Out ......................................9
      4.3. Seek Resolution, Not Perfection ...........................10
      4.4. Implement .................................................10
   5. Examples .......................................................11
      5.1. Multipath TCP .............................................11
      5.2. Congestion Exposure .......................................12
   6. Security Considerations ........................................13
   7. Acknowledgments ................................................13
   8. Informative References .........................................13

1. Introduction ✨

In telecom, standards are essential 💅 Most of the time, technology only interoperates if everyone agrees on one standard for a given problem. But unlike most research, standards work is driven by real-world problems. The solutions have to be theoretically correct, and they also need to be implementable with state-of-the-art technology in a cost-effective way. They have to be incrementally deployable in the actual Internet by the stakeholders involved. So standards should be both theoretically correct and practically applicable. In the academic world, the first one is often more important than the second, and that's a whole mood 🙈

In the IETF, a practically applicable solution with some well-defined, acceptable deficiencies beats a theoretically complete and optimal solution that can't be deployed 👑 Likewise, a solution to an interesting theoretical problem that doesn't exist in the deployed Internet at large doesn't need urgent standardization. And finally, standardization often focuses on piecemeal improvements to existing technology to enhance secondary aspects. That doesn't excite an academic researcher who's looking to solve juicy problems 🍓

These differences between academic research and Internet standardization are the main reason many researchers struggle at first when they start participating in the IETF 😭 The struggle can look like this:

• for ideas that are too far outside the IETF's areas of current work
• for ideas that are too high-level for the IETF to begin protocol-level work on
• for proposals that solve problems that are not expected to arise for a very long time
• if there is a reluctance to give others a say in how a research idea is being made concrete, or giving over change control entirely
• if there is a feeling that the IETF "does not listen" to them or does not have "the right people"
• if there seems to be no working group or other venue to bring the work to
• if the researchers are not interested in topics such as security, performance, and operational management -- topics that the IETF will consider carefully
• when the process seems too time consuming
• when the researchers do not have the resources to keep the IETF effort active for an extended period of time
• if there is not a convincing enough argument for the IETF to start working on something, despite great simulation results
• if the research idea is just not implementable in today's Internet

This document gives some basic advice that researchers might want to keep in mind when deciding to bring their ideas to the IETF, so they can boost their odds of success 🎯 It's meant to complement the more general advice in [RFC4144] about "How to Gain Prominence and Influence in Standards Organizations". For more general advice and detailed explanations of how the IETF is structured and how it works inside, check out "The Tao of IETF" [RFC4677] 📚

The authors have been part of several research projects, including collaborative ones, that tried to standardize some of their results at the IETF. So we want to pass on some advice (sometimes it's stuff we learned the hard way!) 🥲 The advice is split into three groups: before you approach the IETF; how to get the IETF to start work on your proposal; and finally how to increase your chances of success once work has begun.

2. Is the IETF the Right Venue? 🧐

Before you bring a proposal to the IETF, you should check whether it's actually the right venue. One way to do that is to imagine the IETF has already standardized your proposal and it's been deployed, and then ask yourself two questions:

1. How would the Internet be better?
2. What Internet nodes would have been upgraded?

It's super important to have a clear explanation of your proposal's motivation: what would its benefits be? What problem does it solve? Lots of ideas don't bring a clear benefit to the Internet in the near term (of course they can still be fine pieces of research!) ✨ In the past, the IETF has often developed protocols that ended up not being used. So now it thinks harder about the benefits before starting new work, and it makes sure a proposal solves a current, significant problem rather than one that might theoretically show up in the future. It's best to be specific about what improvement your proposal would make and the use cases where that improvement would be seen.

You also need a simple description of what additions or changes are needed, and which nodes they apply to (end-hosts, routers, middleboxes, etc.) 🎀 Is it substituting for an existing IETF protocol, or supplementing one? Again, be specific. Do both ends need to adopt the new protocol? Can it fall back or interoperate with the existing IETF protocol? Do the "first movers" (the first nodes that include your protocol) get an improvement, or do the "last movers" gain the most? What assumptions do you make about the network or host (maybe that the host is multi-homed, or that there are no middleboxes on the path)? While you think through all this, it's also worth considering operational practices and business models. If you're likely to break some of these, you'll inevitably face some opposition in the IETF 🙃

If these questions are hard to answer, the idea might be too high-level or abstract for the IETF. Then it may be better to approach the IRTF (the research arm of the IETF) 🧪 The IETF needs a specific protocol-level proposal before it can begin work, while the IRTF considers work that isn't mature enough for standardization yet. Another danger is that the IETF is the wrong standards body, because a different one would need to standardize your proposal.

If your idea involves replacing several IETF protocols and/or upgrading several types of nodes all at once, it's probably best to rethink it 💀 The IETF finds it almost impossible to handle radical, "clean slate" proposals that change lots of things at once. Maybe you can trim off a subset of your idea that's a smaller initial step requiring only an incremental change to an existing protocol. But you need to consider whether it's still useful.

Last but not least, before bringing a proposal to the IETF, know that there are intellectual property implications. For example, it will affect any patents you want to file. Less obviously, you grant the IETF the right to publish your contribution, and you should inform the IETF if your proposal is covered by a patent. For more about the rights you grant to the IETF, the best thing to read is the IETF's "Note Well" [NoteWell] and the documents linked from there 📝

3. How to Get the IETF to Start Work on Your Proposal? 🚀

Once you've decided the IETF is the right venue, you now need to persuade the IETF to start work on your idea. We cover three steps that should help, and they can be done in parallel 🫶 After that, we briefly cover how to form a new working group (WG), if that's necessary.

3.1. Identify the Right Part of the IETF 💅

okay so the IETF is HUGE 😭 like, you need to talk to the right part of it or nobody's gonna hear you. It's split into areas like routing, security, or transport, and inside those areas are working groups (WGs) that each handle a specific topic. There are over 100 WGs 🫠 so step one is figuring out whether a WG already exists for your work.

If one does, join its mailing list, send emails, and maybe write an Internet-Draft 🎀 A WG's current to-do list is called its "Charter" 📜 Be aware that if your idea is outside the charter, the charter would have to be extended before any formal work could start. Most WGs think about re-chartering every year or two, but most also allow some limited discussion of items outside their current charter, so you're not totally locked out 🦋

If no suitable WG exists, then find the right Area. WGs are grouped into "Areas" with a shared theme like security, and each Area has one or two Area Directors in charge of it 👑 You might have to get a brand new WG created in the most relevant Area, and ngl that is a seriously hard step (more on that below) 💀

Picking the right WG is kind of like picking the right conference or journal to submit your paper to 📚 A bad conference choice gets your paper rejected as irrelevant, but the IETF is way friendlier about it, since most WG Chairs and Area Directors will try to redirect your work to a better WG if you pick poorly 🫶 Still, ending up in the right "venue" is critical, because that's the only way you'll collaborate with the right group of people ✨

3.2. Build a Community 🌸

Standards need agreement and approval from a wide range of people, so you have to convince others that your idea is worth it. But honestly? You need to go further and convince them to actually do work 😤 At a minimum, that means thoroughly reviewing your proposal, and preferably developing and testing it with you. The IETF community needs to see evidence of wider support, interest, and commitment. A lack of reaction means work will not go forward (silence is not consent!) 🙅‍♀️ Early on, support can show up as comments on the mailing list. It's also a very good idea to have some Internet-Drafts jointly authored with people from beyond your research team, maybe an industry player 🧚 For example, you could write a "use cases" document together with a "user", such as an operator.

Working with others has the extra perk of helping you clarify your idea and explain its benefits and how it works, which is so real 🙌 There are tons of experts in the IETF who can stress test your idea technically and advise you on process and culture, so get some of them involved as early as possible 💜

It may be worth trying to hold an informal session at an IETF meeting too 🦋 That can help build a community of interest around your idea. See the advice in [BAR-BOF] for more.

3.3. Outline Your Protocol 🍓

You also need to describe your proposal in a way other people can actually understand 🧠 Your first document should outline the protocol. Detailing every single aspect is counter-productive, unless the protocol is incredibly simple. Firstly, too much detail swamps people with information they can't process. Most people understand things by learning about them several times at increasing levels of detail 📈 Secondly, a bare outline makes people feel they have a real chance to make worthwhile suggestions and changes, so they're way more likely to engage with you 🫶 Thirdly, working out the details is usually something a wider group is better at than an isolated individual 👯‍♀️ Fourthly, for the IETF to start work, it matters more to convince it that there's a problem it needs to solve than to convince it that your solution is great 🔥

A good idea is to document a "protocol model", as described in [RFC4101]: "a short description of the system in overview form ... to answer three basic questions: 1. What problem is the protocol trying to achieve? 2. What messages are being transmitted and what do they mean? 3. What are the important, but unobvious, features of the protocol?"

Send your contributions as an Internet-Draft (I-D) 📄 I know it feels like a pain to squish your nice paper or slides into this idiosyncratic format, but it's the format IETF people are used to reading, so it's worth it 💖 Pulling the IETF-relevant parts of your publications into an I-D also tends to reveal the bits that need more work from the IETF, like protocol details you glossed over 👀

3.4. Establish a New Working Group 🎀

You only need a new WG if your idea falls outside the scope of the existing ones 🙃 Creating a new WG almost always means a specific session called a "BoF" (Birds of a Feather) at one of the IETF's face-to-face meetings 🐦 That's where the pros and cons of the proposed WG get debated, so it's giving pressure 😭 As part of your BoF prep, you need to:

• Build a community (see above)
• Document the benefits: for example, a problem statement and/or use cases
• Document the architecture: for example covering assumptions and requirements on a solution
• Suggest specific work items for the proposed WG, typically the protocol to be standardized and the supporting informational documents

Getting approval to hold a BoF and running a successful BoF meeting are both quite difficult 😩 Working with someone experienced and reading the guidance in [RFC5434] are highly recommended 📖💕

4. How to Increase the Chances that the IETF Successfully Standardizes Your Proposal ✨

Congratulations, you got the IETF to agree to start working on your proposal 🎉👑 Now it's only the actual work left! In this section, we give some advice about ways of working that will increase the chances that the standardization runs smoothly 💅

4.1. Commit Enough Time, Energy, and Perseverance ⏳

Folks new to standards bodies are often surprised by how long and how much effort it takes to standardize something 😵‍💫

Success at the IETF takes active participation: convincing others your idea is worthwhile, building momentum, gaining consensus 💪 Most IETF work happens on mailing lists, but in practice, face-to-face time is critical, especially for new or substantial work. If you can, go to the three IETF meetings a year ✈️

It takes a pretty long time for a proposal to become an IETF standard, even if it's mature when you first present it 🐢 There are so many steps: building a community of interest, convincing the IETF to start work, working through suggestions from technical experts and incorporating their improvements, gaining consensus, getting detailed reviews (any IETF publication gets significantly more reviews than an academic publication 😳), going through the formal IETF approval process, and so on. Even if you can work on the proposal full time, you still need effort from other people who can't 🫠 Also, the IETF tends to work in intensive bursts, with activity concentrated in the run-up to and then at the IETF meetings, with lulls of low activity in between 🌊

The IETF proceeds by "rough consensus". Unlike some other standards bodies, there's no voting and no top-down process from requirements to architecture to protocol 🙅‍♀️ The downside is that the IETF isn't great at making decisions, so you need to persevere and guard against decisions unwinding 🧗‍♀️ On the other hand, if the consensus is to reject your proposal or there's little interest in it, persevering is likely a waste of time. You should probably give up or restart at Section 2 💔

All this means it takes a considerable length of time to finish something at the IETF. Two years is probably a minimum ⏰ So even though a typical three-year research project sounds like plenty of time for standardization, if you haven't raised the idea within the first year, you're probably too late to finish standardization before your project ends 😬 And since it's quite likely that IETF standardization won't be finished when your project ends, it's particularly important to convince others to help, so the work is more likely to get completed afterwards 🫶

4.2. Be Open and Focus Out 🦋

It helps to come to the IETF with an open mind-set 🌈

Co-authorship is good! Some standards bodies value trophy authors, who indicate their support but don't actually do any work. At the IETF, it's much better when co-authors are actually investing cycles into developing the proposal, whereas simple indications of support can happen on the mailing list or at the meetings 💅

In particular, if the IETF is going to standardize something, then in effect it takes ownership, and it's no longer "yours" 🥲 A really good milestone of success is when your individual document becomes a WG draft, because then the WG owns it. The research mentality is a bit different, since it prizes authorship and confidentiality until publication 🤭

It's very important to be open to working with others. One specific reason is to get help on aspects beyond your expertise or beyond what you've had time to think about, like how to make your protocol more secure, how to make sure it's congestion-friendly, or how it impacts network management 🔐 The IETF makes sure any protocol it standardizes has thought carefully about these aspects 🧠

Also, the IETF works by collaboration! For example, there may be two proposals to solve the same problem. In academia, their proponents may treat each other as rivals and write "related work" sections that point out flaws and shortcomings of the opposition 😤 At the IETF, they'll soon work together on a common document, typically a synthesis of the competing proposals, and be sensitive to each other in order to help build consensus 🤝 You'll also need support, or at least not vehement opposition, from IETF people working on other topics. So be aware of what else the IETF is doing (in case your proposal conflicts) and what other problems exist on the Internet today (in case your proposal makes them worse) 👀

Finally, collaborative research projects sometimes find it hard to stay open to working with others 🙈 Firstly, such projects typically have a consortium agreement about confidentiality, and it must not stop you from engaging properly day-to-day with people outside the project. Secondly, you may have to spend considerable effort on intra-project coordination. But an individual researcher only has so much energy and enthusiasm for collaborating, so if you spend a lot of time liaising between different groups within your project, you'll have little left for working with the IETF 🪫💜

4.3. Seek Resolution, Not Perfection ✨

Okay so, researchers tend to dig into every single possible detail of an idea until it's perfect, and sometimes there's no deadline at all 🫠. The IETF vibe is different: get something out there that works, even if it's not perfect yet 💅. If people find it useful, there's another round to improve it, usually for needs that only show up once it's deployed at scale 🚀. The goal is a reasonable solution to the problem that exists right now. And honestly, if you spend forever over-optimizing, your solution might already be obsolete 💀. Maybe someone solved the problem a different way, or maybe the problem got so big that people had to find a totally different approach 😭.

4.4. Implement 🔧

The IETF is obsessed with actual implementations, aka "running code" 🤩. It helps the standards process move along, it helps people believe it really works, and it helps you and everyone else find any issues 🔍. An implementation that others can download and try is seriously helpful for getting your protocol actually deployed 🎉. That's presumably the real goal, right? Not just getting an IETF standard 🙈. Longer term, you may need to think about how to get it into the Linux kernel, for example 🐧.

Honestly though, getting a protocol into widespread use is super hard 😩. There are way more IETF protocols on paper than there are in use 📄.

5. Examples 🌸

In this section we share a few examples where the authors were deeply involved and (we think!) successfully brought the research output of a collaborative research project into the IETF 🦋.

5.1. Multipath TCP 🛤️

Multipath TCP (MPTCP) lets a regular TCP connection use multiple paths at the same time 🌈. It extends TCP so each endpoint can use multiple IP addresses 🔥. This work is one output of the Trilogy research project, which was brought to the IETF for standardization, and it's currently making good progress 💜. Here's a quick rundown of the steps.

The first stage was early socialization of the main ideas behind MPTCP 🗣️. The team presented in a few relevant WGs: the Routing Research Group (July 2008) and the Transport Area Open meeting (July 2008 and March 2009) 🎤. They also set up an open mailing list for anyone interested in discussing Multipath-TCP-related issues in the IETF context, plus a public Web page with MPTCP material like papers, Internet-Drafts, presentations, and code 🍓. The feedback was encouraging enough to keep going ✨.

Once they confirmed the ideas had potential traction in the IETF, the next step was finding the right venue 🔍. There were two options: go for a BoF with a view to a new WG, or add work items to an existing WG, and TCPM seemed like a good candidate 🤔. After talking to the Area Directors, a BoF seemed like the right move, at least for the initial discussion stage 💖. So a BoF proposal went to the Transport ADs for the IETF 75 meeting in Stockholm in July 2009 🇸🇪. The initial proposal was written by Trilogy people, but it was sent to the open mailing list so the rest of the community could discuss and change it 🫶. The BoF request was approved, and the MPTCP BoF was held at IETF 75 🎉.

The general feedback from the BoF was that there was enough interest and energy in the community to do this work within the IETF 🙌. A first charter draft went to the mailing list for comments a couple of months after the BoF 📬. After about a month of charter discussion on the list, the MPTCP working group was created in October 2009 🥳. The charter includes deliverables due by March 2011 📅.

The MPTCP working group has made significant progress so far, and most of the milestones have been delivered on schedule [MPTCP] 👑.

5.2. Congestion Exposure 🌊

Congestion Exposure lets sending end-hosts tell the network about the congestion that earlier packets on the same flow ran into 📡. That means network devices can act on the congestion information and the perceived user behavior 🧠. Like the MPTCP work, it's an output of the Trilogy research project, and it was successfully brought to the IETF 🏆. Here's how that happened.

Early socialization included presentations at the Internet Congestion Control Research Group and the Internet Area meeting at IETF 75 in July 2009 🎀. They also created an open mailing list to discuss Congestion Exposure issues in the IETF, and posted materials like papers, Internet drafts, and code on a public web page 💻. On top of that, an informal, open meeting (sometimes called a Bar-BoF in IETF parlance) was held during IETF 75 ☕.

After processing the feedback from the Bar-BoF, a BoF proposal went to the Internet Area ADs for the IETF 76 meeting in November 2009 📨. The BoF was accepted and held as planned 🙌. The feedback was positive, but the IESG was not sure about chartering a working group on this topic 😬. (The IESG is the IETF's management body and consists of all the Area Directors 👩‍💼.) To address the IESG's remaining concerns, another BoF was held at the following IETF meeting 🔁.

After a lot of debate, the CONEX WG was approved by the IESG, but its charter was narrower than the original proposal 😤. This was due to concerns about the proposed allocation of the last bit in the IPv4 header 🧐. The CONEX WG is a great example of the kind of compromise you sometimes need when research ambition meets Internet standardization 🤝. The CONEX WG [CONEX] held its first meeting at IETF 78 in July 2010 🥂. Its charter contains deliverables through November 2011 🗓️.

6. Security Considerations 🔐

This document has no known security implications.

7. Acknowledgments 💌

Part of this work was funded by the Trilogy Project [TRILOGY], a research project supported by the European Commission under its Seventh Framework Program 🇪🇺.

Similar material was accepted for publication in ACM CCR, July 2011 [CCR] 📚.

8. Informative References 📖

   [BAR-BOF]   Eggert, L. and G. Camarillo, "Considerations for Having a
               Successful "Bar BOF" Side Meeting", Work in Progress,
               August 2011.

   [CCR]       "How to Contribute Research Results to Internet
               Standardization".  Marcelo Bagnulo, Philip Eardley, Lars
               Eggert and Rolf Winter.  ACM Computer Communication
               Review (CCR), Vol. 41, No. 3, July 2011.

   [CONEX]     "Congestion Exposure working group",
               http://tools.ietf.org/wg/conex/.

   [MPTCP]     "Multipath TCP working group",
               http://tools.ietf.org/wg/mptcp/.

   [NoteWell]  "Note Well", http://www.ietf.org/about/note-well.html.

   [RFC4101]   Rescorla, E. and IAB, "Writing Protocol Models", RFC
               4101, June 2005.

   [RFC4144]   Eastlake, D., "How to Gain Prominence and Influence in
               Standards Organizations", RFC 4144, September 2005.

   [RFC4677]   Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
               Guide to the Internet Engineering Task Force", RFC 4677,
               September 2006.

   [RFC5434]   Narten, T., "Considerations for Having a Successful
               Birds-of-a-Feather (BOF) Session", RFC 5434, February
               2009.

   [TRILOGY]   "Trilogy Project", http://www.trilogy-project.org/.

Authors' Addresses 💜

   Philip Eardley
   BT
   Adastral Park, Martlesham Heath
   Ipswich
   England

   EMail: philip.eardley@bt.com


   Lars Eggert
   Nokia Research Center
   P.O. Box 407
   Nokia Group  00045
   Finland

   Phone: +358 50 48 24461
   EMail: lars.eggert@nokia.com
   URI:   http://research.nokia.com/people/lars_eggert/


   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Madrid
   Spain

   EMail: marcelo@it.uc3m.es


   Rolf Winter
   NEC Europe
   Heidelberg
   Germany

   EMail: rolf.winter@neclab.eu