Improving Technical Security Internet of Things (IoT)

US NTIA Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching

What happens when smart device manufacturers don’t pay (enough) attention to basic security principles? How do we support, upgrade, and patch existing devices when security issues are identified after they’ve hit the market? These are some of the questions we tackled at the kickoff meeting of the US NTIA “Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching” held on 19 October in Austin, Texas.

The Internet of Things, or IoT, has been widely referred to as the “Internet of Insecure Things.” This has been brought into sharp focus in recent weeks as the Mirai botnet was apparently used to launch high profile and very disruptive Distributed Denial of Service (DDoS) attacks. These attacks were notable in that compromised IoT devices were the dominant part of a botnet used to send unprecedented levels of traffic.

The source code for the Mirai botnet was subsequently released to the public and it turns out that it is not particularly sophisticated. In large part, it takes advantage of well-known default usernames and passwords and simply scans the Internet looking for devices it can log into and infect. While in the past this has been an issue with home routers, IoT brings another dimension to the problem space since many of the devices on the market and in use also use well-known default passwords, many of which cannot be easily changed.

This is an example of what happens when vendors ignore basic security principles, which need to be part of development and design processes from the beginning and all the way through until products reach the market. But the responsibilities do not end there in terms of supporting, upgrading, and patching them in the field. The Internet is a vast and complex ecosystem, and as these recent attacks have demonstrated very clearly, security choices made by vendors can and will have profound impacts on us all. It is the responsibility of all vendors in this space to ensure that they are good Internet “citizens.”

More to the point, security is a never-ending process and not simply a “once and done” part of the design cycle. In essence it is an ongoing arms race with those who would seek to exploit Internet-connected devices to do harm. Note that “harm” can extend far beyond simple DDoS attacks when it comes to IoT since many healthcare, building automation systems, and SCADA (Supervisory Control And Data Acquisition) systems used in industrial and utility settings can cause real and significant damage to life and property if misused.

As security issues and vulnerabilities become known, they need to be corrected by installing patches or upgrades to the software and firmware running these devices. In many cases in the IoT this is extremely challenging due to a variety of factors, including:

  • difficulty in accessing devices, whether physically or through the network
  • limited capacity on the device, including memory and processing power needed to receive and perform the upgrade or patch

The Internet Society (namely Olaf Kolkman, Chief Internet Technology Officer, and myself) was pleased to participate in the kickoff meeting of the US NTIA “Multistakeholder Process: Internet of Things (IoT) Security Upgradability and Patching” held 19 October 2016 in Austin, Texas. It was chaired by Allan Friedman, Director of Cybersecurity Initiatives, NTIA Office of Policy Analysis and Development.

This meeting spurred excellent discussion among a diverse group of participants, and led to the formation of five working groups (detailed below). This meeting was well aligned with the Internet of Things Software Update (IoTSU) workshop [1] held earlier this year, and represented a good first step toward stakeholders working together to solve common problems.

Overall observations:

  • We need to think about unexpected consequences of the behavior, and misbehavior, of devices when they are part of a bigger ecosystem
  • There are challenges in different ways of defining and describing the issues, which lead to potential area of ambiguity
  • While there are and have been efforts to address device security, upgradability and patchability haven’t received a lot of attention until recently

There was a general recognition of the seriousness of this issue among the meeting participants, and consensus in the room that the stakeholders want and need to self-regulate to avoid what all agreed would likely be regulatory and/or legislative intervention that none would like. Thus there was significant incentive to move, and to move quickly if at all possible. Time will tell if this is successful, but we are cautiously optimistic.

The workstreams coming from the initial meeting:

  1. Review of existing standards and Initiatives: What are existing standards and tools for IoT security upgradability that can inform or should be part of this initiative?
  2. Maximum capability and minimum expectations: For each defined class of device, what is the least we might expect and the most we might expect for upgradability?
  3. Communicating IoT upgradability: This working group will examine ways for IoT product makers to describe the why/how/what/who of updatability to buyers.
  4. Incentives and Barriers: How do we foster greater adoption of good patching and updating practices?
  5. Shared open upgrade framework: What are the benefits, requirements, barriers, and existing components of a shared open upgrade framework to support smaller producers or end-of-life products?

