IGF 2018 - Day 1 - Salle VI- WS40 Internet Mega-Trends' Impact on the Internet’s Architecture

>> And it's called Internet mega trends impact on the Internet's architecture.  It's organized by Internet Society, together with representatives of Internet Engineering Task Force.  Just to give a small introduction, last year we had a session called strengthening cooperation with IGF, and the IETF was invited to tell more about the work it's doing and explore more to the broader IGF community.

We will present three case studies.  The IGF is invited to reflect on the current and the future Internet protocols as they impact the investments, policy decisions, et cetera.  So the question is why is the work of the IGF important to other communities?

Internet protocols is what makes the Internet work and without these standards there's no Internet and it was developed when Internet security was not an issue.  It's aimed at making the Internet safer and more secure for users and there are very many trends and topics going on that actually make a different Internet in the near future.

So to have a chance at changing several options that exist, we will have a presentation on them and one of them is to have a better understanding of the technical work that the IETF.  It allows others to plan better and create policies for deployment.

With us are Alissa Cooper, the current IETF chair and Jari Arkko, who is a predecessor and Maria Ines Robles.  And Alissa will focus on the writing of encryption in the Internet core protocols.  Jari is an expert on Internet architecture with Ericsson research in Finland and his input is on consolidation and Ines is working on a Ph.D. at the University of Finland and her presentation will tackle the work on the shift from device centric to service centric networking.  All these very technical subjects are carried out with the reason that Internet is changing fast.  The technical community deals with the consequences for us all.

So the presentations will come first and then after that we will go into a debate with several questions that have been prepared and announced basically on the website of the IGF, and we thank you all for being present here and I would like to start with Jari as the first presentation.

>> JARI ARKKO: Thank you.  And can we advance the slides?  One more.

Yes, so I will talk about consolidation or the creation of larger and larger entities in the Internet and that's not something that the IETF is not just working on but our work is sometimes affected by that and it affects other trends in the IETF.  Go to the next slide, please.

So if we go back and then I guess many of us still have this notion that the Internet is like the ultimate distributed system that's sort of allowing good things to happen, and allows equal opportunity for various different entities, individuals, small players, lots of players and allows open interfaces and that is, of course, still true but at the same time, the Internet has, of course, grown up and become a big business, and as part of that, we have seen the introduction of fairly large entities in the Internet that provide a large part of Internet services for users.  At the same time, we have also seen a trend towards more centralized architecture that instead of like this end‑to‑end from one user to another, we have ‑‑ we have to go through a centralized entity in between.

And there's many examples of this.  Of course, you can all think about that.  You know, the most obvious examples are ones that are most visible to end users and consumers like what kind of social media systems or other services you have in the Internet, but you have to understand that this actually goes pretty deep, like on many different levels.  Starting from like Internet traffic, which is consolidating more and more or concentrating on relatively small number of hands.  So the large Internet companies, of course, are high up there, as well as CDNs and other providers like that.

You can also think about things like app stores and cloud service and so forth, where there's relatively small number of choices or your choices as an end user may be somewhat limited.

And just sort of reflecting on some of this personal experiences in this space, at least.  So for instance, if you think about social media networks, I mean, obviously, you have a choice of many, but you may feel like you have to be in that particular one because everybody else is there but you have very little freedom to personalize your experience or dictate how you want to use it, you being given a particular product and you can't change that much.

Email is another example, obviously email is a distributed system, and it works well today, but I have found that it's actually quite difficult, even as an expert technical user to set up your own services and you have to go ‑‑ like, I have an email service in ‑‑ you know, in ‑‑ with the set of colleagues in my company, but it's actually difficult to manage that even if we know what we are doing, because larger entities find it easier to provide email services as you are not as easily booked by various kinds of Spam, black lists and such which we sort of constantly are without any fault of our own, for instance and it's ‑‑ it's difficult to provide services because you can be treated in any passion as a small entity, but if you say gmail nobody in their right mind would block them from their email service.

Next slide, please.

So obviously, the growth of the Internet and sort of it becoming real business or real thing, it's important for all of us has to be key factor in this, and this is kind of like a thing where the market forces, economics, competition, policies, and technology meets and this is the end result, or these things all affect us.  And from our perspective, like, we are technologists.  Like, our job is to work on technology and trying to figure out what to do next, like what would be the good thing for the Internet and for us to develop.

You know in some sense, we are not specialists in economics, for instance, or competition issues or anything like that, but it's good for us also to understand, like, what's happening at the Internet.  I think for all of us, it's good to understand what's happening in the Internet, and ‑‑ and it may affect our work.  So, for instance, it might be that we see ‑‑ if you understand the situation, we might be able to do something, like if we choose this path, on a technological choice, then this will improve the chances of small players versus large players.

Next slide, please.

Just briefly, I'm going to talk about some factors leading to consolidation beyond the economical ones.  Obviously, network effects, you go to a particular service, because there's lots of other people or other entities there, that that's a value, it provides more value the more people there are in that particular network.  There's some other things and fundamental things.  For instance, if you want to provide a low latency is service, like where you get to some content or something from, you know, different places in the Internet, like 10 milliseconds, you have to do it fundamentally on a global spaces, and you can't do it because of speed of light.  If you have to deploy that has low latency is you have to do it globally and that will take resources, a lot of money.

There's obviously the permission, that you can come up with your own ideas and sort of without asking permission from anybody, you can ‑‑ you can pursue those and build the structures that you want.  But it also seems that ‑‑ like, when you read a particular level in connectivity, when you have this very good connectivity to different places, then you can actually build sort of closed structures on top of that.  There's a double edged sword.

There's also some more specific technical things.  One issue that we deal about quite frequently is a lot of service attacks.  Distributed service attacks and those, I guess, large entities by its nature are better equipped teal with an attack like that.  Learning and AI is another area where you may ‑‑ the more data you have, the better algorithms you can actually develop.  So that's a future thing that hasn't really happened yet but we will probably see the effects of that.  Next slide, please.

So we have some open questions that we could talk about, through the rest of the session and you can provide feedback or answers to these questions.  So I guess the first one, do we understand these kinds of trends well enough to be able to take them into account?

Do we, for instance, do we not research on this, and I would actually claim that we don't.  We could ask about the consequences of consolidation, and one of those consequences might be, for instance, that you have this ‑‑ assume metric, balance of power that this large entity that dictates how things are and the small entities that the individual users can't really have much say.

And then how can we better address those things.  Like not just we like the engineers or techies but like we all together, what's the forum?  Is it the IGF where we can talk about things like this, that are crossing technical and other areas?  Also specifically for the engineers what technical tools might actually mitigate the situation there.  You can think about some things like you do federated systems, which might help small players get together and build ‑‑ build a system or service.

You think about things like browsers have tools that, you know, are on the side of the users preventing information leakage to the various services that they use.

And we have many of those things today, but they are not super successful, I would say, and also it's kind of weird that they are not the default.

So I think I will leave it here and let you, Alissa, continue.

>> ALISSA COOPER: Thank you, I think.  We can go to the next slide.  Thank you.

