There has been a lot of progress on the project to revamp of the www.ietf.org website. The updated website will be the “front door” for the IETF, not only for for active IETF participants, but also provides an onramp for potential participants, and helps explain the work of the IETF to people who are not directly involved in developing Internet standards. The complete Scope of Work for the project is available here.
Based on recent feedback, including the demo table at IETF 98, the initial design and features of the website have been improved in many ways. For example, in response to the feedback provided, there is now a single page that provides links to tools and resources commonly used by active IETF participants.
The project is now entering the next phase of the website development. The goal for this phase is to gather input more broadly. While there are still a few features to be implemented and some content still needs to be fine tuned, the general organization and the look-and-feel of the website has been implemented based on the initial research and input received to date. Of course, there will be some additional significant work before the site is ready for production; for example, before the website is final, we will implement methods to ensure that well-known URLs continue to work as expected.
Working on technical standards in the computing, communications and networking industries often involves dealing with patents. Like most standards-development organizations (SDOs), the IETF has policies that deal with patents covering IETF protocols, specifications and standards. The IETF’s first patent policy appeared in RFC 1310 (Mar, 1992), but the basis for today’s policy approach originated with RFC 2026 (October 1996), which still defines many aspects of the Internet Standards Process. The first major overhaul of this policy occurred a decade later in RFC 3979 (also designated as BCP 79). Though the IETF’s policies relating to copyrights, open source code and other forms of intellectual property (IPR) evolved, particularly after the formation of the IETF Trust in December 2005, the IETF’s patent policy remained relatively stable for more than 20 years.
As stated in RFC 2026, the overall intention of these policies has been to benefit the Internet community and the public at large, while respecting the legitimate rights of others, and that remains the case today.
As originally codified in RFC 2026, the IETF patent policy states that anyone who makes a contribution to an IETF specification or standard must disclose any patents held by the contributor or his/her employer which cover or may cover the contribution and are “reasonably and personally known” to the contributor, as well as any such patents that cover contributions of others. If an IETF participant knows of third party patents covering some aspect of an IETF document, disclosure is voluntary. Unlike many SDOs, the IETF does not require that patent holders make any particular commitment to license their patents on fair, reasonable and non-discriminatory (FRAND) or any other terms (a discussion of the history behind this approach can be found here). However, the IETF provides a facility (the IPR Disclosure Form) whereby patent holders can voluntarily disclose their licensing terms, and many make use of this facility to declare, for example, that they will not assert patents against implementations of IETF standards except in defensive situations.
In 2010, following a period of extensive discussion of IPR policies in the industry and at other SDOs, and with the completion of a major overhaul of the IETF copyright policy in 2008 (RFC 5378/BCP78), we began to consider updating BCP 79 to reflect current practices at the IETF, as well as the evolving roles of the RFC Editor, IETF Secretariat, IETF Executive Director, IRTF, IAB and other groups operating within IETF.
This was not a quick process. We began work in 2010 and held a first BOF at IETF 81 in Quebec City (July 2011). We published a -00 version of a revised policy in December 2012 and held a second BOF at IETF 87 in Berlin (July 2013). We received comments and input from a wide range of community members, legal counsel and interested parties. The Internet-Draft went through 13 versions and was finally published as RFC 8179 in May 2017, seven years after we began to work on it.
The principal changes that RFC 8179 introduced to BCP 79 are described in Section 13 of the document. A quick summary of the highlights is below:
What’s a Contribution to the IETF? — Over the years, the modes in which IETF work takes place have changed. We updated BPC 79 to reflect the reality that technical contributions are made in BOFs, and online via chat rooms and other online fora. In addition, we have clarified the rules regarding oral contributions and when they trigger a requirement to disclose patents.
What is Participation in the IETF? – Many of the obligations imposed by BCP 79 apply to persons who “participate” in IETF standardization activities. So what does “participate” mean? Does it include walking into a meeting room where a discussion is taking place, sitting in the back saying nothing, or silently “lurking” on an email list? In BCP 79bis, we clarify that participation in the IETF means either making a contribution or “in any other way acting in order to influence the outcome of a discussion relating to the IETF Standards Process”. Thus, silently rolling your eyes or giving a thumb’s down during a technical presentation could subject you to the IETF’s disclosure requirements.
What to Disclose? – In addition to information regarding a patent and the portion(s) of an IETF document that it covers, the inventor(s) must now be disclosed.
Updating Disclosures – We have added a lot of needed detail around the process for updating IPR disclosures, including when such updates are required and how they should be made.
Licensing Declarations – When a person or company makes a voluntary statement about the terms on which it will license its patents covering IETF standards, that statement is viewed as binding and irrevocable so that others may rely on it.
General Disclosures – We updated the procedures relating to voluntary disclosures that are not required by the IETF rules. These disclosures of patents potentially covering IETF documents can be made by anyone and will be posted on the IETF IPR Disclosure page. We also clarified that required disclosures that are deficient in some way (e.g., they omit some required information) are also posted.
Failure to Disclose – We outline some of the remedial measures that can be taken when the IETF disclosure rules are violated, including IESG actions described in RFC 6701.
Evaluating Alternative Technologies – We provide some guidelines around the consideration of patent and licensing disclosures by IETF WGs. We also discuss some areas in which royalty-free licensing is preferred, such as security technology.
Alternate Streams – We have made it easier for other groups using the IETF RFC publication process, such as the RFC Editor, IAB and IRTF, to adopt the IETF patent policy.
As you can see, the changes are mostly clarifications; the basic patent policy remains as it was defined in 1996. Changes in patent law or patent practice may, at some point in the future, necessitate an update to RFC 8179, but that will be someone else’s task.
Emergency calls placed by vehicles involved in a crash can provide significant benefit, especially when vehicle occupants are injured or unable to place a 9-1-1 call themselves. Sometimes called “Advanced Automatic Crash Notification” or “vehicle telematics”, the ability to automatically or manually place an emergency call when a vehicle is involved in a crash has been available for over two decades in the U.S., while the EU has a mandated system called “eCall” that is in the process of being deployed. Recently published IETF RFCs aim to expand the capabilities of such services, and to make them more broadly implementable.
Current U.S. systems are proprietary; some use non-standard in-band modems to send vehicle location and crash data from the vehicle to a call center, which then relays the information to the Public Safety Answering Point (PSAP, also known as an emergency call center). The relaying is done either by non-standard out-of-band data transmission or orally by a service center agent. Other systems place a 9-1-1 call, play a prerecorded message to the PSAP call taker, and use text-to-speech to convey vehicle location and sometimes crash data. The EU eCall system uses a standardized in-band modem to convey vehicle location and crash data from the vehicle to a specialized PSAP, which has a corresponding modem to receive the data.
The IETF has published two documents: RFC 8147 and RFC 8148 that specify how such calls operate using next-generation (all-IP) technology. Vehicles using these RFCs initiate emergency calls either manually or automatically in the event of a crash or other serious incident; the calls carry a standardized set of vehicle location and incident data. Such a call can be routed to a PSAP equipped for this, where the data can be automatically processed and displayed to a call taker at call assignment. During the call, the call taker can request that the vehicle send updated data or perform an action such as flashing its lights.
The IETF developed a generalized mechanism for making data related to an emergency call available to the PSAP along with the emergency call. This mechanism, called “Additional Data”, RFC 7852, allows standardized data “blocks” to be sent in a SIP (RFC 3261) call, either as data in the body of an INVITE message, or as a URL sent in the header which, when dereferenced, yields the data block. RFC 8148 defines a data block for the U.S. “Vehicle Emergency Data Set” developed by the Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA), while RFC 8147 defines a block for the eCall data set used in the EU. These RFCs also provide a mechanism for the call taker to request that the vehicle perform an action, such as honking the horn or flashing the lights to allow the responders to locate the vehicle.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. This one is by Mirja Kühlewind, who is an IETF Transport Area Director. You can also see her interview here.
Mirja Kühlewind, IETF Transport Area Director at IETF 98.
I first got involved with the IETF when I started my PhD. A colleague, who was already involved pointed out that it was starting work closely related to my own interests. I attended my first IETF meeting in 2010, when the CONEX [Congestion Exposure] Working Group (WG) held a Birds-of-a-Feather meeting. From then on, it was my own initiative that kept me working with the IETF—I had support from my group, and they usually had enough travel budget for me to attend the meetings.
Three years ago, I became chair of the RMCAT [RTP Media Congestion Avoidance Techniques] Working Group. I only gave that up when I became Transport Area Director (AD). I also was chair of the TCPINC Working Group for half a year. So I became an AD just six years after starting to participate in the IETF.
There are a limited number of people involved in the Transport Area. As soon as I became more active, I was encouraged to take the role of a Working Group chair. Transport AD wasn’t an option until I finished my PhD. Ultimately, though, it worked out nicely because I got stable funding for a project for a little more than two years, which freed me up to consider the position.
The project is generally funded by the European Union, with additional funding by Switzerland for my part, which includes work we planned to bring into the IETF. This would have allowed me to justify spending so much of my time on IETF work. However, since the project funding is coupled to certain research goals, I additionally contacted some companies and they provide support for some of my time and travel budget.
I hope that my experience as AD can count as management experience and that people value it. It’s a good way to improve your skills because you are in a management position where you don’t have any power, but you need to motivate people. For me, it is about how well I manage Working Groups and how well I manage my time. I spend 40% of my time on my AD work and 60% on my research project. It can be a challenge to balance them.
I don’t think that ETH directly benefits from me being Transport AD. But they did get external funding for our project, and that funding had a strong focus on making an impact on industry. So my standardization work may have helped to get the project funded. I don’t think I needed a leadership role for that. Being a Working Group chair was probably enough to show that I had IETF experience, but my AD role of course also makes a good impression.
Everybody’s biggest concern about taking on an IETF leadership role is time management. I do it on a 40% basis. It’s a little stressful, yes, but it is possible. The other reason it’s hard to find people for the Transport AD role is that the right person not only needs support, money, and time for the IETF, but also must have an overview about what’s going on in Transport. I was in the unique position that I was following the same Working Groups that I now carry as AD—it’s no extra effort.
I don’t have a plan yet for when my term is over, but I know I’d like to stay involved in the IETF. When my ETH project is finished, I’ll be a four-year post doc. I’ll need to make a decision about whether to stay in academics or go into industry. If I apply for a job next year, I won’t stand as Transport AD—I can’t ask a new employer to let me spend 40% of my time on the IETF. Even as a professor, it would be hard for me to get 40% of my time off for the IETF.
It’s been an interesting experience, particularly because I’m just starting my career. I’ve learned a lot, and I’ve made a lot of industry contacts that I’ve gotten to know well. I’m grateful—the IETF as a community has provided me with networking opportunities and a source of ideas for research.
Photos from IETF 98
A collection of photos from the IETF 98 meeting held 26-31 March in Chicago, Illinois, United States.
Before IETF 98 began, the IETF Hackathon was in full swing.
Applied Network Research Prize winner Alistair King presents his research at IETF 98 Chicago 26/03/2017
Applied Network Research Prize winner Yossi Gilad presents his research at IETF 98 Chicago 26/03/2017
David Clark speaking on the question:What is the relationship between Internet Protocols and Human Rights? During the IETF 98 Plenary on Wednesday, 29 March 2017 Niels ten Oever, Head of Digital for Article 19, and David Clark, Senior Research Scientist at the MIT Computer Science and Artificial Intelligence Laboratory, tackled this question. They offered different perspectives on the role human rights considerations should play in the Internet protocols and, in particular, how these considerations ought to factor into the work of the IETF. (L to R: Niels ten Oever, David Clark, Lee Howard)
Outgoing IETF Chair Jari Arkko speaking at the IETF 98 technical Plenary, Chicago 29/03/2017
Incoming IETF Chair Alissa Cooper speaks during IETF 98 Plenary on Wednesday, 29 March 2017.
John Mattsson, senior specialist at Ericsson Security Research speaking as part of the IETF Host Speaker Series on ‘The real deal on cellular security’ during the IETF98 meeting in Chicago, Thursday, 30th, March 2017.
IETF 98 Wrap up video with Jari Arkko and Alissa Cooper, Friday, 31 March 2017.
Periodic posts on the IETF Blog highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. This one is by Jari Arkko, who will step down as the current IETF Chair during IETF 98 and begin an appointment as a member of the Internet Architecture Board (IAB).
I had my first contact with the IETF in 1996. I started working with modem pool and access server products at Ericsson. Some of what we wanted to build for our products needed standards so they could interoperate. I started working with AAA protocols and extensions. Later I became chair of the EAP, EMU, and MOBIKE working groups. These were long-term efforts that I was heavily involved in.
When I was first approached about the area director role, it didn’t sound like a feasible goal, but it grew on me. But a few years later, I applied to become an Internet Area Director. It turned out to be a perfect fit — I got to work on many topics that I really cared about, such as IPv6 transition techniques. And it was good for our company because this is the layer where our products mostly were.
I was an AD from 2006 to 2012. Six years is on the long side for this job. We tell people that four years is optimal because it takes about two years to learn the job. When I was an AD, the IETF took up 50–100% of my time. Meanwhile, Ericsson benefitted from me advising them on where the technical pieces that we cared for were heading to.
I spent the year after the AD term in the the IAB. I was already wondering if I wanted to be the IETF chair. But I knew it would be a growing experience, perhaps even a scary challenge. But I thought about it for a long time and decided to go for it.
I was IETF Chair from 2013 to 2017. And this year we are again in a situation where things are changing: I will still be at the IE, contributing, and again at the IAB.
I have personally benefitted tremendously from the involvement with the IETF. Those challenges were well worth taking! It is a privilege to witness Internet technology in the making. .And the nature of a leadership role in the IETF demands that you see things in a broader way, talk with other companies, talk with lots of people with new ideas. It forces you to understand the bigger picture. I’ve become personal friends with lots of people in the industry, a perk I’ve enjoyed a great deal.
In a leadership role, you get the feeling that you are in the middle of important issues. As chair of one of the more active or high-profile working groups, you are doing things that are broadly visible and have an impact on the Internet. As IETF chair, I was witness to many interesting things. I am an engineer and have no interest in going into political matters. Yet observing the IANA [Internet Assigned Numbers Authority] transition was a wonderful experience, and I was glad to see how that played out.
The work of the IETF chair represents almost 100% of my efforts, although I spend a fair bit of time at Ericsson. My main role at Ericsson is to share with people what is happening in the Internet and make sure we take it into account. There were many cases, including Internet of Things technology, HTTP and encryption changes, where our business was affected by what was happening at the IETF. The company appreciates our IETF team’s involvement and expertise on these topics.
If you are thinking about applying for an IETF leadership position, my suggestion is to take the challenge! Expose yourself to new things. You will understand more, which is a benefit to both you as a person and your employer.
For me, being a leader in the IETF has underscored that we actually can make a difference. We can make significant technical changes in the Internet, or change how the Internet is administered. Yes, some of the work is hard and takes a lot of effort, but isn’t that the exciting part?
Periodic posts will highlight individuals who serve in IETF leadership roles, people who have recently begun working in the IETF, and organizations that make the work of the IETF possible. Each post aims to describe experiences working within or supporting the IETF. The first of these is by Alissa Cooper, current IETF ART Area Director, who will take on the IETF Chair position during IETF 98.
Alissa Cooper, IETF 96 at Intercontinental Hotel, Berlin, Germany.
I started participating in the IETF in 2008 and went to my first meeting at IETF 72 in Dublin. I was working at the non-profit Center for Democracy and Technology (CDT) in Washington, DC, where my role was to explore and articulate the technical implications of policy. I worked on a number of issues there, including online privacy.
In 2008, real-time applications were the focus of many of the consumer privacy issues of most interest to CDT. Initially, I focused on the Geopriv Working Group. I became a document author and then a co-chair of the group. It was a busy time in Geopriv – many tough battles had already been fought concerning the design of the technology, but finishing out the protocol suite required substantial effort. Over time the IETF grew into a larger portion of my job responsibilities because it was well aligned with the rest of the CDT work I was doing.
In 2011, I was appointed to the Internet Architecture Board and soon thereafter became the lead of the IAB’s Privacy Program. CDT was thrilled—they saw it as a huge honor that one of their own had been selected to serve in this capacity.
In 2013, I joined Cisco, and in 2014, I joined the Internet Engineering Steering Group as Applications and Real-Time area director. I’ve tried to do my area director work approximately half-time and my day job half-time. I’m leaving the post as I’ve been appointed IETF Chair beginning in March 2017—my new full-time role for the next two years.
Leadership in the IETF offers exposure to a broad swath of Internet technology that most of us otherwise wouldn’t be able to justify spending our time learning and influencing. This is particularly true on the IESG, but also on the IAB. It’s incredibly enriching and highly beneficial because you’re able to make connections between your day job and things going on across the whole industry.
IETF leadership also requires management skills of many kinds. You have to manage authors, your time, big community processes. It requires a lot of strategy and work in the background to achieve good outcomes. Many people do not realize the depth of the management education you get while serving in the IETF leadership.
Lastly, you get to (try to) promote your vision of what the future of the Internet should look like. Everybody might not agree with you, but serving in the leadership gives you a platform to steer and influence.
Cisco has been a big supporter of the IETF because it is deeply invested in the growth and stability of the Internet. Its customers like the idea that the products they buy from different vendors interoperate. Cisco enjoys having people in leadership positions dedicating a portion of their time to furthering interoperability and making sure that standards are keeping pace with other technological developments.
In recent years, some IETF participants have encountered difficulty in trying to convince their employers about the value of the time commitment associated with IETF leadership positions. But in reality it is possible to balance your day job with an IETF leadership role—you set the parameters for how you manage your time. Lots of positions require a half-time commitment or less.
Having a well-functioning IETF and an Internet that runs on secure, performant, interoperable standards should be pretty important to any large tech company at this point in history. If that model goes away, the options for how we replace it are all inferior. Hopefully the indirect benefits of supporting IETF leaders are obvious, but if not, current and past IETF leaders are always happy to explain the benefits. We have a big incentive to expand the population of people willing to take on leadership roles.
IETF Hackathons embody the IETF’s tradition of running code—testing theories against the realties of implementation, with a goal of accelerating the definition and adoption of protocols and technologies that make the Internet work better. One of the best things about theses events is the shared success of a broad range of participants, from long-time IETF contributors to those who have never attended an IETF meeting or joined an IETF working group. Of particular note, university students from around the world have been remarkable contributors at the past few hackathons.
Team from Sungkyunkwan University IETF Hackathon at IETF 97
At the most recent IETF Hackathon in Seoul, a team from Sungkyunkwan University worked on implementations of the specifications being defined with the Interface to Network Security Function (I2NSF) Working Group. Powered by energetic professors and students from Sungkyunkwan University in South Korea, the team used RESTCONF and NETCONF together with YANG data models to implement network security services using OpenDaylight and mininet. In doing so, they validated the approach defined by the IETF’s I2NSF Working Group.
Charles Eckel, an Open Source Developer Evangelist for Cisco DevNet, who has led the IETF Hackathons over the past few years, has witnessed first hand how teams with a diverse set of participants often leads to impressive results. Eckel commented, “The most successful hackathon teams are those with a good mix of participants with different skillsets. When you combine IETF newcomers with great coding skills with IETF veterans with tremendous knowledge of evolving Internet protocols—that’s where the magic happens.”
IETF Hackathons provide students with unique learning opportunities as well. Eckel observes, “The mentoring and teamwork that comes from working closely with a group of people on a focused effort over the course of two days is a rich and valuable experience that you are not likely to get merely by reading a few drafts and attending a handful of meetings.”
On numerous occasions, even the hurdle of geography has been cleared by hackathon participants. For example, Ecole Polytechnique de Louvain in Belgium organized two teams working on Multipath TCP during the IETF 97 Hackathon in Seoul. Five participants in Seoul, including three PhD students, worked with 25 students in Louvain-la-Neuve on a new socket API that allows application developers to more easily make use of multipath TCP subflows. Together, the teams received the Best Overall award for the hackathon.
The result confirms Eckel conclusion that, “IETF Hackathons are great events for both long-time IETFers and well as newcomers. “
The next IETF Hackathon will be held in Chicago on 25-26 March 2017. As Eckel notes, “For someone with coding skills and an interest in working on the Internet, IETF Hackathons provide opportunities to get plugged into a project and immediately start producing tangible results.”
“There’s a huge problem with the Internet of Things and we need to do something about it.” That was the invitation that brought participants to the Internet of Things Software Update Workshop (IoTSU) held at Trinity College, Dublin on June 13 and 14.
The “huge problem” with many IoT devices is that they are un-patchable, and if they cannot be patched, they cannot be made secure. The IoT is on a growth path that is quickly leading to the ubiquitous deployment of unattended devices throughout our homes, offices, factories, and public spaces. All of them, by definition, are connected to the Internet and hackers will eventually discover and exploit the vulnerabilities in these devices. When that happens, there must be a way to detect the intrusion and deploy software updates to fix the security flaws. This is a hard problem to solve and it has the attention of the IoT industry as well as that of the Internet Architecture Board (IAB) and the Science Foundation Ireland-funded CONNECT Centre who sponsored this workshop.
The workshop materials and raw minutes are here. An IAB report will be published in the near future.
The participants at the IoTSU workshop submitted nearly 30 papers on topics covering analysis of past incidents, current practices, and proposals for future standards. The organizers classified the papers and the participants discussed them during four sessions across two days. The following summarizes just a few topics from the workshop that I felt were particularly significant.
Problem Scope and Technical Constraints: IoT devices are deployed on a range of hardware platforms, many of which are more highly constrained than others. At one end of the spectrum are the “System-On-Chip” devices with full memory management units (MMUs) running embedded Linux and full time access to mains power and a permanent Wi-Fi connection. At the other end of the spectrum are tiny “motes” connected via Low-Power and Lossy networks and required to run for years on battery power or harvest their own energy. The biggest software update challenges are with these highly constrained devices considering that all updates must be done securely and with zero risk of bricking the device. It seemed that most of the participants felt the greatest need was to first address the challenges at the lower end of this spectrum.
Photo: Hannes Tschofenig
IoT as a Service: When I buy a product, I have a certain set of expectations regarding ownership, control, and life expectancy for that product. An IoT device, however, is not a standalone product; it is highly dependent on the services it receives over the Internet and all of the technical, organizational, and policy infrastructure that underpin those services. Many of the IoT devices on the market are being sold today as products, and consumers are not always aware of the services those devices depend upon for their long term continued operation. Developers and vendors need to keep this perspective in mind when designing and marketing the IoT.
Full Lifecycle Requirements:
To properly address the challenges of the IoT software update problem, it is essential to consider the full lifecycle of the IoT device. This begins during manufacturing when the security credentials must be generated, allocated, and provisioned into the devices in a secure manner. It also incorporates the lifecycle of the device vendor who might be bought out or go bankrupt – we need to consider how to continue patching essential devices when the original manufacturer no longer exists. Finally, it ends with addressing various end-of-life scenarios such as how to decommission and recycle those devices that no longer can or should be supported.
The workshop concluded with a discussion about next steps. For starters, the organizers will publish an official workshop report. The participants also supported the concept of publishing a document to capture the current best practices in the IoT industry relative to software update. Some also brought up the need to clarify the scope of the workshop activities in terms of whether the focus should be on constrained devices or to also include other platforms or even networks of connected devices such as those found in vehicles. There may also be the opportunity for future standards work such as recommendations for certain minimum hardware requirements to address the need for random number generation, real time clock, and memory to support multiple binary images during an upgrade.
The participants at the IoTSU workshop came together because of their common concern about issues that could potentially threaten the long term success of the IoT. It was a good mix of representatives from both industry and academia who willingly and openly shared their experience and expertise. I believe the workshop was a good first step towards working together to address the common challenges that we are facing as the IoT continues to grow.
I wanted to provide a brief update on the the progress of the www.ietf.org website revamp project, which began in earnest last year and is scheduled to move into production by the end of this year.
As the scope of work developed with input from the IETF community specified, we have been working with the selected vendor, Torchbox, to develop a site that reflects the IETF’s position as the premiere Internet standards organization. Beyond updating and improving navigation and the visual design, the revamped site will work better for all classes of devices, including smart phones and tablets. It is also designed to improve accessibility and to work well for visitors using low-bandwidth and high-latency connections.
Of course the revamped website must work well for current IETF participants. But it also aims to serve *potential* IETF contributors by making it easier for them to get started in the IETF, and it aims to ensure that even people who aren’t likely to be contributors can understand what the IETF does and how it works. A goal of the project was to develop a design informed by data, so we interviewed people from each of these groups. We also looked at usage data available from the current website and benchmarked against websites of similar organizations.
Since sharing the initial design and prototype at IETF 93, the project team has been working on fine-tuning the design and transitioning content. The IETF Tools team has also been involved so that the information about RFCs, IETF Areas, and working groups displayed on www.ietf.org is drawn directly from datatracker.ietf.org. This will make it easier to keep the www.ietf.org site current, and provide opportunities to guide people to the ongoing work of the IETF.
Work is still underway to finalize the content and features on the new site, including additional testing with the target audiences to be sure it works for them. The current project schedule calls for an extended “preview” of the new site so the entire IETF community will have a chance to try it out before everything is finalized. I expect to have a further update on the exact timeline in the next few weeks.
Joe Hildebrand, Project Manager
Screenshot of the Revamped IETF Blog
Example of a revamped information page about an IETF Area
An example of the responsive design for an IETF Blog post