The group is working on arranging a next meeting in early- to mid-December 2016, location not yet determined. The Internet Society welcomes this effort and we will be monitoring it as it progresses, but we will not be active participants in it.

This is intended to be an open and inclusive process. If you are a producer, retailer or consumer of “Things” your voice is important, so please consider participating.

Meeting website, including unedited notes taken in real time and information about how to participate in the workstreams:

[1] Internet of Things Software Update (IoTSU) workshop site, including position papers:

Draft workshop report:

Internet Governance Open Internet Standards

IANA: Keeping The Ultimate Objective In Mind

Later this week, ICANN’s Chartering Organizations will indicate whether they will support the third draft proposal of the CCWG-Accountability Work Stream 1 Recommendations. This is a significant moment in the IANA transition process. Support for the accountability proposal by the ICANN community will mean that we are very close to a point when the transition can move to its next phase.

Since the beginning of this process, the IANA transition has had many moving parts. In its original announcement, NTIA identified what it called “directly affected parties” – each of whom had work to do to develop a consensus proposal on how the transition could take place in a way that upholds the core principles that NTIA set forward.

On the operational side, this work has been completed by the IETF, the RIRs and, for the most part, by the names community.

The remaining piece is to ensure that, post-transition, ICANN is fully accountable to the community it serves. This work has been ably led by the CCWG.

In Dublin, the community reached a milestone inasmuch as it agreed, in concept, to work within a so-called Single Designator Model. It is understood that this governance model can meet the requirements of the community for accountability while having minimal impact on ICANN’s corporate structure.

There is also agreement on a set of community powers “designed to empower the community to hold ICANN accountable for the organization’s Principles”.

In addition, there is general agreement on the need to clarify ICANN’s Mission & core values; to appropriately reaffirm ICANN’s commitment to human rights; and, to discuss the accountability of the Supporting Organizations and Advisory Committees.

Finally, in Dublin, the community agreed to a general set of procedural steps for the exercise of the community powers, namely:

Community powers will be exercised through consensus: Engage, Escalate, Enforce.

In short, there appears to be consensus around a governance framework for how accountability will work inside ICANN going forward.

Let’s not lose sight of this considerable progress.

The open questions that remain to be solved have to do the scope of those powers, who exercises these powers, and the implications for ICANN as a corporation. While these issues are by no means trivial, they are solvable, particularly if the parties stay focused and collaborate in good faith.

It strikes me that we are in a place where we need to grab consensus knowing that the community has done the hard work of satisfying the fundamentals of its Charter — meeting the criteria for success that has been set forth, not just by NTIA, but by and for itself. I was encouraged by Steve Crocker’s blog earlier this week in which he expressed the Board’s commitment to work with the community to get the transition done on time.

For the past few weeks, there have been intense discussions on how to improve the current draft proposal based on community feedback. This is typical in any consensus process but in working collaboratively towards the ultimate objective, we should make sure that the timeframe of the transition is met.

Importantly, while the discussions about accountability are primarily focused on the ICANN community and its processes, the outcome of this is critical for the IANA transition as a whole and for all the directly affected parties to the transition.

Moreover, seeing this transition through, in a timeframe that is realistic in light of the U.S. political environment, matters for the entire multistakeholder ecosystem. We cannot go back – we cannot simply pretend that the past 22 months haven’t changed the landscape for Internet governance. They have. If we, as a community, fail to deliver, there will be ripple effects throughout the IG ecosystem.

But if we succeed, when we succeed, we will have collectively done the right thing for the Internet.

IETF Internet Governance Open Internet Standards

Rough Guide to IETF 93: The IANA Transition

The 93rd meeting of the Internet Engineering Task Force (IETF) kicks off next week (July 19-24) in Prague to discuss a variety of issues, ranging from security to privacy to DNSSEC and IPv6. The IANA stewardship transition process, which has been underway since March 2014, is also part of the IETF’s agenda.

The IETF has a vested interest in a successful IANA transition process. Being one of the ‘directly’ affected customers of IANA, the IETF is responsible for developing Internet protocols and policy for those protocols. As such and at the request of the IANA Coordination Group (ICG), the IETF was the first community to submit its proposal back in January 2015. Since then, the IETF community has been closely following the process and has consistently talking with both the numbering and the names’ community.