When we get into the discussion portion, I think we will find lots of places where the trend that I will talk about, encryption intersects with what Jari just talked about, consolidation.

If we think back to the early days of the Internet when many of the core protocols were being developed in the '80s and '90s, many were encrypted in a clear text fashion.  Some of them also had ‑‑ were accompanied by versions that were more secure and that provided encrypted modes.  But the dominate way as unencrypted manner.  But any server on the network was able to access or read the data that was being transmitted using these protocols.

In the late '90s and early 2000s there started to be more of a push to develop more protocols in a secure fashion and we started to see some of those, seeing wider deployment, but even up to this very decade that we are in now, there's a large proportion of traffic on the Internet being sent unencrypted.  In 2013, with the revelations about mass surveillance, a lot of that began to change and that set of events really kick started a huge push within the industry, within the technical community to deploy the existing encrypted protocols more widely and to develop new ones that we could get deployed.

Now, when I talk about encryption of the protocol level, it's important to realize what that achieves from a security and privacy perspective.  What you get is confidentiality or privacy protection on wire from an observer.  The two parties who have the keys at either end should be the only ones who can decrypt the content but that doesn't say anything about what happens to the content at either end.  So it doesn't get you protection from compromise or sharing of the data by the parties who are authorized to have the encryption keys.

So it's I somewhat limited scope of the topic for today, but that's just how we are limited in terms of how we design protocols in the Internet.

So to kind of understand how things have changed and what the implications are of this trend, I will walk through three different examples today and they all kind of build on each other.  Next slide, please.

The first one is HTTP, the web protocol between browsers and servers to exchange data.  Lots of mobile applications use HTTP to exchange data and there are many, many other applications on the Internet that essentially use HTTP as a means of transporting information back and forth.

A prior version of HTTP, 1.1, which was originally standardized in the 199s.  As a result, over the past several years, it was really in need of an update.  And it's a common thing with the design of the Internet.  You deploy something, it's very exciting.  And you start to realize that there's lots of ways this thing could be improved and lots of fixes that people want to apply to it.

For HTTP, that was primarily related to the performance of the protocol.  So it had an issue where it ‑‑ it ‑‑ to be performing needed to have multiple connections that could be in into flight at the same time and could you exchange more data when you are using HTTP in your browser and we needed to change the design of the protocol in order to speed that up.  Essentially.

If you go to the next slide.  So there led to the development of HTTP 2, it was standardized in 2015.  And there was a big question that arose in the creation of HTTP, whether encryption was going to be mandatory.  For the purpose of HTTP, just the way it's architected this was a question of whether another protocol would be required along with that.  And that's it.  LS, the transport layer security protocol.  This was a big debate, within the IETF, people discussed this are we going to mandate that TLS gets used every time that HTTP it gets used.  The rough consensus was we would not mandate this.  It's not mandated but it's effectively mandated because most browsers require HTTP in an encrypted mode.  Buzz the way that HTTP 2 exists on the Internet.

As a result of that development along with a greater push to encrypt even HTTP 1.1, which has an optional use of TLS that is supported we have seen a tremendous growth in the proportion of web traffic which is encrypted.  If you go back to 2013, something like 30% of Firefox page loads were encrypted in flight.

If you look at that number today, it's 70%.  Nothing changes that fast if you look across the whole broad, internet.

And so the key insight here is that in developing HTTP 2, it was aimed at improving that performance on the web and something that web companies are really, really sensitive to.  It turns out that by deploying it with the requirement of TLS, we married the performance gains to the security gains.  We said, okay, if you want to have these performance benefits that HTTP 2 is going to get you, then you will get encryption along with it.

Even those companies who sought to deploy HTTP 2 primarily because they wanted their websites to work faster, also benefited everybody by adding this encryption to the network stack.

Next slide, please.

So the next example is TLS1.3 and this is going to genericize this story a little bit further.  So TLS is a very commonly used, probably the most commonly used security protocol on the Internet and we just heard about it in HTTP story but it also gets used as a security layer for other applications email, instant messaging and many others.

And as a result, it can have kind of an even more powerful security impact because it's a more generic building block than HTTP itself.

With TLS, 1.2 was published in 2008 and again in a span of the ten years from then until now, there were lots of discoveries about things that could be improved with this protocol, in particular there were a couple of cryptographic algorithms that were prone to attacks and there was an initiative to update the TLS standard to deprecate those algorithms and remove them from support in the protocol so people could month of on to stronger algorithms not subject to those attacks.

There was also a strong push to mandate something called perfect forward secrecy.  The perfect forward secrecy, there's a different set of keys used for each transaction and as a result even if one set of keys is compromised, all of the data that was previously encrypted with the keys cannot be compromised just by virtue of having that one set.  So this is a key feature of TLS 1.3.  And TLS 1.3 improves performance.  Everybody knew that it would be a target work case for TLS and we wanted to build on that case with HTTP and make those connections go even farther.

So TLS 1.3 was published this August of 2018 and it has seen more deployment in 2018, than TLS 1.2 saw in the first five years.  So, again if we can tie the performance gains to the security gains everybody who deploys TLS 1.3 gets all of those performance benefits in addition to the new crypto algorithms and all the other security benefits of the protocol.

Next slide, please.  So the last example I will talk about is actually a protocol that's currently in development.  It's called QUIC.  I don't even think it stands for anything so I won't expand the acronym.  But you will hear a sim already thread in this story.

So in terms the transport layer which is the layer that QUIC is looking at, the protocols predominant on the Internet, TCP and UCP have been there for many decades and over the decades we developed several other transport protocols, none of which have seen significant deployment whatsoever.  It's very difficult to get these protocols through firewalls.  A lot of firewalls are built that they can recognize TCP and recognize UDP and they will let them through but they won't let any other transport protocols through.  It's a key goal in the design of QUIC, that we want to make it easy to deploy and get through the firewalls to matter what else they might be filtering or blocking and we also don't want to have to require changes to the operating system of every machine on which this protocol is running in order to get it deployed.  So these are all means to make it easier to see why deployment.

In addition to all of those features, QUIC is encrypted.  It's not the same way that HTTP is.  It also encrypts additionally ‑‑ it encrypts the headers.  That's the idea of this picture here.  What you could get before, with HTTP over TLS was pretty good.  Could you encrypt the payload of the transactions so that the data that exchanging back and forth is protected from observation on the Internet.  What you couldn't get is the encryption of these headers things like session identifiers and congestion window information, and it gets transmitted by TCP if you are using a traditional HTTP tack that reveals things about the end points.  It can reveal a whole lot about the communication that's happening there and with QUIC, what we decided to do is roll TLS right into it.  And get rid of the TCP layer and the UDP headers don't give very much rich information about what's happening at all.  Being built on top of UDP and rolling TLS in and having HTTP incorporated as well, this gives you a generic protection layer protocol which encrypts more of the stack than we have ever seen, to for a protocol for wide deployment.

This is still if development.  It will hopefully have its first version officially published next year.  But, for example, Google already has something like 30% of its traffic running over QUIC, which is one indication of how wide we expect the deployment of this to be.

