GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6417

Independent Submission P. Eardley Request for Comments: 6417 BT Category: Informational L. Eggert ISSN: 2070-1721 Nokia

                                                            M. Bagnulo
                                                                  UC3M
                                                             R. Winter
                                                            NEC Europe
                                                         November 2011
   How to Contribute Research Results to Internet Standardization

Abstract

 The development of new technology is driven by scientific research.
 The Internet, with its roots in the ARPANET and NSFNet, is
 no exception.  Many of the fundamental, long-term improvements to the
 architecture, security, end-to-end protocols and management of the
 Internet originate in the related academic research communities.
 Even shorter-term, more commercially driven extensions are oftentimes
 derived from academic research.  When interoperability is required,
 the IETF standardizes such new technology.  Timely and relevant
 standardization benefits from continuous input and review from the
 academic research community.
 For an individual researcher, it can however be quite puzzling how to
 begin to most effectively participate in the IETF and arguably to a
 much lesser degree, the IRTF.  The interactions in the IETF are
 much different than those in academic conferences, and effective
 participation follows different rules.  The goal of this document is
 to highlight such differences and provide a rough guideline that will
 hopefully enable researchers new to the IETF to become successful
 contributors more quickly.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.

Eardley, et al. Informational [Page 1] RFC 6417 Contributing Research to the IETF November 2011

 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained 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, as 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

Eardley, et al. Informational [Page 2] RFC 6417 Contributing Research to the IETF November 2011

1. Introduction

 In telecommunications, standards are essential.  More often than not,
 technology interoperability requires an agreement on a single
 standard for a given problem.  However, unlike most research,
 standards developments are driven by particular real-world problems
 and require solutions that are not only theoretically correct, but
 need to be implementable with state-of-the-art technology in a cost-
 effective manner, and must be incrementally deployable in the actual
 Internet by the involved stakeholders.  In other words, standards
 should be both theoretically correct and practically applicable.  In
 the academic world, the former is often more important than the
 latter!
 In the IETF, a practically applicable solution that has some well-
 defined and acceptable deficiencies trumps a theoretically complete
 and optimal solution that cannot be deployed.  Likewise, a solution
 to an interesting theoretical problem that does not exist in the
 deployed Internet at large does not require urgent standardization.
 Finally, standardization oftentimes focuses on piecemeal improvements
 to existing technology in order to enhance secondary aspects, which
 does not excite an academic researcher looking to solve juicy
 problems.
 These differences between academic research and Internet
 standardization are the main reason why many researchers initially
 struggle when they begin to participate in the IETF.  Symptoms of
 this struggle occur, for example:
 o  for ideas that are too far outside the IETF's areas of current
    work
 o  for ideas that are too high-level for the IETF to begin protocol-
    level work on
 o  for proposals that solve problems that are not expected to arise
    for a very long time
 o  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
 o  if there is a feeling that the IETF "does not listen" to them or
    does not have "the right people"
 o  if there seems to be no working group or other venue to bring the
    work to

