Of Birds and RATS
Two Birds of a Feather sessions were approved for the IETF 103 meeting, one of which focuses on Remote ATtestation ProcedureS (RATS).
The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use.
So the reports about large-scale monitoring of Internet traffic and users disturbs us greatly. We knew of interception of targeted individuals and other monitoring activities, but the scale of recently reported monitoring is surprising. Such scale was not envisaged during the design of many Internet protocols, but we are considering the consequence of these kinds of attacks.
Of course, it is hard to know for sure from current reports what attack techniques may be in use. As such, it is not so easy to comment on the specifics from an IETF perspective. Still, the IETF has some long standing general principles that we can talk about, and we can also talk about some of the actions we are taking.
In 1996, RFC 1984 articulated the view that encryption is an important tool to protect privacy of communications, and that as such it should be encouraged and available to all. In 2002, we decided that IETF standard protocols must include appropriate strong security mechanisms, and established this doctrine as a best current practice, documented in RFC 3365. Earlier, in 2000 the IETF decided not to consider requirements for wiretapping when creating and maintaining IETF standards, for reasons stated in RFC 2804. Note that IETF participants exist with positions at all points of the privacy/surveillance continuum, as seen in the discussions that lead to RFC 2804.
As privacy has become increasingly important, the Internet Architecture Board (IAB) developed guidance for handling privacy considerations in protocol specifications, and documented that in RFC 6973. And there are ongoing developments in security and privacy happening within the IETF all the time, for example work has just started on version 1.3 of the Transport Layer Security (TLS, RFC 5246) protocol which aims to provide better confidentiality during the early phases of the cryptographic handshake that underlies much secure Internet traffic.
Recent days have also seen an extended and welcome discussion triggered by calls for the IETF to build better protections against wide-spread monitoring.
As that discussion makes clear, IETF participants want to build secure and deployable systems for all Internet users. Indeed, addressing security and new vulnerabilities has been a topic in the IETF for as long as the organisation has existed. Technology alone is, however, not the only factor. Operational practices, laws, and other similar factors also matter. First of all, existing IETF security technologies, if used more widely, can definitely help. But technical issues outside the IETF’s control, for example endpoint security, or the properties of specific products or implementations also affect the end result in major ways. So at the end of the day, no amount of communication security helps you if you do not trust the party you are communicating with or the devices you are using. Nonetheless, we’re confident the IETF can and will do more to make our protocols work more securely and offer better privacy features that can be used by implementations of all kinds.
So with the understanding of limitations of technology-only solutions, the IETF is continuing its mission to improve security in the Internet. The recent revelations provide additional motivation for doing this, as well as highlighting the need to consider new threat models.
We should seize this opportunity to take a hard look at what we can do better. Again, it is important to understand the limitations of technology alone. But here are some examples of things that are already ongoing:
And we are confident that discussions on this topic will motivate IETF participants to do more work on these and further related topics.
But don’t think about all this just in terms of the recent revelations. The security and privacy of the Internet in general is still a challenge even ignoring pervasive monitoring, and if there are improvements from the above, those will be generally useful for many reasons and for many years to come. Perhaps this year’s discussions is a way to motivate the world to move from “by default insecure” communications to “by default secure”. Publicity and motivation are important, too. There is plenty to do for all of us, from users enabling additional security tools to implementors ensuring that their products are secure.
In the Vancouver IETF meeting, there will be time dedicated to discuss this, and we ask that those interested in working on this topic contribute to the analysis and develop proposals in this area. Those contributions are very welcome and can start now and continue in Vancouver and beyond.
Relevant mailing lists (from most specific to most general) include:
Two Birds of a Feather sessions were approved for the IETF 103 meeting, one of which focuses on Remote ATtestation ProcedureS (RATS).
For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues. However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at.
Two Ph.D. students describe their first participation at an IETF meeting during an Internet Research Task Force Measurement and Analysis for Protocol Research Group (MAPRG) session at IETF 101 in March 2018.
After more than 10 years, the IETF is making a major update to the administrative framework for supporting its work.
William Zhang, a high school student from Alexandria, Virginia, USA presented his work on Automatic Multicast Tunneling at IETF 101 in March 2018.
TLS 1.3 updates the most important security protocol on the Internet, delivering superior privacy, security, and performance.
From July 14 to 20 over a thousand participants gathered in Montreal for a productive IETF meeting.
IETF 102, taking place July 14-20 in Montréal, Québec, Canada, is shaping up as a unique gathering for people from across a wide array of Internet engineering backgrounds and disciplines.
Three community discussion sessions on wide-ranging topics have been approved for IETF 102 in Montreal.
Today, is the 6th anniversary of World IPv6 Launch. We have come a long way since June 6, 2012.
At the end of April the Internet Engineering Steering Group (IESG) gathered in Paris for its 2018 retreat.
The IETF has chartered a new working group to document changes to its administrative arrangements.
I am writing to share the sad news that Bob Braden has passed away. Bob's contributions to the development of the Internet were extensive.
IETF Hackathons began just over three years ago as a way of connecting Internet protocol development more closely with running code, and they have been growing ever since.
Just after IETF 101 in London, let’s analyze the current state of affairs in the YANG Data Models world.
The IETF community took full advantage of the opportunity to collaborate at the 101st IETF meeting last week in London, UK.
Newly selected members of the Internet Architecture Board (IAB) and the Internet Engineering Steering Committee (IESG) were officially seated in their new roles during the 101st Internet Engineering Task Force Meeting held in London this week.
The intent behind this policy is to balance people's legitimate desire not to be photographed with the IETF's ability to document activities and enable remote participation. The following policy applies to all IETF events, including WG meetings, plenaries, and the hackathon.
IETF participants are gearing up for an intense week of collaboration and discussion at IETF 101, with numerous sessions focused on new work proposals and our largest Hackathon yet.
One of the tasks of the IAB is to look at trends affecting the Internet. Recently, we've been discussing traffic flows and popular applications on the Internet, and the role of smaller vs. larger players in the Internet ecosystem.
A slate of new work proposals have been approved for scheduling at the upcoming IETF 101 meeting.
Bufferbloat is responsible for much of the poor performance seen in the Internet today and causes latency (called “lag” by gamers) even by your own routine web browsing and video playing.
The IAOC is pleased to announce Bangkok, Thailand as the site for IETF 103 from November 3 - 9, 2018.
As chair of the 2017-2018 NomCom, it gives me great pleasure to announce the results of the NomCom selection process for all positions to serve for the 2018-2020 cycle.
Internet routers must be able to buffer packets: buffering acts like a shock absorber for transient overloads that arise when the input link is faster than the output link or packets arrive simultaneously on different links bound for the same destination.
The deadline to submit Birds of a Feather (BoF) proposals for IETF 101 is rapidly approaching: Friday, February 2 at 23:59 UTC.
The Internet Governance Forum’s meetings bring together Internet user communities, businesses, technical folk, and a set of UN and government bodies.
Thanks to everyone who provided further input about the revamped www.ietf.org website around IETF 100.
For years, the IETF has been driving the industry transition from an overloaded Software Defined Networking (SDN) buzzword to data modeling-driven management.
Hackers.mu is a developer group based in Mauritius made up of a wide range of people from different backgrounds: high school students, university students, professional engineers, and advisors to the minister of ICT.
IETF 100 wrapped up just over a week ago in steamy Singapore. In addition to our usual productive working group sessions, hallway conversations, and ad hoc collaboration, we took the opportunity to mark the milestone of the 100th meeting with looks backward and forward in the IETF’s trajectory (plus some bubbles and sweets) at the plenary session.
The YANG team delivered again at the IETF 100 hackathon. With our goal to help YANG model users and designers, we developed new automation tools.
IETF 100 is just around the corner. It will offer all the usual opportunities for high-bandwidth exchange among IETF participants and collaboration around specs, coding and interop work.
RFC 8188 builds on existing protocols to provide a new option for delivering trustworthy messages containing confidential information over the Internet.
A highly interactive workshop organized by the Internet Architecture Board raises important issues and generates ideas for significant follow-on work.
Birds of a Feather sessions (BoFs) are initial, informal, in-person discussions about a particular the topic of interest to the IETF community. BoFs may or may not lead to establishing an IETF Working Group.
The IAOC is pleased to announce Vancouver, BC, Canada as the site for IETF 107 from March 21 - 27, 2020.
In early 2002, the RFC Editor revised their website look and feel to one that would stay essentially unchanged for the next 13 years.
I am pleased to share that the IAOC has successfully concluded its search for an interim IETF Administrative Director.
With the intention to encourage the development of a solution to an issue currently under discussion within an IETF working group, I wanted to offer a personal view of a possible ways forward.
IETF Internet Area Director Suresh Krishnan provides a brief wrap up from IETF 99.
IETF 99 is about to kick off in Prague, Czech Republic. There is lots of exciting work going on across more than 100 working groups, plus Birds-of-a-Feather (BoF) sessions, plenary talks, and other meetings.
There has been a lot of progress on the project to revamp of the www.ietf.org website.
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.
5G is the latest generation of cellular network standards. There’s a tremendous amount of activity around it in the industry. But how does 5G relate to Internet technology? Are there 5G-related work items that the IETF should be working on, for instance?
On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows.
Last week I had the opportunity to participate at the 3GPP plenary meeting in West Palm Beach, Florida, USA, at the invitation of the 3GPP liaison to the IETF, Georg Mayer.
Before each IETF meeting, the Internet Engineering Steering Group (IESG) collects proposals for new working groups. We decide which ones are ready for community discussion on the IETF meeting agenda, with input from the Internet Architecture Board (IAB)..
Recently published IETF RFCs aim to expand the capabilities of such services, and to make them more broadly implementable.
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.
The IESG held its annual retreat last week, meeting one day jointly with the IAB and two days on our own in Montreal, Canada.
As Routing Area Directors, we have now made it a habit to share some of our thoughts after each IETF meeting. This is a short summary of some of the highlights from the recent one in Chicago.
About a month ago I officially took on the role of IETF Chair.
Newly selected members of the Internet Architecture Board (IAB) and the Internet Engineering Steering Committee (IESG) were officially seated in their new roles during the 98th Internet Engineering Task Force Meeting held in Chicago on 26-31 March 2107.
The IETF 98 is now over. This was a successful IETF meeting in multiple ways, one of which is the IETF Hackathon, two days of hacking on Saturday/Sunday.
The 98th IETF meeting wrapped up last Friday in Chicago. It was a typically busy work week for IETF participants, but also a special week, as a number of changes in our leadership became official.
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.
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 Chicago IETF begins in a couple of days, and I wanted to point people to a few highlights from my perspective.
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.
Recent news stories, and some IETF list discussion, have related to the release of (claimed) CIA materials relating to surveillance, hacking and information warfare.
The current IETF Administrative Support Activity (IASA) arrangements were created more than ten years ago when the IETF initially took charge of its own administration [1].
Many working groups work with open source repositories, even for their work on specifications.
Every year, the IETF selects its leadership through the nominations committee or NomCom process. Today, the committee has announced our new steering group (IESG) members.
The Internet Engineering Task Force (IETF) is a global community of network designers, operators, vendors, and researchers that develops Internet protocols.
RFCs are documents designed to serve a variety of purposes. They offer information to developers engineers on how to make the Internet interoperate.
We will be hosting another IETF Hackathon at IETF-98 which will take place in Chicago at the end of March. The Chicago Hackathon will run from Saturday March 25 to Sunday March 26, but will surely have follow-ups during the rest of the week.
First, there will be a CodeSprint on Saturday March 25th just before IETF-98 in Chicago.
Do you have an idea that you believe would be worthwhile standardising? Now would be a great time to start talking about it, in time for our meeting in Chicago in March!
The Internet Governance Forum or IGF is a discussion forum on matters relating to the administrative and policy questions surrounding the Internet. A handful of IETFers attended the yearly IGF meeting, this time happening in Guadalajara, Mexico, in December. We wanted to report what we saw and talk about why the discussions at the forum are important.
I wanted to send a post summarising my thoughts of the discussions at IETF-97. We had 1042 people from 52 countries on site in Seoul, very active development on a number of fronts, and I thought a successful meeting! (Apologies for sending this post out late, other tasks, holidays, etc intervened.)
Looking Back on IETF 97
This report is sent out before IETF-97 begins, in an effort to reduce reporting at the plenary and to provide an ability to discuss topics on list beforehand and afterwards.
Let me start with some good news. Not only we recently approved RESTCONF (right now in the RFC editor queue), but we published the IPv4 and IPv6 base routing models in RFC 8022.
There is a class of documents that help guiding a working group to agree on the problem(s) and even converge on a solution. These support documents can include, for example, problem statements, use cases, and requirements.
IETF-97 is starting in a couple of days in Seoul, Korea, as well as running online for many participants connecting over the Internet.
The arrangements relating to administrative support for the IETF (IASA, RFC 4071) were created more than ten years ago, when the IETF initially took charge of its own administration.
The scale, complexity, and potential harm of Denial-of-Service attacks involving the use of compromised or misconfigured nodes or “things” is increasing. Across multiple services and activities, the network seems to be unable to defend itself effectively against large-scale bad behavior. Why is this? Can something be done about it? Who should act?
A month before the meeting our steering group collects proposals for new working groups. We decide which ones are ready enough for the community to discuss the proposals in the meeting. We did this last week, and I wanted to report what new meetings will be held.
Today marks the execution of the contracts and arrangements relating to the IANA stewardship transition. The US government has ended their role in this matter. I am happy about the transition, and happy that it is happening as specified by the IETF and other communities. For me, the key issue is that the communities are in charge.
Standards organisations have their areas of work, but for many topics efforts affect multiple organisations, or even span across multiple organisations. Take the IETF and the IEEE for instance, as our efforts often interact.
I wanted to remind you that we are soliciting proposals for new work at the IETF. If you have an idea, this would be a good time to bring it up!
The essence of the IETF is not that we write specs for some other people to implement. It is that we are a place for people who write code to write specs as well. With that in mind, a big part of our work is allowing for that code writing to happen.
Kicking off IETF 96 in Berlin, Germany was the weekend’s IETF Hackathon. There is growing engagement between the Open Source communities and the IETF. The IETF Hackathon had more participants than ever and we experimented with having a place for it in the IETF Lounge all week.
We had a great meeting in Berlin, the IETF crowd clearly likes to meet there! As our meeting ended, we had 1424 people participating on site and 337 people remotely. Out of the registered remote participants, 79 were from USA, 73 from India, 52 from Brazil, and 13 from Japan.
“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.
When the idea of participating in this hackathon came about, the goal was mostly to leverage FD.io’s Vector Packet Processor (VPP) as a platform and show its performance, capabilities, modularity and development simplicity. So we looked across existing IETF technologies and drafts which were not yet implemented in VPP and found out this new ILA technology (draft-herbert-nvo3-ila), which seemed to be a perfectly valid use-case for VPP used as a physical or virtual router.
This report is sent out before IETF-96 begins, in an effort to reduce reporting at the plenary and to provide an ability to discuss topics on list beforehand and afterwards. This reporting style follows what IAB has adopted in recent times; the plan is to provide only a brief summary in the in-person presentation at the plenary. If you have topics that you think the IESG should, or should already have, discussed, please send email to iesg@ietf.org with details and we'll get back to you.
I arrived in Berlin today, but there are many volunteers and support vendors who arrived days earlier to prepare for the meeting. It takes a lot of effort to setup the network, for instance. The team reports that the network is up and running, and that they have taken over the hotel network as well.
Today is the deadline for registering at the IETF with the early bird price. Do register!
During nearly every IETF meeting since 1993, an informal gathering of women participants, the Systers, has taken place. We chose the name Systers as an answer to the late Anita Borg’s call for women in computer systems to support and celebrate each other.
In my experience it is important that we talk to each other, all of us, the techies, the operators, the economists, and the policy people. We live in a connected world that is developing very rapidly, and none of us have a full picture of everything. It benefits us to share our views and increase our understanding.
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.
I wanted to report what new ideas are going to be discussed at the meeting in Berlin in July.
In the midst of a day’s discussion about particular issue that troubles us with technology or something else, it can be difficult to focus on topics that have a longer timescale. As you probably remember, I had asked a design team to write a draft about various trends around us that affect the IETF.
Today the US Department of Commerce National Telecommunications & Information Administration (NTIA) announced that the Internet community’s proposal to transition the stewardship of the Internet Assigned Numbers Authority (IANA) functions meets the criteria it set out for the process.
If you have followed the IETF discussion list recently, you’ve probably seen a thread about a planned meeting in Singapore next year. Traditionally, the IETF announces meeting sites as they have been contracted. After announcing Singapore during IETF-95, we heard from our LGBTQ participants that laws in Singapore make their participation (particularly when they travel with their families) a concern.
The IETF meetings are a busy time for many of the active participants, including members of our steering group or the IESG. Most of the time is spent in actual working group meetings, and there’s little time to reflect on broader issues. Every year the IESG finds some time for a “retreat” meeting to discuss topics with sufficient amount of time, to get to know the new ADs, do some team building, and so on.
The IESG has just had a two and half days of meetings in Cambridge, Massachusetts. These events are an important opportunity for our group to meet and discuss broader topics and IETF work in more depth than is possible during the regular IETF meetings.
We had a great IETF 95 meeting in Buenos Aires a few weeks ago, with a lot of topics and many participants.
Over the last few years, the IETF community has been focused on improving and expanding the use of the technical foundations for Internet security.
I am pleased to announce that Ericsson has just signed a MoU with the ISOC (Internet Society) in which Ericsson commits to support the IETF in a ongoing fashion.
In 2013, the IESG set the IETF anti-harassment policy. The IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect.
A recent Internet Draft noted the growing Free and Open Source Software movement as a trend that the IETF, as a community, can participate in by helping open source and open standards work together.
This morning I arrived in Buenos Aires, where volunteers and staff have been busy preparing for our 95th IETF meeting. It looks like everything is ready, the network is up and the hotel facilities look great.
The IETF is about interoperation. Yes, IETF participants like cleaner architecture, and more elegant solutions, and so on. But at bottom, both “rough consensus” and “running code” are all about making diverse things work together as much as possible.
It’s almost time to pack our bags and head south to Argentina. This is the IETF’s first ever meeting in Latin America!
Just before the IETF 95 in Buenos Aires, let’s analyze the current state of affairs in the YANG Data Models world.
Many of us have been working over the last two years on a small change to the way the IANA functions are managed.
My previous blog post was about the IETF BoFs, but there are also new meetings in the research arm of the IETF, the IRTF.
With the preliminary agenda just published (or soon will be), I wanted to report what Birds-of-Feather (BoF) sessions there will be at IETF-95. This time there is quite a lot of work following up on a recent IAB workshop on the effect of encryption on network operators.
Some time ago I mentioned the Internet of Things Semantic Interoperability (IOTSI) workshop organised by the IAB. This workshop is important for the work on application data formats, semantic definitions, and interoperability in the Internet of Things space.
This blog post is not about technology. A while ago I asked for volunteers to help us understand some of the non-technical changes around the IETF.
Thinking of some new ideas that could be worked on by the IETF? This Friday, February 19th, 23:59 UTC is the deadline to submit proposals for what we call Bird-of-a-Feather (BoF) sessions at IETF-95 in Buenos Aires.
I cannot think of a better example where interoperability is important than the Internet of Things. Without interoperability, lights won’t work with the switches, sensor’s can’t be read by your smartphone, and devices cannot use the networks around them.
The IETF turns 30! As we work on the day-to-day tasks needed to make the Internet work better, or even as we look back over last year and gaze ahead to the year to come, from time-to-time it is useful to consider our work on timescales that are a bit larger.
This statement published on 2016-01-11 provides IESG guidance on interim IETF working group meetings, both face-to-face and virtual.
With the year closing, I wanted to make a post highlighting some of the events and hot topics of the year. And say a few words about the challenges that lie ahead.
It’s been a while since we’ve had a diversity related update and with the approval of the Anti-Harassment BCP and publication of the Independent Stream Editor (ISE) document, RFC7704 it seems timely.
Perhaps the topmost thing on my mind is how friendly and welcoming place Japan is for the IETF.
The Internet Governance Forum or IGF is an organisation that enables the discussion of public policy issues pertaining to the Internet. It is an open meeting for many different types of participants ranging from (some) technical community members to governments.
The Yokohama IETF Hackathon is now in progress!
The Yokohama Code Sprint is in progress! There are a few new code sprinters, and part our efforts has been in setting up development environments for them, as well as building a Docker image so that future setup will be easier.
Welcome to IETF-94, and back to Yokohama! We were here in 2002, yet I remember it like yesterday. The impression left by the scenery, the Japanese friendliness, food, and many other things was lasting!
Both the IETF and the W3C are meeting in Japan this month.
A recent paper on shortcomings of Diffie-Hellman key exchange has received attention and raised questions about security on the Internet, as Diffie-Hellman is used for cryptographic handshakes in popular Internet protocols.
We’re both at ICANN 54 in Dublin, and of course a big topic is the IANA transition.
The ICANN 54 meeting is now starting in Dublin, Ireland. On the agenda are various topics around the IANA stewardship transition.
横浜のIETFのためのプログラミング!
Claims of encryption having a effect on network bandwidth optimisation methods have been coming thick and fast to the IETF since IETF89. To help understand the real use cases and issues the IAB organised the Managing Radio Networks in an Encrypted World (MaRNEW) Workshop working with the telecoms association, GSMA.
One of the things that can make surveillance too easy is when the technology we use has weaknesses.
MaRNEW This is a joint workshop between the IAB and the GSMA, and the focus will be on managing networks, particularly mobile ones, under the assumption that much of Internet traffic is or will be encrypted.
A key aspect of the IETF is running code, and we often apply our technology in our meetings, or run experiments to determine how well something works or gather information about networks.
The IETF community approved document using the Special-Use Domain Names registry established by RFC 6761 to register ‘.onion’ as a special-use name.
The NETVC working group aims to create a video codec that can be used in open-source software, in addition to proprietary software and hardware encoders.
Our meeting in Prague ended last Friday, and I wanted to thank everyone who participated! I hope you all have had an opportunity to return to home and rest after the trip.
The IETF has recognised that the act of accessing public information required for routine tasks can be privacy sensitive and can benefit from using a confidentiality service, such as is provided by TLS. [BCP188]
The combined proposal from three communities has today gone out from the IANA Transition Coordination Group. This is important.
Today’s blog post is a story from Adam Roach that he had originally shared on social media.
The IETF meeting rooms and registration desk are ready for the meetings to start. A lot of activity is already going on on Saturday this time, but actual registration opens on Sunday at 1000 in the Congress Hall Foyer on the Lower Lobby level.
The IETF is once again in Prague! The city is clearly one of our favourites, given that we’ve been there also in 2007 and 2011.
The 90th IETF starts next Sunday in Toronto, Canada. Canada is one of our favourite places to meet at.
I would like to update you on the IANA transition, including important events that took place at the 53rd ICANN meeting in Buenos Aires.
Earlier this week, I was sitting on a train ride through Finland. As usual, my iPad acted as a mobile broadband gateway, and I suddenly realized that my other devices were using IPv6 to reach the Internet through the gateway.
What will our first meeting next year be like?
Before an IETF meeting, we sometimes receive a few requests to extend the deadlines related to Internet Draft submissions.
The Internet Architecture Board (IAB) and the Internet Society (ISOC) hosted day-long Coordinating Attack Response at Internet Scale (CARIS) workshop took place last Friday in coordination with the Forum for Incident Response and Security Teams (FIRST) Conference in Berlin.
The IESG has received some reports of IETF participants having been listed as document authors on drafts without their consent ("surprised authorship").
Education and newcomer orientation activities have existed in the IETF in various forms from the early 1990s (if not earlier). As the IETF and the world around us evolves, we are now rethinking what types of activities are best suited for the future.
We will once again have a Code Sprint in Prague prior to IETF-93.
This is a good time to submit more new proposals for the IETF!
An IETF meeting is a busy time for the Area Directors. We do not have much time for discussing IETF-wide topics or getting to know new team members. Every year we meet for a couple of days as a team, outside the IETF meeting.
The first flow-related BoF (birds of a feather) took place in London in summer 2001 during the IETF meeting 51.
On the weekend before the IETF meeting in Prague (July 18-19), we will hold our second IETF Hackathon event at the Hilton Prague.
This is a brief report from a meeting between a number of Internet organisations that took place last week in London.
Every year, IETF’s leadership groups (IAB, IESG, IAOC) meet for retreats. This year all the three groups meet in London.
End-to-end (e2e) encryption for email is hard. We know this from OpenPGP and S/MIME efforts with the main problem being around obtaining, installing, and exchanging keys.
One of the great scientific challenges of our time is the construction of a practical quantum computer.
You may have heard about the IANA transition, or to be more precise, about the transition of US government oversight relating to IANA. In March 2014, the US government announced their intent to relinquish their role to the multistakeholder Internet community.
La semana pasada, al hablar de Internet abierta para un evento de Gobernanza en Moscú, Jari se reunió con gente del Capítulo Rusia de Internet Society.
The upgrade to the datatracker UI mentioned in plenary at IETF 92 has just been released. This effort has been underway for more than a year.
Last week, while speaking about open Internet in Moscow for an Internet Governance event, Jari met with folks from the Internet Society Russia Chapter. They had recently made a translation of the IETF Journal to Russian!
April 7 marks the anniversary of the publication of the first RFC.
Thank you all for a wonderful meeting. I wanted to thank all the sponsors and participants, and our host Google for their support. And the wonderful social event. Well done, you all!
Newly selected members of the Internet Architecture Board (IAB) and the Internet Engineering Steering Committee (IESG) met in person for the first time during the 92nd Internet Engineering Task Force Meeting this week in Dallas, Texas.
Coordinating incident response at Internet scale as a concept sounds fabulous, but can we achieve it? What will it take?
First things first, the network for IETF-92 is up and works well! Both the meeting area and hotel room networks are operational.
There is just 10 days until our next meeting begins, in Dallas, Texas. This is our third visit to Dallas
We will once again have a Code Sprint, now in Dallas prior to IETF-92.
One question that often comes up regarding the IANA Stewardship transition is how to ensure that the IANA protocol parameter registries continue to serve the worldwide Internet community.
After more than two years of discussion, over 200 design issues, 17 drafts, and 30 implementations, the HTTP/2 and HPACK specifications have now been approved by the IETF’s steering group for publication as standards-track RFCs.
The deadline for submitting proposals for new working groups for IETF-92 is approaching fast.
I’m on the train this morning after the two-day Stack Evolution in a Middlebox Internet (SEMI) workshop at the Swiss Federal Institute of Technology (ETH) in Zürich.
In less than 9 months–representing just two IETF meeting cycles–the DiffServ Applied to Real-time Transports (DART) working group (WG) moved from a concept to Internet Engineering Steering Group (IESG) approval of the Internet Draft it was chartered to produce.
The IETF traces its start back to a meeting that took place 29 years ago today, January 16th. Happy birthday, IETF!
Protocol parameters such as port numbers are an integral part of technical specifications that the IETF produces and developers implement. Along with naming and numbering functions, protocol parameters are maintained through IANA.
In March the US government announced their intent to move their role in overseeing the IANA system to the Internet community. Since the announcement, the communities impacted by IANA functions have been working hard to develop a transition proposal.
Just after the IETF 90 meeting last July, I posted this “YANG Takes Off in the Industry” blog.
Our meeting in Honolulu is over. How did it go? Let us know. In the following I have collected some of my own observations.
This week at IETF91 we carried out an experiment to randomize Wi-Fi MAC addresses of users to improve privacy.
New to the IETF, or exploring new topics for your work? I wanted to point people to the various introductory sessions and materials that we have about the IETF and Internet technology.
I wanted to welcome everyone to the 91st IETF meeting that is starting tomorrow, November 9th, here in Honolulu, Hawaii. I also wanted to welcome our remote attendees!
We wanted to let you know that a number of Chinese participants have had trouble for getting visas to this meeting.
The network for the IETF is a bit of a unique beast.
The IETF meeting in Honolulu starts a week from now.
I thought it might be useful to provide a brief summary of some of the things that have happened in the past week related to the transition of the IANA Stewardship.
New IETF work begins often as a proposed new working group, through something called a Birds-of-a-Feather (BoF) session.
We will once again have a Code Sprint in Honolulu prior to IETF-91.
The transition of NTIA’s stewardship of IANA has been discussed extensively. Just last week there was a meeting of the IANA Stewardship Transition Coordination Group or ICG.
The OpenStand approach to creating global standards has never been more relevant—or important—than it is today.
The IETF has had another lively discussion about mailing list usage in the ietf@ietf.org mailing list, followed by a long plenary debate on how to make it more useful to the community.
In 2003, RFC 3535, “Overview of the 2002 IAB Network Management Workshop” documented the outcomes of a dialog started between network operators and protocol developers to guide the IETFs focus on future work regarding network management.
IETF-90 is over and I wanted to provide a summary of what I saw in the meeting.
We have built a lot of support for remote attendance in the IETF, but this week I saw something new.
On Thursday morning of the IETF 90 meeting, we had a Birds of a Feather (BoF) session called IANAPLAN: Planning for the IANA/NTIA Transition.
RFC 2026 defines a "Historic" status for documents: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level.
Last week, I visited the ICANN50 meeting in London. The meeting was held at a location well known to us at the IETF – the Hilton London Metropole.
For every IETF meeting, the steering group receives a number of proposals for new work. Not all new work in the IETF has to go through a public meeting to be accepted.
New IETF work begins often as a proposed new working group, through something called a Birds-of-a-Feather (BoF) session.
During an IETF meeting, the IESG and IAB members are busy with what is going on in our areas, and we have little time to talk to each other. But we organise yearly retreats where we get to talk to each other, and can tackle issues beyond the usual daily ones.
This document describes the role of the 'DISCUSS' position in the IESG review process. It gives some guidance on when a DISCUSS should and should not be issued. It also discusses procedures for DISCUSS resolution.
The NETmundial meeting was held last week in São Paulo, Brazil. I wanted to provide a brief report of my view of the meeting and its outcome.
I have previously talked about the upcoming changes at IANA.
The two-day NETmundial conference that starts on Wednesday. Me, Russ, and several other IETFers are attending this event.
The previous blog post talked about the IANA discussions at the ICANN meeting. But of course that was not the only topic that we talked about.
Two weeks ago there was an announcement from the US government regarding their role in managing IANA.
The leaders of the Internet technical organizations responsible for coordination of the Internet infrastructure (IETF, IAB, RIRs, ccTLD ROs, ICANN, ISOC, and W3C), welcome the US Government’s announcement of the suggested changes related to the IANA functions contract.
I wanted to share two excellent videos in this post.
Today I would like to celebrate the anniversaries of the World Wide Web (25 years) and W3C (20 years).
With the IETF week over, I wanted to write a brief summary of the main discussions. And what a week! I spent ten days in London due to a workshop preceding the IETF and even some meetings that took place after the IETF.
The IESG is aware of discussions in the OPS area and in a number of working groups about the current practice for standards-based approaches to configuration.
The IETF-89 meeting is starting a week from now in London, UK. This is our second time in London. Our previous visit was IETF-51 in August 2001.
The IETF’s relevance in the marketplace was the subject of a workshop held by the IAB in December in Cambridge UK on Internet Technology Adoption and Transition (ITAT).
Today is International Data Privacy Day, and I wanted to let Alissa Cooper say a few words about how we are working on privacy topics at the IETF. - Jari Arkko, IETF Chair
I wanted to draw attention to Mark Nottingham’s excellent blog article about strengthening HTTP.
In this article I wanted to highlight an important but often hidden part in the IETF ecosystem: Internet Assigned Numbers Authority (IANA).
The last days of the year seems like a good opportunity to reflect on some of things that happened during 2013.
Wow what a week! Working with Internet technology often involves details deep inside the technology. But it seems that this week has been a perfect storm of highly visible and important technical developments:
L’IETF a suscité un large consensus pour l’amélioration de la sécurité des protocoles Internet en réponse à la surveillance omniprésente
Amplio consenso de la IETF por mejorar la seguridad de los protocolos de Internet en respuesta a la vigilancia generalizada
IETF reaches broad consensus to improve the security of Internet protocols to respond to pervasive surveillance
Reports about pervasive surveillance have been the big discussion topic in the Internet community in the last couple of months. Our commerce, business, and personal communications all depend on the Internet being secure and trusted, so the situation is disturbing.
Many students were brought to IETF 87 by a pilot university outreach programme, run by ISOC with 15 universities in Germany and Austria.
This IESG statement explains that the IETF strives to create and maintain an environment in which people of many different backgrounds are treated with dignity, decency, and respect.
The IETF network for the meeting is up. Even the network in the hotel rooms switched to IETF network by mid-Friday. Everything is ready for the IETFers to come!
The IETF-88 meeting is starting next week in Vancouver. Vancouver is a long-time IETF favourite city, as this will be our fifth time there. And we were there just last year. Vancouver works well for the IETF, and I’m very happy to return again!
More than 1200 top engineers and technologists will assemble to advance the development of open Internet standards
When I visited the ICANN meeting last summer, they were about to launch a set of panels to advice themselves about strategic topics in coming years. Those panels are now operational.
As I mentioned in “Security and Pervasive Monitoring” article in September, the IETF community has expressed concerned about the large-scale monitoring of Internet traffic.
I visited the RIPE meeting and IGF meetings recently, and wanted to post two speeches that I held in these events.
Last week I toured China, talking to the local IETF contributors. And there are so many! I talked to people from equipment vendors, operators, researcher institutions, and local standards organisations.
The Internet community and the IETF care deeply about how much we can trust commonly used Internet services and the protocols that these services use.
It seems like yesterday when we were in Berlin, but I wanted to highlight that our Vancouver meeting is coming up soon.
The IETF meeting in Berlin is now over. I hope everyone has been able to return home safely, and that you all can enjoy at least a weekend if not some vacation time after a busy meeting week.
I wanted to return to a topic that we have talked about before: increasing diversity at the IETF.
A while ago I wrote about the issue of the IETF document process being quite heavy-weight in its final stages. Documents go through a lot of review and changes in their last few months. Some of this is natural as the document gains more exposure.
This week I’m visiting the ICANN meeting in Durban, South Africa. It has been an opportunity to meet many interesting people and get a glimpse of the issues that other important organisations in the Internet ecosystem deal with.
The Internet of Things is about embedding communications technology in all objects that can benefit from it, from cars to buildings, everyday objects and even materials. This is an ongoing revolution in the scope and scale of networking.
In two weeks, we will have the IETF-87 meeting in Berlin! The previous time IETF was in Germany was in August 1997 in Munich – that was too long ago and it is a pleasure to be back!
I would like to talk about standards and what kind of approaches are suitable for developing them when it comes to Internet technology and applications.
One of the most rewarding parts of my job is talking to various IETF contributors or people who rely on our results, and trying to understand their experiences about the IETF process and what kinds of technical topics they expect us to tackle. This article focuses on the process aspects.
Diversity has been a recent big discussion topic at the IETF. Many of us have participated in this discussion, but I also wanted to bring it up here in the blog.
I wanted to return to the topic of Bits-n-Bites which we briefly reported on already earlier. Dan York and Paul Brigner from ISOC shot a few videos of some of the interesting demos, and the videos are now available below.
As we were preparing for the Orlando meeting, we talked about ways to make the Bits-N-Bites program more dynamic and provide a place for the IETF community to perform experimentation and get running code in a production like network setting.
IETF participants define the standards for the global network that connects more than 2 billion people
Our meeting in Orlando ended on Friday. I thought it was a very successful meeting, and brought up many new topics that we should pursue.
I would like to welcome you all to Orlando, where the 86th IETF meeting starts on Sunday!
The previous article talked about how exciting and important the work at the IETF is. And it is. But there are also challenges, both for the Internet as a whole and for us at the IETF.
Welcome to a new publication from the IETF, a blog from the (incoming) IETF chair!
The IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC).
Internet-Drafts (I-Ds) are working documents of the IETF. RFC 2026, BCP 9, describes the purpose of I-Ds, and it also provides some policies that govern the I-D Repository.
IEEE, IAB, IETF, Internet Society and W3C Invite Other Standards Organizations, Governments and Companies to Support Modern Paradigm for Global, Open Standards
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
This IESG statement describes the manner in which the IESG will process RFC Errata concerning RFC Metadata [RFC5741].
This statement provides guidance from the IESG on selection of a Document Shepherd for documents from IETF working groups and documents from individuals.
Protocol specifications and other documents intended for RFC publication often include useful examples with correctly formatted and syntactically valid codepoints, addresses or names.
RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings.
This IESG Statement obsoletes all earlier IESG Statements regarding Copyright statements in MIB and PIB Modules.
This IESG Statement deals with the proposed status for IETF documents reserving values, numbers, addresses, etc. for example purposes. In this statement we use the term 'resources' for these values, numbers, addresses, etc.
This statement dated 2008-09-02 provides IESG guidance on interim IETF Working Group meetings, conference calls, and jabber sessions. NOTE: This statement is superseded by the IESG Statement "Guidance on Face-to-Face and Virtual Interim Meetings" dated 2016-01-11.
The [below] describes the manner in which the IESG will be processing RFC Errata for the IETF Stream. The current tools on the RFC Editor site support "approved" and "rejected", but they need to be updated to also permit "hold for document update" as errata states.
The following principles apply to spam control on IETF mailing lists:
RFC4395: Guidelines and Registration Procedures for New URI Schemes
RFC 3406: URN Namespace Definitions
Managing off-topic postings to IETF Working Group (WG) mail lists is challenging.
The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may be made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026.
This document describes the process that the IETF transport area directors employ when new congestion control algorithms that differ significantly from currently-published IETF standards are brought to the IETF for specification and publication as Experimental RFCs.
This statement discusses the process related to "individual submissions", publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This statement covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate.
Under RFC 2026, the IESG issues Last Calls to the IETF community for all draft Standards Track and BCP documents, and for selected draft Informational and Experimental documents.
Nearly all RFCs contain citations to other documents, and these are listed in a References section near the end of the RFC.
The IESG today makes the following statement, but will welcome community feedback on it.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Spam Control on IETF Mailing Lists" dated 14 April 2008.
The IESG has decided that as of now, any IESG-approved drafts that enter the AUTH48 state, where the RFC Editor waits for final text approval from all listed authors, may be released on the responsible AD's authority if any authors have not responded after a reasonable time, typically two weeks.
The IESG does not prescribe the use of any single syntax for format definitions.
IDNA [IDNA] specifies an encoding of characters in the Unicode character repertoire [UNICODE] which is backwards-compatible with the current definition of hostnames.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Copyright" dated 8 September 2009.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Spam Control on IETF Mailing Lists" dated 14 April 2008.
Design teams are mentioned in The Working Group Guidelines RFC (RFC 2418) as follows:
This temporary guideline has been prepared by the IESG in response to a specific case; it is intended that it be put into an internet-draft and progressed as an IETF consensus position.
NOTE: This statement formed the Sub-IP Area, and this Area has subsequently been closed.
Two weeks ago I sent a message informing the community of some plans to improve the organization of some significant work going on in the IETF on "sub-ip" technologies.
Traditionally the IETF has focused its efforts "above the wire and below the application."
This is the IESG "Statement Guidance on Interim IETF Working Group Meetings and Conference Calls" dated 2000-08-29 . NOTE: This IESG Statement is superseded by the IESG Statement "Guidance on Interim Meetings, Conference Calls and Jabber Sessions" dated 2 September 2008.
In some cases, it is necessary and appropriate to moderate IETF mailing lists.