Next slide, please.

So just to sum up and talk a little bit about the implications of this trend.  The sort of strategy in some is that we have focused on designing features that the market is demanding, in particular, more performance protocols and tying those features to mandatory security.  So if you want these performance benefits, you will get the security benefits too.  If you want to get through firewalls, you will get these security benefits too.

And that has yielded essentially dramatic improvements for user privacy and security on the Internet, replaying that formula every time we look at a new protocol design.

Now, in addition to this, this is a shift for network operators who are accustomed to having lots of access to metadata and consent in clear text, in order to do lots of different things on their networks.

If you think about your typical way of measuring performance if you are a network operator, of doing diagnostics and troubleshooting, of doing Spam filtering, of doing malware and attack detection, of applying quality of service or traffic differentiation, to the traffic on your network, a lot of the systems that are in use today, that are used for all of those functions totally rely on the notion that they are going to have clear text access to the entire packet, every time it hits their network interface, and that, obviously is changing.  It has already changed a lot with HTTP and is going to change a lot more with QUIC.  And from our perspective that means there's lots of new engineering problems to solve.  There's lots of questions to be answered about how are we going to be able to manage networks in a new world, where they are predominantly encrypted.

Even so we are looking at things like malware detection on encrypted streams and novel ways of doing the same things that you can do now, in terms of network management and operations as you could do when most of the traffic was unencrypted.

Just the last point to tee up some Q&A.  There's a potential for interplay with consolidation encryption.  It limits the parties who have access to the data.  If what you are concerned about is a smaller number of entities with access to a larger amount of data.  Encryption force out a lot of data.  No you whether that necessary forces consolidation is maybe something to debate but that's the touch point where the two things interact.

I will leave it right there.  Thanks.

>> MARIA INES ROBLES: Thank you, Alissa.  Next slides, please.  Next, next.

Okay.  Good morning, everyone.  I will talk to you about how now the Internet is device central to Internet working.

Okay, when the Internet started like 40 years ago, there was a train to connect in‑house devices or host with resources that are remote.  So I need a way to look ‑‑ to locally devise that report from an IP number.  So that was Internet but nowadays, we still use IP, of course, but nowadays with the deployment of the worldwide web, people get content, retrieve content from the Internet and the Internet where it's located.  So we have to think how can we moderate the Internet based on services and content.

Yeah, independent where it's located.  So that's the future Internet and we have to work on that as well.

Next slide, please.

Ands well, the future Internet includes Internet of things.  What ‑‑ we know it's like all kinds of device connected constrained resources like low power, low memory.  And as well, in constrained networks like high packets lost, as well as not included the constrained networks and no constrained devices.

So nowadays, we have our home, like a smart home scenario.  Like, we have smart devices.  And in this case, we see that not only the user communicate with the devices, but as well the devices communicate with other devices.  So, for example, if the freeze, they want to detect with a sensor that's run out of milk so they can order the grocery to bring more milk.  Or he can program it to let him know about some event.

We see here that Internet, the user who used the Internet is based on which service we can get from that.  Independently where it is located.  We don't care, right?  We care that we get the functionality running, what we want.  So next slides, please.  Other samples of where the Internet as well is based on services, for example, in ‑‑ in eCommerce or online shopping, where you have a stateful services.  Means, like you need to transfer between the client and the consumer, some teach of information, especially for security reasons.

So we need to detect how we bill these kind of services in a specific ‑‑ a ‑‑ contents we can assurance like privacy and all the aspect together to get the efficient communication.

Next slide, please.

For example, we can use like a use case.  There is a trend right now working, that we see working in the web of things.  It means that I can connect, right, the devices through the web browser.  That is the work going on.  And since the deployment of the work brings these kind of services like thinking about services, now we have, like, the browsers allows the devices to connect between then.

So we are going to build on the architecture based on kind of services.  Actually, based on a structure called screen description that's built by properties, actions and events, that is composed by a device.  So, for example, I describe a device, or actions like turn on, turn off or events, for example, I want the device to alert me when it's overheating at some point.  So this is focused on the service or the functionality that it provides.  The goal of w3c, is ‑‑ so it doesn't care if I connect between HTTP or co‑op, I should be able to check with a device and I should be able to access to that service or acts that I want.

So that architecture is basically built by Think.  Like it thinks like anything ‑‑ a resource that you can locate in the Internet.

Then the things is ‑‑ is described by the thing ‑‑ by the descriptions like a set of property, actions and events that you can manipulate with operations.

Then when you want to connect these kind of structure, you want to connect your service, between the independent protocols, you specify the protocol and so if I want to use HTTP or co‑op, I add information in my description, especially find which protocol want to use.  And then the last part of the architecture is go to API where it allows me kind of operation, for example, to expose my description, expose my set of properties, actions and events, expose my services.

What kind can I do?  What can I offer?  Then as well with script in API, it means I can manipulate the properties, actions or events.

So based on that, this is a new trend.  So it's ‑‑ we see that they are working on basically how we can build the Internet based on actions, services independent, where we are located or independent of the underlying implementation.

Next slide, please.

Okay.  The open questions will be for this topic.  How could we model the service topology?  How could we do like a resource management?  What is a resource?  Resource is an atomic piece of information that you can manipulate in the Internet.  A temperature, value, service or operation.  It's very important when we talk about services that we can identify globally, right?  We should be able to identify globally a service.

So we have to find a way to identify the service.  For example, through a URI, right, that we can locate globally a resource.

As well, of course, all of these kind of services are spread in cloud, in the Internet, in service in the Internet and that's as well in the age, meaning it's the gateway between going to the Internet.

So we have to ‑‑ we have to see how can we form our architecture in the way that we can get, for example ‑‑ we can change information in the age and so we ‑‑ we don't ‑‑ we avoid some kind of congestion to the cloud, to the net.

As well very important, well, how we do the forwarding of the services, if we ‑‑ if we base our architecture based on service I. D, how can we efficiently do the routing on the services.  All of these need orchestrator.

So they can efficiently manage the kind of service distribution and since the service are finally by user, by end user, we need assurance that the security and the privacy components are there.  We cannot avoid the security.  It's not negotiable and we need to specify and assurance and the leg s components for that.

Thank you.

>> MODERATOR: Thank you all.  I forgot to introduce myself.  Which I usually do because I'm so enthusiastic.  My name is Wout de Natris.  I'm being assisted by Paula Rio.  My first question is this anybody online at this point?

>> There are people online, but there's no question yet.  I will ask.

>> MODERATOR: Just ask if there are any questions and we will make sure that they are addressed.

Just to get a feel of who is in the room.  Who is here from the technical community?  Raise hands please.  That's a fair amount.

Who is here from government?

And who is here from the public ‑‑ the industry?

A few.  And from academia?

So the technical community is ‑‑ civil society.  Sorry, civil society.  Thank you very much.  Sorry!  Who is here from civil society?  Thank you.  Thus it shows that the civil society is very interested in this topic and there's lots of interaction.

We will try to end in the last 50 minutes to see how and when necessary that the interaction is being taken to the next level.  And see how that can actually be done.