Eardley, et al. Informational [Page 3] RFC 6417 Contributing Research to the IETF November 2011

 o  if the researchers are not interested in topics such as security,
    performance, and operational management -- topics that the IETF
    will consider carefully
 o  when the process seems too time consuming
 o  when the researchers do not have the resources to keep the IETF
    effort active for an extended period of time
 o  if there is not a convincing enough argument for the IETF to start
    working on something, despite great simulation results
 o  if the research idea is just not implementable in today's Internet
 This document attempts to give some basic advice that researchers
 might want to take into account when deciding to approach the IETF
 with their ideas, in order to improve their success probability.  It
 is intended to complement the more general advice in [RFC4144] about
 "How to Gain Prominence and Influence in Standards Organizations".
 Other, more general advice and detailed explanations of the structure
 and inner workings of the IETF can be found in "The Tao of IETF"
 [RFC4677].
 The authors have been involved in several research projects,
 including collaborative ones, which have sought to standardize some
 of their results at the IETF, and we hope to pass on some advice
 (sometimes that we have 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 the
 chances of success once work has begun.

2. Is the IETF the Right Venue?

 A researcher should consider whether the IETF is the right venue
 before bringing a proposal to it.  A way to do so is to imagine that
 the IETF has standardized your proposal and it has been deployed, and
 ask yourself two questions:
    1. How would the Internet be better?
    2. What Internet nodes would have been upgraded?
 It is very important to have a clear explanation about the motivation
 for your proposal: what would its benefits be?  What problem does it
 solve?  Many ideas do not bring a clear benefit to the Internet in
 the near term (of course they may still be fine pieces of research!).
 In the past, the IETF has often developed protocols that ended up not
 being used, so it now thinks harder about the benefits before

Eardley, et al. Informational [Page 4] RFC 6417 Contributing Research to the IETF November 2011

 starting new work and makes sure that it solves a current,
 significant problem rather than one that may theoretically arise in
 the future.  It is best to be specific about what improvement your
 proposal would make and the use cases in which this would be seen.
 It is also important to have a simple description of what additions
 or changes are needed and to which nodes (be they end-hosts, routers,
 middleboxes, etc.).  Is it substituting for an existing IETF protocol
 or supplementing one?  Again, it is best to 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 most?  What assumptions do you make about the network or
 host (perhaps that the host is multi-homed or there are no
 middleboxes on the path)?  While thinking about these things, it is
 also worthwhile considering operational practices and business
 models.  If you will likely break some of these, you will inevitably
 face some opposition in the IETF.
 If it is hard to answer these questions, it may indicate that the
 idea is 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 is not yet mature enough for
 standardization.  Another danger is that the IETF is the wrong
 standards body, as a different one would need to standardize your
 proposal.
 If your idea involves replacing several IETF protocols and/or
 upgrading several types of nodes simultaneously, it is probably best
 to rethink: the IETF finds it almost impossible to handle radical,
 "clean slate" proposals that change lots of things at once.  Perhaps
 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 is still useful.
 Finally, before bringing a proposal to the IETF, you need to be aware
 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
 information about the rights you grant to the IETF, the best thing to
 read is the IETF's "Note Well" [NoteWell] and the documents linked to
 from there.

Eardley, et al. Informational [Page 5] RFC 6417 Contributing Research to the IETF November 2011

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

 Having decided that the IETF is the right venue, you now need to
 persuade the IETF to start work on your idea.  We discuss three steps
 that should help; they can be done in parallel.  We then briefly
 discuss how to form a new working group (WG), if that is necessary.

3.1. Identify the Right Part of the IETF

 The IETF is a large organization; therefore, you need to communicate
 with the right part of it.  The IETF is organized in areas such as
 routing, security, or transport.  Within those areas, working groups
 are responsible for a specific topic.  The IETF consists of over 100
 WGs.  So, a good step is to identify whether there is already a WG
 suitable for your work.
 If yes, then join the WG's mailing list and send email and perhaps
 write an Internet-Draft.  A WG's current set of specific items is
 defined in its "Charter"; be aware that if your proposal falls
 outside the WG's current charter, then it would have to be extended
 before formal work could begin.  Most WGs think about re-chartering
 every year or two, although most allow for some limited discussion on
 items outside their current charter.
 If no suitable WG exists, then you should identify the right Area.
 The WGs are clustered into "Areas" with a common theme such as
 security, with one or two Area Directors in charge of each Area.  You
 may have to get a new WG created within the most relevant Area; this
 is a significantly difficult step (see below).
 Finding the right WG is akin to finding the right conference or
 journal to submit to.  While a poor choice of conference will get
 your paper rejected as irrelevant, the IETF is friendlier, as most WG
 Chairs and Area Directors will try to redirect your work to a better
 WG, if you choose poorly.  However, ending up with the right "venue"
 is critical, as only then will you collaborate with the right group
 of people.

3.2. Build a Community

 Standards require agreement and approval by a wide range of people.
 Therefore you need to persuade others of the merits of your idea.  In
 practice you need to go further and persuade others to do work.  At a
 minimum, this will be to thoroughly review your proposal and
 preferably it will be to develop and test 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!).  At an early stage, support could be

