Gergana Petrova

IETF 101 Liveblog

Gergana Petrova
Contributors: Massimiliano Stucchi, Colin Petrie, Gwen van Berne, Marco Hogewoning, Nathalie Künneke-Trenaman, Tim Bruijnzeels, Mirjam Kühne, Stephen Strowes

40 min read

The 101st meeting of the Internet Engineering Task Force (IETF) runs from 17 - 23 March 2018 in London. RIPE NCC staff at the event will be live blogging key moments. See this page for regular updates on the issues, arguments and ideas discussed over the course of the meeting.

23 March 2018, 12:00

Day 5: Congestion Control

The IETF week is nearly over and my first and last session of the day is congestion control. Paul Congdon presented P802.1Qcz – a project which aims to isolate congested data flows within data center environments such as high-performance computing and distributed storage. Bridges individually identify flows that create congestion in the data center and adjust the transmission selection for those flows and the signal congested flow information to the upstream peer.

Ingemar Johansson presented his experiments when modifying BBR (Bottleneck Bandwidth and RTT) for L4S support. It converges quite well when multiple flows compete for the same bottleneck by keeping the queue small. There is a degree of jitter, a result of the necessity to be a bit aggressive in order to achieve convergence for multiple flows.

Michael Schapira presented on PCC (Performance-oriented Congestion Control). Unlike BBR, which models the network pipe as a single link and tracks the bottleneck bandwidth, PCC associates rate with utility value and applies online learning to adapt the rate in direction and pace that yields higher performance. PCC reacts better to network changes, has a better buffering ratio for streaming video and achieves better throughput-latency tradeoffs in LTE-like environments.

 - Gergana

22 March 2018, 18:00

Day 4: SIDR Operations

At the sirdops WG we started off with a presentation from Aris Lamprianidis from AMS-IX about "Signaling Prefix Origin Validation Results from a Route Server to Peers”. They suggest to introduce a transitive 4-octet AS specific extended community to flag invalid routes and want to lower the barrier of new entrants of RPKI who are reluctant in dipping their toes due to political, technical or business reasons. There were some concerns that this draft steps away from the end-goal of native origin validation filtering.

Next, Sriram Kotikalapudi presented the draft Origin Validation Policy Considerations for Dropping Invalid Routes addressing questions such as: How to deal with invalid state ROAs? When should you drop them if there is a more specific route? This draft is a soft stick, it recommends to drop an invalid ROA if the address space is covered by a valid or not found route.

The next three presentations came from our very own Tim Bruijnzeels. The first one was about RPKI signed object for TAL. Sometimes a new URI (Uniform Resource Identifier) or new key is needed for a Trust Anchor and at the moment the new Trust Anchor Locator has to be installed by hand. This draft covers planned roll-overs and how to publish new URIs for example HTTPS to Trust Anchors. Tim was collecting feedback if he should include unplanned key-rollovers, and time slots.

Tim was collecting feedback if he should include unplanned key-rollovers, and time slots.

The next one was about RPKI Trust Anchor Locator, which is adding support for HTTPS URIs in a TAL (Trust Anchor Locators). It was very straight forward and there were no comments or questions.

Tim's last presentation was about the new version of our RPKI Validator, version 3. Tim is looking for beta-testers and explained the new features: added support for router certificates, added incremental updates and better stability. We’re still working on adding the possibility to create local exceptions and whitelists. At the moment we don’t have a CLI, but we’re interested to hear you if you need it.

- Nathalie

22 March 2018, 17:50

Day 4: Building Community Internet

The Internet is an enabling environment for human rights (RFC 8280). Yet, as Luca Belli explained during his talk, there are many factors that prevent people, especially people from remote areas, from connecting to mainstream networks: connectivity might not be available, due to lack of interest from operators (low return on investment); connectivity might be too expensive due to limited competition between operators keeping prices high; people's lack of interest due to absence of relevant local information in the local language; or simply low levels of literacy. The author spoke against zero rating arguing it severely limits Internet experiences of the users. They become passive app consumers, who also trade in their personal data. He proposed that people should instead build their own internet and tht barriers for doing so should be scrapped. Recently groups of individuals have been doing just that - building local networks, used and managed by the community.