First, we will have some questions on the screen.  We will probably have some questions in the room.  I will start the interaction with asking the three people who presented to us their questions and then we turn it the other way around.  Who would like to start?

>> ALISSA COOPER: I don't want to necessarily start, but I wanted to see, I think we have until 13:20.  So we have 55 minutes, right?

So open for questions.

>> MODERATOR: Please.

>> AUDIENCE MEMBER: Hi.  Well, what do you think about this kind of service‑oriented networking, like, do you see often in your daily routine kind of use internet like e‑commerce, right?  What do you think should be improved based on your daily routine using those tools or you don't like realize?

>> MODERATOR: Please introduce yourself and your affiliation.

>> AUDIENCE MEMBER: This is awkward.  My name is Taylor Bentley, I'm with the government of Canada.  So I love the interplay went these three mega trends.  It's a really great example of multiple dimensions of all of these issues, right, consolidation is not this looming nefarious presence.  It has some massive benefits as far as take up of key issues.  Towards the more secure direction.  The port service centric trend is really fascinating.  So we are doing quite a bit of work on Internet of Things and a big candidate for us right from the get‑go and remains an ongoing focus is through MUD, manufacturer usage descriptions.

But this is ‑‑ I mean, this is a design problem and the design problems take many years to fix.  Where it sounds like service problems could be just a matter of a policy update.

For instance, an improved browser that can ultimately provide this service benefit, the functionality of making our devices make them work better and make them more secure because we have ‑‑ I mean, a part of making sure they function properly is understanding them, understanding their limits.

So, I guess within my question is, how quickly can we fix or improve or enhance the security of the Internet of Things using this service‑based approach?  Thanks.

And is convergence the secret to this?

>> MARIA INES ROBLES: For the IoT.  The IoT is something new, which generate new business models we didn't have before like normal devices communicate between them, right?

So we have to think, like assurance, privacy in the user, of that information and if you see them, they say it's still a work in progress.

I mean, it's open to everyone.  So if you want to participate, you can do it.  And there is a group of people working in security.  There's protocols, like DTLS done for that.  All of the information is already encrypted for this.  Every protocol should have its own security considerations.

So it's still work done, but still it's like ‑‑ it's fresh because these new business models bring new issues, security issues as well.  So ‑‑

>> ALISSA COOPER: And just to take that up one level, if you look at the way at least in the IETF that we approached IoT standardization it's to take protocols that we know well and people are accustomed to using in their software stacks and adopt them where the devices are contained in some way.  And the theory was to make this easier to get these things reused by having the basis for them to be very familiar and the sort of software development ecosystem around them be familiar.

In some cases that's not incentive enough as we have seen.  So in many cases you have IoT devices that are ‑‑ they are so cost constrained that the cost of deploying even these specialized protocols which are easy to configure, it looks like too much.  So we are getting deployed without the basic security features in.

MUD is another strain of the engineering effort, which is to look at that situation.  We know there's insecure devices out there and try to layer on top some other mechanisms that network operators and device manufacturers can use to detect ‑‑ to start being able to detect attacks or to detect anomalous behavior.  And that what MUD is all about.

Instead of attacking that at the layer of the protocol is going to use, we are assuming it will use tools like MUD to help find out when that's happening and then hopefully to mitigate any ‑‑ my potential attacks.

I just wanted to highlight something else that was said because I thought it was very insightful.  The consolidation friends that Jari is talking about, you only need a small number of actors to decide something good for the Internet and it makes things positive for a wide swath of users.

If you go back 10 or 20 years, and you had many, many more operators and content providers who were, you know, proportionally serving the user base, if you had to convince all of them to start using TLS, for example, that would ‑‑ that could take a really long time to reach the bulk of the content being served on web, as these things consolidate it means a smaller number of actors can take a positive step and have a big impact.  If the smaller number of actors take a negative step, it is also have an impact.

>> MODERATOR: And if I can follow up on that.  First on the IoT space, and security, one of the difficult issues there is that the IoT is not like one thing.  It's like, you no he, 10 million different things.  Literally 10 million applications.  It's difficult to generalize necessary, but the issue is that people do not just like ‑‑ you know, they don't necessarily deploy the greatest technology, but they also do very stupid mistakes like default passwords and stuff like that.

I think we have to attack it from multiple fronts.  And one of the fronts is to create better devices, for instance, when you create a product for the IoT space, and avoid some of these simple mistakes, even if MUD and other technologies can help somewhat, that's still necessary.

And another thing on Alissa's point, the small number of people being able to affect the Internet in some way, and that's ‑‑ that's certainly true, but it's actually quite complicated still.  Like, let's take one very concrete example in the IETF, we developed a pro toe called dough DNS over ITTP.  Instead of DNS pros, use HTTPs to access the content or the DNS content.  So you use inquiries around this protocol and it's encrypted and it's a good thing.  It limits the number of people who can access whatever you are asking the DNS for.  It does have a down side and the way it's possibly being deployed.  It hasn't really happened yet but we are suspecting it will happen.

One way of deploying it, you go around, like where ever ‑‑ whatever network you happen to be, you ask the local DNS server for information and inquiry.  There's 10 million different servers in the world or even more, in different networks that answer these questions.  So it's very difficult for anybody to get to all of those servers and figure out, like, what are the people in the world asking DNS about?

But one way of deploying this technology.  The browser vendor decides we will use this dough service but it's not really available if all of those 10 million different servers so why don't we just point it to 888, or 111, or one of these general purpose resolver services.  Yes, you encrypted information from outsiders but you centralized information that used to be in 10 million different places in the world into like, you know, a handful of small a small number of entities that are large.

I know some of these people personally, they their networks and services personally and you create this place of extremely valuable information that could be asked by the governments or used for commercial purposes and it's particularly for the government it's difficult to resist.  It's not entirely trivial how we approach some of these questions.

>> MODERATOR: Thank you.

I think what all of these examples show is that how it affects literally all of us, all the devices we run at home, how consolidation will affect probably the sort of services that we have or the quality of the services that we have, the Internet of Things we haven't seen the beginning of it yet.  So from there, I think the question is what you said, Jari, we need to have better tools, better Internet‑connected devices but who is the we?

And probably a lot of the we are represented in this room.  So how do you envision the we getting together and then?  I will ask also the room to reflect on how do you see your role in the topics we are discussing today?

So then I will go to the remote question.

Thank you.

So who are the we and how do we connect?

>> AUDIENCE MEMBER: Hello, I'm from the private sector from Switzerland.  I will have the honor next week to chair at the Swiss IGF a session on how can we master the transformation and one of the big questions that I'm asking myself right now is aren't we too fast with these developments?  Technology is trying to breach things and make things much quicker than the users.  End users can actually swallow them.  While it's not actually up to the users to ‑‑ to make final use of it, but the trust may be gone.  So aren't we too fast with technical development?

>> ALISSA COOPER: I'm the lucky person who gets to answer that.

(Laughter).

Let me give you my answer in a sentence.  No.