Eardley, et al. Informational [Page 6] RFC 6417 Contributing Research to the IETF November 2011

 demonstrated through comments on the mailing list.  It is a very good
 idea to have some Internet-Drafts jointly authored with people from
 beyond your research team, perhaps an industry player.  For example,
 you could develop a "use cases" document with a "user", such as an
 operator.
 Working with others has the extra benefit that it will help to
 clarify your idea and explain better its benefits and how it works.
 There are many experts in the IETF who can help stress test the idea
 technically and advise about process and culture.  You need to get
 some of them involved as early as possible.
 It may well be worth trying to hold an informal session at an IETF
 meeting.  This can help build a community of interest for your idea;
 see the advice in [BAR-BOF].

3.3. Outline Your Protocol

 You also need to describe your proposal in a way that others can
 understand.  Your initial document should outline the protocol.  It
 is counter-productive to detail every aspect, unless the protocol is
 incredibly simple.  Firstly, too much detail swamps people with
 information that they cannot process.  Most people understand things
 by learning about them several times at increasing levels of detail.
 Secondly, providing only an outline makes people feel that they have
 a chance of making worthwhile suggestions and changes, so they are
 more likely to actively engage with you.  Thirdly, working out
 details is generally something that a wider group of people is better
 at than an isolated individual.  Fourthly, in order for the IETF to
 start work, it is more important to convince the IETF that there is a
 problem that it needs to solve than to convince it about the merits
 of your solution.
 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?"
 It is best to send your contributions in the form of an Internet-
 Draft (I-D).  While it may seem a burden to convert your nice paper
 or slides into the idiosyncratic format of an I-D, this is the format
 that IETF people are used to reading.  Also, extracting the IETF-
 relevant parts of publications into an I-D will often help to
 identify aspects that need more work by the IETF, such as protocol
 details glossed over.

Eardley, et al. Informational [Page 7] RFC 6417 Contributing Research to the IETF November 2011

3.4. Establish a New Working Group

 You only need to establish a new WG if the idea falls outside the
 scope of existing WGs.  Establishing a new WG nearly always requires
 a specific session, called a "BoF" (Birds of a Feather), at one of
 the IETF's face-to-face meetings.  Here the pros and cons of the
 proposed WG are debated.  As part of the preparation for the BoF, you
 need to:
 o  Build a community (see above)
 o  Document the benefits: for example, a problem statement and/or use
    cases
 o  Document the architecture: for example covering assumptions and
    requirements on a solution
 o  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 only remains to do the actual work!  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

 Those new to standards bodies may be surprised how long and how much
 effort it takes to standardize something.
 Success at the IETF requires active participation: to convince others
 your idea is worthwhile, to build momentum, to gain consensus.
 Although IETF work is done mainly through mailing lists, in practice,
 face-to-face time is critical, especially for new or substantial
 work.  If possible, go to the three IETF meetings a year.
 It takes quite a long time for a proposal to turn into an IETF
 standard, even if the proposal is mature when it is first presented.
 There are many steps: building a community of interest, convincing

Eardley, et al. Informational [Page 8] RFC 6417 Contributing Research to the IETF November 2011

 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 full time on
 the proposal, effort is required 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 is no voting and no top-down process from requirements
 to architecture to protocol.  The downside of this is that the IETF
 is not good at making decisions.  Hence you need to persevere and
 guard against decisions unwinding.  On the other hand, if the
 consensus is to reject your proposal or there is little interest in
 it, persevering is likely to be a waste of time -- you should
 probably give up or restart at Section 2.
 All this means that it takes a considerable length of time to
 complete something at the IETF.  Two years is probably a minimum.
 So, although a typical three-year research project sounds like plenty
 of time to do standardization, if you haven't already raised the idea
 within the first year, you're probably too late to complete
 standardization before your project ends.  Since it's quite likely
 that IETF standardization won't be finished when your project ends,
 it is particularly important to convince others to help, so that the
 work is more likely to be completed afterwards.

