Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Technology

Discussing MANRS at RIPE 72 Next Week

Some time ago, a group of MANRS participants agreed that it’d be a good idea to have more precise guidance for the implementation of MANRS Actions. Having such a document could serve at least two purposes:

  • Ease deployment of measures required by MANRS (stub networks or small providers – the majority of ASNs)
  • Help check if the network setup is compliant with MANRS

Job Snijders presented this idea and an outline of the MANRS BCOP document at RIPE71 in November 2015. The idea was supported by several network operators and experts who joined the team to develop such guidance. Since then the team has done some heavy lifting as it appeared even the implementation of basic routing security practices cannot be accomplished by a single line in a config file!

We plan to present this work at the RIPE BCOP TF on May 23 during the RIPE meeting. If you are planning to attend RIPE72, please join the discussion.

This is a work in progress, but you can find the current version of the document here:

We welcome your review and contributions. We expect that shaping up of the document will continue in the RIPE BCOP TF.

[Editor’s Note: This post was originally published on the Routing Resilience Manifesto blog at]

Deploy360 Events IPv6

ION Cape Town: Good COP, BCOP

ion-capetown-ai-pngThis week we’re highlighting some of the topics that were covered during ION Cape Town a couple of months back. This was our third ION conference of 2015, and was held in conjunction with South Africa iWeek 2015 which has been South Africa’s leading annual Internet industry conference since 2001.

Today we’re looking at the presentation from Jan Zorz, the Internet Society’s Operational Engagement Manager, on Best Current Operational Practices or BCOP. These are living documents covering, as the name suggests, best current operational practices as agreed by subject matter experts and periodically reviewed by the global networking engineering community.

BCOP aims to address the issue of knowledge being passed in an informal and unstructured way, quite often through word-of-mouth rather than through a documentation and review process. This leads to information being difficult to find and potentially restricted to certain communities or even lost, so BCOP draws on a variety of efforts to produce community derived best practices. There are currently BCOP groups under NANOG (North America), LACNOG (Latin America), RIPE (Europe & Middle East),  JANOG (Japan), NZNOG (New Zealand) and most recently AfNOG (Africa), producing BCOPs on Deploy360 topics such as IPv6 question and answers, IPv6 troubleshooting, IPv6 address (de)aggregation, IP peering, anti-DDOS measures, and DNSSEC operational practice.

ION Cape Town – Best Current Operational Practices Update from Deploy360 Programme (Internet Society)

The Deploy360 team is heavily involved with the BCOP communities, and as well as fostering new BCOP initiatives, is seeking input as to what new BCOPs should be developed. Suggestions include testing visibility from the global Internet, use of the Internet Routing Registry (IRR), IPv6 enterprise renumbering scenarios, and ICMP filtering, but please get in touch if you have other suggestions.

The full list of current BCOPs can be found on the Deploy360 website.

Please also check out the other presentations and videos from the conference, as there’s some interesting deployment case studies and trials of the Deploy360 technologies.

Building Trust Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

MANRS Turns 1 and First Japanese Operator, IIJ, Joins

Just over one year ago, on the 6th of November 2014, a group of 9 network operators launched an effort called MANRS – Mutually Agreed Norms for Routing Security. We also kept another name – Routing Resilience Manifesto – to emphasise the collaborative and collective nature of it.

Since then more operators have joined, bringing and promoting the initiative all around the globe.

On its first anniversary, MANRS has expanded its geography to Japan! A company that is known for its innovative vision, advanced technology, and attention to security, Internet Initiative Japan Inc., or IIJ, has joined the group of MANRS participants.

“Coordination and cooperation based on our relationships of mutual trust are the key elements to run the Internet, and we have shared responsibilities to improve the Internet operation. As part of the Internet operation community, IIJ is committed to the MANRS actions,” said Junichi Shimagami, Director CTO of Internet Initiative Japan Inc.

We are looking for more leaders – networks that have already implemented the MANRS recommendations and much more – to sign up, support this effort, and encourage others!

[Editor’s Note: This blog post was originally published on the Routing Resilience Manifesto site at]

Image Credit:
IETF Improving Technical Security Open Internet Standards