Sore I actually do think that kind of trying to lump all of technology development into one category makes that category almost impossible to answer.  I think we can break it down.  So I think from the perspective of some of the developments that at least the ones that myself and Ines talked today, these are like identified engineering challenges that we have known about for decades, where people could see in the 1990s that there was a better way of doing this and if we could just figure out how to do this, then a lot of people would reap the benefits of service oriented architecture or, you know, the rise of encryption because things were getting attacked and you couldn't compose services very easily.  And when you roamed from network to network, you had to start all over and there were serious user experience issues and, you know, attacks against the integrity of the communications and the network, that where it was obvious that we needed to develop some solutions.

From our perspective, the fact that it took ten years to develop the next versions or to get it deployed, it's not too fast at all.  It couldn't have come fast enough.  We feel like we found this rhythm where we figured out how to embed the incentives of the people who need to embed the thing into the design of the thing itself so that once it's finished everyone looks at it and says, oh, yeah, want that.  I want it on my network and it will improve the experience that my users have and experience of everybody else on the network.  There are some obvious problems to get solved.  I think it's not moving too fast.  It's not movie too quickly.  We only can figure out how can we make the process go more quickly.

I think the broader set of, okay, now we deliver all of this technology to people and there's all of these implications, I think that's more of a case by case, you know, if we could go lower, what would that mean and what would that look like?  But for these harmonizing the architecture and increasing the security, it's not necessarily a loss to go more quickly.

>> Okay.  We have two questions from the same person.  He asked in the presentation was about services based on IoT or if you were talking about a new trend of Internet between devices.  He follows up with a question, about if you have any future few about consciousness robots and devices permitted to make decisions.

>> MARIA INES ROBLES: Thank you for the questions.  Well, I was talking about service Internet working which nowadays include devices as well with them, because it's like the future of this present Internet.  We have Internet of things in our devices.  It's IoT available in the mark.  So you can build your smart home easily nowadays and as well, there's a lot of IoT system deployed like for agriculture buildings, smart building and AEI, like electricity.  There are a lot of IoT work ongoing and deployed.  So it's like the service you should think that you are connecting people and connecting devices.  You cannot avoid and think only in people.  Nowadays the devices are with us, right?

And these web of things they try to connect devices between the browsers and they have open source and running code and it's not enough time that they came.

And then the second question was ‑‑

>> If you have any future views on robots consciousness and devices that make decisions.

>> MARIA INES ROBLES: Yes, the devices can make decisions.  Maybe the basic ones like the call to the supermarket when I run for milk, or maybe more advanced depends how you program.  Now the platform is not so expensive.  So you can program intelligently on the devices to do whatever you want.

Yes, I mean these type of learnings, the orientation, in the IGF, and working on machine learning for networking, there's a lot of research in academia and working with the agents on the web browser area.

So it's like a fact, yeah, for me.  Thank you.  I don't know if I answer.  I hope.

>> AUDIENCE MEMBER: Yes, thanks, Matthew Shares with ICANN.  These three presentations are really interesting.  I want to bring the conversation back a little bit.  I will answer your question, but in a roundabout way.  I want bring the question back to what Jari was saying about consolidation and the impact, or the potential impact on permission of this innovation and what it might mean for future innovation.

What is interesting about this service topology is that it's, in fact, basically sharing an increasing amount of information between databases in a particularly active space and you mentioned the home, but it could be applied to any number of particular spaces.

In my mind, it raises the question, are we ‑‑ and it's a general question.  Are we through adopting and promoting these type of services?  We increasing the convenience to the user but at the same time, are we increasing that element of consolidation and the default notion that Jari was talking about in the beginning?  How is this ‑‑ how does this interplay?

And then to Alissa's point, is there a role for encryption in ensuring that that exchange of data and information between all of these devices is then lessened so that the opportunity for capture and defaults and things like that an consolidation is lessened.  So that's the kind ‑‑ and to your question, I think ‑‑ so that's the first point.

To the question of how do we pull yourselves together to address this, I don't think it's so much an issue of that or going too fast but looking at these technologies holistically and understanding what these particular issues might be.  Thanks.

>> JARI ARKKO: Yeah, so I think for me one the key questions is like, we have been sable to make ‑‑ Alissa explained, we have encryption over the Internet what we haven't dealt with is data what can we do about that?  If I ‑‑ like, I can up I my own thing at my own home and make sure that my servers are fine but for most people, like, it's more convenient and there's lots of benefits, if you ‑‑ you use some kind of service or part of some service, where you have to disclose some data.

Or at least, some parts of data.  And being able to protect that data is, you know, today is essentially you just, you know, give everything, you know, for free and unprotected and so on.  And I think some progress is needed on the next step.  I don't know how to do it, at least not yet, but hopefully someday.

>> ALISSA COOPER: I think you raise an interesting question, between invasion and wall gardens is sort of what I heard in your question.  I was thinking about this earlier too.  A lot of the security benefits, ideally what we would like to see when they get rolled out on the network is that users don't notice a difference.  So people are going to start using it protocol that you already spoke about, DNS over HTTPs and the hope is that people don't notice any difference at all, unless their DNS traffic was censored and no longer it's censor because it's intermingled with the rest of the web traffic but they shouldn't have to be involved or make a complicated trust decision about what DNS resolve they can configure.

Who can configure their own DNS resolve?  There are four people in the world!

Those are things we are actively trying to take out of the hands of 50 users because they are complicated and establishing a baseline, which is more secure for everybody.  And it's a better way to get these things out on the internet.

At the same time, if that literal system significance is opting people into a wall garden and a space where the majority of their data is only getting shared with a smaller number of providers this races the question of whether that's a decision that people should be automatically allowed into.  And that's where the big challenges will be going forward with this interplay, you know, do you go back and try to give people lots and lots of choice, knowing that that defeats the purpose of some of the security features we are trying to deploy.  It's a hard design space, I think.

>> AUDIENCE MEMBER: Okay.  After all of these presentations, there's simplified roles.  What is the future development direction?  Because you closed the transmission.  We have got concentration.  It's a new risk and now it's a key issue.  It's how to provide adequate tools for person to manage his personal data on both sides.

And especially in such situations the super concentration which we all have.  And it's in all ways, because it's obvious that service‑oriented networks will be serviced API, for smaller players over the elephants.  And for me, as a person, of course, I can believe in any IoT things only if my data will be protected on remote site, not only here.

It's how can we resolve this feature, its ability to manage, to access your data, anywhere in the world.  It will be a huge problem.  Thank you.

>> AUDIENCE MEMBER: I'm Andrew Sullivan from the Internet Society.  I wanted to chase something that Alissa was saying because it strikes me that the second part of this ‑‑ of the title for this, right, was about what these mega trends do to the Internet architecture and I think that there's a really significant piece here, that Dimitri just touched on, in fact.

The consequence of this sort of ‑‑ the sort of service development and the natural consolidation that maybe comes from that because the services all end up being done over HTTPs and HTTPs tends to concentrate because it presses it to a server under single operator.  It means we have a network architecture that cannot or perhaps cannot deliver the end‑to‑end experience the way we originally envisions this.

