These are unedited transcripts and may contain errors.

Cooperation Working Group

15 May, 2014, at 11 a.m.:

MARIA HALL: Hello, everybody. It's actually 11:00 sharp so I think we can
start our first session of the Cooperation Working Group. Thank you so much
for coming here to our session and I am Maria hall, I am the CEO for the
Swedish university network and I am one of the co?chairs for Cooperation
Working Group. I would like to introduce Meredith and which is also
co?chairs. It's been a pleasure, it's been a great pleasure to work with
Meredith and Al an and finally the agendas for the two cooperation Working
Groups we are going to have today so it's going to be a lot of good
discussions and hopefully very interesting topics that we will bring up.
Alan and Meredith maybe you would like to say a couple of words about
yourself to introduce you.

Meredith: It's a pleasure to be here, thank you for having us. And to Alan
and Maria who have done a bunch of work over the last number of months since
RIPE to put this agenda together. My day job is a programme manager at
Google research and I focus on network measurement and OpenSource usable
security and a number of other things that all sort of have their share in
common, a kind of interest in the ways in which political and social issues
intersect with technological decisions and determinations and I think that
is ?? that is what my co?chairs and I have been working to make this group
reflect, a discussion of the ways in which these two areas over intersect,
and ways in which we can make that something that is profitable and
interesting for the RIPE community. Soil leave it there. Alan.

Alan: Thank you. I don't know how you pronounce it in English, just call
me Alan. Love to be here, great working the three of us, we have been
working really hard on developing a programme which will suit, we hope, the
needs of this community. It's the first time I think we have two sessions
at RIPE, so for the next 25 years, I hope we can expand on that one. In
terms of background, I am both technical and I have worked in government,
some call it the dark side; I just call it the other side. So I have worked
for Cisco. I used to know to you to programme BGP a long time ago, I have
worked for the European Commission and I have actually even doubled with bar
acfor those who were at connect BoF this morning.

MARIA HALL: Thank you so much. We have a couple of formal things just to
go through before we start the session, with discussions and so on. I will
give the floor to Chris, who will have a tiny couple of things of
housekeeping. Chris.

That was one of the housekeeping things to get it to work. Thank you for
doing that. While that is going on, I would like to finalise the minutes
from the last Cooperation Working Group RIPE at 67, so can we have approval
on that one. Nobody against. Thank you.

And of course, you see the agenda or you should have seen the agendas, I
would like to finalise that one as well even don't we don't see it right
now. Do we have any other comments or the agenda? No. Chris, a couple of
words on the housekeeping. No, we don't have to do that OK. I will leave
the floor to Meredith who will take care of the first slot of this session,
so the floors is yours, Meredith.

Meredith: First we are going to be talking about the subject of content
blocking and we have three really interesting presentations we are going to
hear from Olaf, who is going to summarise and expand on IAB paper that has
enumerated methods of content blocking, this is a technical overview, how is
this done and what is the impact on the network. We are going to hear from
two really interesting projects one of which is looking to circumvent
censorship in network infrastructure. The next is trying to do another kind
of circumvention which is sort of route around circum ?? around censorship
and measure what is being sensored in certain regions and I think this is a
really cool example of where sort of political and social mandates meet sort
of technological implementations and sort of what is the ?? what is are the
impacts of those things overall on the networks that we use, that we run,
that we rely on and I would love to see kind of a spirited debate around
this, right, what are we looking at and trying /O achieve and what are the
goals and costs of these things because this is where the co?op Working
Group could add a lot of value to this /KHAOUPBT and this community can add
a lot of value to the Internet as we know it. I will leave it to Olaf to
take it away with the first presentation. These are quick, it's ten minutes
and five for questions.

OLAF KOLKMAN: That is going to be an extreme challenge, so to speak. So I
am doing this work with Pier Carlo Chiodi, he cannot be here, so he reached
out for somebody to channel his presentation and I stepped up because this
work that he wrote the paper on, that you can find it is work in ?? in
action, so to speak, can be found on this blog ?? resonates a lot with work
I have been doing within the context of an IAB draft, together with Mr.
Cooper and Barns over here. And it also resonates, this material, with
Stefan's presentation in the DNS Working Group.

What I am trying to achieve here is give an overview of the content of those
documents. I think that in ten minutes it might be hard to go into all the
technical details, but at least give you a feel of what is in these
documents and what is the sort of general gist of these documents.

It's a bit of a challenge so I will go ahead.

First, how the Internet works. Well, as most of the people in this room
will know, we have packets flowing from one end of the network to the other
and shows are shipped by ISPs. On the edges of our big Internet we have the
content providers, website operators are people that provide content to the
web on their own behalf. And of course, things work over the Net and they
go to the transit providers and these, you know, entities can all switch

Now, all devices on the Internet, they exchange packets, packets from
end?to?end and carry information. The network is neutral to content, I
think that is the most important lesson. Content is generated on the edges
as soon as it is removed from those edges the network actually doesn't know
any more.

So, in order to find content you usually use /SKRAOEUPers that contain DNS
address and name of where you can find that content. The DNS is sort of the
most general place where you do generaled view of finding information on the
Internet. (Rendezvous) so the DNS is not the way that information is
traversed but it's the way to find and locate information or at least one
step of that information.

And the DNS is a hierarchical model with lots of players and entities that
are distributed over the network and are not tied to specific legislative
boundaries, so to speak.

So content blocking. Why do folk turn to content blocking? Well, there is
very bona fide reasons of blocking illegal content. Now the concept of
illegality is, of course, might be regionally bound but there is some things
we all think of universally not really accepted, child abusers is one of
those, but with unauthorised gaming and gambling might be illegal in one
region and frowned upon in another. I make distinction between illegal and
illicit, you can go further down and start to frown your eyebrows even more,
if it comes to blocking content to suppress democratic debate.

The best way to block illegal content or to block content if you want to
block content regardless ?? and now, I am stepping away of making a value
judgement about what is to be blocked and what is not. That is separate
from the debate. But suppose that an entity needs to block content for one
reason and let's suppose that is because of legal reasons that are accepted
by that community, suppose that content needs to be blocked but the content
itself doesn't live in the areas to which the legislation applies, what can
you do in those cases? The best way to remove content is actually to go to
the content provider and say, will you please remove this, this is illegal,
this is against the law. If can you not do that, you have to revert to
different methods.

Now, what are the control points to get to block content? Well, as I said,
the best way, at the end point, at the place where the content originates.
Because then, you can be extremely precise in addressing that content; like,
in the top half corner of this page, the left top, there is a URL, and the
URL consists out of a protocol field, very specific protocol field, it has a
domain name and then a very detailed resource, namely a page on a web page.
But if you don't have access to that you cannot block that specific content
at the end point and you have to resort to the network, then you can two do
things: Either block the content by blocking the stream of packets or by
blocking the rendezvous mechanism.

If you block the rendezvous mechanism, you can do that in several places,
the rendezvous mechanism being the DNS has a bunch of actors. There is the
authoritative name servers on the right?hand side of the space, which serve
content, distribute it all over the world; and there is the recursive name
servers that usually live within close to the end user, so usually within
the jurisdiction, so to speak.

To do that you usually run into collateral damage, overblocking, you block
people that have legitimate reasons and are legitimately using that content
that might not be able to get to that content. But also, you might be
toying with the sort of trust in the Internet as a whole, if you start to
block and our friend Stefan gave an example of that, if you start to block
content, then DNSSEC ?? based on the DNS, then DNSSEC validation might fail
and people who want to get to that content might run around installing
plug?ins disabling DNSSEC and in the long?term I think that is bad for the
Internet, you disable trust mechanisms that we need to rely on for our
businesses. And that is the sort of collateral damage that you need to
weigh off in your decision about blocking content and allowing the Internet
to be open.