An interesting discussion arose after the presentation. People debated if it is fair for individuals to be burdened with arranging their own connectivity, rather than obliging governments to provide universal Internet. However, it was noted that governments are notorious with misusing funds intended to increase access and coverage. In the end it was agreed that the right to individuals' network self-determination should go hand in hand with the governments’ efforts (and obligation) to provide connectivity to everyone.

- Gergana

22 March 2018, 15:30

Day 4: Global Access to the Internet for All!

During the GAIA RG we heard a series of interesting presentations about community networks in various parts of the world. For instance Vassilis Chryssos from the technical university in Crete explained how they are building local WiFi networks together with local village farmers. The motivation for these farmers are their grandchildren: they are more likely to visit them if they have Internet connectivity in the village :-) But obviously there are other motivations such as access to online medical services. People loved the presentation and the projects, bu they had some questions about the sustainability and maintenance of such community networks.

Village Farmers building a community network on Crete

Jonathan Brewer from the Network Startup Center (NSRC) talked about constraints for IoT or sensor networks and the various radio frequency protocols available at the moment. He highlighted the pros and cons and gave some recommendations which of them might work best for community networks.

- Mirjam

22 March 2018, 13:00

Day 4: Systers Lunch

I attended the IETF Systers lunch which is now an integral part of the meeting. It was great to see about 50 women in the hotel restaurant (more than we could fit comfortable), newcomers and more experienced participants. Kathleen Moriarty, security area director until yesterday evening (when she was presented with this cute little unicorn), welcomed everyone and thanked the many sponsors (the number of sponsors is also growing which is a good sign). Kathleen also used the opportunity to introduce some women who currently hold leadership positions in the IETF (IETF chair, IRTF chair, area directors and working group chairs) and encouraged others to think about becoming WG chairs in the future. The systers lunch is always a very delightful experience and a great opportunity to meet interesting women in the IETF community.

- Mirjam

21 March 2018, 19:00

Day 3: Plenary - Respectful Behaviour and The Future of Internet Access

Alissa Cooper, the IETF Chair, gave an update about the IASA 2.0 BoF that is reviewing the current administrative structure of the IETF (including the possibility of setting up a legal entity for the IETF).
Further discussion will be held on the mailinglist.

IETF 101 Plenary session with beautiful sparkling ceiling

Alissa also mentioned the importance of respectful behaviour in the IETF. There are number of policies and guidelines in place (in addition to the anti-harassment policies and BCPs , there is now also a photography policy). Alissa stressed however that the policies are only one part of the story. This community is as respectful as we make it. “Treat people the way you want to be treated.”

Andrew Sullivan, the newly elected chair of the IETF Administrative Oversight Committee (IAOC) informed the community that the IETF budget is static, but the revenues are decreasing and that it might be necessary to increase the meeting fees next year, possibly by 10%.

Per usual, the call for nominations for the Jon Postel Awards opened today and will remain open until 2 May.