That is the services end up being run by other people.  They have to be, because they are run as services in the network by concentrated server operators.

If that is true, then ‑‑ then we are ‑‑ we are potentially creating an Internet, which has differentiation among nodes built into the architecture instead of an accidental property of the way we have deployed it.

So the way we deploy the Internet, in fact, right, the theory was all the nodes were ‑‑ all the hosts were the same, and they could all send TCP to one another, but, of course, that never happened.  What actually happened was we had consumer access and then we had like the real people and the consumer people were out here at the edge and they were just consumers.

The ‑‑ the network architecture that is employed, however, by the orientation and consolidation suggests that it's now a feature of the architecture that cannot be avoided and you create a class of people who are consumers of whatever the network services are.  If that's the case, are we still talking about the Internet or are we talking about a different kind of network, you know, some new thing that uses some of the Internet protocols underneath but is a consumer network more like the kind of cable system with ‑‑ with somewhat passive consumption at the edge.  I don't know if that's the case, but it strikes me that there's a drift of this conversation that's making me that way and making me semi‑suicidal about it.

(Laughter).

I thought I would ask the question to see if everybody else gets depressed too.

>> MODERATOR: I'm glad you can still laugh about it, otherwise I would get some medics for.

>> JARI ARKKO: I don't think we need to get depressed.  Step one is to recognize that we are in a situation and whether that's a change to the architecture, but at least we can think about, like, how could we go ‑‑ go around that in some fashion.

And one of the things that sort of strikes me at least in this discussion, in architectural sense, like we have a very different situation on the lower layers that, you know, we have this IP and transport protocols and very widely deployed and anybody can connect to anybody, and that's no problem today, and there's a lot of interoperability, but on the higher levels, like we have this closed world and universes and there is not ‑‑ you know, you can talk to this thing from your browser but I can't develop a component that I would use to replace a part of Facebook.

But, you know, maybe that's a direction that we should go into that, that would be sort of opening up some of this universally used parts and being able to standardize some of the interface and APIs and that may help to break up the log jam a little bit.  Just one of those things.

>> ALISSA COOPER: I agree with that.  I think the kind of parade of horribles doesn't necessarily follow in factually the way that you laid it out, because in many of these cases, you know, the service provider who is at the center of this is there in order to connect to end points.  It's not like a pure peer‑to‑peer exchange.  Although there's an interest to move more to peer‑to‑peer and decentralization and distributed computing and all of that.  And it's quite possible that we could be in kind of in an upswing of a sort and swing back towards the middle.  Even if that doesn't happen, as Jari said, we are looking at components and still have a lot of interest and energy in the IETF and elsewhere.  And standardizing technology that have peer‑to‑peer of some sort.  And web RTC is the new web‑based suite of realtime protocols that let you make a phone call or video call through your browser.  This is not only be used in the browser and Facebook messenger.  You have Facebook in the middle setting up your call but you connect to the other peer.  That's the same thing with layer security, which is for group chat.  How many people have more than one messaging application on their phone?

Yeah, probably lots of people.  Messenger is a huge growth area.  Even though there's a service provider in the middle, you are connecting peers.

I think it's easy to fall into the trap if you look at the Internet from the perspective of the ‑‑ which kind of traffic is the most volume and it's clearly video streaming and so we must be optimizing for that.  That's only true in once Wednesday.  Other thing, just to refer to Jari's very good list of causes for this, it's not all pro toe ‑‑ protocol design is not the only cause of consolidation.  There's ten other reasons including economics and network effects and so for the.  To the point you raise in particular, we may have created this client server mentality, but the ‑‑ the disparity between uplink and downlink capacity on both residential broadband and mobile wireless networks also has contributed significantly to this.  So if you wanted, you know, to go back to the time when it really was a network of equals you have to go really, really, really far back if ever.  To the point where you are getting the same amount of uplink and downlink.  Most people can't even dream of that.

(Laughter).

>> AUDIENCE MEMBER: Thank you.  I have a couple of points to make.  First of all, about the Internet consolidation, I just wanted to know if ‑‑ so if centralization is necessarily a problem or is this actually a good thing?

I mean, it's great to have decentralized networks and that has been, like, a value for us for a long time, but might it be that the values change over the time?  And there is ‑‑ I don't know if it's a rumor and everyone talks about it.  The Internet protocols being designed by the main industry players are being adopted by them.  So there is this perception that those who attend IETF are going to adopt them and just this is going to ‑‑ this is how it will be dominant.  It's not mainly about interoperability.

Sorry this was a very controversial thing.  I just said it.  I put it out there.  This is just a question and not my opinion.

Your presentation I was concerned about what you were telling us.  We have the policy aspect of things which is how the Internet of things can be secure and private and then there are multi‑stakeholder processes at NTIA that look at these issues and then the technical aspects.  I guess your questions are not really addressed to the civil society end user person.  You are not asking me if I want to allow my fridge to come to my room and beat me up if I eat something that has a high calorie.  I don't think that these are the design features that you are predicting and the predictability of the internet protocol and what sort of effects it's going to have on rights, is just not possible.

I don't think ‑‑ when you see the problems you can solve them but I don't think you can predict the problems.

>> JARI ARKKO: On so the centralization question.  If there's information you don't want exposed and you think it's important that it stays in your control, I think what to do in that situation is not put in a centralized location, or perhaps done even let it out of your hands.  Don't put it in one place where anybody in the world can get to rather easily by government mandate or something.

The other thing, the question about ‑‑ you know, who uses and who standardized things.  I mean, it's a fair question and certainly some proposals come from certain sectors of the industry, but that's natural.  IETF, we don't standardize protocols because we like them or some person like that ‑‑ you know, this speck looked nice.

We implemented them in order to be implemented.  TLS 1, I was in a hackathon, but it's exactly those 18 and maybe more than 18, but you want those people adopting things and affecting the standardization, definitely.  That's a Fitch.

>> ALISSA COOPER: There are benefits and drawbacks.  If you lieu at DDOS, as you look customers, they can consolidate.  That may lead to other drawbacks of it but it comes with some type of benefit, maybe someone who was trying to access the IGF website.  They got a notification from CloudFlare, one of whose lines of business is to do exactly this and the wider foot present they have, the more ‑‑ the better they get to providing service to folks.  There's no question about centralization.

I think to build on what you said about the IETF, it's obviously an open forum and anybody can operate.  It operates on the basis rough consensus.  If we have a bunch of people who could.  From a handful of providers and we have I handful of participate to participate.  It can be resource intensive in terms of taking up a lot of time.

For example, historically, it's been harder for us to have as much participation from some network operators because, in operators tend to ‑‑ you know they have a lower margin business of and they don't have a bunch of engineers working longer range at the kind of future standardization projects that are relevance to their company and they do a lot of outreach to try to bring those people in and make sure the perspectives are representative.