4.2. Be Open and Focus Out

 It is helpful 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.  In the
 IETF, it is much better if co-authors are actually investing cycles
 on developing the proposal, whereas simple indications of support can
 be made on the mailing list or at the meetings.
 In particular, if the IETF is going to standardize something, then in
 effect, it takes ownership; it is no longer "yours".  Indeed, a good
 milestone of success is when your individual document becomes a WG
 draft, as then it is owned by the WG.  The research mentality is a
 bit different, as it prizes authorship and confidentiality until
 publication.
 It is very important to be open to working with others.  One specific
 reason is to get help on aspects beyond your expertise or beyond what

Eardley, et al. Informational [Page 9] RFC 6417 Contributing Research to the IETF November 2011

 you've had time to think about -- perhaps how to make your protocol
 more secure, or how to ensure it is congestion-friendly, or how it
 impacts network management.  The IETF ensures that any protocol it
 standardizes has thought carefully about such aspects.
 Also, the IETF works by collaboration.  For example, there may be two
 proposals to solve a problem.  In academia their proponents may treat
 each other as rivals and for example write "related work" sections
 that point out flaws and shortcomings of the opposition.  At the
 IETF, they will 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 will also have to get support,
 or at least not vehement opposition, from IETF people working on
 other topics.  So you need to be aware of what else the IETF is doing
 (in case your proposal conflicts) and what other problems exist in
 the Internet today (in case your proposal exacerbates them).
 Finally, collaborative research projects sometimes find it difficult
 to be open to working with others.  Firstly, such projects typically
 have a consortium agreement about confidentiality -- it must not
 prevent 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,
 then you have little left for working with the IETF.

4.3. Seek Resolution, Not Perfection

 The research mind-set is often to investigate very thoroughly all
 possible details about an idea -- to seek perfection -- sometimes
 with no particular deadline.  The IETF mind-set is to get something
 done and out there that works, albeit imperfectly; if people find it
 useful, then there will be another iteration to improve it, probably
 to meet needs that only become apparent on widescale deployment.  The
 philosophy is to find a reasonable solution to the problem that
 currently exists.  Time spent over-optimizing may simply mean that
 the solution has been superseded (perhaps the problem has been solved
 in some other way, or perhaps the problem was so significant that a
 different approach had to be found to avoid the problem).

4.4. Implement

 The IETF is very impressed by actual implementations: "running code".
 It helps smooth the standards process, it helps people believe it
 really works, and it helps you and others discover any issues.  An
 implementation that others can download and try is extremely helpful
 in getting your protocol actually deployed -- presumably, that is

Eardley, et al. Informational [Page 10] RFC 6417 Contributing Research to the IETF November 2011

 your real objective, not simply to get an IETF standard!  In the
 longer term, you may need to think about how to get it incorporated
 in the Linux kernel, for instance.
 Overall, it is very hard to get a protocol in actual widespread use.
 There are far more IETF protocols on paper than in use.

5. Examples

 In this section, we include some examples in which the authors have
 been deeply involved and have managed (we believe) to bring the
 research output of a collaborative research project successfully into
 the IETF.