Allison Mankin, the chair of the Internet Research Task Force (IRTF) gave an update of recent IRTF activities. She mentioned that there might be a Quantum Internet RG (QIRG) in the future. I am especially happy to see this, because we supported Stephanie Wehner and her team with this effort (after an impressive presentation at the RIPE 74 meeting and an article on RIPE Labs.

The technical part of the plenary covered an interesting and important topic: The Future of Internet Access. All three presentations were great! Leandro Navarro Moldes, Associate Professor at Universitat Politècnica de Catalunya, started by referring to RFC 3271 which stated that the Internet is for everyone. However, that is not yet the case yet. Leandro stressed the importance of community networks and showed some successful examples in various parts of the world. The next speaker Steve Song, researcher at the Network Resource Startup Center started his presentation by quoting an industry friend who helps to connect people in remote areas and who said:


Steve further talked about how diversity matters, also in technology and in the access market. He said that “access diversity breaks oligopolies.”

The last speaker in this series, Jonathan Brewer, Consulting Engineer at Telco2 Limited, gave a fascinating and also funny presentation about satellite technology and why he believes the future of the Internet is up in the sky.

The last part of the plenary was dedicated to the open mic session, an important oppportunity for the IETF community to ask questions or raise issues with the IESG and the IAB.

- Mirjam

21 March 2018, 18:30

Day 3: Protocols on a Diet

One of the guiding principles of the IETF has always been Antoine de Saint Exupéry’s "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.” But that doesn’t mean that all protocols developed here are lightweights. Especially from the perspective of a small, battery operated IoT device, implementing and using some common protocols can be quite a burden.

The Internet protocol suite, TCP and IP are actually not that popular amongst the people who design and build the small sensors and actuators that we usually classify as the IoT’s thing. Some of these arguments might be valid, keeping state in the traditional sense of TCP can be quite a big thing, if all you need is to send a few bytes representing a temperature. Likewise, in low power radio long range environments, the full IP and TCP/UDP headers might be larger than the packet you are allowed to send.

Over the years the IETF has been working on addressing some of these issues and we saw for instance the birth of 6lo, a trimmed down version of IPv6 that is much better suited to be used on such constrained networks. Similarly, the Constrained Application Protocol (CoAP) tries to minimise some of the protocol overhead at the application layers, by providing a light weight way to access web APIs.

Even though these new protocols exist, pickup by the market is still very limited. In order to address some of these barriers, IETF's Light-Weight Implementation Guidance (LWIG) is chartered to exchange experience and document best practice and implementation guidelines for IETF protocols in constrained environments. If you are working on IoT applications and devices, it is certainly worth tracking the output of this group or share your experience and help others.

- Marco

21 March 2018, 17:30

Day 3: Public Policy Programme Continued

During the third day of the Public Policy Programme we discussed topics such as encryption, hijacking, IXP and BGP peering and community networks. LINX gave a presentation about their role in this spectrum. We attended a session where IETF, IAB and ISOC leadership explained how they fulfil their role and what they see as the main challenges for the future of the Internet. We learned more about possible concerns for consolidation and capacity. The interoperability will become more complex when more people and devices connect and this means that the work of the technical community needs to evolve accordingly. Technical standards and policy makers have to work together on this.

- Gwen

21 March 2018, 15:30

Day 3: Cooperation

At the IETF, a lot of useful work gets done outside of the sessions. Today Thiago, Felipe and I met with Rafael Cintra and George Michaelson from APNIC and discussed how they are using Kubernetes to manage deployments of their software. We have been looking to use this as well, so hearing from our Asia Pacific counterparts whose service and software landscape is very similar to ours, was extremely useful.

- Tim

21 March 2018, 13:30

Day 3: Quantum what?

We've already posted a few summaries from the Internet Research Task Force (IRTF) sessions. Today, the IRTF Open took place. Firstly, let me remind for the ones new to this, as the chair Allison Mankin, pointed out: the IRTF focuses on longer term research issues related to the Internet, while the IETF - shorter term issues of engineering and standards making.

So let's get into it. The first presenter talked about unentangled networks, which are good only for quantum key distribution (QKD) and entangled networks, which can also serve as high-precision sensor networks or connect quantum computers into a Quantum Internet. The presentation reviewed experiments at the Technical University Delft for QKD and entanglement distribution via satellite. Those interested can get involved with the Quantum Internet Alliance or the discussion around potentially forming a Quantum Internet Research Group.

Next followed two presentations by winners of the Applied Network Research Prize. The first identifed CDN performance problems, from the server, network and client sides, that impact video streaming using end-to-end per chunk measurement. The second presented Vroom - an end-to-end solution that fully utilises CPU/Network by decoupling dependency discovery from parsing and execution. The author claimed that Vroom decreases median page load time by 5s for popular sites - pretty cool!

- Gergana

20 March 2018, 21:00

Day 2: Social and Science

This IETF's social event took place in the London Science Museum. It was great to walk around among airplanes, cars and old instruments. The display below especially caught my eye :-)

Display of early measurement tools

- Mirjam

20 March 2018, 18:00

Day 2: DNS Operations

An interesting discussion at DNS Operations revolved around the draft that would like to provide an additional mechanism to RFC5011 for identifying which root key to use for DNSSEC Validation. This is a very important function, because it should allow the Root Key to be rolled - exchanged - more smoothly. The first Root KSK Key rollover will happen in a few months, and it's considered some sort of uncharted territory. The DNS Operations Working Group has been active in trying to find solutions for a better DNSSEC experience. The discussion at the session would feed nicely into the root KSK rollover webinar I will be holding on 27 March.

Another discussion concerned CNAMEs not being accepted at the top of a zone. This means that you can have redirection in dns for, but not for This is a problem for many CDNs, which can't be used with zone apex domain names. The draft presented tries to eliminate this problem by providing a new resource record, the ANAME. The room agreed on it being needed, but provided some guidance on how to make it better and a direction to go for future revisions.

- Max

A quite humorous presentation by Bert Hubert, The DNS Camel, suggested that the ever increasing number of extensions to the DNS protocol, increase the complexity of the system, which might lead it to break at some point in the future. Several DNS implementations ceased to exists and as the problems get more complex, there are less and less people capable of solving them. Whereas decreasing diversity in vendors might not be regarded as an immediate problem, it is a disturbing trend. However, the real danger might not be in the few implementations that manage to keep up, but in the many that don’t.

Bert causing a bit of a queue at the dnsops microphone

The discussion focussed mainly on “when to say no”. In the situation of Bert’s example, the server had to be modified to cater for implementation issues in the CPE. Several people attested to similar events where implementation decisions are driven by client demand, which from an economic perspective is not all that strange. The working group discussed several options to try curb the number of new features, especially focussing on those current standards that are not implemented or provide a very niche feature. An RFC with the “core” DNS RFCs could help there, as well a better feedback from the operational community on which features are really needed.

- Marco

20 March 2018, 17:20 UTC

Day 2: Paths, Paths, Paths

As Brian Trammell eloquently explained in the Path Aware Networking Research Group, an internetworking architecture is path-aware if the network explicitly exposes information about the paths to the endpoints and if it allows those endpoints to have control over the paths over which their traffic will be sent. The current Internet architecture is not path-aware, but IETF technologies (and others) could be used to build a path-aware Internet. It would expand multi-path transport beyond multiple-connected devices, explore alternate routing architectures and experiment with cooperative signaling.

Theresa Enghardt, a PhD student at the TU Berlin, presented a socket intents prototype that selects a path with shortest expected completion time. Daniel Bernier talked about using segment routing for selecting a network path based on need. Tom Herbert presented on using packet tickets to allow applications to signal the network for services it wants applied to packets.

Spenser Dawkins reflected that during the first PANRG meeting, at IETF 99, there was a lot of path awareness, but not much experience with getting path awareness deployed. He urged the audience to help him document their learning experiences, mistakes or ideas.

Brian presented a few open questions. How should transport-layer and higher layer protocols be redesigned to work most effectively over a path-aware networking layer? How is path awareness different when applied to tunnel and overlay endpoints? How can a path-aware network be effectively operated, given control inputs from the network administrator as well as from the endpoints? How can the incentives of network operators and end-users be aligned to realise the vision of path-aware networking?

The audience hummed in support of transitioning the Research Group into full status. Yay!

- Gergana

20 March 2018, 14:20 UTC

Day 2: Measurement and Analysis for Protocols

The Measurement and Analysis for Protocols Research Group is always an interesting meeting. The aim of the group is to present measurement results to shine light on how the internet and internet protocols actually behave in the wild. In all, there were 11 presentations, and the RG is well worth checking out!

Luuk Hendriks presenting at maprg

Some of the most interesting things to me are IPv6 measurements, and maprg provides a few: Luuk Hendriks, a former RACI attendee at RIPE 69, presented his ongoing battle to find ways to visualise the IPv6 space. Tommy Pauly presented some of the first substantive performance results measured by Apple on how TCP performs over IPv6, not only by TCP handshake RTTs, but also by taking SRTT values at the end of connections. Also, Erik Nygren presented his measurements on IPv6 growth, while also considering residual IPv4: the 55 biggest networks appear to carry 50% of the IPv4 traffic, and more than half of those have IPv6. But as you run further down the tail of this distribution, fewer networks have nontrivial IPv6 deployments.

- Stephen

20 March 2018, 13:00 UTC

Day 2: Lunch at the IETF

Lunch meeting at a near-by lebanese restaurant with Job Snijders, Max Stucchi, Nathalie Künneke-Trenaman, Guillermo Cicileo and Tim Bruijnzeels

Lunches at the IETF are all about work. Today I had a lunch with my colleagues Tim and Max, Guillermo from Lacnic and Job Snijders from NTT. Yesterday, Job pitched an idea in the IETF grow working group about introducing the concept of as-sets in RPKI. We discussed how to investigate this idea at the RIRs, what the use cases would be and a brainstorm session about tooling and features.

- Nathalie

20 March 2018, 11:15 UTC

Day 2: Your Opinion on Consolidation

Discussions at the IETF do not stop at the protocol level. A new protocol might be far superior to an existing one, but in a model where adoption is voluntary, it also needs some to bring some economic benefit to the operators and providers deploying it. It's often mentioned that IPv6 is subject to a "first mover disadvantage” where the costs of deployment is not linked to any direct return.

In a recent paper, the Internet Architecture Board is asking how market consolidation and the existence of a few large players influences the Internet ecosystem and work at the IETF. While there probably isn't a single magic solution, it certainly is a discussion worth having. What happens with a new protocol? Who is important when it comes to implementation? How can you convince those entities to implement this new protocol? How does IPv6 bring benefit to your company?

We would love to hear more from you on this topic via the IAB architecture-discuss mailing list or the comment section of this blog. What are the effects of those extremely large players to the Internet, whether good or bad and how can we safeguard the Internet against some of the negative effects on smaller and new providers?

- Marco

19 March 2018, 20:00 UTC

Day 1: Crypto Forum

The Internet Research Task Force session on crypto was quite a challenge for the not-technical of heart. It started with a presentation on tools for verifying optimised assembly and C implementations. The speaker proposed HACspec - a new high-assurance specification language and encouraged the audience to use it in their next RFC and send him feedback. The next speaker explained that PRNGs (pseudorandom number generators) can break or contain design flaws such as the Debian and Dual_EC bugs. He proposed the NAXOS trick: a tool whose distinguishability guarantees reduce the secret key security for broken PRNGs. The next talk gave a breakdown of the reasonable mechanisms for Hashing to elliptic curves. Several methods were discussed (for the ones who really want to get into it: icart, SWU, Simplified SWU, Elligator2).

I hope I haven't lost you! Next was a presentation on PAKE (Password Authenticated Key Exchange), which enables two parties to establish a shared cryptographically strong key over an insecure network, using a short common secret as authentication means. The author proposed two PAKE protocols which support forward security and work in any group.

Slide at the Crypto Forum

- Gergana

19 March 2018, 19:00 UTC

Day 1: The Public Policy Programme

With the socioeconomic importance of the Internet rising, governments and regulators want to understand what goes on behind the scenes: who makes the decisions on what the Internet looks like, how it functions, and even more important - how these decisions are made. About four years ago, the Internet Society (ISOC) launched an intense multi-day programme that introduces policy makers to the work of the IETF. A number of experienced IETF participants gave these fellows a high level overview of the main discussion topics, often intertwining these presentations with some history that explains how we got to where we are now. Another important element is the opportunity for policymakers to attend some working group sessions and sit down afterwards to reflect on the session and ask questions to people involved.

- Marco

The day started with a presentation from Olaf Kolkman, ISOC, about DNS and the functioning of name servers. Robert Pepper, Facebook, then gave an interesting presentation about the implications from the inclusive Internet index. Together with the Economist, he is involved in measuring the broader aspects of the Internet ecosystem. He explained the data sets that they are using and the 57 indicators that measure country differences around Internet usage and connectivity. Marco Hogewoning, RIPE NCC, explained why it is important for governments to move forward with their IPv6 deployments.

The group then went to the IETF 6man WG session where the maintenance issues of IPv6 were discussed. There was a discussion about the pass of extension headers which got a "hum" from the community. Furthermore, I witnessed a debate about a new flag option for router advertisement. The flag allows administrators to notify dual-stack hosts that IPv4 is not available on default routers. The community debated the wider implementation implications (what does this mean for our behaviour) and several participants argued why they supported this initiative (see more on this below). After the WG session we received more information from George Michaelson, APINIC, about IPv6 capability and eyeball share (market penetration) in Asia. Guillermo Cicileo did this for LACNIC. Fred Baker and Ryan Polk ended the day with a presentation on routing security and Salam Yamout, ISOC, explained to policymakers the relevance of MANRS.

- Gwen

19 March 2018, 18:00 UTC

Day 1: News in Internet Domain Routing

The Inter-Domain Routing Working Group had a packed agenda at IETF 101. Ongoing work was presented on the route leak detection and mitigation work, and the status of the current draft document. This activity is important, driven by the ongoing problem of route leaks that cause problems for Internet users. It is good to see that progress is being made towards an improved situation.There was also discussion on some drafts to add BGP signalling information for the ongoing IPv6 Segment Routing (SRv6) work, for both L3VPN and BGP-LS. Another extension for BGP-LS to propagate network topology information through an Inter-AS topology to the SDN controller was also discussed, as currently there is no easy way to signal this information via BGP-LS across multiple ASNs.

A fairly recent proposal to add new Extended Communities was presented and discussed. These differ from normal Extended Communities by using IP addresses as Targets. An IPv4 and an IPv6 version are being considered. This is different from a Route Target because it instead proposes a new Node Target. Finally, there was a proposal to enable BGP-LS signalling in BGP-only networks. Normally BGP-LS focusses on propagating IGP information via BGP, but this draft addresses how to provide this information with networks that only use BGP.

- Colin

19 March 2018, 17:00 UTC

Day 1: Some Interesting RFC Drafts

During the IPv6 Maintenance WG the draft for IPv6 Router Advertisement IPv4 Unavailable Flag generated a lot of discussion. There isn't yet agreement that the approach is even necessary, which resulted in much skepticism in the working group. The intent of this draft is to provide a means in managed networks for routers to indicate to hosts that there is no IPv4 and to hint that the router is not an IPv4 router. Part of the difference in opinions within the group comes from whether this is a hint or a requirement, and what the semantics are: is it a hint that one router isn't handling IPv4, or that a whole network is not handling IPv4? Some of this is in the draft already, but there is still clarification required to get to a point where the working group can decide whether this is a valid future feature.

Another draft that caught my attention, Measuring ATR, is closely related to some DNS fragmentation measurements run by Joao Damas and Geoff Huston at APNIC. The main point is that fragmentation makes packet delivery unreliable, and that fragmentation rates can be alarmingly high on both on IPv4 and IPv6. But some applications do not have clear approaches to avoid these problems, in particular DNS and DNSSEC. What follows in the draft is a repetition of the common wisdom, that networks should not filter ICMP PTB messages, but also perhaps some pragmatism: applications should not rely on fragmentation, if at all possible.

- Stephen

19 March 2018, 14:30 UTC

Day 1: IPv6 Operations WG

Greetings from the RIPE NCC's IPv6 Program Manager, I'm adding my input from my v6-goggles throughout the week. Today there was a nice presentation during v6ops about Mythic Beasts, a company in the UK that decided to go IPv6-only. They provide hosting and run VMs for their users, mostly only using IPv6. They shared their experiences on running NAT64 for their customers and how they help them understand that they don't need IPv4 anymore. It works for them, so it could be a good pointer for people who are looking into getting IPv6 rolling in their organisation. The slides are not available, but the video should be uploaded pretty soon. 

During the same v6ops session, a draft I helped write was accepted into last call, which means that it might become an RFC  pretty soon. The draft discusses how enterprises can multihome using IPv6 while avoiding running BGP in their network. This might simplify how network can become resilient using IPv6 as transport.

- Max Stucchi 

18 March 2018, 21:00 UTC

Day 0: The IEPG, RIPE Atlas and welcoming newcomers

The Sunday of the IETF week is always a busy day for me starting with the IEPG meeting (probably the session most related to network operations at the IETF), then rolling straight into a series of tutorials I co-organise together with other members of the IETF education team, followed by a number of newcomer events. This Sunday wasn't any different: The IEPG meeting was packed with presentations, mostly related to the DNS. I submitted a talk (not related to the DNS): the new user-to-user measurements my colleagues Emile Aben and Jasper den Hertog have been developing over the last few months. It is based on RIPE Atlas measurements (more specifically the IXP Country Jedi) and the user population estimates by the APNIC. It is a prototype and we're still working on the actual graphs and interface (it has not even been described on RIPE Labs yet, that's how new it is :-)), but we wanted to get some feedback from the operators at the IEPG. It was encouraging to see heads nodding and thumbs being stuck up at the end of my talk. There was also a good suggestion to show connectivity for different protocols: IPv4 vs. IPv6 of course, but also whether networks will transit UDP, TCP, ICMP. Here is a sneak preview of the user-to-user measurement graph (more on RIPE Labs soon):

RIPE Atlas user-to-uer measurements presented at the IEPG


Gergana already mentioned the Newcomers tutorial earlier (see below). There were four more tutorials in the afternoon: an introduction to OAUTH 2.0, an overview about what's currently happening in the Transport area and a tutorial about how to write a good RFC. After the tutorials, I ran to a session we now call "Quick Connections": it allows newcomers to easily connect to people that work in the areas they are interested in. It's always a great opportunity to meet interesting, new people: During that hour I spoke to people from Jordan, Germany, the Netherlands, Mozambique, Zimbabwe, India and Canada, all of them super motivated to dive into IETF work. The day ended with a welcoming reception, first for newcomers and then the general IETF crowd which meant more talking and catching up with more people :-) It was a great start of the week.

- Mirjam 

18 March 2018, 20:00 UTC

Decorated IETF 101 badge

Day 0: Welcome to the IETF!

Let’s kick this blog off with some information for those of you who, like me, don’t have much experience with the IETF. As nicely explained by Mirjam Kühne and Brian Haberman during the newcomers session today, the IETF’s mission (RFC 3935) is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use and manage the Internet. The IETF is not a typical standards development organisation – there is no voting, no official membership, no government role. Instead, self-selected individuals participate via mailing lists or face-to-face meetings; decisions are taken based on rough consensus, gauged by humming or feeling the room; standards are voluntary and driven by market-based adoption.

There are seven main overarching areas, which might help the overwhelmed participant decide which working group to follow (there are more than 130) or which session to attend (out of more than 140). These areas are: Applications and Real-Time area (art), the General area (gen), the Internet area (int), the Operations and Management area (ops), the Routing area (rtg), the Security area (sec) and the Transport area (tsv). Next to this, there are sessions organised by the Internet Research Task Force (IRTF). With over 1,300 in-person and 300 remote participation registrations, it is promising to be a very busy week.

A quick deep dive on current work was offered later in the day during the Hot RFC Lightning Talks session, which covered 18 draft RFCs on topics ranging from web packaging, to three key cryptography to digital tokens.

- Gergana

You may also like

View more

About the author

Gergana Petrova is the Community Development Manager at RIPE NCC. She helps lead the RIPE NCC's engagement with a broad range of stakeholders, including the RIPE NCC membership, the RIPE community, government, academia, civil society and other Internet stakeholders. Gergana has been working for the RIPE NCC since 2013. Originally from Bulgaria, Gergana studied in Germany before relocating to the Netherlands. Gergana has a Masters in Business Research.

Comments 0