Rough Guide to IETF 92: Routing Resilience and Security

There is considerable work underway across a number of IETF working groups to ensure the Internet’s routing infrastructure is more secure and resilient in both the short and long runs. Many of those working groups will be meeting in Dallas, TX, next week at IETF 92.

Let me begin, as always, with listing the WGs where security and resilience issues of the global routing system are discussed and solutions are developed. The groups meeting at IETF 92 are:

The SIDR WG is focusing on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to BGP and is an important component of BGP security extensions – BGPSEC, also developed in SIDR WG. This is a key technology for improving trust in the routing infrastructure.

A lot of work has been done, and there are quite a few operational deployments. This results in refinements to the protocols and fixing some issues. This is a normal cycle of protocol maturity, when operational experience is fed back into the protocol development, leading to improvements.

One such refinement is an RPKI Repository Delta Protocol (, which provides relying parties with a mechanism to query a repository for changes, improving the overall scalability and performance of the system compared to the currently used rsync protocol.

Another draft is related to the problem of potential operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries. The draft, “RPKI Validation Reconsidered” (, has its next revision, but not much discussion happening despite some disagreements over the proposal within the Working Group.

There are some movements in the BGPSEC area, too. The BGPSEC protocol specification is in the WGLC (draft-ietf-sidr-bgpsec-protocol-11). People found a few omissions that are easy to fix, like unsecure AFI allowing the attacker to confuse IPv4 and IPv6 prefixes that look the same on the wire.

Extra care needs to be taken when making significant reconfiguration, like AS migration when networks are merged, for example. A draft “BGPSec Considerations for AS Migration” ( discusses this for a common method for AS migration within the BGPSEC protocol.

As a matter of fact such a common method is not trivial and requires some BGP features that are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. Absent these features, it would have required an ISP to coordinate an ASN change with, in some cases, tens of thousands of customers. In particular, as each router is migrated to the new ASN, to avoid an outage due to ASN mismatch, the ISP would have to force all customers on that router to change their router configurations to use the new ASN immediately after the ASN change.

This is addressed in the draft “Autonomous System Migration Features and Their Effects on the BGP AS_PATH Attribute” ( This draft is being discussed in the IDR WG and is largely parallel to one of the SIDR WG I just mentioned, although addressing different aspects.

Speaking of network reconfigurations and maintenance, one very important requirement is operational continuity, which is also applicable to the two drafts I just mentioned. Even if an ISP has redundant connections, simply taking down or bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications, like Voice Over IP (VoIP), online gaming, or VPN. Therefore, a solution is needed for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. Such a solution is described in a draft “Graceful BGP session shutdown” (draft-ietf-grow-bgp-gshut, now expired because of dependencies on other drafts, not because of the loss of interest), that is being discussed in the GROW WG.

In general, the focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

One of these items, which originally emerged in the SIDR WG and is now being discussed in the GROW WG, is so-called “route-leaks.” Simply speaking, this describes a violation of “valley-free” routing when, for example, a multi-homed customer “leaks” an announcement from one upstream provider to another one. Since usually customer announcements have the highest priority, if no precautions are taken this results in traffic from one provider to another bypassing the customer – potential for a staged MITM attack. But this is an explanation in layman terms, and the group was working on nailing down the definition and the problem statement, see

This time there is not much work related to routing happening in the OPSEC working group. But late last year the IESG approved draft “BGP operations and security” ( as a Best Current Practice (BCP194, RFC7454). This is a very useful document that brings major operational issues and best current practices with regard to routing security. It has gone through a second Working Group Last Call and hopefully is close to be published as a BCP RFC.

Related Working Groups at IETF 92

Follow Us

There’s a lot going on in Dallas, 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

Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS)

New Routing Security Survey Shows Incidents and their Impacts

Routing security incidents happen – for many network operators probably at least once a month, and probably close to 5% of those incidents have real (and negative) network impacts. And though overall the routing system tends to be pretty quiet, some networks have really bad days sometimes. These are some of the results from the Routing Resilience Survey Report we just released from our pilot project to analyze routing security incidents and their real-world impacts.

At the end of 2013 we launched, in partnership with BGPmon, a pilot project called the Routing Resilience Survey. As I explained in a November 2013 blog post announcing the project, the effort was focused on collecting incident data related to routing resilience from operators’ points of view. This approach allowed us not only to filter out false positives – for instance, legitimate configuration changes – but also to record the impact and severity of the incidents.

The pilot ran for a little more than six months, from November 2013 until June 2014, with 30 operators from Tier 1, Tier 2/3, cloud and content delivery networks, enterprises, and other types of ISPs from all around the world. Because we allowed the participants to also classify events related to their customers’ networks, the Survey represented 239 autonomous systems in total.

Over the course of the project, we collected more than 2000 potential routing security incidents!

Participants were asked to respond to BGPmon’s weekly summaries of potentially harmful events related to participants’ networks that the monitoring system detected. Were these legitimate incidents, and what were their impacts? Was it a monitoring system or a customer call that alerted the operator to the incident, or did it go unnoticed? These were some of the questions we asked in order to classify the events.

Full study findings are presented in the report at

The results are not surprising, but they can help us understand some of the challenges to global deployment of routing security protocols. The main conclusions of the report are:

  • Incidents with real impact are rare.
  • There is a high percentage of false positives.
  • Incidents are fixed quite quickly.

More specifically, we found that the routing security problem is not perceived as critical by many network operators. It is very interesting to see the difference in impact assessment between an operator’s and an external observer’s point of view. And quite frankly, neither is probably right – the truth is most likely somewhere in between. According to the report, “while network operators are aware of the vulnerabilities of the routing system, risks associated with them are perceived as low. In such circumstances, reactive measures seem to be more appropriate and proactive protection is deployed only if it has low operational costs associated with it.”

However, relying only on reactive measures definitely does not offer sufficient protection. Many, if not most, routing incidents happen outside the operator’s control, and resolving the incident often requires help from other network operators.

And, as we have stated plenty of times, deploying simple routing resilience measures like those outlined in the “Mutually Agreed Norms for Routing Security” (MANRS) document can help your network and many networks around you. And if done collectively by network operators around the globe, it can help the entire Internet.

Please read the report and let us know what you think!

Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Technology

Seeking More Internet Leaders for the Routing Resilience Manifesto: Do You Have MANRS?

It’s been two weeks since we launched the Routing Resilience Manifesto initiative, featuring the Mutually Agreed Norms for Routing Security (MANRS) document, and we’re proud to see three new participants sign up since hearing about it. But we need more operators from around the globe to step up and publicly commit to improving the security and resilience of the global Internet! Will you join us?

Some history – work on the Routing Resilience Manifesto began more than a year ago, when a group of network operators met at IETF87 in Berlin to discuss how improvements can be facilitated in the global routing system. The result is four concrete Actions that define the minimum package that network operators should consider implementing. These Actions were vetted by the operator community and published as the MANRS document on 6 November. The participants have publicly committed to implement specific Actions that:

  • prevent propagation of incorrect routing information,
  • prevent traffic with spoofed source IP addresses,
  • facilitate global operational communication and coordination between network operators, and
  • facilitate validation of routing information on a global scale.

In order to become a participant of this initiative, a network operator has to implement one or more Actions. But the Routing Resilience Manifesto is more than just the MANRS document, it is a commitment to improve the global Internet.

The goal of the initiative is to make this set of Actions the new norm for the Internet, which will lead to significant improvements in the security and resilience of the global routing system. To make this happen, the Manifesto needs more “weight” and awareness to become an incentive for operators to implement the required security measures.

We are looking for leaders, the network operators who take security and resilience seriously and have already implemented these Actions and probably many more. We are looking for leaders whose reputation will motivate others to step up.

If you are such a leader: We ask you to demonstrate your commitment and sign up at

If you know such leaders in your region: Please let us know about them by contacting us at

I hope you will join us!

Improving Technical Security

Initial Routing Resilience Survey Results Show At Least 10% Of Incidents Are Real Threats

Last year in November we launched, in partnership with BGPmon, a new project called Routing Resilience Survey. As I wrote in the blog post “New Internet Society Project Aims to Learn: Is Your Internet Routing Secure and Resilient?”, this effort is based on collecting incident data related to routing resilience from an operator’s point of view. This approach allows us not only to filter out false positives – for instance, legitimate configuration changes – but also to record the impact and the severity of the incident.

Since the beginning of the project four months ago, 25 participants representing more than 300 ASNs joined the effort – providers often take care of their customers’ routing problems and wanted to include those problems in the survey. In total we asked folks to classify almost 500 events, and more than half of them have indeed been classified! And while we hope to collect more data to get a more statistically representative picture of these incidents and their impacts, there is already something to look at.

So I couldn’t resist the temptation to show you some graphs from this presentation of initial results (full presentation embedded below and available on SlideShare).

Routing Resilience: Impact Severity

First of all, let’s look at the number of registered incidents and their impact [slide 9]. Do not be surprised that the timeline starts back in 2011 – for each participant we presented a “historical” overview of significant events, and asked them to classify each. Green is the most prominent color – these are “false positives,” configuration changes, like connecting a new customer. But even with our relatively small set of surveyed networks, one can notice moderate and severe incidents.

If we look at the impact from a slightly different angle [slide 10], we see that “false positives” constitute at least half of all events. Real incidents sum up to 10% of all events. This number may be higher, depending on what is in the “unknown” category – events that have not been classified yet.

Finally, it is interesting to look at how folks became aware of the incidents [slide 11] – a question we asked when classifying an event. “Customer call” is a dominating answer, which indicates that reactive measures prevail over proactive ones.

It is still not too late to join this effort – your contribution will help us better assess the state of security and resilience of the routing system from a risk perspective. In return, you may become more aware yourself how risky the environment is, and after the project is completed, get an individual report where you can see how your risk profile compares to others.

Please send a request for the creation of your account to

In the request please indicate:

  • your AS number
  • email address for notifications

You may also include AS numbers of your customers for whom you would like to monitor and classify related security incidents.

Hope to see you soon!

Improving Technical Security

Resilience of the Commons: Addressing Routing Security Challenges

Why do some innovations take off like wildfire, while others take ages to reach widespread deployment? What makes for a successful protocol? How can we detect a protocol failure ahead of time and correct course? Recently I attended an Internet Architecture Board-hosted workshop on Internet Technology Adoption and Transition (ITAT) that aimed to address these questions.

The workshop stimulated interesting discussions, helping us better understand the enablers of and inhibitors to technology adoption and, since it focused on IETF protocols, what makes for a successful protocol.

The IAB has discussed this before. In fact, in 2008 the IAB published RFC 5218, entitled “What Makes for a Successful Protocol?” Without providing a recipe for a successful protocol or technology, it looked at various factors that “contribute to or hinder a protocol’s success.” It found that for a protocol to be successful, it should:

  • Meet a real need
  • Have open code and specification availability
  • Have open maintenance processes
  • Have good technical design (though for initial success it seems to have minimal impact compared with other factors)

The IAB also found that a successful protocol can be deployed incrementally, meaning that early adopters gain some benefit even if others do not support the protocol. Indeed, ability to use and benefit from a technology independently of other actors makes the deployment strategy clearer and simpler.

But what happens when a protocol’s benefits begin to unfold only when their penetration is substantial, like IPv6 or DNSSEC? Early adopters incur costs and gain little until the number of users reaches a tipping point. It doesn’t make sense to join a social network if only a couple of strangers are on it, or deploy DNSSEC if only a few others have adopted it. Protocols and solutions for securing the global routing system are among this group of collective action problems, too.

Everett M. Rogers, a prolific scholar of communication and social change, once noted, “diffusion is essentially a social process. While the mass media often create awareness-knowledge of an innovation, interpersonal communication with peers is necessary to persuade most individuals to adopt a new idea.”

At the ITAT workshop we presented an approach to tackle these issues based on our work with network operators. Similar to Rogers, our approach is based on the understanding that technology building blocks and solutions are an important aspect, but people are what ultimately hold the Internet together. In our new paper, “Resilience of the Commons: Routing Security,” we argue that to achieve a positive outcome, we must:

  • Build consensus around an understanding of the problem space
  • Share an understanding of the potential offered by different solutions
  • Create a culture of collective responsibility based on an understanding of collective and individual benefits
  • Focus on a positive end goal

We also see improving routing security and resilience as a social process. That is why our efforts in the area of routing security are focused on the people that run the networks and make the global infrastructure resilient. One recent example of such an effort is the Routing Resilience Survey aimed at involving operators in collecting factual data about routing incidents and their impacts. (You can still join the project!)

Security of the global routing infrastructure is to some extent no one’s concern and everyone’s concern at the same time. How can we stimulate improvements in this area – an area where traditional market forces, the main drivers of the Internet’s development, do not work, where regulation may not be effective, where one’s actions may benefit competitors more than one’s own customers?

Technology building blocks and solutions are an important aspect, but Internet development has been based on the voluntary cooperation and collaboration of the peopleinvolved. We believe that is still one of the essential factors of the Internet’s prosperity.

Deploy360 Securing Border Gateway Protocol (BGP) To archive

Operate an Internet Router? Join our “Router Resilience Survey” To Help Make The Internet More Secure

Routing Resiliency SurveyDo you operate a router connecting your network to the rest of the Internet?  Would you like to help us understanding how resilient and secure the Internet’s routing infrastructure is? If so, please visit our new “Routing Resiliency Survey” at:

and read more about the new project at:
New Internet Society Project Aims to Learn: Is Your Internet Routing Secure and Resilient?

The cool thing is that as a participant in the project you’ll receive a basic level of performance monitoring from BGPmon who is partnering with the Internet Society on this survey.  You’ll also receive the report when the 6-month survey is complete and you’ll help gain insight into questions such as:

  • What happens with the prefixes your routers announce elsewhere in the global Internet?
  • How will your network be impacted by routing misconfigurations?
  • How safe and resilient is the overall global routing infrastructure?

Participating in this survey will greatly help us – and the rest of the Internet community – understand better exactly what kind of threats and attacks are being seen out within the Internet’s routing infrastructure. As you can read on the RRS page, the time commitment should be minimal and all data will be anonymized – plus, as mentioned above, you’ll get to see reports related to your own routers.

Please do check it out and help us if you can!  (Thanks!)

Events IETF

Rough Guide to IETF 88: Routing Resilience

Security is an important topic for the Internet Engineering Task Force (IETF) in general and at IETF 88 next week in Vancouver in particular. Not for nothing, all RFCs are required to have a ‘Security Considerations’ section to encourage document authors to consider security in their designs and to inform the reader of relevant security issues (RFC3552/BCP72). Security has many facets and the specific focus of each IETF working group (WG) is different. Efforts with the common aim of making Internet infrastructure more resilient and secure are spread across several WGs.

Speaking of security and resilience of the Internet routing infrastructure, there are several WGs that contribute in this area: Secure Inter-Domain Routing (SIDR), Global Routing Operations (GROW), Inter-Domain Routing (IDR), and Operational Security (OPSEC) Working Groups, to name a few.

The SIDR WG is focusing on securing inter-domain routing. The overall architecture is based on a Resource PKI (RPKI), which adds an authentication framework to the Border Gateway Protocol (BGP) – a global routing protocol fundamental to the operation of the Internet – requiring a certificate management infrastructure. This is a key technology for improving trust in the routing infrastructure.

In its current phase, the group is working on the BGPSEC requirements and protocol (see, for instance The work on origin validation, allowing a relying party to check if a network (or an Autonomous System, AS) is legitimately announcing a prefix, is mostly complete from a protocol development perspective. Still, discussions continue around issues like scalability of the repository system and best practices for RPKI origin validation.

For example, a draft “Multiple Repository Publication Points support in the Resource Public Key Infrastructure (RPKI)” aimed at improving scalability and resilience of the RPKI infrastructure has generated quite a bit of discussion.

Since the inception of RPKI there were concerns that the hierarchical PKI structure creates new dependencies and associated risks. For instance, a parent Certificate Authority (CA) might make inappropriate changes to the RPKI, either accidentally or deliberately (e.g., as a result of some form of “government mandate”). A new proposal referred to as “Suspenders” is intended to address this risk. This is not a WG item, but it will be discussed during the SIDR WG meeting.

The focus of the GROW WG is on operational problems associated with the global routing system, such as routing table growth, the effects of interactions between interior and exterior routing protocols, and the effect of operational policies and practices on the global routing system, its security and resilience.

For instance, using BGP to implement certain business-driven policies is quite a common practice. Draft draft-ietf-grow-filtering-threats exposes how unexpected traffic flows can emerge in autonomous systems due to the filtering of overlapping BGP prefixes by neighboring domains.

Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead of IXP participation, and many IXP participants use these systems as a preferred means of exchanging routing information. Draft draft-ietf-grow-ix-bgp-route-server-operations describes operational considerations for multilateral interconnections at IXPs.

Improper handling of malformed BGP attributes may cause serious outages, and even cascading effects affecting other networks. Draft draft-ietf-idr-error-handling, being considered by the IDR WG, discusses the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. The working group is also working on improving the BGP, and there are several drafts in its portfolio aimed at improving its scalability and resilience.

More immediately, the OPSEC working group, which documents operational issues and best current practices with regard to network security, has a draft in WG last call [draft-ietf-opsec-bgp-security] that summarizes best practices for the security of inter-domain routing, providing guidance for implementing the best approaches to make the system more robust and secure.

In summary, there is a considerable set of work underway across a number of IETF working groups to ensure the Internet’s routing infrastructure is even more secure in both the short and long runs.

Related Working Groups at IETF 88:

IEFT 88 Rough guide:

Deploy360 Improving Technical Security To archive

Comments? Our “Routing Content Roadmap” Is Now Available

We want your comments and feedback!  Back in December we announced our new section on routing resiliency/security. Since that time we have been talking to many people about what we can offer to help people make their routing infrastructure more resilient. We’ve come up with our list of what content we now think we need to add and posted it to our site:

Now we would like to hear from you. What do you think of this list? Is this the content we should be adding?  Are there additional other resources we should be adding?

We are planning to start writing these resources soon, so we’d love to hear from you soon. Please send us email or complete our feedback form to let us know your thoughts. Thanks!

Deploy360 Events IETF Improving Technical Security IPv6 To archive

Deploy360@IETF86: Day 5 – MIF, LISP, IPv6 Maintenance… and we’re done!

IETF LogoAnd so we reach Friday… the final day of the 86th meeting of the Internet Engineering Task Force (IETF)  where it’s a short day that ends early and for us within the Deploy360 Programme only hits two of our topics:  IPv6 and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.

Here’s the preview of how we’re finishing this very busy week…

0900-1100 Friday, March 15

Multiple Interfaces (MIF) – Caribbean 1
Computers and devices today have the ability to connect to multiple networks simultaneously. Think about a laptop that can connect over WiFi or Ethernet – or a smartphone that can connect over WiFi or the cellular data network.  In those cases which network interface should the device use?  The MIF working group is working to document the existing practices and outline the issues involved in a world where multiple network availability is routine.

Location/ID Separation Protocol (LISP) – Caribbean 6
The LISP working group is defining a series of experimental RFCs around a new routing protocol designed to improve the scalability of the Internet’s routing infrastructure.

1120-1220 and 1230-1330  Friday, March 15

IPv6 Maintenance (6man) – Caribbean 4

The 6man working group “is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture.” (quoting the charter)  This is where most of the work is happening to refine the IPv6 protocol itself, and today’s session should be quite a busy one.

With those sessions, we’ll be closing out our work at IETF 86 this week.  Some of us will then be moving into a meeting of the Internet Society Advisory Council happening on Friday afternoon before we head to the Orlando airport for our flights home.

It’s been a great week and we’ve made some significant progress on a number of fronts!

On a final note, this is the first time we’ve posted these daily previews – were they helpful?  We’d love to hear your comments – either in response to this post, on social networks or via our email or feedback form. (Thanks!)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86’s Hot Topics“.

NEW!Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):