Now, I saw a five?minute sign so I cannot go into all these examples that we
have. But in the documents that I referred to in the beginning, we tried to
make an analysis: If you apply a certain methodology, then what is the
scope of that methodology? How many ?? which users do you actually impact?
Can you be granular in your decision? Can you actually target a very
specific piece of content or a very specific user to block the content from?
For instance, can you block pornography from minors? That could be a
question that you want to ask. The efficiency ?? efficacy ?? I keep messing
up that word because to me it's not a natural word being a non?native word
but it's to evaluate how difficult it is for users to avoid the blocking
measure. Remember that picture of 888 on the walls of Turkish buildings
whereby people said, you know, your recursive name server, your DNS is
blocked, you can go elsewhere, that talks to the efficacy of the thing.

The security, what is the impact of the blocking mechanism to security of
the general Internet? And then of course there is the feasibility. How
much does it cost. Now, I realise that I am now at slide 13 of 36 and I
still have two minutes left. So, I am not going to go through all these
detailed examples. But what the documents does and what the slide set does
is look at various parts and determine what all these scope, efficacy,
feasibility, security, issues, are.

DNS registries. Those are players within this DNS world. Authoritative
servers themselves. Other places where you can block are recursive name
servers, and there is examples in the documents and in the slides of how do
users work around it in an easy way.

Blocking on IP, for instance, is a way. The packet inspection is a way,
which is very expensive and hardly feasible. The set take away or the set
take away is that blocking is a trade?off of very, very many arguments and
circumstances. If you look at the Internet architecture, blocking is best
done at the end point; that means if you have collaboration with the users,
then you can block easily. Take a virus filters on your general purpose
computer or adult content blocking that can be turned off by ?? on and off
by parents on computers, those are very efficient ways of blocking that have
a very limited scope, but as soon as you have to do blocking in a network,
you have to make all these trade?offs, and these trade?offs go into really
fundamental questions, and now, the stop sign has arrived. So I am going to
round off because I believe that there will be a few other presentations in
the same content.

Questions and answers. Or is it handier to do that at the end because this
seems to be a block of sort of similar things. Unless there is a clear
clarification or something.

AUDIENCE SPEAKER: May I? Lars. I want to make a small addition which may
be part of the presentation that we didn't see. Which is that some of these
methods are for good intended things but they still have collateral damage.


LARS?JOHAN LIMAN: For instance, hotel network they hijack all the traffic,
the hotel income in the rooms. I can't do DNSSEC, I can't validate
collateral damage. There was one other thing but I forgot that.

OLAF KOLKMAN: No, the problem; you cannot make (problem is) if you look at
the technical things, making the sort of ethical judgement about why things
are blocked, we try to keep away from that a bit.

LARS?JOHAN LIMAN: The second thing is when it's obviously and clearly
stated that it's happen, it's kind of better. When it happens just behind
the curtain, that is worse.

OLAF KOLKMAN: I would ?? we cannot ?? we can block these microphones.

AUDIENCE SPEAKER: Andre, Internet Society. So a few years ago when there
was a debate about ?? we prepared a paper on content blocking and our view,
well, it's of course kind of simpler and stronger to say do not do blocking
but in many cases it's not possible and also without judging the
requirements, why would you need to do blocking? We just looked at the
hidden costs, right, I think I liked the breakdown of impact efficacy and
other stuff and you mentioned security but it's not only security; there may
be a wider ranging impacts and hidden costs that blocking introduces. And I
think for policy makers it's also important thing to see those when they are
making these policy decision and that may not be immediately obvious. So
they look at the immediate effects, they analyse this but the cause and
negative impacts are often long?term and much more difficult to kind of
mitigate and work back. So that was the ??

OLAF KOLKMAN: One of the examples that I didn't get into that pier had in
the slide deck is if it is the case that you cannot get to a ?? to content
that you as a user would like to get to, you will do basically everything to
get to that content, and that might cause you, as a user that wants to get
to that content, to install scripts and work arounds, and that, in the end,
has, again, might create backward doors into computers and raise the viral
footprint on end machines, and those are things that are very hard to put
your finger on, but they are a significant long?term effect.

AUDIENCE SPEAKER: My question is not only for you but for the full room. I
came from country of content block in France and being used by government.
Please raise your hands, I want to see percentage if content blocking is
active in your country. OK. And who thinks that content blocking is abused
by government in your country? On your feelings, on your feelings. So you
think that Netherlands is blocking, OK, thank you. And maxima is thinking
that content from Russia is not abused by government. OK. Thank you very

AUDIENCE SPEAKER: Richard Barns. The backing up a couple of points to the
notion that the hotel network here is doing interception of blocking. I
think one of the nice things about this debate it harks back to some
fundamental Prins of Internet design. A lot of this rests on the end?to?end
principle, the more stuff you insert in the middle of the network the more
your blocking strategies rely on happening in the middle of the network, the
more stuff you are going to break and you are more brittle and
circumventable your strategy is going to be. I think this is one of the
nice things. These captive portals in the hotel network are an example of
how the end?to?end principle matters for stability and security, it breaks
the one security model and all that, so the end?to?end principle is a really
nice starting point for a lot of these discussions.

JIM REID: Speaking slowly for myself. There is probably another one of
the slides you glossed over, I think there is the question of collateral
damage and also ex ternalities so if someone takes a decision to block
access to this IP address because its hosting illegal content for some
definition of illegal content it blocks all access to that particular
address or perhaps there is other stuff hosted in that address that is not
to do with website and we find the D service for important TLD goes away
because it happens to be hosted in the same box or /24.

OLAF KOLKMAN: Yes, even if you a block a very specific service, then you
might be overblocking, suppose you block Twitter for very specific content
then all the fine people that would like to see the RIPE 68 feed will not
see it and they will miss out, I tell you.

JIM REID: Just again a personal anecdote. I was asked to do expert witness
report to do with blocking intellectual property stuff and one of the
questions ? we were asked that the quote we were asked ?? what else would be
damaged if we switched off access to port 80 for this particular IP address?
And I said I don't know, we will find that out by talking to the web master
for the IP address and that is the guy hosting stuff you want to switch off.
I don't think he is going to cooperate.

Meredith: Thank you very much for that, Olaf. I think for everyone here
the slides are going to be on the website and linked to the IAB document and
pier's document so this is a good resource for for you trying to explain the
issues here, the technology is agnostic, blocking child pornography uses
similar methods as blocking political dissent and what are the costs to the
network and how do you weigh those when making decisions.

Thank you so much for that. Now we are going to turn to Eric from
University of Michigan and he is going to present ?? you already see some of
the slippage in term, there is content blocking and anticensorship and here
we are talking effectively about the same thing. He is going to talk about
a proposal to avoid content blocking in network infrastructure. So thank
you, Eric.

ERIC WUSTROW: Thanks, Meredith. And thanks Olaf for the review of
censorship techniques.

So, I am going to be talk about anticensorship sort of broadly and some
tools that we can use in ISPs to basically circumvent sense ship and I am
going to start by pointing out as we have heard before, this is a global
problem, that this happens in a lot of different countries and for a lot of
different reasons. And we talked about some of the other examples but there
is some extreme ones that you have probably heard of, China blocks Facebook
and Twitter and YouTube explicitly, you cannot get to them, and Iran also
blocks those as well, they also block political sites, including things
against the government or religious sites that are in disagreement with the
people in power. And in Iran's case they also block again lesbian dating
sites because people in power think that is against their culture.

This map is specifically not meant to be a defin I have list of who is sense
erring and who is not and how much, it's more a compilation of several
different sources that show there is a pretty systemic problem around the
world. If you sum up what a lot of these countries are doing, they fall
into at least a lot of them do, a large group that are doing similar things.
And this threat model is that we can assume that clients inside a censored
network, for example, in China or Iran are subject to the whims of that
particular country's policies. But the centre doesn't work things outside
of the network or the users computers, that is not always true but more
often than not. The censors tend to block using blacklistings, they don't
say these are the ones you are allowed to use and go to them. Instead they
compile a list of offensive websites or ones they don't want people to visit
and block them according to this blacklist using IP blocking or DNS
filtering or depacket inspection.