Last month, during ICANN’s 53rd meeting in Buenos Aires more progress was made. The names’ community successfully concluded its proposal and submitted it to the ICG. Jari Arkko’s blog update from ICANN provides a very good overview of what took place and what are the next steps for the ICG and the stewardship transition process in general.

After the ICANN meeting, a new timeline was also posted. Responding to a request by Assistant Secretary Larry Strickling, the ICG outlined the three phases they anticipate will be required for the full transition to take place. Taking into consideration all the various components and dependencies – i.e. issues of accountability for the names’ part – the ICG anticipates that the earliest the transition could be completed in the July 2016 timeframe.

Finally, and as the accountability discussions continue with urgency, the ICG has announced that the proposal to transition the stewardship of the IANA functions will be out for public comment July 31 to September 8 (approximately).

The IANA transition discussion is scheduled to be discussed in the Thursday, 23 July, afternoon session.

Related Working Groups and BoFs at IETF 93

ianaplan (Planning for the IANA/NTIA Transition)
Thursday, 23 July 2015, 15:20-17:20, Congress Hall II

Follow Us

There’s a lot going on in Prague, and whether you plan to be there or join remotely, there’s much to monitor. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

IETF Internet Governance Open Internet Standards

Rough Guide to IETF 91: The IANA Transition Process

Paving the way toward an IANA transition process – the IETF “Draft Response to the Internet Coordination Group Request for Proposals on IANA” is in the WG Last Call.

In March 2014, the U.S. National Telecommunications & Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions. In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene and facilitate a process to deliver a proposal for transition. As part of that process, the IANA Stewardship Transition Coordination Group (ICG) was formed.

The ICG’s mission is to coordinate the development of a proposal among the “operational” communities affected by the IANA functions. The IANA functions are divided into three main categories: domain names, number resources, and other protocol parameters. The “operational” community for the protocol parameters function is the IETF community.

To develop an IETF consensus response to be submitted to the ICG and that describes the expected interaction between the IETF and the operator of IETF protocol parameters registries, IETF chartered an IANAPLAN working group. The development of the draft follows the IETF standard process that is (a) open – anyone can participate, (b) transparent – all the proposals and discussions are publicly available (see, and (c) the final outcome should have IETF consensus.

Good progress has been made since the creation of the working group. The current, third version of the draft, “Draft Response to the Internet Coordination Group Request for Proposals on IANA” is in the WG last call that will end on 11 November.

So, what are the main points of the draft and the main discussion themes?

Let’s start with the draft itself. I want to stress here that the items below are current draft items, which may change through the course of the working group and the IETF review.

The draft documents the existing scope and structure of the IANA protocol parameters function and outlines the IETF policy role for the overall management of the registries as stated in RFC6220 “Defining the Role and Function of IETF Protocol Parameter Registry Operators” and RFC5226 “Guidelines for Writing an IANA Considerations Section in RFCs,” and the role of the IAB as an oversight body. The work to be carried out by the IANA staff for the IETF and the Internet Research Task Force (IRTF) is defined and documented in the memorandum of understanding (MoU) between ICANN and the IETF community and has been in place since 2000.

The draft concludes that no structural and no major changes “are required, however, the IETF community has expressed a desire for several points to be addressed by supplemental agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA regime.”

What are these points? Again, these are still open for review and comments.

  • First, it is the intellectual property rights related to the data of the registries. The draft asks the IAOC to engage the appropriate parties, both inside and outside the IETF, to make clear that data in the protocol parameters registries is in the public domain.
  • Secondly, it is an issue related to the dispute resolution mechanisms. Here, “the IAOC is asked to conclude a supplemental agreement regarding jurisdiction and any necessary dispute resolution mechanisms that are mutually acceptable to the parties.”
  • Thirdly, the existing NTIA contract provides for contingencies when a transition to another operator is required in the future. The IAOC is asked to supplement the MoU with similar provisions and the requirement of the transfer of any associated marks and identifiers to subsequent operators. Regarding the latter requirement, there was a substantial discussion on the list on how to ensure that, in the event of future transition, there is no confusion regarding the location and content of the IETF protocol parameters registries.

Regarding these concerns it is important to stress, as the draft does, that the “IETF community is quite satisfied with the current arrangement with ICANN.” In this sense the draft supports the current status quo, but, also, inserts a form of an “insurance” request for unforeseen future events.

One of the interesting points of the discussion concerned what the protocol parameter registries encompass. A casual reader will most probably associate this with, but these are not all of them.

In fact the IETF is responsible for policy relating to all number space with the exception of the space delegated to the Internet Number Registry System, which includes the architectural definition of the entire IP address AS number space. There are several sub-registries for special IPv4 and IPv6 assignments as well as a number of special use registries with regard to domain names that the IETF maintains.

The working group will meet 13:00-15:00 (Hawaii Standard Time) on Monday, 10 November 2014 to review and discuss the outstanding issues in draft-ietf-ianaplan-icg-response as well as next steps.

The deadline to submit proposals to the ICG is 15 January 2015.

IANAPLAN (Planning for the IANA/NTIA Transition) WG
Monday, 10 Nov 2014, 1300-1500 HST, Coral 3

Follow Us

There’s a lot going on next week, and whether you plan to be there or join remotely, there’s much to follow. To follow along as we dole out this series of Rough Guide to IETF blog posts, follow us on the Internet Technology Matters blog, Twitter, Facebook, Google+, via RSS, or see

Internet Governance Technology

Understanding the IANA Functions

“NTIA Announces Intent to Transition Key Internet Domain Name Functions” – this caption has marked much of Internet governance discussions so far in 2014 and it is expected to continue to do so in 2015, at least until the 30th of September, when the IANA contract is set to expire. 

Since 1999, the IANA functions have been contracted to ICANN and have historically included:

  • The coordination of the assignment of technical Internet protocol parameters performed by the Internet Engineering Task Force (IETF);
  • The administration of certain responsibilities associated with Internet DNS root zone management;
  • The allocation of Internet numbering resources to the Regional Internet Registries (RIRs); and,
  • Other services related to the management of the .ARPA and .INT top-level domains. 

For the Internet and its community of users, discussions on the proposed transition of the IANA functions is important because it concerns both the technical stability of the Internet and the accountability to the public for these functions. Because of this, the NTIA has communicated that the transition proposal should have the broad support of the Internet multistakeholder community and must adhere to the following minimum principles:

  • Support and enhance the multistakeholder model;
  • Maintain the security, stability and resiliency of the Internet DNS;
  • Meet the needs and expectation of the global customers and partners of the IANA services; and,
  • Maintain the openness of the Internet. 

In addition, the NTIA made clear that its role should not be replaced by an intergovernmental structure.

It is important to remind ourselves of these criteria. The IANA functions involve a set of technical specifications that allow people to send emails and access websites in a friendly and easy way; they are part of a technical design. Understanding what the IANA functions are is important. And, as part of this process, it is equally important to understand what the NTIA criteria mean.

The Internet Society is contributing to this understanding. Early on in the process, it released a paper that uses everyday examples to explain what the IANA functions are and how they interrelate. Moreover, as an identifiable partner of the IANA services, ISOC has elected Narelle Clark and Demi Getchko as its representatives to the IANA Coordination Group and is in continuous discussions with its chapter and organization members. Finally, initiating a substantive dialogue on the NTIA criteria, the Internet Society has produced a living document on the openness of the Internet; it is planning to do the same for the other criteria. 

As a delegation of staff and members heads to ICANN 51 in LA, the Internet Society maintains that: 

  • The ongoing process for transition stewardship of the IANA by the US government is a process that needs to be focused and result in a timely proposal carried by the broad Internet community.
  • Issues of accountability constitute core elements of the discussions, especially as they relate to and inform the core issue of the IANA transition discussions; and,
  • All interested parties should recognize that the directly affected parties have their own processes for consent, which can be used as case studies that can positively contribute to the discussion. Case in point the IETF.

The Internet Society will continue to deliberate and offer its views on the conformity of the proposals to the NTIA criteria. We will further continue to facilitate a successful IANA transition process with the rest of the Internet community. 

Internet Governance Open Internet Standards

Reflections from the world of Internet governance

Some years ago there was a brilliant man with a notebook. In that notebook he kept a list of names, numbers and specialized identifiers for a project he was working on at the US’ DARPA research agency. That project grew into the Internet we know today. The brilliant man was Jon Postel.

Since that time this simple list – now known as the Internet Assigned Numbers Authority (IANA) – has evolved into what is arguably the most important database in today’s Internet world. Indeed, if somehow it was suddenly removed, some the Internet functions would become extremely unstable and over the longer term the interoperability that is the hallmark of today’s Internet would be much harder to achieve.

Just imagine if we’d set up a service level agreement for that notepad. Using the technology and standards of the time we might have insisted it be kept dry, away from cups of coffee and locked in a safe when not in use. We would have insisted on archive quality paper and that the writing be clear. Of course we would have insisted also that entries be checked personally and be completed that week, and a copy be held in another location.

While this might seem a trivial comparison, the current discussions on the evolution of the IANA functions are simply about that: reaching agreement on a replacement set of requirements that comprise a rigorous formal contract between the US government – actually its National Telecommunications and Information Authority (NTIA) – and the Internet Corporation for Assigned Names and Numbers (ICANN). This contract has worked effectively since 1999 with minimal intervention from the NTIA in that time.

As most of the world now knows, IANA is in the process of transitioning into the stewardship of the global multistakeholder community.

For some years now entries into this database have been determined by distinct policy processes and these are not currently up for review. These processes are well defined and sit within the Internet Engineering Task Force (IETF), The Regional Internet Registries (RIRs) and ICANN itself.

A co-ordination group has been established to draw in the views of the community to define the process for transition. The remit of the coordination group is limited, albeit of great significance: draw the views of the Internet community and compile a proposal that is consistent with the roles and responsibilities of the various bodies performing the IANA functions. Overall, however, the proposal needs to be mindful of the Internet itself– its architecture, nature and future.

This latter point is perhaps the most significant. In order to ensure that this transition does not harm the Internet, the NTIA has provided some guidance: “[…] the transition proposal should have broad community support and address the following principles:

  • Support and enhance the multistakeholder model;
  • Maintain the security, stability and resiliency of the Internet DNS;
  • Maintain the openness of the Internet;

With all this at stake, the coordination group met for its first face-to-face meeting in the middle of July and established a general operational framework; the work is on its way. Information and a record of that meeting can be found on the ICANN website; I would encourage you all to read and reflect on the charter and the issues discussed during this first meeting.

However, it is the next part where the real effort is required. Along the way, there will be various questions that need answering.

Over the coming months I hope to get more input from our community in order to properly represent it, along with my colleague Demi. I trust you can assist in this journey and I am looking forward to working with all of you.

Internet Governance Open Internet Standards

IANA Evolution

Last week the National Telecommunications and Information Administration (NTIA) of the U.S. Department of Commerce announced that it has asked ICANN to convene global stakeholders to develop a plan for transitioning the current role played by NTIA in coordination of shared Internet resources through the Internet Assigned Numbers Authority (IANA).

In many ways, the U.S. Government has been preparing for—and the Internet community has been working towards—this moment since 1998, when ICANN was established and was awarded the first IANA contract. The US Government has played an important role in guaranteeing the security and stability of the Internet, and we believe the criteria set out by the NTIA for the transition plan provide an important framework for the work ahead:

  • Support and enhance the multistakeholder model
  • Maintain the security, stability, and resiliency of the Internet DNS;
  • Meet the needs and expectation of the global customers and partners of the IANA services; and,
  • Maintain the openness of the Internet.

The Internet Society was recognized as one of the key Internet organizations by the NTIA statement. The Internet Society has consistently advocated for the US Government to complete the transition of its stewardship role to the global multistakeholder community. We have previously submitted comments to the NTIA, and recently joined with the leaders of other Internet organizations in the Montevideo statement calling for the globalization of the IANA functions.

The global Internet community now has an opportunity to further strengthen the multistakeholder model. We can ensure the continued evolution of the IANA functions and security of the Internet. And, we can establish a framework that is accountable, transparent, bottom-up, and sustainable over time.

We have much work ahead of us. It critical to the future of the global Internet, and important to get it right. The Internet Society is looking forward to working with ICANN and all other stakeholders, and to supporting our community’s engagement in open and inclusive processes. We are committed to an Internet that remains managed by distributed collaboration. This collaboration has been key to its dynamic and resilient growth as a platform for innovation, communication, and economic development.

On Monday, 24 March 2014, ICANN has scheduled two sessions entitled “IANA Accountability Transition” and  “ICANN Accountability”.  Both sessions will be audio streamed in a number of languages.

We have set up a dedicated email list ( for the Internet Society community, and invite you to subscribe:

We will look forward to your input and ideas, and will be working to actively engage you as developments and discussions progress.

Kathy Brown

Internet Governance Open Internet Standards

TWO-FOUR-SIX-EIGHT – Who Do We Appreciate? IANA!

On Friday, 14 March 2014, the U.S. Department of Commerce National Telecommunications and Information Administration (NTIA) announced its intention to transition the IANA functions to the global multistakeholder community. As expected, the announcement has sent adrenaline coursing through the veins of Internet governance experts and government policy people the world over. I’d argue, however, that it is an important point for the Internet’s technical experts to sit up and take notice, as well: the fact that you are probably saying “what problem does this solve?” is a testimony to how much works well today, and we want to make sure it continues to work well in any future arrangements.

First of all — do you remember where the Internet Assigned Numbers Authority started? Vint Cerf wrote, in RFC2468 (two-four-six-eight):

“Out of the chaos of new ideas for communication, the experiments, the
tentative designs, and crucible of testing, there emerged a
cornucopia of networks. Beginning with the ARPANET, an endless
stream of networks evolved, and ultimately were interlinked to become
the Internet. Someone had to keep track of all the protocols, the
identifiers, networks and addresses and ultimately the names of all
the things in the networked universe. And someone had to keep track
of all the information that erupted with volcanic force from the
intensity of the debates and discussions and endless invention that
has continued unabated for 30 years. That someone was Jonathan B.
Postel, our Internet Assigned Numbers Authority[…] “

Forty-odd years later, the task that one person took on has evolved into a multi-organizational, global, community-driven effort, based on open and transparent processes to develop policy, provide oversight, and implement the processes for managing shared Internet resources.

It’s a pretty big elephant, and your view of the IANA space depends very much on where you touch it.

If you’re a network operator, you know you get your IP addresses (IPv6, right? ;-)) from your Regional Internet Registry (RIR). You know there are processes and allocation and assignment policies that shape what constitutes a reasonable request and what isn’t allowed. Those policies are developed in open, transparent policy processes in the five RIRs around the globe. All of that is actually part of the bigger picture of the IANA-as-global-coordinated-effort.

For a reliable, global Domain Name System you need to be confident in the continued integrity and accessibility of the DNS, from its root downwards. Today, it is a reasonable expectation that any needed and authorized updates for Top Level Domains (generic or country code) are made in the root zone and propagated to the root servers uniformly and within reasonable delay.

And, finally – if you implement or otherwise use Internet standards, you rely on the work of the Internet Engineering Task Force and the rest of its protocol parameter registries. Every Internet protocol that requires a list of values (set by IETF actions, or chosen by protocol implementers) requires a registry to maintain the list. That’s everything from assigned port numbers for individual protocols to agreed-upon labels for services. While the contents of those registries are generally less contentious than some names or numbering issues, they are a critical part of making sure that Internet standards can be implemented and used interoperably, and thus imperative to the IETF’s continued efforts. For more details on how that all works, see Thomas Narten’s recent article in the IETF Journal

With so much that is working well now, it’s easy enough to get lost in the focus of news media. But, the bottom line is that this is not about a government letting go of the Internet, as headlines would have you believe – rather, it’s about removing the footnote on the second page of the “Shared Internet Resources” diagram that explains that some IANA functions are carried out under contract assigned by the US Government. The important thing now is to ensure that whatever replaces that footnote is consistent with the principles that have allowed the Internet to flourish to date, and continues to provide the secure and stable functioning we enjoy today.

As noted in RFC2468, we appreciated IANA-the-person. I hope this description helps solidify your appreciation for IANA-in-the-large, and that you care about the outcome of this transition process. As we’ve said before, the Internet requires collaboration and collective stewardship of shared resources.

So, get involved! The multistakeholder model of the IETF, ICANN, the RIRs, and other Internet organizations requires individual participation at all levels in open, transparent processes. Attend meetings (either in person or remotely), join and participate in relevant mailing list discussions, and stay informed about what is happening in the industry. It is only with *your* participation that the future of the Internet will remain secure.

P.S.: Since I mentioned Jon Postel, let me put a plug in for the Jonathan B. Postel Service award – nominations open until 7 May 2014!