>> MARIA INES ROBLES: I about the IoT security, yes, actually this' a lot of layers to CI was talking about, like, yeah, protocol oriented but when we talk about IoT security, we talk like a different layers or a stakeholder that should address and be responsible.  The government should say, go if this service is available to the community, she will have these kind of privacy and security considerations, right?  So it's not only the protocol that we develop as well as like the people that use that service or that protocol, maybe it's not aware of what type of threats it can have.  Maybe an institution like the government or some type of university, they can do some individual users could do some helping of the community.  Actually it's very big and it's made through the stakeholders.

If we make a protocol, like in a right‑of‑way, it's not going to be useful.  When we talk about the security in IoT, like my partners say, we talked about the devices with different kind of constraints.  So some kind of devices are not able to run all the security aspects.  So we have to ‑‑ we have to see how we can put in these small devices with this kind of constraint, like the basic security, right?

Or these kind of devices as well are built to be autonomous.  They should be able to stop by themselves, right?  And they should connect to the subserver and retrieve the information for connection in a secured way.  So we have these kind of scenarios with constrain devices and they can't deal with the security aspect but the minimum, right?

When you have this type of IoT scenarios, we can envision some individual users with some kind of threads.  So we can have these kinds of threads.  So this kind of attack that the IoT devices made like the negation of service, right, we ‑‑ we never thought, oh, this kind of device, like for one Euro we can get.  It kind of led the server down, right?

So these kind of new business things or business models or operation of function brings some kind of problems or trends that we have to consider and address, right?  So therefore, we can envision these kind of threads.  Okay?

>> MODERATOR: It was an interesting question.  Who are the questions addressed to?  Well, for example, what we have tried to do, we tried to get consumer organizations in this session.  Plainly and possible because we didn't know what the IGF was.  Oh, this is a very technical topic.  What where have we got to do it with?  We don't have the money to travel.  The I think the consumer organizations would have this role with these sort of discussions but this has to be a significant reach out towards them to make sure that they are ‑‑ they are here in 2019, and here being Berlin, of course.

But I could probably go for other organizations as well that you would like to interact.  I will take one more question and then we got final session of the final part of this session.

>> AUDIENCE MEMBER: Thank you.  So I'm Ethan.  I'm a youth IGF fellow.  So I know we have talked a lot about consolidation this session and I would be ‑‑ it would be very bad of me not to continue that.  So I think that this is going to be one of the biggest changes to the Internet architecture and it's a small players snowball effect.  As we have gone and on, the consolidation is more intense.

Standards, Internet standards are increasingly, I think, either being directly being taken from the ‑‑ these consolidated private companies or they are being de facto invalidated by them.  So, for example, for both of those, so HTTP 2 with the push, I noted before that Google same out with speedy, which was a standard that did quite a lot of the same things and then let's just keep the same standard.  So when the IETF came out this was a big debate about whether it includes TLS in the stack and the answer was no, but nowadays to de facto you, HTTP, you have to use TLS because they came together and said you know what, we are going to decide that TLS will be mandatory.

My overarching wonder with this, in the future are we going to see more and more these consolidated players being able exert what they want to on to the Internet community as a whole?

>> AUDIENCE MEMBER: My name is John.  I'm coming from civil society, the IO foundation.  I got basically two questions.  They may not need an answer, but at least I wanted to throw in.  How do government feel, how we try or we testing them and how do they feel about increasing encryption communications if we have this tendency of trying to encrypt even the headers the communication?  Are we going to be sending in two applications and do we suspect that we will fall into supply sort of compromise situation eventually where they will ask, you know, by law to have back doors and whatnot?

And the second question is how do we face a problem that we don't have control over the hardware over which those protocols is being run?  Thank you.

>> ALISSA COOPER: I will go first.  So I find this narrative about standards to be really fascinating because I started participating in standards ten years ago and I remember when I first came into it, somebody told me ‑‑ was talking to me about the routing protocols which I didn't know anything about.  Cisco comes in with what they want to do and juniper, comes in with what they want to do and we let them duke it out.  There's not historically very many vendors in the routing space.  I have no idea whether it's true prior to that.  I always find it interesting when people say, oh, no, there's such a small number of players and you have these four or five browser vendors and if they decide they want to do something, then that's how it is for the web.  Then four or five is a lot more than two.  I don't know.  It depends how you look at it, but even there, I don't fully buy the narrative because I think if you look at what happened to HTTP 2, yes, there was speedy and speedy came in and it got changed it.

Wasn't a rubber stamping effort and this' a huge amount of involvement from the server side and the mobile space, who were deeply, deeply involved.  Like building implementations alongside the standardization process and running interopt tests and trying to make sure that when we fix these things in the standard, it will provide the features.  Now as tradition for consensus process, it's true that when ‑‑ you know, if the browsers get together and they decide if they will support the feature or not support the feature, it's definitional for what exists on the web.  We try to set the playing field and not force that to happen, necessarily and there's plenty of cases where that doesn't happen.

The same thing with QUIC and there's another thing called GQUIC.  Google who owns the client side on Android and Chrome and all the other properties and it's changed dramatically in process of standardization because the whole point of bringing it into a standards organization like the IETF was to get outside input.  I think it is a vibrant space in terms of input.

And it might be useful to find of compare it historically and see if it's better or worse rather than kind of judge it right now.

I think on the encryption question, governments are not monolithic and so I think if you ask a cybersecurity agency or a Homeland Security agency, or an intelligence agency, how they view the encryption trend on the Internet, you may get a different answer than if you ask a law enforcement agency or potentially a legislator.  You know, people just have different, they are oriented differently towards what their view of the problem is and it's certainly the case that more encryption in the transmission as we have been talking about all day, clangs the dynamic in terms of where access to information and clear text can be obtained.  If you are accustomed to getting certain information, now you may have to go to the endpoints to get it, and that's a shift but there's not a uniform view on this, based on where you set in government.

I have completely forgot the last question.

>> JARI ARKKO: I think I will.  So on the standardization question, I think like we should not look into this as like, you know, can we prevent the big guys from standardizing things because those things like the encryption thing, it's a really useful feature and it improves the performance and the security.  That's not what we should be trying to block.  So resources.  Come up with technology and I think she's right that at the IETF, there's at least for this cases like TLS or quick and the HTTP 2 there's' huge amount of people involved in the effort and not just some of the guys who came up with the basics.

Just to take a silly example, the doe thing and that's easy to explain example, but, you know, maybe like there are tons of other examples that we should be talking about.  I will take one example.  It doesn't seem like an impossible task wearing my researcher hat that you could diffuse the information, obfuscate the information when you send something to someone and not create a huge data store, like who asked for what.  I think that's possible, rather than block somebody from doing doe.

And then one comment on the inception thing, of course the governments care.  I forget to say, one thing I wanted to add to what Alissa was saying.  We had this big change where we went from 30 to 50% and my numbers are 20 to 80% but there's separate change brought on by I guess dough and similar techniques and then something called encrypted SNI.  It's a funny little thing inside TLS, and they prevent the information about where is this connection going to?  And that's going to have further impacts.  We should not think that oh, this encryption already happened and now we have corrupted the Internet.  That's not entirely true but it may actually be true in two or three years.

>> MODERATOR: Thank you.  We are moving into the final part of this session, just to come up with recommendations on how to discuss a situation like this.  We have seen, there's lots of different sort of interests and different questions coming to the technical community.  I think that's the right thing that's coming out of this session.

How can we actually make sure that policymakers are aware of the work that's going on and that they actually make decisions based on that work?  How can he with make sure that consumer organizations when they test products are aware of the possibilities that are being offered from the technical community?  How do politicians make decisions that are being put to them but they know what is behind those decisions and how do we do that sort of reach out and where do we start?  I think people nodding yes.

What are the recommendations for the next steps?  Say we are better win what sort of steps should we have then to continue this debate?  And I will start with what you have learned and then move to the room and maybe we can go over five minutes because there's nobody coming into the room at 1320.  So what would be the next step?

>> ALISSA COOPER: I think a session like this is useful because you get a particular variety of people in the room here, but I don't really view this as a once a year kind of engagement and that's not how we view it in the IETF.  We have a bunch of initiatives to expose our work to the broader world and bringing people into our fold.  The Internet Society hosts a policy guest program, led by the fearless Constanious over here.  They come three times a year and they get a crash course on all things IETF, and many of the trends we have been talking about today are topics of discussion there.

So that's ‑‑ that's a way not to, you know, assume that policymakers will become dedicated participants in the IETF community but for them to be able to go back to their home countries and home governments and spread the word about what it is that we are doing and what the trends are.

We have some more informal outreach, like the operator communities and research community, who we bring in in different ways for different types of workshops so people can get up to speed and learn more about what they do.

The consumer organizations is an interesting one.  It's not one that the IETF really directly engages with very much, in part because we sort of put the standards out there and then, you know, hope that they get deployed and implemented and a think a lot of consumer organizations are on the far end of that doing certifications and that's a space like other standard organizations which do their own certification programs and testing of implementations, that's not something that we have traditionally done in the IETF.  So that's a bit of a gap.

>> AUDIENCE MEMBER: Thanks very much, Taylor Bentley from the government of Canada.  This group therapy has helped.

>> We are here to provide.

(Laughter)

>> AUDIENCE MEMBER: The key is empathy, I'm sorry that the fellow from the Swiss IGF left because we ‑‑ it feels fast when we don't know what's going on.

And you can't trust someone you have never met or it's very difficult to.  So it's, you know, keeping that conversation going and keeping that familiarity and that empathy strong.

Now this is where we get consolidation and convergence to work for us, because thankfully there aren't many competing standards organizations or ‑‑ well, not standards, but direct competitors with the IETF, sorry, actually, there are.

But we get that consolidation to work by supporting people to come in.  We grow our networks and we make that as effective and robust and I guess the thing as big as possible, right?

Google supports a lot of these initiatives and, you know, they all have community‑building budgets.  So we get that to work for us.  The difficulty, of course is making sure that we are all writing the same narrative and speaking the same language and I was really struck by what you are saying that we have been doing this for a long time and we are just kind of getting our groove, right?  We are kind.  Making it work and we are still doing that with collaboration and empathy.  So that's going to take some time but I think we are find our groove eventually.  Thank you.

>> MODERATOR: Would you like to add something from a political point of view?  A politician's point of view?

>> AUDIENCE MEMBER: Yes.  Thank you for asking because in the beginning you asked are there technicians here and government.  You didn't ask are there politicians here, right?

So there are two of us.  Great.  Good.  Yeah, I think this is a very important subject for politicians, actually, because I would like to at this at the same time that we are looking at the climate change problem, and now we are in the middle of a lot of problems and we have to solve that.  The same thing could have to do if we don't do the right thing on the Internet.  That's why we are all talking here.

So I also think there's a responsibility of politicians but not without the IETF doing way they do their job.  We do it in consensus and there's a problem with the fact that we don't have all parties at the table.  I think that's something where politicians can help by giving funding and providing whatever as needed for you to do your job.

For that, they need to understand what is their job and why is it important.  And as soon as it comes it technical things that politicians tend to go, okay, it's way too difficult, which is really there strange because we don't say the same things the noise an airplane makes.  At least in my country.  We know about the bells and everything that happens or we know about the different of concrete we have or buildings.  But when it comes to net we go, like, what's this?

So Wout, he would like to organize a meeting on this parliament on this subject and try to get some politicians there and we'll get them to understand what it is that the IETF is doing and why is it important and why they should be involved in one way or another.  That would be my offer to you and I hope that maybe some of our colleagues of me and other parliaments can pick this up.

There's another organization eye thinking of the Inter‑Parliamentarian Union, IPU who has the parliamentarians all over the world in them.  They sometimes do some things with tech but that's more about fake news and stuff like this, but this could be an item there too and I could see if I could get it in.

So, yeah.

>> AUDIENCE MEMBER: Aisle Julie ward.  I'm a member of the European parliament.  So he just want to back up what you say, sorry we never met before.  We have met before.  I forgot, sorry.  There's a really great organization called parliamentarians for global action.  It's a membership organization and it works on issues of human rights and democracy.  So they ‑‑ and it's a macro way, and it's been very effective in dealing with some ‑‑ sorry, it really focuses and targets on specific issues.

So certainly in the European parliament, we have a small caucus of people, who are members of PGA, but we have been able to be very effective when with ways of getting people on board were not.  So I just ‑‑ I can give you introduction to the PGA Secretariat.  I think they may be open to some new projects.

I'm sorry I wasn't here for the whole discussion, but when I came, in I heard somebody saying oh, everybody is connected.  Everybody can get online.  Can I tell you that's not true?  Okay?  There are many people would are still not connected.  It's still not ‑‑ it's still not a level playing field for everybody.  In many remote areas, people don't have access.  They don't have access for a lot of different reasons, and so there's a massive digital divide still.

And also people with disabilities, with, you know, they also are not always in' situation where they are given equal access and some of the best workshops that happen in the IGF community.  Because they are so shut out, they are the innovators and doing amazing things that all of us benefit from.

I don't see any in the room.  They had a fantastic event last night, called discotheque.  I learned more from their communities in terms of getting better legislation in the European Parliament than if I just talked to you guys.

Now I have to go to youth IGF, which is my other big thing.  Thank you.

>> MODERATOR: Thank you.  Any other suggestions like we just heard and the way that we can reach out to each other?  Deep silence.

Last words from ISOC?

>> AUDIENCE MEMBER: Sorry, just a plus one, the diversity issue.  Especially like the institutional barriers that exist that make collaboration more difficult.  Harassment, all of these things they need to be addressed if they don't address them, that's a poison that nobody will want to talk to us.  Thanks.

>> It looks like that people are hungry.  The interest net society partially exists to bring these conversations together.  So I really courage people to make sure that you hold us to it and make us do our job because that's what we are here for.  Thank you.

>> MODERATOR: Okay.  Then I thank you all for being in this room.  It was a lot fuller when we started.  But this' a lot of interest in this topic.  And I think that that is the main lesson we have learned but we also learned there's an interest to reach out to each other and for starting that, I would like to thank, all of my panelists and Internet Society for making this and Paula for doing the online.  And the scribe are doing the hard work somewhere in the world.

Thank you very much.