And for the unblocked websites these censors allow https connections to
these sites which is important for our proxy, as we will see in a bit.

But note if you started to run a proxy, for example, at one of these https
unblocked sites, like this, the censor could discover it and
add that to their blacklist and this quickly becomes a cat and mouse game
between the users and censors where trying to discover these new resources
while the censor is trying to discover them so it can block them.

So, we wanted to ask the question: What if we could make this much more
difficult for the censor, on all or nothing thing for a to block particular
websites, have to decide between users able to get to all of the websites,
including the ones they don't want to, or not being able to get to any of
them externally. An idea we came across a couple of years ago along with my
co?author, Scott, Ian and my advisor, is telex. The idea is the user is
trying to get to, a website censored by the government, in this
case we can see the user trying to make a request and it's blocked by the
censor. We have going to have the user install a telex client, from
intermittently available proxy or a trusted friend and the user is going to
send their blocked request through this proxy which is going to make an
innocuous https connection to unblocked site, and of course
the censor will allow this because is not hosting any
objectionable content.

And inside this connection the user is going to place the telex client is
going to place an invisible tag and this is constructed such that anyone can
create these from a public key but only the holder of a private key can
these these tags are there. To everybody else this looks like a normal
innocuous http connection. And along the path this takes out of the
censor's network in a friendly ISP we have hosted a telex station that can
observe these packets as they go past, and inside this telex station we have
the private key that can allow it to see that these tags are there and allow
it to decrypt and obtain a short shared secret with the telex client and
this allows the telex station to decrypt, the true request, that the client
has made through this connection, in this case to and can forward
this on to a local proxy server get the response and reply to the user as if
it came from And it's important to note that this
connection to the censor looks indistinguishable from a normal connection to
https NotBlocked and they have to make a choice of whether they want to
block all these websites that could be potentially be these
or allow to access this content through this proxy.

So we implemented in this in a prototype and deployed it as a small test and
we have a couple of websites that are sort of behind this test and we tried
to approach some ISPs and said, you know, would you be willing to work with
us and deploy this? And the response was, a lot of these people were very
interested, and said yes we are they ?? freedom is important and censorship
is important and we believe what you are doing. I am sorry we can't do this
and the reason was because telex requires, along with other work like
Cerapede and decoy routing, similar works in the similar area and about same
time as ours, all require in?line blocking that can selectively block those
at some point, when you say that is something I want to proxy for. And the
other thing to specific to Telex we don't work with assymetric, we require
to see ?? we can see both sides of the connection. We came back to the
drawing board and said can we do better and make a version of Telex that
doesn't require this inline blocking that works asymmetric routes, in other
words can we have Telex that works with just a passtive tap and the answer
is we were able to do that with some trade?offs which I will get into a bit
but just to sort of briefly go over the technical details of how we are
doing this, now we are having the client establish a normal TLS connection
with the serve. There is no tag in this part of this, this is the normal
TLS handshake. And the client then makes a request, a very simple request,
there is two special things about this, however: One, this request in the
cipher text contains that invisible /TARBGS and two, this request is
incomplete, a serve would make the rest of your request, it doesn't contain
the two back slash ends that the server is waiting for. It's going to cause
the server to wait, the server will send a TCP acknowledgement for this
data, see Wednesday N Y ?? can extract that tag and extract the shared
secret between the client and the server and respond as if it were the serve
saying yes, I am here, I am Telex, feel free to use this as a proxy and the
client is going to acknowledge this because this is data, at TCP level and
that is going to reach the serve, because we don't have any blocking
infrastructure, it's all a passive tap but the server is going to ignore
this because this is an acknowledgement number because not what the serve
expects because this is not data that the sent has sent it's going to drop
this, this is for the TCP spec as well as the implementation and Linux does
this. And the user, the client here can send additional data that the proxy
can see that will also be ignored by the serve and the ISP proxy can
continue to respond back to the user and give them their censored content
and act as proxy in this manner. There is no inline blocking required here,
this is only a passive tap. This also works with asymmetric flows. The
disadvantages, the censor can use active probes to check if a particular
flow is a Telex connection or is being used to proxy. We have some active
defences that can be used in those cases if we can observe those probes and
we can sort of respond in ways that make it difficult or more difficult for
the censor to be able to distinguish between Telex and non?Telex flows and I
would be happy to talk more off?line about those.

Where are we looking to in the future: For ISPs that are willing to help
and they can help: One of the most valuable things we have gotten from
people, engineers in particular is the technical feedback of what works and
what doesn't and what actually makes sense to be deployed in a network.
Even the no answers of no this won't work, asking why has been really
informative for us. And on top of that if we have a scheme that looks to
you as something that actually seems kind of reasonable, we'd be more than
happy to talk to you about actually deploying a prototype deployment to
actually test this out and see exactly how feasible this is.

We have some other ideas for future work as well but I wanted to /SKWR*S
focus on the ISP ability to collaborate in this area.

So, with that, I guess I will conclude and I want to thank my Co. authors
for their help in this work and I would be happy to answer any questions.

AUDIENCE SPEAKER: Robert Kisteleki, security interested guy. I wonder if
the bottleneck with this approach is going to be key distribution or not,
because the way I understand, you need to generate public private key parts
and just give it to people, so they need to agree, this is my public, this
is your private. And that kind of tells me that the bad guys can also have
some keys, and they will have some keys. And if they can pretend to be the
good guys because you don't know any better, you might make it worse for the
client, not better.

ERIC WUSTROW: Yes, that is definitely true and that is definitely we talk
about in the Telex paper to some extent is how can we protect against the
censor being able to distribute, for example, bad clients, that contain the
bad public keys, that the censor maintains a private key too and of this
course is a very difficult problem, we can do all the same things we do for
other RPKI things and trusted third parties. I think the best answer we
have so far is to have a centralised in a sense Telex entity that is
globally known and visible. One thing that we have noticed in a lot of
these censorship locations is that it's actually fairly easy to get
broadcast information into these networks, it's hard to get specific
browsing information, low latency at that time. It's fairly easy to get ??
to broadcast to the country using either radio or wi?fi or just even over a
long period of time, this is the circuits this is the thing that you should
trust. It's not to to say that that is completely solved but this is ??
this is the sort of thing that we are thinking along.

AUDIENCE SPEAKER: Key management is hard and I think your success depends
on it, so get it right.

ERIC WUSTROW: Thank you. I think key management is hard pretty much
everywhere and everyone's success depends on key management everywhere and I
think Telex is no exception. So thank you.

MEREDITH: Thank you, Eric. I am going now introduce Walid Al?Saqaf who is
going to talk about circumvention technology and this takes a much different

WALID AL?SAQAF: I have my own clock. I am actually from Yemen, so I think
I am not really in my own crowd here in the Arab world, out of place. I am
thinking in terms of freedom levels. We have suffered a lot during the Arab
spring so this is really an interesting place to be in because mainly I come
from a desire to liberate Arab people from oppression on the Internet. So
this is where I stand, it's a bit of a different context. So take it from
me now that illegitimate censorship is what I'll be talking about,
censorship of people speak out their opinion, if we take that as the first
assumption we can move forward with this.

Basically, the idea behind it became when I myself had my website blocked, was accessible in Yemen and it was blocked in 2007. And
then I realised perhaps I am not the only one who had his website blocked.
I was a media scholar so, I attempted to do two things in my own work. I
would try to understand what is being blocked around the world and that is
why I developed this idea of mapping URL filtering, trying to see where
websites are being blocked around the world, through crowd sourcing so to
allow people to report from their spot, wherever they are, if a website or
URL is inaccessible, software is named Alkasir, and it's the Arabic word for
circumventer if you're wondering. The ideas was allowing people to
themselves to report, that gives me an indication of what is more
interesting for them. To access.

So, also it helps understand where the URL is blocked, whether it's at the
ISP level, AS level or maybe within a particular Internet cafe, a library,
so that would help a lot in understanding where censorship is happening.

And then the idea also is important in terms of measuring whether there is a
government or let's say a political events happening at the time of blocking
so because once a week later the same URL would be reported again as
unblocked so it gives us some sort of longitudinal understanding of

Then, I obviously people want to be encouraged to report unless there is
some sort of carrot and the carrot was that you can access the blocked
website; it's more of a win?win station. I do my work as a research and
developer and once you report this website being blocked, you get access to
it. So it utilises what I call split tunneling, it's a merely a SOC proxy
that you is similar to TORE, the idea behind it is that there is a central
server, my own server, I did it all out of my own pocket. You can tell when
you are motivated you can spend a lot and my wife didn't like it, though.
So I allowed people to use my own SOC proxy. I gave them the user agreement
to look at and read and then I allowed them to only access the websites that
are blocked and that have been reported to be blocked. In that way, I
actually saved the bandwidth of my proxy server. I cannot use the same
proxy for all traffic, otherwise it will have been really a big financial
burden. And furthermore it allows me to understand indeed what are the,
let's say, accesses like and do people access Facebook more often or not if
it's blocked and what are the URLs that are access the most.

So, I ended up having this process, mainly for, I called it crowd sourcing
because it allows people across the world to Tuesday and the way it works is
that the software first verifies if a URL is really blocked because it
compares a version from the country where the person is accessing it, to a
version that is free, let's say accessible in the US or elsewhere and it
understands from the response headers what has been happening and there are
people moderating, making sure that the URL is indeed blocked through
comparing the headers. The only difference here is that I had to not allow
pornography to be accessed in the Arab world, because otherwise my server
would have been dead because most of the porn websites are blocked anyway,
so it would have been a big burden on me to the moderator's role to make
sure the metadata are not really porn related. And some people have not
forgiven me for this.

But then the idea behind it is that it helps through the data that I get to
understand where and what is being blocked around the world, as well as
giving people the ability to access content. And I was supposed to give a
demo but time doesn't allow. Nonetheless, there are different ways in which
I discover blocking happening, through sometimes it's transparent, you see
403 which is forbidden page. Sometimes it's not not. Sometimes it gives
header response, which is regular but totally different content. Sometimes
it checks and looks into the content doing really substantial data packet
inspection. And I am not sure what else might be there, because this is
just the beginning.

And there are examples in Bahrain where off URL saying this is blocked but
another URL that is accessed but returns no data. So you actually see
transparency liking, sometimes they are clear and sometimes not. And I see
the benefit of this it helps maximise the user's ability to report to me in
a way that will help improve research in this area while allowing me also to
use a small server to grant as many people as possible to access blocked

It uses a very simple method, it's often the case that you have browsers
that allow you to use what we call auto proxy servers so ?? auto
configuration proxy file that allows you to see which websites are aloud
through the proxy. In my case,, that website is always
tunnelled so always going through the SOX proxy and always encrypted. And
then the based on where you are in the world you find different list, in
Iran they have hundreds of websites that are blocked; in other countries
there are not as many. And briefly, this is how it works:

Like Splitter, it splits data requests based on if it's blocked or not. And
it also makes sure that the proxy is very efficiently used, these are
examples of benefits, the whole presentation is on?line so you can look into
what benefits it may have. And this had actually been part of my research
by the way, which I have finished as a doctoral dissertation yesterday, so
it's a big day for me.

Thank you. And the data was quite fascinating because it shows governments
were quite eager to block content during peak political turmoil times when
things were really getting out of hand in terms flow of information. And
Syria had the biggest number of ?? it was 3200?plus websites during the peak
of the Arab spring. Apart from that, also, I did some research to
understand which websites ?? which circumvention tools used most often and
apparently it was the top three spots were, hot spot shield, ultraserve and
web?based proxies. Not any more these days. But this has demonstrated that
there is lack of understanding of using circumvention tools and we need to
bring more aware tonnes people about the different tools available. And
also I did some sort of survey to understand what is important in terms of
circumstance couple /SREPBGS solutions. Apparently the biggest and most
desirable thing is speed and stability, which makes sense, but also there
were ?? there was need for Moran onimity so they would like to know that no
one is watching over their shoulders when they are accessing blocked
content, as well as becoming more, let's say, blocking resistant. Often
times you have circumstance couple /SREPBGS tools that are blocked after a
while so they keep on looking for over tools. It's the way, it makes
governments quite satisfied, given that they are succeeding in preventing
circumvention pools from working. What are the future ambitions.

I would love to make this tool OpenSource, it's still in that phase. It's a
personal project so it had to work from ?? I had to work on it from scratch
but luckily I am working now with a group of people in Stockholm where I am
working on my study, and they are actually giving us the EU had given us a
grant to help expand the software and make it OpenSource and more ?
resistant but I also love to more to the mobile world. We know in the Arab
world there is interest in using mobile devices so these are going to be
critical for the success of circumventing censorship. Having to reduce
risks on users as much as possible. There is no 100 percent solution for
reducing risk but for ?? for eliminating RIS be, but it's possible to reduce
it. There should always be multiple methods, even web?based proxies not to
die. We can figure out ways to make it work and building an API to allow
research community members like yourselves to access the database that I
have gathered over the years, and categorising content is very tricky,
allowing me to know what is blocked, what is supposed to be pornography or
not for my case, if I ever continue on this path. Some people are urging me
to let go of this restriction. And there is also the initiatives that are
already being run like now, Herdit, Open Internet, and these are major
players I am trying to work with. And there is an ability to use split
tunneling for other circumvention tools to make them more efficient. That
is basically all it is. And questions are welcome.

AUDIENCE SPEAKER: Andrei. Brilliant, excellent project. And
congratulations with your doctoral. Were you able to deduct or did you make
an attempt to deduct what methods of blocking were used?

WALID AL?SAQAF: Yes, indeed, there are ways to do that. One way of
checking it is basically to see if there is a DNS, correct DNS inquiry so
you know if there is DNS leakage for example, or some sort of DNS hijacking
and after that if you see OK that is going through, but there is lass header
response so through the header response we can actually often see the
response of very prominent proxy filters such as web sense which has very
clear signature. So you can say, OK, this country using Web Sense and this
Smart Filter and so forth. We can tell if it's a URL because of a key word
that has been used, that key word is blocked because whenever you use
multiple URLs with the same key word, you keep on getting a similar
response. So it's more of trial and error, the more data we have, the more
we understand what is happening.

AUDIENCE SPEAKER: Do you have this data analysis available somewhere on
different methods used in different ??

WALID AL?SAQAF: It's not in detail but we are working on producing some
data that will be helpful.

MEREDITH: I am going to interject very quickly as someone who works in
network measurement as part of my day job, there is also a project by the
TORE team called OONI, that is designing a measurement suite to measure
methods of blocking and censorship so they have data that is available, I
think you can Google it but that would be in addition to what Walid Al?Saqaf
is providing.

AUDIENCE SPEAKER: Thank you very much for interesting report. I live in
another country, it's not an Arab world ?? it's a /KWAUT world, have some
problem with censorship. But maybe question not only to you but to all ??
there is a great community request for censorship monitoring and so on.
Maybe should it be at least task force try to be organised as community of
the this region to work together on this point because censorship monitoring
exist in Russia. We are doing this of some technologies, you are doing it
this work. This is a great place, it's much more set of freedom, let's
compare our worlds. Maybe should be done here. I know Paul doesn't like
this idea he likes to work with governments but in this case maybe we should
use this platform to work, somehow, aside of governments, do you think and
maybe some other?

WALID AL?SAQAF: Actually, I am ?? I happen to be affiliated to the Internet
Society, and remarkably with ICANN, I am an ICANN fellow and I often find
difficulty in reconciling the view you are a technical community you should
not be involved in issues of judgement, focus on what is technical and let
the civil society carry on with whatever advocacy they need. I understand
their viewpoint. It's possible that the technical work use on the technical
community level be utilised by the advocacy groups so I wouldn't mind having
some sort of bridge connecting the two but not necessarily having the
technical community do it.

AUDIENCE SPEAKER: But example, in Russia shows that the technical society
saying we are not going to do anything, let's somebody else do this,
somebody feels they are being censored, if not we, who else?

WALID AL?SAQAF: As I said, civil society groups are many, and I can connect
you to some of them as well.


So, thank you to all the presenters, that was awesome, and I guess maybe I
will speak out of turn a little bit here but I would echo that these issues
are technical and social, combined. There is no real divide. Even if you
don't think you are making a judgement through a disseat implementation its
impact shows that you made a choice of doing one thing or another and the
way that impacts people who use the Internet and access content, you know,
is just as meaningful as the way that a clear and sort of social and
prescriptive judgement may have impacted people. That is where I come from.
And thank you so much to the presenters. Are there any last questions
before we move on to the next topic area, which is IANA? No. People are
really eager to get to IANA. I know Paul is going to give a great
presentation. All right. Thank you ??

PAUL RENDEK: I want to make it clear that the last time I looked at my
contract I was not working for a government. I want to make that clear.

MEREDITH WHITTAKER: Cool. All right, I will pass it to Maria who is going
to introduce the next session. Thank you.

MARIA HALL: Thank you very much. I would like to have Paul up on stage
here to have a little presentation ?? OK, OK, first, Chris, OK. Anyway, the
next topic for the day is the IANA transition and as you might know, we had
this panel debate on Internet governance on Tuesday so me and Paul had a
tiny presentation of what it is about and what questions need to be raised
and the confusion is in this issue. So we tried to sort it out today and
hopefully give some feedback from all of you to give the RIPE NCC strong
information or feedback to have a strong voice on this issue. But first I
give the floor to Chris who wants to have some housekeeping things or
something. Whatever.

CHRIS BUCKRIDGE: Not housekeeping exactly. So I think, this IANA question
has come up already a few times this week. And we are at the beginning I
think of a process here and that process particularly in this early stage
hopefully will be primarily consisting of discussion of hearing from you,
from the community, but to kick that off, I think it's probably useful that
we provide a little bit of background information and so that is what I am
up here to do and then myself and Paul will sort of steer the, or at least
moderate the discussion later in the session.

So, starting with the background here. In March this year, the NTAA, which
is an agency of the US department of commerce, announced its intention to
transition out of its oversight role of the IANA function, so that is the
Internet assigned numbers authority functions. So those functions are,
there are a number of those functions; one of which certainly relates or
several of which relate to the distribution and registration of Internet
number resources, so IP addresses and autonomous system numbers and in that
regard, RIPE and RIPE NCC and the other RIRs are very key stakeholders in
IANA and how IANA is managed. The other IANA functions include management
of DNS root zone and protocol parameters for the IETF. And so management
and the operation of all of this essentially updating the databases, which
make up the IANA functions, is contracted out to ICANN, and it's been that
way since the late '90s when ICANN was formed. They basically provide this
service which is relatively clerical in nature and we work with ICANN in how
they do that.

So, a bit of discussion about how the structures that are in place. The
RIPE NCC and the other RIRs obtain the number resources that we distribute
to our members, to you, from a global pool and that global pool is managed
by IANA. More recently, that also involves returning some of those
addresses to IANA. So there is a two?way relationship there.

But all of this happens according to global policies which are developed by
the RIR communities, by the RIPE community and by the other RIRs. Once
these policies are agreed, they go via the NRO number council, which plays
the role of the ASO address council within the ICANN infrastructure, to
ICANN for ratification and implementation. But our relationship, our
interactions with IANA are really quite limited. This is not a day?to?day
event. As we looked back, sort of at our interactions with IANA over the
last few years, there is really only a couple each year where we go back to
say we need some more resources from you and to give these to our members.
So this is not a day?to?day activity.

I want to show you a couple of graphs here to illustrate some of this. The
first one is ?? and this is a draft and it's also not terribly ideal for use
on a slide upfront like this, it's something ICANN has been developing in
cooperation with the ISTAR organisations including the RIRs. And it shows
that the way this relationship in terms of policy making works. So policies
are made in individual RIRs, if there is determined to be a need for a
global policy which would apply to how the IANA is operated, that goes
through a global process, the orange circle in the centre here passes via
the address council to ICANN who make the implementation and that
implementation then obviously affects how those resources are distributed
back to the RIRs.

This is only talking about the number functions within IANA. At this stage,
we are not talking about the DNS or the protocol parameter side of things.

We have also been working internally on another graphic which this ?? this
graph doesn't know the NTIA which I think is interesting in terms of this
discussion and so we have tried to remedy that a little bit here. This is
very much a work in progress, we have having discussions and disagreements
and new agreements about how this should look, but I wanted to put it up
here because it shows, OK, the NTIA has oversight which essentially I guess
at the end of the day means some sort of ownership of these IANA functions
but that is contracted out to ICANN for all of the operational
responsibility of that. The policies as to how those operations are carried
outcome from the RIR communities, as I explained, and then there is an
operational relationship between IANA and the RIRs.

So the question then is what is oversight? So historically, oversight of
these functions is held with US Government, initially in the early days with
Department of Defence, that then moved to N TA and the department of
commerce in the late '90s. Generally, this has been very hands?off form of
oversight. Certainly, as I explained, there is no direct oversight role
there in the policy making process when it comes to how Internet number
resources are distributed by IANA.

But there is a very significant role of that oversight and that is
management and renewal and changing the terms of the IANA contract itself,
and so this, we have seen this over the years every time this contract is
renewed, certainly the last time in 2011, the N TA made a public call for
input from stakeholders of the IANA as to what was required in terms of the
future of these functions and so the contract with IANA was then adjusted in
line or to reflect what the feedback that they got from IANA stakeholders
and that includes the NRO. You can find the submission we made to them on
the NRO website.

So, that role of managing the contract over who runs and how they operate
the IANA functions, is a key area of the oversight and is a key area that
is, I guess, up for /KPWRABS, it's on the table, it's what we are talking
about here (grabs)

So when this announcement that. NTIA made, it was an announcement of an
intention to transition out of this oversight, but it was very much based on
a global multistakeholder discussion about this and that is as I say, what
we are kicking off here today in one of the key stakeholder groups for IANA
but it also laid down a number of requirements, which the NTIA would require
to be met if they were ?? if they were to transition out of this oversight.
And so, I have listed those here. It's support and enhance the
multistakeholder model, maintain the security, stability and resilience see
of the Internet DNS, meet the needs and expectations of services ?? that is
us I guess and maintain the openness of the Internet.

Now, certainly, a number of pretty key terms there are somewhat vague, I
think. Not least of which is multistakeholder, and certainly openness also,
but what does it mean for security, stability and resiliency the Internet
DNS. So we have some open questions.

And a starting point, I think, for any discussion of what proposal the RIPE
community might come forward with as to how this oversight should be
transitioned and who it should transition to is what do these requirements
of the NTIA mean for us, how do they need to be incorporated into any
proposal that is developed by this community, to what extent must oversight
be multistakeholder, does that mean a requirement for input from all
possible stakeholders before moving forward or are our processes in the RIPE
community sufficient in the RIR ?? RIR community, sufficient to meet that
requirement? Do major changes risk the security, stability and resiliency
of the Internet DNS? Does this change, this transition need to be baby
steps, can we come forward with a whole new proposal, model, for how this
works but will that be stymied by this requirement? And then how does
oversight, particularly when we are talking about Internet number resources,
affect the openness of the Internet?

And so then finally, where do the RIR communities fit into any model we have
for the future? And what does that mean for the community processes, the
policy development processes that RIPE and the other RIR communities have in
place? Do they need to change? How do they need to change?

So, this, we are going to talk about how RIPE will contribute here. Paul
Rendek will step up here in a second. One thing that I will note in the
first top half of this slide, there has been some discussion already and
that has been primarily about the global process. ICANN has made a proposal
of how they believe this should look. There was a deadline of 8th of May
for feedback on what people thought of this process and they actually
received I think 48 responses from a really broad range of IANA
stakeholders, including technical community, the NRO, IAB, number of
governments, the ICANN GAC. One of the key parts of that proposal for the
process was the formation of what they called the steering committee, to
coordinate the global discussion and channel it into development of a
proposal. There has been discussion about what that sort ?? that steering
committee will look like, what its power will be, whether steering committee
is how we would like to characterise this. I have put slash coordination
group here because that is perhaps more what we would like to think of this
as, not necessarily steering the process but coordinating the input that all
of the different stakeholders have. I will pass over to Paul to talk a bit
about how we think or how we hear from you how this process will work in the
RIPE community.

PAUL RENDEK: I am Paul, from the RIPE NCC, and Chris, thanks very much for
giving us that presentation and leading us here. I understand that probably
for some of you in the room, this might be a bit confusing but you don't
ever deal with IANA and you probably haven't really taken a look at what the
oversight means. This is the first time we are coming together and actually
exploring the feedback from the technical community on this subject matter.
This will certainly not be the last time that we are discussing this. So I
just want to explain to you how we want to go with this process and then I
think we need to open up the mikes and get some general feed backs and
comments coming.

So what does RIPE NCC intend to do here? I think, you know, we have taken
a look at what ICANN has done in facilitating this process. We thought, OK,
as the RIPE NCC we need to reach out to our service region and see how we
are going to get this feedback and feed this back into ICANN so that we can
actually, at the end of the day, produce a document that wouldn't only come
from the RIRs but all the other communities that need to come together and
submit to ICANN.

So, we had a good jump start here because we knew we had a RIPE meeting
coming up. We have many meeting coming up until a document submission needs
to be made. Let me explain how I would like to proceed with this. I also
want your feedback on this, if you think there is any better way or things
we can enhance in getting this information to ICANN.

What we intend to do today, we want to have this discussion as open as
possible. Put the issues on the table and we we will document these, send
them back to the Cooperation Working Group list so everything is transparent
and everyone can see what is happened here.

From the discussions we have here and lucky you because the first ones to
have this discussion, we will take this on the road where we go, to ENOG, to
M NOG, to RIPE NCC regional events and to other events of course with our
other RIR colleagues to get as much feedback from a diverse a part of our
service region as we can get. So and in this process we will be
drip?feeding this information to the Cooperation Working Group lists, so,
again, everybody can see what are the steps and what are the different areas
or what are the different groups discussing.

We will compile all this information together, I think this will take us
quite some time but what we hope to do is to have some good texts together
so we can give a preliminary draft of the issues, the biggest and main
issues that have come up by the next RIPE meeting, in London. That will
certainly not be the end of this because there are some meetings again that
will take place, groups coming together that will keep feeding but at least
we will have something to chew on as a group and people can add into some
text that is there. So this is the process that we are processing, this is
going to take us a little while but what we would like to have is, by March
of next year, I think we hope that we can conclude our discussions from this
service region. We will probably end with a Menog that we have scheduled
around there and it would probably be the last bit of input and we hope by
then to have covered a bit of ground. If not we will continue, this is up
to this community to decide what it needs to discuss here, and all the
issues around this, but hopefully we will have something concrete because
what we need to do, you have to understand, 2015 September is coming up, but
we have to work with a whole bunch of other stakeholders to get this
document together that will be submitted to the US Government. So we must
have something concrete that we can give to the process. And I hope that
the RIPE community can be a leader in what we can give there. So, that is
the process.

So we hope that around March, if any later than that we probably wouldn't be
able to run into the rest of the stakeholders to get something that we can
then give so that the US Government can chew on this and the steering
committee ?? and I grit my teeth when I hear that word, that was the first
thing I wanted removed out of the whole thing ?? the word "steering
committee", it doesn't make sense to us, as Chris said we would prefer some
kind of coordination team that is there. We need to give these people, you
know, the documentation they need to go and make sure that they represent
us in this process that ICANN is facilitating.

So I won't stop us any more there because we need to get the discussion
going. I would like to open up the microphone, if we can go back to the
questions that we had, these are the questions we'd like to look at. Of
course we can go into any other areas. When I spoke, I talked about
oversight and what that oversight meant. Certainly it's that US Government
oversight over IANA. But if we want to also talk about any of the things
that affect the operations of IANA, we should do so; we should talk about
any of these piece that is we think are important to us. Thank you.

Daniel, please, I think you raced first.

DANIEL KARRENBERG: I think Rob was first.

ROB BLOKZIJL: This is a whole complicated process to start, and I am
absolutely sure since ICANN is involved, that what you could present today
is only the tip of the iceberg. So we have only 15 minutes left so I will
try to cut through a lot of this fluff and come back to some practical
things, I have two or three remarks.

In the first place, Chris, in your overview of what exactly our daily or
yearly interactions with IANA are, I think you forgot the Reverse?DNS, and
that is a bit more than twice a year we need interactions with IANA. So
this is a technical remark. But I think you should correct that in your
further presentations.

Secondly, the RIPE NCC has been operating for about 20 years. I do not
recall, but correct me if I am wrong, that we ever met the NTIA.

PAUL RENDEK: You are right.

ROB BLOKZIJL: Or that we ever felt the need to interact with them. So I
think we don't need them, neither them nor their oversight, because the
oversight function has been completely empty. The requirements they put on
ICANN, and I was thinking about the new gTLD programme because that is what
Americans think when they say ICANN, that is fine, but it has nothing to do
with us. The requirements are fulfilled by this community from day one; we
are open, we are transparent and we are all inclusive. If not everybody
participates in our meetings, that is not our fault; maybe we can do a
little bit of outreach in the light of this, but we should not be
overwhelmed by this whole new exercise because most of it does not concern
us; we have been operating quite successfully and we are responsible neither
to NTIA nor to any new umbrella which is created by ICANN. We are
responsible to the community, to our users, who use our services and to the
community at large who define the conditions for our services or policies.
So, keep focused and you can ignore most of this iceberg.

PAUL RENDEK: Thank you very much for those comments.

DANIEL KARRENBERG: I have a number of similar comments. First of all, this
is not the first time this is before us. No. We have had this discussion
in the '90s when ICANN was in creation and this whole IANA arrangement came
out of this, and our position at that point was exactly what Rob just
outlined: Is we have ?? we are basically bottom up industry self?regulation
of all ?? we were quite successful at it and I think we are still quite
successful at it. And in this whole discussion we basically said we have
our regional ?? at that point it was three, bottom?up processes, they are
transparent, open to everybody to join, including governments, and what we
really need is a central registry doing very few things and they should be
governed by our policies, that we develop, and over the time since then,
this whole thing that was on Chris's first and second slide has been refined
but, in the end, it's very simple: We have RIPE as the community, we have
our way of discussing, our way of coming to conclusions, to consensus and to
come to policies and we reflect that, coordinate that with the other regions
and, in the end, that is it. And I think we should not complicate things a
lot, in the end there is a very small central registry function that we need
to organise. Yes. And we have been happy with this being organised at the
IANA under a contract by the US Government, we have consensus about this,
that that was fine with us and all we need to do is to look at how that
would be organised in the future, yeah. And we shouldn't ?? and sorry, so
my main point here is we should do this in the way we have done it before,
that we should do this inside RIPE and we have a Working Group for this,
which is this Working Group, and we should have this discussion clearly
focused in this Working Group. So I was a little bit concerned that there
might be a misunderstanding here that all this outreach we are doing in ENOG
and MENOG would be the process. I think the process should be right here in
this Working Group and the discussion should be right here. Of course we
should do outreach and say this discussion is happening, but I think we
should, right here, discuss on what we want and we shouldn't blow this out
of proportion.

My third and last point is if any of ?? so the IANA, as has been explained,
is a conglomerate of three main functions: One is DNS route zone, one is
protocol parameters and ours is the Internet numbers. So, we should, when
we have this discussion, concentrate on the Internet numbers, not have it
touch all these other things, because they are of concern to us but not in
this room, yeah. And it might very well be a good thing to really
concentrate on our requirements for the numbers thing and even to the point
where we envisage how we would organise it if, somehow, this whole global
process was not going to converge into an IANA that still has these three

So what I am saying just to be quite clear, we should really have a plan B
that says we will organise this ourselves. And we should be very explicit
about this; we shouldn't be, talk around the bush with this and we should
say, you know, if this ?? we would like to see continue it as much as
possible but if, somehow, there is a kink in the works, we have credible
self governance processes and we can just organise this ourselves.

PAUL RENDEK: Absolutely, thank you very much, Daniel. I am asking everyone
if you can please look around, there are a lot of people at the mic, so
please state your points as clearly and concisely as you can.

MALCOLM: I would like to agree with the objectives of those two great
previous speakers, but I must respectfully disagree with Rob in one very
specific but important point, the idea that oversight is not important and
not needed and that we can do without it. The NTIA writes the IANA
contract. This specifies what the IANA functions are; and, therefore, also
what they are not. This is the principle means within ICANN by which our
ability to set our own policies is protected. We set policies here and the
previous speakers have said that, I explained what I think is very much a
consensus of this community that, we wish this to continue. It's not how it
works on a DNS side of the house. On the DNS side of the house, policy is
determined within the ICANN community and imposed through registry
agreements and registrar agreements on the registries and registrars and
then out through them, out to the end users and this has profound
implications, for example in DNS users are required to submit to the uniform
dispute resolution policy which is an ICANN policy, into the registry
policy. They are required to submit to the new Whois policies as well,
these are highly controversial policies and decided within ICANN. Now we
don't work that way. We determine our own policies mere but it may not
continue way it's not guarantee, it's possible that ICANN might decide it
wants to start developing policies for how ?? for the conditions for getting
address space, for the requirements that LIRs should have, to impose upon
people that get address space. That is a possibility. What stops that
happening? Partly the fact that we set those policies but partly the fact
that we are able to set those policies because these are not part of the
IANA function to set those policies. If that were redefined, we would
potentially lose or at least be in a very least, a strong fight over who had
the right to set policy. This function, this oversight function, is an
external check on ICANN that prevents ICANN from changing its mind about
whether we get to set our policies or not. I would argue that it is very
much in our interest to say that there needs to be a credible and effective
external mechanism that continues to protect our right to set our own
policies. Thank you.

PAUL RENDEK: Thank you very much, Malcolm. You had a you had a newer
Annie, I am from Netnod, I will try to be brief. Two points. One is to
emphasise, we are the number resource custodians, we need to own this
process, not just RIPE community, obviously the RIR communities. And I
think what we really need to produce is recommendations in relation to that,
and two, what registry functions we need to support that.

Then obviously, you know, a lot of us wear lots of hats and I think there
is a lot of experience and a lot of clue in the room. And I think some of
the people here will and should be participating in the broader sort of
process. But I agree with Daniel that we should focus on those specific
issues here.

Then, I actually also then have a comment on these NTIA requirements and I
agree, you can interpret it in two ways: You can say these are vague
requirements, how do we actually ?? how do we craft our response to ?? when
we guess what they mean with this. Or you can say, we are the ones defining
that, and that is what I think we should be doing. We should, through our
response, define what is multistakeholder, what is security, stability and
resiliency in this context. And so, instead of trying to get what we think
the NTIA might think, we should define these things.

PAUL RENDEK: Thank you very much.

JIM REID: Random individual off the street. A couple of things to say.
First of all, I kind of disagree with one or two of the comments that Rob
was making, if I could paraphrase his words, he was saying nothing to see
here and move along. I don't quite agree with that general tenor of remarks
and I agree wholeheartedly with what Malcolm said, we really must make sure
whatever arrangements are for the continuation of the IANA function that
those roles and responsibilities are clearly defined and there is little
scope for wiggle room or for fish and keep, that is going to be stopped. I
think we have to think about what kind of participation we would consider
appropriate or necessary inside any future arrangements for the ?? into the
oversight of IANA. Broadly speaking, IANA works fine as far as the numbers
registry is concerned, and we don't have much of a concern, but if
circumstances with the chain, if there was a massive turnover in personnel
or whatever, we might have some concerns, how would we express those
concerns and be sure they got acted on, so I think it's important we get
that point across as well, it's not what we think might be the definition of
multistakeholder and all this other context.

A final comment is for yourself, Paul, you were talking about the idea of
doing the coordination of this with a view to trying to get consensus within
RIPE. Good luck with that. And then you are going to try to take it
further and hock it around the other RIRs and get consensus there. Good
luck with that as well. I think we have to be careful about also how we are
going to try and reach some kind of consensus within our community, what
have we got as a fall?back in case we can't quite do that. We have had
attempts in the past, it's taken longer than we would have liked and not
quite worked the way we would have liked, so I think we have to have some
fallback positions. If we can't get some positions on the NTIA over sight,
what is our fall back, how are we going to cope with that so we can make a
meaningful discussion.

PAUL RENDEK: Very nice. These points will be all brought to whatever
brought forward to them so I am sure they will discuss these. We will not
be running all around the RIRs as you suggested, we will be sharing what our
community has /TKOFPBLT they have their own process to follow.

Jar Jari: I don't want people to be looking for things that aren't there so
the last 15 minutes there has been a lot of evolution in the communities in
how to handle these tasks, so as an example in the IETF we have, an
agreement together with ICANN on what to do for the services, we have an
oversight group, the IAB to look at things, administrative committee, that
can renegotiate contracts or select new operator if it were needed so there
has been a lot of good things happening. We are already are doing this
thing, completely, I think, and so do not look for the missing things if
there aren't any.

The other comment is, you were asking where do the RIR communities fit in.
I think echoing the comments of many here on the mic before me, you are the
community or you are the communities, please take ownership. This is your
thing and you need to be in charge, and you own this resources, please
design the processes, please feel responsible for doing the ?? whatever you
need to change or not change, going forward. You are in charge and there
may be some coordination committee to align us a little bit but you are in

PAUL RENDEK: Thank you very much. /*L Sal em. Fr. Leb /HROPB, I am trying
to frame the problem as we see it from my side of the world, in simplistic
way. So, for the Arab world or Middle East region, the United States
controls the Internet, so if you need an oversight function and that
oversight function is not United States government, then it should be
another government or a bunch of other governments. Right? And from their
point of view, the three issues that they really care about are, first,
control, but that has been remedied by having all the DNS, the /RAOUFRS
distributed, but there are two issues that are still on the table and it's
sovereignty, who has a right to use ccTLD to give them, lots of problems
with dot TV and all other cases we know, dot Canada, also.

And the second issue or the third remaining issue from the three is money,
you know DNS is generating a lot of money and now with new gTLDs money is
really flowing around and why isn't this money redistributed into the rest
of the world or the rest of the communities. So these, I believe, whatever
you do, has to address these issues.

PAUL RENDEK: Thank you very much.

Olaf. Can I just stop you. I would like to ?? we have just overstepped the
time here, I would like to steal ten minutes so that everyone here at the
mic can finish their comments and we will let you go to the break.

OLAF KOLKMAN: I will try to keep it short. I have been active in the IETF
community around this and one of the things that we did there is basically,
try to align the IETF on a very principle?based approach, and one of the
most important principles that we have of steering from the community, is
that the IETF controls its own destiny. Those ?? these discussions having
people empowered to have discussions with principles in their back pockets,
will help the debate going forward, it will help the ?? the community needs
to give guidance to people who are at the tables because there are many
tables at which these discussions are being had, if alone in that steering
group that is being formed or coordination group, whatever that is,
developing a bunch of principles is a very good tool. The IETF has done a
lot of work, RC6220 is one of those, basically, in a very pragmatic way,
saying what do we want to get out of a registry when one needs to be found,
so to speak.

I will leave it at that.

PAUL RENDEK: Thank you very much. And just to stop anyone wondering where
this discussion is going to take place. This discussion will take place in
RIPE, in the Cooperation Working Group, on the mailing list. And that is
where we are going to form our opinions. I wanted to make that clear.

AUDIENCE SPEAKER: Paul Wilson from APNIC. I don't want to be too
repetitive, but I think agreeing with several of the speakers so far we
don't want to overthink this. The IANA is three separate parts, three very,
very different parts and one of those parts is highly controversial, it's
responsible nor 99.9% of everything that happens at ICANN, it's going to
take a lot of work to fix that, to transition that part.

But the other two, including ours, is pretty well organised, it's pretty
well structured. What we have, what we need, the IAB just recently said we
are ready to do ?? for them, for the transition of the protocol and
parameters, parts. We could have said the same thing, I was sort of tempted
to try and say the same thing. I don't think we are quite ready but I think
what needs to be done is about documentation and about transparency and
making sure that is what is in place and has been in place for a couple of
decades now is clear, it's accessible, it's understood, it's consistent
across the RIRs and I think once that happens we are ready. We don't want
to overthink this and start throwing in a whole lot of oversight and
accountability on top of something that is overseen and accountable already.
I think we are very close to ready. Thanks.

PAUL RENDEK: Thank you very much for those words of wisdom.

AUDIENCE SPEAKER: Phil Rushton, BT. I fully support the approach you are
proposing and I think it's a good idea. The only stir that I'd put into the
mix is the other activities that are going on in parallel to this ?? UN
General committee 2 looking at the Whois review while not directly involved
in this, you can't ignore the politics, the comment made bay colleague from
Lebanon about what the governments from that region are looking at. You and
I both have experience of that so I think anything you do do in this area,
in order to maintain the integrity and the independence of what is done here
on governance and control of own selfregulation, should also influence and
take account of those other activities.

PAUL RENDEK: Thank you very much. Daniel

DANIEL KARRENBERG: Rob had to run away so I am trying to defend him a
little here. Because it looks like some people misread him of saying there
is nothing ?? there is no ?? nothing wrong, it's business as usual, and he
didn't say that. Listen again to what he said. And I'd like to expand on
one more thing, that is exactly ?? I'd like to also, first, respond to
Malcolm, in the sense that I don't agree that another level of oversight is
actually needed to protect us. We have actually agreements with ICANN that
protect us. Contracts. And ICANN is nothing but a legal entity and the
only way you protect yourself against ICANN or you make better to say it
constructively, to make arrangements with ICANN about the ground rules is
contracts and we have those. And they say quite clearly what ICANN can and
cannot do. And they cannot single sidedly, one?sidedly, unilateral, sorry,
I am losing my diplomatic speak, unilaterally change those, it doesn't mean
for protection we need another level of oversight. I don't agree with that.

And finally, the thing that Jim said is like good luck with getting
consensus in RIPE or even across the RIRs. I think that is much, much too
pessimistic because as several people have said, this is not all that
complicated. The only thing that makes it complicated it's sort of linked
to the DNS bit, and I think we should make every effort to unlink it, and to
?? we should also make every effort to get the consensus, because if we
don't ?? and this is my main point here ?? if we don't get the consensus
then we basically invalidate our claim that we have a working mechanism of

PAUL RENDEK: Thank you very much, very wise words.

AUDIENCE SPEAKER: I will support everything that has been said before, and
say that, in fact, this process we shouldn't ignore but we should use it, in
fact, to come up very strong about what we do. One other thing that should
come out from this, is to properly document what we have as processes, as
mechism that allows you to exercise oversight and control and everything we
are talking about because this is the IANA function globally and the
function has three aspects and one of them concerns the RIR and IP address
number registry globally and we have the responsibility to show the world
that we are ready, we have everything in place, we can manage it. Because
we have to be proud of our system, we have a system that is bottom up, that
is diverse, that is regional?based, it is a unique system that we can really
show case in this process. We have to participate so that give us the
opportunity to talk about what we are doing, to document it and let the
world know that we have a system that is working.

At the NRO level, talking for the NRO, we have start looking at these
different aspects, I think a lot of information will come out from that.
But we have been clear to ICANN on this, saying as a community globally we
have a lot of things in place that we think will cover this, and as
community, we have to step behind that and properly promote it around this
system. But our participation is key, we shouldn't ignore the process.

PAUL RENDEK: Thank you.

AUDIENCE SPEAKER: Sandy Murphy, Parsens. I'd like to agree with Malcolm,
thank you for your forceful words and Jim and others who said this really is
important. There is a chance that decisions could be made that would
fundamentally impact our ability to maintain the model that we like. So,
please, it's not technical, it will be a whole lot of words. The transition
mailing list is full of people who are exploring political science, it's
hard. But please do pay attention, it's the only way we'd like to have

I would like to ask some questions about what the time?line is going to be.
The NTIA announcement said that they are opening up this question, they
reserved themselves ?? you know, a governmental body, they said they are
not interested. There seems to be a suggestion that if they don't like the
final product they are presented with, they could say, never mind. And we
have already experienced that the announcement came after the IETF, so lack
of ?? we couldn't have discussed it then. The meetings set a public comment
period that spanned ARIN but it had come too late for it to be added to the
ARIN agenda, like, and ended before this meeting, so no opportunity there;
that comment period was to decide on the process for coming up with the
plan, so does that mean the process is now set, someone has made the
decision as to what the process will be? The process is now established?

PAUL RENDEK: That is not clear and it's not set. They have those 48 pieces
of input that have come in, different pieces of input. I am sure ICANN is
going to deliberate on this and they will publish something definitely
before we hit London, at the next ICANN meeting. You know, we think ?? we
know that this process is still up in the air and I think we are very much
part of making sure that we guide that where we want that to be as well, but
I don't think that stops us from having this discussion. We know what we
are talking about here, this is not the first time this has come up here.
But I do appreciate you can see some of the bits that you may have missed
opportunities or what have you. I am sure at the next IETF and I'm sure at
the next ARIN meeting, these bits will come up, but on mailing lists, these
discussions can be had over what ICANN is going to process.

AUDIENCE SPEAKER: OK. And where can we see what the process for deciding
the process for ?? for producing the plan, all those timelines sorts of
things, where can we look at that structure?

PAUL RENDEK: Right. That is on ICANN's website.

AUDIENCE SPEAKER: I have seen the pretty graph that looks like a game

PAUL RENDEK: Yes, that is the process there, that they have it all outlined

CHRIS BUCKRIDGE: I was just going to say I won't try and sort of recite out
any long URLs, but if you go to the home page there is a link on
the page to IANA transition, and on a link to the ICANN page which lays out
the process which was subject to the consultation.


PAUL RENDEK: I wanted to wrap this up, thanks for giving me the time of
your break. In the all the deliberations I have had with the NTIA and State
departments and such, because we do run around and get chances to speak to
these people, I can assure you we will be doing ourselves a great disservice
if we complicated this and tried to come up with some strange thing that we
have never even tried before. No government would ever give up that kind of
oversight to something that they have never seen actually working in
progress. We have this working in progress, I think we need to refine it,
understand what we are doing, document it correctly and talk about this. So
thank you very much for this. You will see this on the mailing list and I
hope that you will join the discussions there. Thank you.

MARIA HALL: Thank you very much. I know that ?? we are between you and the
lunch so just have a good lunch and welcome back the Cooperation Working
Group at 2:00. We are going to have additional more interesting
discussions, so hope to see you then.