5.1. Multipath TCP

 Multipath TCP (MPTCP) enables a regular TCP connection to use
 multiple paths simultaneously.  It extends TCP to allow the use of
 multiple IP addresses by each endpoint.  This work is one output of
 the Trilogy research project which was brought to the IETF for
 standardization, and it is currently making good progress.  We
 provide a brief overview of the steps taken.
 The first stage was doing some early socialization of the main ideas
 of MPTCP.  Presentations were made in several relevant WGs: the
 Routing Research Group (July 2008) and the Transport Area Open
 meeting (July 2008 and March 2009).  In addition, a mailing list was
 created, open to anyone who was interested in discussing Multipath-
 TCP-related issues in the IETF context, and a public Web page was
 created containing Multipath-TCP-related material, including papers,
 Internet-Drafts, presentations, and code.  The feedback received was
 encouraging enough to continue with the effort of bringing the work
 to the IETF.
 Once we verified that the proposed ideas had potential traction in
 the IETF, the next step was to identify the proper venue for the
 proposed work.  There were two choices, namely, to go for a BoF, with
 a view to a new WG, or to try to add additional work items to an
 existing WG, in particular TCPM seemed a good candidate.  After
 talking to the Area Directors, it seemed that having a BoF was the
 right approach, at least for the initial discussion stage.  So, a BoF
 proposal was submitted to the Transport ADs for the IETF 75 meeting
 held in Stockholm in July 2009.  The initial BoF proposal was crafted
 by Trilogy people, but was sent to the open mailing list for
 discussion and modification from the rest of the community.  The BoF
 request was approved and the MPTCP BoF was held at the IETF 75
 meeting.

Eardley, et al. Informational [Page 11] RFC 6417 Contributing Research to the IETF November 2011

 The general feedback received during the BoF was that there was
 enough interest and energy in the community to do this work within
 the IETF.  A first charter draft was posted on the mailing list for
 comments a couple of months after the BoF.  After a month or so of
 charter discussion on the mailing list, the MPTCP working group was
 created in October 2009.  The charter includes deliverables due to
 March 2011.
 The MPTCP working group has, so far, made significant progress and
 most of the milestones have been delivered on schedule [MPTCP].

5.2. Congestion Exposure

 Congestion Exposure enables sending end-hosts to inform the network
 about the congestion encountered by previous packets on the same
 flow.  This allows the network devices to act upon the congestion
 information and the perceived user behavior.  Like the MPTCP work, it
 is an output of the Trilogy research project and has been
 successfully brought to the IETF.  We next describe the steps
 followed to do so.
 In this case, early socialization included presentations at the
 Internet Congestion Control Research Group and the Internet Area
 meeting at the IETF 75 meeting in July 2009, the creation of an open
 mailing list to discuss Congestion Exposure related issues in the
 IETF, and posting the related materials such as papers, Internet
 drafts, and code in a public web page.  In addition, an informal,
 open meeting (sometimes called a Bar-BoF in IETF parlance) was held
 during the IETF 75 meeting.
 After processing the feedback received in the Bar-BoF, a BoF proposal
 was submitted to the Internet Area ADs for the IETF 76 meeting in
 November 2009.  The BoF was accepted and was held as planned.  While
 the feedback received in the BoF was positive, the IESG was uncertain
 about chartering a working group on this topic.  (The IESG is the
 IETF's management body and consists of all the Area Directors.)  In
 order to address the remaining concerns of the IESG, another BoF was
 held at the following IETF meeting.
 After much debate, the CONEX WG was approved by the IESG, but the
 scope of its charter was limited compared with the original proposal.
 This was due to some concerns regarding the proposed allocation of
 the last bit in the IPv4 header.  The CONEX WG serves as a good
 example to illustrate the kind of compromise that is necessary when
 research aspiration meets Internet standardization.  The CONEX WG
 [CONEX] held its first meeting at the IETF 78 meeting in July 2010.
 Its charter contains deliverables through November 2011.

Eardley, et al. Informational [Page 12] RFC 6417 Contributing Research to the IETF 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/.

Eardley, et al. Informational [Page 13] RFC 6417 Contributing Research to the IETF November 2011

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

Eardley, et al. Informational [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6417.txt · Last modified: 2011/11/01 22:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki