Dear all, The text in my mail yesterday was the summary of the IANA discussion - the full minutes of the working groups session are now below. My apologies for the confusion!
Alain > > ------- Beginning of Minutes ------- > > Cooperation Working Group Draft Agenda > > Thursday, 15 May, 11:00 – 12:30 > > A. Administrative Matters > > The co-chairs opened the meeting. New co-chairs Meredith Whittaker and > Alain Van Gaever introduced themselves and briefly outlined their hopes for > the working group, specifically ensuring that the content is relevant and > of practical use to the RIPE community. > > The minutes from RIPE 67 were approved, as was the agenda for RIPE 68. > > > B. Content Blocking > > • B1. A Technical Overview of Content Blocking Methods – Pier Carlo > Chiodi, Olaf Kolkman > > Olaf Kolkman gave an overview of the work done by Pier Carlo Chiodi on > content blocking on the Internet and other work in the same area. Outlining > a number of strategies employed by those wishing to block content, he noted > that blocking is done most effectively at the end-point (or origin of the > content), and that blocking in the network involves a variety of trade-offs. > > Lars-Johan Liman noted that even “legitimate” blocking has collateral > damage, and pointed to the example of the hotel network, where the > interception of traffic prevents the use of DNSSEC. He suggested that in > such situations it is best if the effects of the blocking are stated > upfront for users. > > Andrei Robachevsky recalled a paper produced by ISOC (prepared around the > time of the SOCA/PIPA/ACTA legislative proposals), and noted that security > and hidden costs are all important, and public policy makers need to be > made aware of these negative impacts. Olaf pointed out that users will do > whatever they can to get to blocked content, and that this can also have > potential negative effects (including a greater viral footprint or exposing > backdoors to computer systems). > > Alexander Isavnin asked participants in the room who thought their > countries were doing blocking, and whether they thought it was being abused. > > Richard Barnes noted that these issues reinforce the importance of an > end-to-end strategy, and agreed that the hotel network is a good example of > how blocking can break important security elements like DNSSEC. > > Jim Reid noted that blocking access to specific content can mean that > broader services are blocked. He noted a case that he had provided advice > on, where one of the questions asked was "what would happen if we switched > off port 80 access on this particular domain?” - the only person who knows > is the webmaster of the domain, but that person is unlikely to happily > cooperate in the blocking of their domain. > > • B2. Telex: A Proposal For Circumventing Censorship in the Network – Eric > Wustrow > > Eric Wustrow outlined the Telex project, which has been developed to > circumvent content blocking measures. The system provides a means of > connecting users to blocked content via a mechanism that is invisible to > the censoring technology. He encouraged ISPs to contribute to the work with > advice and prototype deployment assistance. > > Robert Kisteleki noted that PGP key distribution may be a bottleneck in > the Telex system. Eric noted that the paper discusses some of these issues, > including preventing censors from distributing “bad” public keys. He > suggested that having a central Telex entity that is known and trusted will > be important to mitigate these risks. He also noted that getting > information into areas subjected to censorship is often less difficult than > might be supposed. > > • B3. Web Censorship Circumvention: Challenges and Opportunities – Walid > Al-Saqaf > > Walid Al-Saqaf outlined his project to map URL filtering via > crowdsourcing, which is developing longitudinal data, while allowing > contributing users to access blocked websites via his own servers. He > presented a range of data and analysis obtained from this work, including > content blocking methods and strategies. He noted the need to make people > more aware of the range of circumvention tools and solutions available, and > that speed, security and anonymity are all important to users. He also > described his plans for the future, including open-sourcing his own project > and cooperating with similar projects. > > Andrei Robachevsky asked whether the project looked at which means of > blocking were most common. Walid stated that he has done some analysis of > this, using the packet headers - the more data he can get, the better this > analysis will be. > > Meredith Whittaker noted that the Open Observatory of Network Interference > (OONI) project, coordinated by the Tor team, is also doing work in this > area and is generating public data. > > Alexander Isavnin suggested that a RIPE task force might be a useful > vehicle for RIPE community members interested in this issue. Walid agreed > that the technical community, and particularly its relationship to civil > society actors in this space, needs to be further explored and understood. > > C. IANA Transition > > Chris Buckridge and Paul Rendek of the RIPE NCC presented background > information on the U.S. Government’s announcement of its intention to > transition out of its IANA functions oversight role. They noted that any > proposal for a future model of IANA administration needs to come from a > global, multi-stakeholder development process, and that RIPE and the RIPE > NCC are key IANA stakeholders. They suggested that the RIPE community’s > discussion of these issues should be centred around the Cooperation Working > Group, with the RIPE NCC assisting in facilitating input to that process > from regional events and voices. > > Rob Blokzijl warned that any process involving ICANN will necessarily be > complicated and political. On a technical point, he noted that future RIPE > NCC presentations on this subject should include the RIPE NCC’s reverse DNS > interactions with IANA, which may be more regular than the number resource > requests already noted. He further noted that the RIPE NCC’s direct > interactions with the NTIA itself were non-existent, and stressed that the > processes developed by RIPE and the other RIR communities already met the > requirements laid out by the NTIA as necessary for oversight of the IANA > functions. > > Danniel Karrenberg recalled that this is not the first time this > discussion has taken place, and that the RIPE community has been vocal in > its preference for the US government stepping away from this oversight role > since the late 1990s. He stressed the success of the RIR community > processes in policy-making and argued against over-complicating the > situation. He also noted that the IANA is three distinct groups of > functions (number resources, the DNS root zone and protocol parameters), > and the RIPE community discussions should focus primarily on the number > resource functions; if difficulties in defining governance processes for > the DNS root zone threaten to derail the oversight transition process, the > community should be explicitly prepared to propose unbundling those > functions and taking oversight of the numbering functions. > > Malcolm Hutty disagreed with the perception that NTIA oversight was not > important, and stressed that this oversight has protected the policy-making > relationship with ICANN itself. He noted that policy regarding the DNS is > determined by the ICANN community and imposed on registrars, meaning that > users essentially have to submit to ICANN policies. RIPE and the RIR > communities determine their own policies with regard to Internet number > management, but it may be conceivable that ICANN would decide it wants to > set these policies in future and impose them on the RIPE community. He > argued that a credible external oversight function must be retained to > prevent this. > > Nurani Nimpuno argued that the RIR communities should take ownership of > this issue, as custodians of the Internet number resources, and that the > community members should be contributing to the broader discussion, while > maintaining a focus on the numbering functions. She also stressed that the > communities should be pro-active in defining terms like “multi-stakeholder” > and “openness” which appear in the NTIA requirements. > > Jim Reid agreed with Malcolm Hutty on the importance of preventing ICANN > mission-creep, and on the need to tightly define the relationship between > the IANA operator and the RIR communities. He also warned that achieving > consensus on a community proposal may be difficult, and suggested that > there should be a fallback position to allow for RIPE and the RIPE NCC to > make a meaningful contribution to the global discussion. > > Jari Arkko noted the evolution that has occurred in how the IETF and IAB > manage oversight of the protocol parameters and their relationship to IANA. > He agreed that the RIPE community needs to take ownership of this and take > charge of what needs to change or not change. > > Olaf Kolkman, also an active participant in the IETF, noted the efforts in > the IETF to align on a principle-based approach, with the most important > principle being that the IETF controls its own destiny. Ensuring that > people are empowered to participate in these discussions will help the > debate going forward, and the community needs to provide guidance - > developing a set of principles may be a good first step. Olaf suggested RFC > 6220 as a good starting point. > > Salam Yamout provided some perspective from the government side, > particularly in the Arab world - notably the perception that the United > States has control of the Internet, and governments’ strong focus on > DNS-related issues. She noted that governments concerns centre primarily > around ICANN. > > Phil Rushton urged the community to be aware of events in other forums, > including the UN, WSIS and the ITU - while there is not the need for > everyone to be directly involved, we need to be aware of what governments > are thinking and the where they still need to be convinced by the RIR > communities. > > Daniel Karrenberg argued that the community does not need another level of > oversight for protection, and noted that the RIR communities already have > solid agreements in place with ICANN, which ICANN cannot unilaterally > change. He stressed the importance (and his optimism) of achieving > community consensus on a proposal. He again suggested that the RIR > communities should make every effort to unlink the number-related IANA > functions from the DNS. > > Paul Wilson noted that the IANA functions comprise three quite different > areas (numbers, protocol parameters and DNS), and that only one of these > (the DNS) is controversial - the IAB has stated its readiness to take > responsibility for the protocol parameters, and the RIR communities should > also, in the very near future, be ready to make such a statement regarding > the number functions. He and Adiel Akplogan agreed that strengthening the > RIR processes, ensuring that they are consistent, clear, accessible and > well documented, is vital. > > Sandy Murphy warned that the outcome of this process may impact our > current model of Internet governance, and stressed the need for the RIR > communities to have their voice heard. She also asked about the ICANN > consultation timeline, specifically the call for comments on its proposed > process, and whether this process is now set. Paul Rendek noted that there > is expected to be more information on ICANN’s planning in time of the ICANN > 50 Meeting, which takes place in London in June. > > Chris Buckridge also noted that all relevant information, including links > to the relevant ICANN web, is posted on the ripe.net website. > > D. Interconnection > > • D1. The Internet, the Internets, and Splinternets – Peter Koch > > Peter Koch discussed the proposals coming from Germany for establishing a > separate “German” Internet. > > Randy Bush noted the experience of the Saudi industry, after the regulator > decided that no traffic between two Saudi users should leave the country, > and pointed out that IXPs are a key element facilitating this. > > There was a question as to whether the German-only email system used the > DNS (which would generate its own cross-border traffic). Peter noted that > the one he mentioned uses special domains, but DNS leakage was of less > concern than the actual content of the messages. > > Alain Van Gaever asked about the rate of take-up. Peter didn’t have > figures to hand, but noted that there are incentives, it is early in the > deployment, and the operators are targeting users of existing email > services. > > Brian Nisbet said that while he can see what’s being attempted, it never > succeeds and generally breaks things that the users want to do. Peter > stressed that walking away from the discussion probably isn’t the right > strategy, and that users often learn what they want from marketing > campaigns. Expanding on the question of what users want, Meredith Whittaker > noted that users want security, and the technical community needs to be a > public voice stating that this is not the way to achieve that. > > Marco Davids noted an initative in the Netherlands using a closed user > group in BGP - this doesn't combat traffic monitoring, but rather helps > mitigate DDOS attacks, and if users (such as banks) are under attack the > group can be closed to users outside the Netherlands. > > Olaf Kolkman asked whether any EU research funding had been channeled to > this, and whether the project could lead to some sort of European > standardisation. Peter noted that the work is based on IETF standards. Jean > Jacque Sahel noted that the European Commission has publicly said that this > is all a very bad idea. > > Jaap Akkerhuis recalled a proposal from Italy to establish a trusted > network for digital mail. > > Olaf Kolkman and Peter Koch, summarising some of the discussion’s key > points, suggested that we are moving intelligence to the core of the > network, and the core is represented by big players. The technical > community cannot just dismiss these initiatives - there are some laudable > goals behind them, and we need to engage in the discussion. > > > • D2. Interconnection: Russia, the EU, and Internet Cooperation and > Governance – Igor Milashevskiy > > Igor Milashevskiy, representing the Russian government in its first RIPE > Meeting, shared some perspectives on that government’s view of the Internet > and related public policy. The Russian government sees the Internet as a > driver of development, with the Russian Internet market the biggest in > Europe - 68 million users, more than 56 million people use Internet every > day, including a significant percentage outside big cities. The Russian > language is also the second largest in Internet, there are slightly fewer > than five million .ru domains and more than 800,000 .рф domains. > > Speaking from personal perspective, he noted that the RIPE NCC is a > reference organisation in the Internet space, and the target is to restore > trust and confidence to the Internet environment, and develop international > tools for preventing improper use of the Internet. > > Ho noted that the main actor in the Intenet is the user, and if those > users have certain rights in the offline world - access to information, > privacy, secrecy of communication and freedom of opinion - we have to > protect those rights online. The process to do this has just begun, and the > Russian government believes there are no rights without duties, no freedom > without responsibility. > > He also suggested that the role of governments in Internet governance > needs to be recognised. NETmundial was a good and innovative attempt to > include all stakeholders, but the outcome document doesn’t reflect all the > contributions. > > Ciprian Nica, participating remotely, asked how and who should define the > proper purposes of using the Internet. Igor explained that the Internet is > a universal tool, and can be used for a wide range of purposes, but that > its primary purpose should be to make users’ lives richer. > > Desiree Milosevich asked if there could be some elaboration on the Russian > government’s issues with the NETmundial statement. Igor noted that this is > in the public record of the Russian statements. > > Paul Rendek extended his thanks to Igor and the Russian government for > their increased willingness to engage with the RIPE community and RIPE NCC, > and welcomed Igor's attendance at the RIPE Meeting. > > > E. Making the Internet a Little Bit Safer Cryptographically - Randy Bush > > Randy Bush discussed the development of an open public architecture for > hardware security modules. The goal is a design (not a product) that is > scalable, composable and assured. He stressed that the project needs people > to audit the code. > > Aaron Kaplan asked where to get a development board. Randy noted that the > boards are available for 170 USD. Aaron also noted that it would be a good > idea to have the testing procedure online and publicly available. > > Eric Wuster agreed that this is good work and asked why go the FPGA route > rather than using a small embedded chip. Randy noted that some of the > applications need speed, particularly some of the encryption stuff. > Regarding chips though, Randy noted that the FPGA Verilog was first done in > Python, meaning there is a Python version and a Verilog version. > > Eric also asked about how the project is sourcing hardware random number > generators. Randy replied that they are currently investigating this issue. > > F. Policy Radar > > • F1. RIPE NCC Updates, including NETmundial and IGF Developments – Chris > Buckridge > > Chris Buckridge gave an update on the wide range of Internet governance > events taking place in the coming months, including the ITU Plenipotentiary > 2014 that is scheduled to take place in October. He highlighted the links > between many of these events, particularly in terms of broader strategies. > He noted suggestions from earlier sessions that the RIPE NCC provide more > targeted information for the community, and reported that the RIPE NCC is > investigating the best method for doing this. > > Phil Rushton noted that the technical community can have significant > impact on events at the Plenipotentiary via their input to Member State > delegations. He also noted that while NETmundial produced a good outcome > for the multi-stakeholder model, other forums, such as the CSTD Working > Group on Enhanced Cooperation, saw much less support for multi-stakeholder > processes and governance. > > • F2. Co-chair Updates and Working Group Initiatives > > Meredith Whittaker closed the session by reiterating the goals of > co-chairs, particularly the need to engage people who are affected by > Internet governance and public policy issues, but don't currently take an > active interest. She noted options such as producing white papers, using > RIPE Meeting time for more workshop-style events, and other ideas for the > working group to serve as a RIPE community “brains trust” for those > involved in public policy discussions. > > Nurani Nimpuno noted her support for the co-chairs’ approach and stressed > the need to bring discussions back to specific issues and make the topics > practical for RIPE community participants. > > The co-chairs closed the meeting. --------------------- End of Minutes --------------------------------- On Wed, Jun 4, 2014 at 7:58 PM, Alain Van Gaever <[email protected]> wrote: > Dear all, > > Please find below the minutes of the Coop-WG meeting during RIPE 68 in > Warsaw. > WG members are welcome to suggest further edits or changes. > > Hope to see you all in London for RIPE-69 ! > > Meredith, Maria & Alain > Co-Chairs of the Coop-WG > > > PS Thanks for Chris for producing the notes! > > ---- beginning of minutes ---- > > Location: Warsaw, Poland > > Attendance: Approximately 150 > > - Minutes of the session > - Full transcript of the session > <https://ripe68.ripe.net/archives/steno/39/> > - Video of the session and information slide-pack > <https://ripe68.ripe.net/archives/video/216/> > > Major points coming out of the discussion: > > 1. The RIR communities need to assert their ownership of issues > regarding the distribution and registration of Internet number resources. > This transition is an opportunity to more solidly formalise that ownership, > with minimal change to the existing policy-making and operational > processes. > 2. While the IANA functions (as a bundle) present a number of complex > issues, identifying a future model for the IANA Internet number registry > functions should be straightforward. The policy-making and operational > processes relating to the IANA Internet number registry functions are solid > and have been in place for many years, and they have never included an > explicit oversight role for the NTIA. > 3. The Regional Internet Registries must ensure that their processes > and policies are clearly defined, well documented, transparent and > accessible. > 4. While the RIPE NCC will facilitate discussion of these issues > throughout the service region (including at community regional events), the > RIPE Cooperation Working Group will serve as the central venue for RIPE > community discussion and development of any proposal relating to the future > of the IANA functions. > > > > Some additional points made during the discussion: > > - Speakers reported on the progress of the Internet Architecture Board > (IAB) and the Internet Engineering Task Force (IETF) in establishing their > ownership and authority over protocol parameter registries maintained by > IANA. > - Several speakers noted the dangers arising from this process, > particularly the potential for an outcome that does not solidly define and > protect the community-driven, bottom-up control and development of IANA > policy. > - Several speakers noted the interest that governments throughout the > world are taking in this process and that government voices will be a > factor in the final outcome. > - Several speakers stressed the importance of reaching RIPE community > consensus on a proposal or position, with this process potentially seen as > a test-case for bottom-up policy making. > - Several speakers argued strongly that any RIR proposal should aim to > separate the IANA number management functions from oversight of the other > IANA functions. > > > > --------- End of minutes ------ >
