March 2022 - ripe-list - mailman.ripe.net

LIR and Member Agreements
by denis walker 21 Oct '22

21 Oct '22

Colleagues [I make no apologies for the length of this email. There are so many errors to discuss. For an overview you can stop reading at the line of '----'. Below that is the detailed review of all the errors.] I have been reading lots of policies, procedures and agreements/contracts over the last couple of months to catch up with current and historical developments of address policy and it's application to allocating resources. It has been an eye opener. Right now I want to focus mainly on the 'RIPE NCC LIR Account Agreement'. Most of the documents I have read are poorly written. This is probably one of the worst. I will itemise below the details of what is wrong with this document. But firstly I will point out some of the serious mistakes. In this agreement there is a definition in Article 1... -RIPE NCC services The Membership Services provided through an LIR account as specified in the current version of the RIPE NCC Activity Plan. In the 'RIPE NCC Standard Service Agreement" there is also this definition in Article 1... -RIPE NCC services The Membership Services as specified in the current version of the RIPE NCC Activity Plan. There are no Membership Services specified in the current version of the RIPE NCC Activity Plan. There hasn't been such a specification since the activity plan of 2017. So for the last 5 years all the active SSAs and LIR Agreements have been referring to an 'empty list'. As both these agreements revolve heavily around these services, I have no idea what the legal significance is of agreements based on an empty list of services. Another serious issue is the absolute, total lack of any legal definition of an LIR (Local Internet Registry) and LIR account and the relationship between LIR and Member. I have not been able to find any such definitions anywhere on the ripe.net website. I fear they may be mentioned in some early RIPE document written 20 years ago that no one could reasonably be expected to find in relation to these agreements. Then we have in Article 3 of the SSA: "the Member acknowledges and accepts that it has obtained the right to use the RIPE NCC services under the conditions outlined in this agreement." And in Article 3 of the LIR Agreement: "the Member acknowledges and accepts that it has obtained the right to use the RIPE NCC services through this LIR account under the conditions outlined in this Agreement." So under what conditions can a Member use these (undefined) services? -those in the SSA -those in the LIR Agreement -a superset of the two sets -the intersection of the two sets ********** I want to put forward a suggestion that the RIPE NCC engages the services of, or employs, a professional contract lawyer to review and if necessary re-write all of the agreements/contracts used by the RIPE NCC. Or at least someone with legal training and experience in the area of contract writing. ********** It was said in a zoom meeting last Wednesday (about reviewing the PDP) that we should keep to a minimum the legal terminology and rely on common sense. That was a valid mindset in the 1990s when the internet was mostly an 'old boys/girls club'. In 2022 this is a very different global, critical industry. The IPv4 market has also changed this industry. There is so much money invested in IPv4 addresses that one 'wrong' decision by the RIPE community could face a legal challenge. If the RIPE NCC has to go to court to defend such an action they would have a better defence based on rock solid, well written, legally watertight contracts than based on a set of poorly written, contradictory documents, common sense and a generally accepted view of how things work(ed). Almost every document I have read has mistakes in it. Some have lots more than others. I wondered why people sign contracts with so many mistakes. Then I realised that most of the Members are not native English speakers, and neither are their lawyers. They almost certainly pass these documents through some translation app. Probably they accept some of the errors as translation errors. So if they go to court over these contracts it will be a case of an LIR arguing over what they think they signed, vs the RIPE NCC defending what they think they wrote. Neither will be a true reflection of reality. I know some people will criticise me for pointing out 'trivial' grammar errors in this document. (Some people will just criticise me anyway.) They will say they are not important. There are much bigger issues to deal with. We don't want to get lawyers involved in this process. Common sense will always prevail. If it ain't broke don't fix it...etc etc. This LIR Agreement is a legal contract at the core of the RIRs business (and it is broken). The quality of this document should reflect the professionalism of the RIR. As a legal contract it should be rock solid, well written and legally watertight. If there is ever a legal dispute with a Member, this contract, along with the equally error ridden SSA, may take centre stage. Do you really want to gamble on a contract that looks like it was written as an undergraduate project? For a native English speaker reading these documents, the grammar errors just leap off the page. They are trivial to find and fix. (So why have they not already been fixed?) For the legal and other content errors, a contract lawyer would not be expected to make such basic, clumsy mistakes. It is the three 'C's that present the biggest problem - Consistency, Continuity and Contradiction. Someone needs to have a clear view in their mind of the entire document set. When a document is changed or a new document is written they should know where to look to ensure integrity is maintained across the whole set. That simply has not been the case up to now. ---------------------------------------------------- So let's look at this LIR agreement in more detail. I am basing my comments on this version: https://www.ripe.net/about-us/legal/ripe-ncc-lir-account-agreement There is no definition of LIR or LIR account or any explanation of the relationship between a Member and an LIR (account). Article 1 "The Membership Services provided through an LIR account as specified in the current version of the RIPE NCC Activity Plan." There is no list of services in the activity plan. Article 2.2 "To enter into this Agreement for additional LIR accounts the Member must send to the RIPE NCC...one copy of the Agreement containing the handwritten signature of an authorised representative of the Member." This is ambiguous. It could suggest you sign one agreement for the initial LIR and one agreement for all additional LIR accounts, not one agreement for 'each' additional account. It should say: "To enter into this Agreement for each additional LIR account, the Member must..." Is it possible for a Member to delegate operational control of an LIR account to another (anonymous) company or natural person in the same way some Members delegate management of their RIPE Database objects to a consultant? It is not clear if an LIR account is an administrative concept or something tangible that can be delegated. As the initial LIR account is not subject to any agreement (see below) that one can certainly be delegated. Article 2.3 "The RIPE NCC reserves the right to amend this Agreement. The RIPE NCC shall notify the Member of such amendments at least one month before these amendments come into effect." This clause is almost certainly unenforceable. It is also ridiculous. It says the RIPE NCC can make any change it wants to this agreement at any time (after you have signed it) without any consultation with any individual, group or community and without any consensus, approval or acceptance and put the change into effect and expect all LIRs to comply with the change. If the NCC wants to fix the simple grammar errors, they would probably get away with it. Any substantive change would almost certainly be met with a legal challenge. They cannot impose a substantive change on 20k+ signatories. The SSA says: "2.3 The Member acknowledges and accepts that the RIPE NCC Standard Service Agreement may be amended by a resolution of the General Meeting of the RIPE NCC according to the procedure outlined in the RIPE NCC Articles of Association. An amendment shall automatically become effective upon the date mentioned in the resolution or the date of first publication of the resolution of the General Meeting and the full text of the amended agreement on https://www.ripe.net, whichever is the latest, without the re-signing of the RIPE NCC Standard Service Agreement being necessary." The same conditions must apply to changing the LIR Agreement. Article 3.3 "The Member acknowledges applicability of, and adheres to, the RIPE Policies and RIPE NCC procedural documents." Use of 'Member' and 'LIR' are interchanged throughout these documents. This agreement is about an LIR account. Do policies also apply to the LIR account or just to the Member? This is not clearly defined. Article 3.4 "The Member shall provide the RIPE NCC with complete, updated and accurate information necessary for the provision of the RIPE NCC services and shall assist the RIPE NCC with audits and security checks as outlined in the RIPE NCC procedural documents, and in particular with the RIPE NCC procedural document “Due Diligence for the Quality of the RIPE NCC Registration Data”." Is this the same information required by Article 2.2 of the SSA? Articles 2, 3 and 6 of the SSA overlap considerably with Articles 2 and 3 of the LIR Agreement. Such overlaps encourage contradictions between separate contracts. Article 3.6 refers to the document ‘Closure of Members, Deregistration of Internet Resources and Legacy Internet Resources' https://www.ripe.net/publications/docs/ripe-775 This document (ripe-775) was last updated on 30 Dec 2021, which is quite recent. Yet in Section B.1.b it says: "Internet number resources are allocated/assigned based on a specific need. When the original technical requirements or the business purpose for the use of the Internet number resources changes, the allocation/assignment becomes invalid. If the RIPE NCC notices any change in the original technical criteria or the original business purposes for using the Internet number resources, the RIPE NCC is authorised to deregister the relevant Internet number resources." This conflicts with ripe-733 'IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region', Section 5.1 which says: "On application for IPv4 resources LIRs will receive IPv4 addresses according to the following: - All allocation requests are placed on a first-come-first-served waiting list. No guarantees are given about the waiting time. - The size of the allocation made will be exactly one /24. - The sum of all allocations made to a single LIR by the RIPE NCC is limited to a maximum of 256 IPv4 addresses (a single /24). If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy." No mention of any 'need' based requirement. This has been the case at least since November 2019. This shows the lack of continuity and contradictions between these documents. Article 3.7 says: "Unless otherwise specified in this Agreement, this Agreement is valid only for one specific LIR account. If the Member wishes to operate an additional LIR accounts, the Member shall sign an additional RIPE NCC LIR Account Agreement." Note the plurality of "an additional LIR accounts". It may be a simple typo. But as written it supports my comment above on Article 2.2 that maybe only one agreement needs to be signed for all additional LIR accounts. Article 4.2 "The Member's obligation to pay any fees corresponding for the LIR account of this Agreement" 'for' instead of 'to' - Another simple grammar error. Article 4.3 "The Member shall make the payment to the RIPE NCC within 30 days of date of invoice" of 'the' date - Another simple grammar error. (Or perhaps even 'within 30 days of the date of the invoice') Article 4.4 "without prejudice to any other of the RIPE NCC's rights which it may revoke against the Member in connection with the latter's failure to effect (timely) the payment." 'other' is in the wrong place, 'to any of the RIPE NCC's other rights' 'revoke' instead of 'invoke' '(timely) the payment' instead of 'the (timely) payment' More simple grammar errors. Article 4.1 refers to the 'RIPE NCC Charging Scheme 2022' and Article 4.6 refers to the 'RIPE NCC Billing Procedure and Fee Schedule' document This takes us off into billing and fees documents. I have reviewed these documents at the end. Article 5.2 "The Member shall be entitled to terminate this Agreement at any time." It doesn't say if the Member needs to give any notice period. Maybe: "The Member shall be entitled to terminate this Agreement at any time with immediate effect." Article 6.1 "The Member shall also be liable for all aspects of its use and all that ensues from its use from the Internet number resources." It should say 'its use of the Internet...' This wording, 'its use', only puts liability onto the Member if they use the resources themselves. It does not put liability onto the Member if they allow someone else to use the resources by assigning them. The wording should be 'the use' or 'any use'. Then the Member accepts full liability for use of these resources by anyone. Article 6.6 "The Member shall indemnify the RIPE NCC against any and all third party claims filed against the RIPE NCC in relation to the Member's use of the RIPE NCC services." Again the indemnity is limited to claims resulting from only the Member's use of the services. This article should say: "The Member shall indemnify the RIPE NCC against any and all third party claims filed against the RIPE NCC in relation to the any use of the RIPE NCC services provided to this Member through any of it's LIR accounts." Then it doesn't matter who is using the services. Article 6.7 "In any event the RIPE NCC's liability shall be limited to a maximum amount equivalent to the Member's service fee of the relevant financial year" This may apply in the event of the Member filing a claim against the RIPE NCC. If a third party files a claim against the RIPE NCC, I don't think the RIPE NCC can set it's own limit on the claim within an agreement the third party has not signed. Article 7.2 "The RIPE NCC's intellectual property (agreements, documents, software, databases, website, etc.) may only be used, reproduced and made available to third parties upon prior written authorisation from the RIPE NCC." If the Member has been allocated address space and they sub-allocate part of that space to another organisation, this is an acceptable use of the address space. By making assignments from the sub-allocation the second organisation will make use of the RIPE Database. This is an acceptable use of the RIPE NCC's intellectual property (database) without written authorisation needed. Article 8.2 "Any disputes that may arise from this Agreement shall be settled in accordance with the RIPE NCC Conflict Arbitration Procedure." This highlights one of the base issues with this LIR Agreement. It clearly started life as a copy of the SSA which was then modified to create the LIR Agreement. If you replace 'this Agreement' with 'the RIPE NCC SSA' you have the basis of Article 11.2 of the SSA. The problem in this Article 8.2 is that the Conflict Arbitration Procedure (ripe-691) is specific to the SSA. Disputes arising from the LIR Agreement are not within scope, according to both the Introduction and Section A.1. of the Procedure. But even in Article 11.2 of the SSA "shall be settled" should be changed to "may be settled". There is always the option to take a dispute to a national court. (Incidentally after a quick read, I only found one error in ripe-691. In Section C.1. "timeframe cannot not exceed".) Article 2.2 "By signing the RIPE NCC Standard Service Agreement as instructed by the RIPE NCC the Member confirms that they have read, understood and agree to be bound by the terms of this agreement for an initial LIR account." After writing all of the above I was told by a Member that they don't sign an LIR Agreement for their initial LIR account. It is somehow implied by signing the SSA. The LIR Agreement is only signed for additional LIR accounts. Now I understand the intention of the wording of Article 2.2 but it is complete madness. You can NOT hold me to the terms of this agreement because I signed some other agreement that makes no mention of this one. IF the SSA included something like this "The LIR Agreement forms an integral part of this SSA. By signing the SSA the Member agrees to be bound by the terms of the LIR Agreement for their initial LIR account." then it would be valid. BUT the SSA makes no mention anywhere of the LIR Agreement. In fact the SSA only mentions 'LIR' 7 times and they are all links to the 'Closure of LIR...' procedure. Article 6.1 of the SSA does say: The Member acknowledges applicability of, and adheres to, the RIPE Policies and RIPE NCC procedural documents. The RIPE Policies and the RIPE NCC procedural documents are publicly available from the RIPE NCC Document Store. These documents, which may be revised and updated from time to time, form an integral part of and apply fully to the RIPE NCC Standard Service Agreement. Each revised document will receive a new document number and can be found on https://www.ripe.net." It then includes a non-exclusive list of these documents, which does not include the LIR Agreement. There are several key points in Article 6.1 that specifically EXCLUDE the LIR Agreement from being an integral part of the SSA. Although the term 'procedural documents' is not defined anywhere, just like LIR, it would be a considerable stretch of the imagination to include an agreement or contract in a commonly understood definition of a procedural document. It also specifically says in 6.1 that the 'procedural documents are publicly available from the RIPE NCC Document Store'. The LIR Agreement is not listed in the document store. It also says 'Each revised document will receive a new document number'. Unlike the SSA, the LIR Agreement does not have a document number. The LIR Agreement is therefore NOT an integral part of the SSA. Signing the SSA does not bind a Member to the terms of the LIR Agreement. This opens an entire can of worms. None of the Member's initial LIR accounts are registered as LIR accounts. None of them are subject to any terms or conditions. As the charging scheme requires a service fee per (registered) LIR and these initial LIR accounts are not registered, technically Members do not need to pay a fee for their initial LIR accounts. Another interesting point is that all RIPE NCC procedural documents are said to form an integral part of the SSA. These documents may be 'revised and updated'. Article 2.3 of the SSA says changes to the SSA need a resolution by the GM. Under what conditions can a procedural document be changed if it is an integral part of the SSA? How is a new procedural document implemented if it becomes an integral part of the SSA? ********** As I said at the start of this email, it will benefit the RIPE NCC to employ someone qualified or experienced in contract law to review and re-write all the NCC's contracts and agreements so they actually say what they were intended to mean. ********** Moving on to the billing docs referenced in the LIR Agreement, there seems to be 3 significant documents which contradict each other. One even contradicts itself. The referenced 'RIPE NCC Billing Procedure and Fee Schedule' document https://www.ripe.net/participate/member-support/payment is marked as last updated on 19 Dec 2018 but refers to the fees for 2022 and has probably been updated each year. What it says is confusing: "RIPE NCC members pay a membership fee every year. For 2022, this fee is €1,400. This is charged on a pro rata basis for new member. New members also pay a sign-up fee, which is currently €1,000. Members can have more than one LIR account, but they must pay the membership and sign-up fee for each LIR account." Again total confusion between Members and LIR accounts. The 'RIPE NCC Charging Scheme 2022' refers to this as a 'service fee' not a 'membership fee'. It doesn't make sense to refer to it as a membership fee and then say it is paid per LIR account. This wording also suggests that there is a sign-up and annual fee for being a member and also a sign-up and annual fee for each LIR account, including the initial LIR account. It makes no distinction between initial and additional LIR accounts. 'This is charged on a pro rata basis for new member.' should say 'new members' - Another simple grammar error. In the 'RIPE NCC Charging Scheme 2022' document https://www.ripe.net/publications/docs/ripe-771 it says: "New members or additional LIR account registrations also pay an additional one-time sign-up fee alongside their annual contribution." Again this is grammatically totally wrong. It uses 'or' instead of 'and'. Also an 'LIR account' is not an entity that can pay anything. It should say: "An additional one-time sign-up fee is paid alongside the annual contribution for new members and when new LIR accounts are registered." In the 'RIPE NCC Billing Procedure 2022' document https://www.ripe.net/participate/member-support/payment/ripe-ncc-billing-pr… it has the same incorrect sentence as the Charging Scheme document: "New members or additional LIR account registrations also pay an additional one-time sign-up fee alongside their annual contribution." In 2.1 the image does not match the table immediately following the image. In Column A of the table it should show the one-time sign-up fee for New Members as 'per LIR account'. For Existing Members it should show the one-time sign-up fee for 'Additional LIR accounts' also in Column A. In 3. it is not clear if the service fees for all LIR accounts set up by a new member will be applied pro rata. Also there is no mention if the service fees for an existing member who sets up additional LIR accounts during the year will pay a pro rata fee for the new LIR accounts. It also says the 'pro rata for each quarter' will be based on 'the time of the year the membership application is submitted.' This has to be the time of year the SSA is concluded. You cannot reasonably charge for services before the period in which the services are made available. In 3.1 it says "The annual invoices will be sent to members between the end of the first quarter and the beginning of the second quarter of 2022." This time period does not exist. It has to be either 'after the end of the first quarter' or 'before the start of the second quarter'. In 3.2 it says "Members are responsible for providing and maintaining correct billing." It should be 'billing details'. In 3.3 it suggests that payment for any Member LIR account can come from any source. There doesn't appear to be any requirement for the payment details to match up with the Member legal entity or natural person. Surely this is open to abuse, fraud or money laundering possibilities? I have done an extensive review here of the LIR Agreement and touched on some of the errors in the SSA and billing documents. Almost every policy, procedure, agreement, contract, document I have read has one or more grammar and/or content errors. Maybe it is time for a full review.... cheers denis co-chair DB-WG

16 23

Draft Document: RIPE Task Forces - Definition and Guidelines - v3
by Niall O'Reilly 27 May '22

27 May '22

Dear Colleagues, [Please view this message as either plain text or HTML, according to your preference.] In view of significant comments received during what we had expected to be a restricted last call, Mirjam and I have decided to make a fresh draft of the proposed document on RIPE Task Forces and to make this available for your review [here][v3]. An onward link leads to an [alternative presentation][v3chg] of the draft, in which recent changes are highlighted. We are very grateful to Boris Duval and Antony Gollan, who did most of the real work. We plan to close the review period just before 24:00 UTC on Sunday 10 April next, and to announce a two-week last-call period shortly after that. Please let us know what you think, in sufficient numbers so that we can understand whether the draft enjoys community consensus. For your convenience, the table below shows the dates when successive drafts of this proposed RIPE Document were announced. | Date | From | Remarks | |------------:|:-----------|:------------------------------------------------| | 19 Nov 2021 | M.Kuehne | [002363][] Draft; suggestions invited | | 16 Dec 2021 | N.O'Reilly | [002402][] Update; last call closing 14 Jan | | 3 Feb 2022 | N.O'Reilly | [002444][] Update; last call extended to 18 Feb | | 23 Mar 2022 | N.O'Reilly | [v3][] Fresh draft for review until 10 Apr | Best regards, Niall O’Reilly --- [002363]: https://www.ripe.net/ripe/mail/archives/ripe-list/2021-November/002363.html [002402]: https://www.ripe.net/ripe/mail/archives/ripe-list/2021-December/002402.html [002444]: https://www.ripe.net/ripe/mail/archives/ripe-list/2022-February/002444.html [v3]: https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-… [v3chg]: https://ripe.net/publications/docs/ripe-documents/other-documents/ripe-task…

12 19

Get Certified at SEE 10
by RIPE NCC Certified Professionals 31 Mar '22

31 Mar '22

Dear colleagues, You can now get certified at our upcoming events! We are happy to offer you the opportunity to take a RIPE NCC Certified Professionals exam during SEE 10 (11-12 April) and at RIPE 84 (16-20 May). A dedicated exam room equipped with a laptop will be available at the meeting venue. You can choose to take any of our three exams: - RIPE Database Associate - IPv6 Fundamentals - Analyst - IPv6 Security Expert ---------------------------- Book a slot at SEE 10 ---------------------------- - You need to register in advance to take an exam at SEE 10. Registration closes on Friday, 8 April. - Exam slots are available on first-come, first-served basis. - Exams can be scheduled to begin between 9:00 - 17:00 (UTC+2) on Monday, 11 April, and Tuesday, 12 April respectively. - Each exam takes a maximum of 60 minutes, with an additional 15 minutes required for checks prior to the exam. You can request an exam slot by sending an email to <exams(a)ripe.net>. The exams team will share additional information including your exam booking code. ---------------------------- Already certified? ---------------------------- Have you already earned a RIPE NCC Certified Professionals badge? We’ll be happy to hand over your well-deserved t-shirt or hoodie at SEE 10! Simply send us an email and let us know which badge you earned, and in which size you would prefer to receive an official RIPE NCC Certified Professionals t-shirt or hoodie. Planning to join us at RIPE 84 in Berlin? Start studying and stay tuned for more details! If you have any questions, please do get in touch. Kind regards, The Exams Team RIPE NCC Certified Professionals

1 0

"Keep Ukraine Connected" initiative - follow up!
by Jan Zorz - Go6 30 Mar '22

30 Mar '22

Dear RIPE community, Kudos to everyone that responded and contributed to our initiative to help Ukraine operators to keep people connected, we are positively surprised how many of you contacted us and are willing to help! You all know who you are! We currently have a lot of equipment coming in. Again - thank you, everyone! To help us process everything we have implemented a supply and demand database. Requesters and donors can both create accounts to access the database. Then anyone who wants to send something to us can enter this in database, and registered requesters can see directly what is available and lay claim to it. We are currently planning the next trip to Ukraine to hand over all the donated equipment. We plan to leave Berlin in early April to collect additional equipment in Prague. Then we will head towards Ljubljana, Slovenia, to pick up more donations and also take part in the RIPE SEE10 meeting. Finally, we will head towards Krakow and stay for the night before driving towards whichever of the Ukrainian border stations in Hlynytsi, Krakowez or Lviv will take us, and hand over our collected hardware on site. If you still have equipment that you would like to donate, please send an email to: ukraine(a)nogalliance.org to get access to our database. https://nogalliance.org/our-task-forces/keep-ukraine-connected/ Cheers and thnx, Jan Žorž on behalf of GNA/KUC team

1 0

2021 IANA Numbering Services Review Committee Report Published
by Boris Duval 24 Mar '22

24 Mar '22

This message is sent on behalf of the Number Resource Organization (NRO). *** The IANA Numbering Services Review Committee (IANA RC) is pleased to announce that it has published the 2021 IANA Numbering Services Review Committee Report. The IANA RC was formed in 2016 and is responsible for publishing an annual report as advice to the NRO EC for its evaluation of the IANA numbering services. This report follows a 30-day public comment period on the IANA Performance Matrix Summary Report published by the RIRs seeking input from the broader community. This report is based on the 2021 IANA Performance Matrix Summary Report, as well as on any input gathered from the global number community. The 2021 IANA Numbering Services Review Committee Report is published at: https://www.nro.net/2021-IANA-RC-Report The IANA RC noted that no incidents were reported in the IANA Numbering services to the RIRs in 2021. *** Best Regards, Boris Duval Communications Officer RIPE NCC

1 0

"Keep Ukraine Connected" initiative
by Jan Zorz - Go6 16 Mar '22

16 Mar '22

Dear RIPE community, Apology in advance for possible duplicates of this information and/or long email :) At GNA (Global NOG Alliance) we started a new initiative (or a task force) called "Keep Ukraine Connected", aiming at mobilizing global technical community to support Ukrainian operators and community with donating and delivering hardware that they need to keep the light on and Internet connectivity available in the country. https://nogalliance.org/our-task-forces/keep-ukraine-connected/ This is a completely non political initiative that is just aimed to help keeping the information accessible to people in distress. We at GNA are in close contact with The Ukrainian Internet Association (UIA) and National Commission for the State Regulation of electronic communications, radiofrequency spectrum and the provision of postal services amd also with their association of business ISPs. They are coordinating the effort on their side with operators and people on the ground, providing us with the current needs. This is a partial list of what we are looking for right now: Specific requests: Wifi Soho (TP-Link, Netis, Mikrotik, etc) Wi-fi Backbone/Backhole (Mikrotik, Mimosa, Ubiquiti) Access switches (PoE preferred) (Any brand) Core switches (Any brand) Power generators (Any brand) General needs: Starlink satellite systems Wifi access points Wifi P2P systems Routers Switches Fiber repair tools (splicers, cleavers) Q/SFP modules Servers Walkie-Talkies It's probably redundant to stress out that all donated equipment needs to be in full working order, because people on the ground does not have time to figure out how to repair stuff at the moment. We are also accepting money donations at the web page mentioned above that will be used for some costs of logistics of transport and also to buy the most needed equipment that we'll not get through hardware donations from the community that we are collecting at warehouse in Germany. How will this work? We have access to a truck based in Germany, and volunteer drivers. We will coordinate filling the truck with the technology bought with your donations, along with the donations of network equipment we have received from the community, then drive that truck to the Ukraine border. Our chair, René Fichtmüller, has already made the journey once — albeit with a more regular cargo of donations. For all questions and/or suggestions, please send an email to ukraine(a)nogalliance.org. We appreciate anything you can do to help out. Thank you! Best, Jan Žorž on behalf of Global NOG alliance and our contacts in Ukraine

1 0

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear RIPE community members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

2 1

Notice to the ASO Community on Rejection Action to ICANN Board Resolution on IANA FY23 Budget
by Antony Gollan 14 Mar '22

14 Mar '22

This message is sent on behalf of the Number Resource Organization (NRO). *** Notice to the ASO Community on Rejection Action to ICANN Board Resolution on IANA FY23 Budget 14 March 2022 Dear RIR Community, On 24 February 2022, the ICANN Board of Directors approved the IANA FY23 Budget. The resolution approving the FY23 IANA Budget is available at: https://www.icann.org/resources/board-material/resolutions-2022-02-24-en#2.a. The approved IANA FY23 Operating Plan and Budget is available at: https://www.icann.org/en/system/files/files/iana-fy23-operating-plan-budget… This resolution (FY23 IANA Budget) is subject to Rejection Action Petitions from the community. As a Decisional Participant, the Address Supporting Organization received a notice from the ICANN Secretary pursuant to Section 22.4(a)(v) of the ICANN Bylaws: https://www.icann.org/resources/pages/governance/bylaws-en/#article22 Reception of this notice triggered a 21-day period during which any member of the ASO community can submit a rejection petition on the matter. If you would like to submit a Rejection Action Petition to the ASO, please consult Section 2 of Annex D of the ICANN Bylaws for the requirements that must be met by a Rejection Action Petition: https://www.icann.org/resources/pages/governance/bylaws-en/#annexD This 21-day period commenced on 9 March 2022 and will end at 06:59 (UTC) on 31 March 2022. Any Rejection Action Petition should be sent to the ASO Secretariat (secretariat [at] aso.icann.org) before the deadline. Kind regards, ASO Secretariat *** Regards Antony Gollan Communications Team Manager RIPE NCC

1 0

Fwd: RIPE Community session on proposed revised PDP - Minutes and draft version 2
by Mirjam Kuehne 11 Mar '22

11 Mar '22

Dear colleagues, Many thanks to those who provided comments so far. You can still provide feedback before the deadline on 16 March 2022. Kind regards, Mirjam ------- Original Message ------- On Wednesday, February 16th, 2022 at 14:44, Mirjam Kuehne<mir(a)zu-hause.nl> wrote: > Dear colleagues, > > On 26 January we held an online meeting to gather feedback about the > > revised Policy Development Process (PDP). The recordings, minutes and > > slides can be found here: > > https://www.ripe.net/participate/ripe/ripe-community-plenary/minutes/revise… > > Below you can find a short summary of the main points discussed at the > > meeting. Based on this feedback we adjusted the draft document and > > created a new red-lined version: > > https://www.ripe.net/publications/docs/ripe-documents/other-documents/polic… > > Please review the changes carefully and provide any additional feedback > > before 16 March 2022. > > Kind regards, > > Mirjam Kühne > > ============ > > Meeting Summary: > > The overall sentiment was to rely on community consensus and common > > sense as much as possible and to keep formalism at a minimum. > > 1. Author and Ownership of the Document > > There was general agreement to make a distinction between the author and > > owner of the PDP: the community should be listed as owner of the PDP and > > the RIPE Chair as the author of the document. [1] > > 2. Scope of the Document > > There was agreement to shorten the introduction of the document to > > clarify that the PDP only refers to policy. There was also agreement to > > keep the section about values and principles. > > 3. Changes to PDP > > Most people agreed that the scope of the Policy Development Process > > should be limited to creating policy. It should not be used to change > > the PDP itself or other RIPE governance documents. It was suggested > > however to carefully manage the change process including clear deadlines > > and announcements to ensure proper community consensus building. > > 4. Re-introducing Informal Discussion Step > > There was strong agreement to re-introduce this step and that gathering > > support prior to a formal proposal is crucial. > > 5. Appeals Procedure – Process, Deadlines, Recusals > > There was general agreement to have a well defined appeals procedure > > with clear deadlines and a certain level of formalism. Some people > > suggested to create a separate appeals body. Others felt that it will be > > difficult to find people and that the WG chairs tend to have experience > > with the PDP. > > 6. Editorial Changes > > There was no disagreement about the suggested editorial changes. > > --- > > [1] There was a question if the RIPE Vice Chair should also be listed. > > However, ripe-714 provides the option for the RIPE Chair to delegate to > > others, e.g. a Vice Chair. > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ripe-list

1 0

Response to Request from Ukrainian Government
by Hans Petter Holen 10 Mar '22

10 Mar '22

Dear colleagues, Today we responded to a request from the Ukrainian Government. We have published this on our website here: https://www.ripe.net/publications/news/announcements/ripe-ncc-response-to-r… Kind regards Hans Petter Holen Managing Director RIPE NCC

1 0

statement on infrastructure governance sanctions regime
by Niels ten Oever 10 Mar '22

10 Mar '22

Dear all, With a diverse group of actors we made a statement on what we think an internet infrastructure governance sanctions regime should look like. Looking forward to discuss it with you. Statement: https://www.pch.net/resources/Papers/Multistakeholder-Imposition-of-Interne… [PDF] Twitter thread: https://twitter.com/nielstenoever/status/1501821745631797249 Press: https://www.theregister.com/AMP/2022/03/10/internet_russia_sanctions/ https://www.washingtonpost.com/technology/2022/03/10/internet-russia-sancti… https://apnews.com/article/russia-ukraine-technology-business-europe-890976… Plain text version of the statement: Thursday, March 10, 2022 The Hague Multistakeholder Imposition of Internet Sanctions Executive Summary The invasion of Ukraine poses a new challenge for multistakeholder Internet infrastructure governance. In this statement, we discuss possible sanctions and their ramifications, lay out principles that we believe should guide Internet sanctions, and propose a multistakeholder governance mechanism to facilitate decision-making and implementation. Introduction The Internet is in its thirtieth year of transition from national to multistakeholder governance. As we encounter pivotal moments, we must decide as a community whether Internet self-governance has matured sufficiently to address such newly encountered issue. Governments have imposed sanctions throughout history, but the global Internet governance community has not yet established a process dedicated to this task. We believe it is now incumbent upon the Internet community to deliberate and make decisions in the face of humanitarian crises. We may not responsibly dismiss such crises without consideration, nor with consideration only for the self-interest of our community’s own direct constituents; instead, maturity of governance requires that self- interests be weighed in the balance with broader moral and societal considerations. This document is the beginning of a global Internet governance conversation about the appropriate scope of sanctions, the feasibility of sanctions within the realm of our collective responsibility, and our moral imperative to minimize detrimental consequences. Principles for Internet Infrastructure Governance Sanctions We, the undersigned, agree to the following principles: - Disconnecting the population of a country from the Internet is a disproportionate and inappropriate sanction, since it hampers their access to the very information that might lead them to withdraw support for acts of war and leaves them with access to only the information their own government chooses to furnish. - The effectiveness of sanctions should be evaluated relative to predefined goals. Ineffective sanctions waste effort and willpower and convey neither unity nor conviction. - Sanctions should be focused and precise. They should minimize the chance of unintended consequences or collateral damage. Disproportionate or over-broad sanctions risk fundamentally alienating populations. - Military and propaganda agencies and their information infrastructure are potential targets of sanctions. - The Internet, due to its transnational nature and consensus-driven multistakeholder system of governance, currently does not easily lend itself to the imposition of sanctions in national conflicts. - It is inappropriate and counterproductive for governments to attempt to compel Internet governance mechanisms to impose sanctions outside of the community’s multistakeholder decision-making process. - There are nonetheless appropriate, effective, and specific sanctions the Internet governance community may wish to consider in its deliberative processes. Recommendations We believe it is the responsibility of the global Internet governance community to weigh the costs and risks of sanctions against the moral imperatives that call us to action in defense of society, and we must address this governance problem now and in the future. We believe the time is right for the formation of a new, minimal, multistakeholder mechanism, similar in scale to NSP-Sec or Outages, which after due process and consensus would publish sanctioned IP addresses and domain names in the form of public data feeds in standard forms (BGP and RPZ), to be consumed by any organization that chooses to subscribe to the principles and their outcome. This process should use clearly documented procedures to assess violations of international norms in an open, multistakeholder, and consensus-driven process, taking into account the principles of non-overreach and effectiveness in making its determinations. This system mirrors existing systems used by network operators to block spam, malware, and DDoS attacks, so it requires no new technology and minimal work to implement. We call upon our colleagues to participate in a multistakeholder deliberation using the mechanism outlined above, to decide whether the IP addresses and domain names of the Russian military and its propaganda organs should be sanctioned, and to lay the groundwork for timely decisions of similar gravity and urgency in the future. Signed, Bart Groothuis, Member of the European Parliament, Netherlands Bill Woodcock, Executive Director, Packet Clearing House Ihab Osman, Non-Executive Director, Internet Corporation for Assigned Names and Numbers Mike Roberts, founding President and CEO, Internet Corporation for Assigned Names and Numbers Jeff Moss, President, DEFCON Niels ten Oever, Postdoctoral Researcher, University of Amsterdam Marina Kaljurand, Member of the European Parliament, Estonia, former ambassador to Russia and the United States Eva Kaili, Member of the European Parliament, Greece Runa Sandvik, security researcher Kurt Opsahl, Electronic Frontier Foundation (affiliation for identification purposes only) John Levine, President, CAUCE North America Virendra Rode, founder and contributor, Outages.ORG Stephen D. Crocker, Edgemoor Research Institute Job Snijders, board member, RIPE NCC, PeeringDB, and Route Server Support Foundation Moez Chakchouk, Director of Policy, PCH, former ADG/CI UNESCO and former Tunisian minister Doug Madory, Director of Internet Analysis, Kentik Ondrej Filip, CEO, CZ.NIC and Chairman, European Internet Exchange Association Greg Rattray, Founder, Next Peak and former cybersecurity advisor to ICANN Serge Droz, in personal capacity, Director FIRST Mark Tinka, board member, FranceIX Dmitry Kohmanyuk, CEO, Hostmaster Ltd. Timothy Denton, Chairman, Internet Society, Canada Chapter Barry Greene Perry E. Metzger, Managing Member, Metzger, Dowdeswell & Co. LLC Roelof Meijer, CEO, SIDN Svitlana Matviyenko, Associate Director, Digital Democracies Institute, Simon Fraser University Rabbi Rob Thomas, CEO, Team Cymru Harald Summa, CEO, DE-CIX Chris Gibson, in personal capacity, CEO FIRST Tom Killalea The Internet Archive Philip Reiner, CEO, Institute for Security and Technology Megan Stifel, Chief Security Officer, Institute for Security and Technology Bart Stidham, CEO, NAND Rudolf van der Berg, Programme Manager, Stratix Consulting _____________________________________________________________________________ Annex: Technical Discussion of Internet Governance Sanction Measures This statement is occasioned by the letter Andrii Nabok (Андрій Набок) of the Ukranian Ministry of Digital Transformation addressed to the Internet Corporation for Assigned Names and Numbers (ICANN) on the morning of Monday, February 28, 2022.[1] ICANN [2] and RIPE [3] replied to Mr. Nabok’s letter directly, in the narrowest possible terms, and in the negative. In this annex, we discuss the technical specifics of each of the proposed sanctions, as well as of other possible Internet sanctions which we suggest are more effective, more precise, and carry fewer risks and lower costs. Analysis of Ukraine’s Request We respect Mr. Nabok’s professional expertise and his inclusion of Ukraine’s Internet community in the drafting of his letter in the full spirit of the multistakeholder principles by which the Internet is governed, and we express our deepest sympathies for the indescribable trauma Ukraine is experiencing as a result of Russia’s invasion, which we condemn without reservation. Mr. Nabok’s letter requests the imposition of four Internet governance sanctions against Russia, namely: - Permanent or temporary revocation of the country code top-level domains “.ru”, “.рф” and “.su”. - Revocation of SSL certificates associated with those domains. - Disablement of DNS root servers situated within the Russian Federation. - Withdrawal of the right to use IPv4 and IPv6 addresses by Russian networks. We commend Mr. Nabok and the Ukrainian people and government for responding to bloodshed with diplomacy and seeking deescalatory sanctions. Internet governance sanctions must, however, be selected and implemented carefully, in order to achieve the greatest effect and to avoid unanticipated consequences. In the attached appendix, we discuss each of the proposed sanctions, as well as others we consider more effective, with lower costs and risks of unintended consequences. Revocation of country-code Top Level Domains (ccTLDs) Every ISO-3166 Alpha-2 two-letter abbreviation of a national name is reserved for the use of the Internet community of that nation as a “country-code Top Level Domain,” or “ccTLD.” This reservation is made expressly for the Internet community of the nation and not the government of the nation. Geographic, political, and sociocultural allocations of “internationalized” top-level domains (such as “.рф” to the Russian Federation, or “.укр” to Ukraine) are made in parallel with the ISO-3166 mechanism. The primary users of any ccTLD are its civilian constituents, who may be distributed globally and may be united by linguistic or cultural identity rather than nationality or national identity. Removal of a ccTLD from the root zone of the domain name system (the sanction suggested by the letter) would make it very difficult for anyone, globally, within Russia or without, to contact users of the affected domains, a group that consists almost entirely of Russian- speaking civilians. At the same time, it would have relatively little effect upon Russian military networks, which are unlikely to rely upon DNS servers outside their own control. We therefore conclude that the revocation, whether temporary or permanent, of a ccTLD is not an effective sanction because it disproportionately harms civilians; specifically, it is ineffective against any government that has taken cyber-defense preparatory measures to alleviate dependence upon foreign nameservers for domain name resolution. In addition, any country against which this sanction was applied would likely immediately set up an “alternate root,” competing with the one administered by the Internet Assigned Numbers Authority, using any of a number of trivial means. If one country did so, others would likely follow suit, leading to an exodus from the consensus Internet that allows general interconnection. Revocation of certificates associated with domain names At least two kinds of cryptographic certificates and signatures are potential mechanisms for sanction, and we discuss each independently. First, revocation of SSL certificates, as mentioned in Mr. Nabok’s letter: SSL (“Secure Socket Layer”), which has been succeeded by TLS (“Transport Layer Security”), is a certification mechanism principally used to authenticate and encrypt connections from web browsers to web servers. Such certificates are used in online commerce and banking, among other less visible roles. Certificates are issued by Certificate Authorities (“CAs”), of which there are approximately 700 in existence, [4] a significant number of them are controlled, directly or indirectly, by national governments or intelligence agencies. Any one of these organizations may issue a certificate to anyone, certifying that they are the authentic administrator of any domain. [5] The revocation of certificates associated with governmental or military domains is not an effective sanction, because the targeted government is likely already using a Certificate Authority under its own control, and if it is not it can easily cause any CA under its influence to issue a replacement certificate. The revocation of certificates associated with private subdomains (for instance, redcross.ru, citibank.ru) would render communications between these organizations and their constituencies insecure and vulnerable to cybercrime until they were able to get new certificates issued; decreasing law and order and rendering a civilian population more vulnerable to crime is not an effective sanction. Alternatively, adding existing certificates for propaganda outlets to Certificate Revocation Lists or using Online Certificate Status Protocol (OSCP) to flag them as revoked would warn casual users such websites are problematic and require them to take explicit action to proceed beyond the warning. These techniques are, however, limited: they must generally be done by the same CA that issued the original certificate, which may not be outside the influence of the sanctioned government. We thus believe this to be an effective sanction in the cases where it is possible to invoke: it is specific, easily centrally implemented and rolled back, and has little chance of unintended broader consequences. Revocation of DNSSEC signatures on DNS delegations The cryptographic signatures used to authenticate domain names are known as DNSSEC, or DNS Security Extension signatures. Clients can evaluate the veracity of the mappings between domain names and IP addresses, which is what allows them to find and connect to resources on the Internet, by cryptographically validating the DNSSEC signature associated with a domain name. If a top-level domain were removed from the DNS root, the DNSSEC signature that validates the delegation of that domain would consequently be removed as well. DNS clients or resolvers still in possession of the old information could continue to reach the websites or email addresses identified by a domain, but they would be unable to validate that they had arrived at the right place. The DNSSEC signature validating the delegation of a top-level domain could also be removed while leaving the delegation itself in place. DNSSEC signatures prevent criminals from performing “man-in-the-middle” attacks, impersonating the website of a retail bank, for instance, to capture the user’s authentication information and empty their accounts. Military and high-security networks may use technical mechanisms to ensure that lack of a DNSSEC delegation above a signature under their control, in the DNS hierarchy, will not interfere with their resolution. Regular Internet users, however, either will be confronted with error messages indicating that their bank’s website is an impostor or will not be notified if an attacker stands between them and their bank. Removing the DNSSEC signature validating the delegation of a national top-level domain, whether in association with the removal of the delegation or not, may have little or no effect upon military and other high-security networks, but it would decrease law and order and make ordinary people much more susceptible to cybercrime. Tampering with DNSSEC signatures is thus not an effective sanction. Disablement of DNS root servers Root nameservers are simply those nameservers that hold a static copy of the DNS “root zone,” which is, by its very nature, public information. Essentially any nameserver may be made a root nameserver, simply by telling it to retrieve and cache copies of the DNS root zone. Disabling specific root nameservers has no effect, since they are, by design, not uniquely privileged or in possession of unique information. Disabling all root nameservers is not feasible since it would disable the Internet for everyone, and anyone could, and would, establish new ones. Disabling root nameservers thus has no utility as a sanction. Withdrawal of the right to use Internet Protocol addresses Internet Protocol (IP) addresses, the numeric identifiers by which Internet devices find each other, are allocated by the five Regional Internet Registries that together constitute the Number Resource Organization (NRO). Réseaux IP Européens (RIPE) is the Regional Internet Registry for Europe, the Middle East, and parts of Central Asia, with responsibility for allocating IP addresses to Russian entities. It is within RIPE’s power, if directed to do so by its member organizations through its multistakeholder governance process, to create policy that would effectively withdraw the allocations of IP addresses it has made to Russian organizations. This situation bears some similarities to the governance of domain names, yet it also contains crucial differences. ICANN’s authority extends no further into the DNS hierarchy than the root level, so actions taken by ICANN inherently affect entire top-level domains unitarily, without the possibility of “surgical” actions upon one subdomain and not another. By contrast, the Regional Internet Registries can affect policy on a per-organization (or even finer) basis. Yet rescinding an IP address allocation does not prevent its previous holder from continuing to use it. Indeed, “IP address hijacking” is a relatively commonplace problem on the Internet. Therefore, although it can be precisely targeted, simply rescinding the right to use an IP address allocation is not, by itself, an effective sanction. Note that this process of IP address revocation and RPKI attestation revocation would be a normal consequence of an address recipient (such as the Russian military) failing to pay annual registration fees to its Regional Internet Registry, something that may in fact come to pass as a consequence of financial and banking sanctions. But such a process might take years. Another negative consequence of revoking IP address allocations is that revoked addresses will likely be allocated to a different recipient subsequently, who will then find themselves competing with the original holder for their use. Manipulation of routing security attestations A potential sanction not explicitly requested in Mr. Nabok’s letter is the manipulation of routing security attestations to produce the effect of a partial or complete disconnection from the Internet of specific networks, such as those of the Russian military or propaganda agencies. As with domain names, technical mechanisms exist to cryptographically verify the legitimacy of use of IP addresses. Routing Policy Specification Language (RPSL) and Routing Public Key Infrastructure (RPKI) are the two primary such mechanisms. To be used for communication on the Internet, IP addresses must be “announced” through the routing system, and the routers of the larger and better-secured networks utilize these two mechanisms to ensure that invalid routes are not used by their routers. Smaller and less-secured networks do not typically implement these mechanisms. A manipulation of RPSL and RPKI records in centralized registries would flow through to all networks employing these common routing security mechanisms, some of which would then automatically stop routing traffic to and from the specified networks, without affecting other “adjacent” civilian networks or being subject to trivial “work- arounds.” The manipulation of RPSL and RPKI routing security attestations could be an effective sanction measure, because it appears precise, easily and quickly implemented and reversed, and reasonably effective. However, the appropriation of preexisting routing security mechanisms for use in sanctions, likely unexpected by the participating networks, could conflict with the business or regulatory requirements of those networks, and, crucially, could risk the withdrawal of networks from the system entirely. Such an exodus would both make this potential sanction less effective in the future and have the far greater cost of eroding cybersecurity for the Internet as a whole, the purpose for which the routing security systems were built in the first place. This thus constitutes an unacceptable risk. Other Internet-associated, non-technical sanctions Other sanctions related to the Internet’s operation and governance may be worth considering. These include, for example, the disallowance of sanctioned personnel from participation in Internet governance, policymaking, or standardization proceedings. Such nontechnical measures are outside the scope of this document. Blocklisting Network operators and DNS resolver operators already make use of multistakeholder-governed lists, similar to the way financial lenders use credit scoring agencies, to determine what IP addresses to route and pass traffic between, and what domain names to resolve. This is the mechanism by which persistent spammers and address hijackers are excluded from the network, and by which Internet users are protected from malware and phishing attacks. The technical mechanisms by which such blocking information is passed are mature, robust, instantaneous, and globally standardized. Information related to IP addresses and Autonomous System Numbers is mostly carried over BGP feeds, while information related to domain names is mostly carried over RPZ feeds. Both mechanisms are implemented by essentially all large operators globally. Blocklisting IP addresses and Autonomous System Numbers has all of the advantages of address block revocation or manipulation of routing security attestations, without the drawbacks. It allows network operators to block both the acceptance of routes and the passage of traffic, each or both of which may be appropriate in different situations and in response to different threats. Blocklisting of domain names allows full precision and specificity, which is the problem that precludes action by ICANN. The system is opt-in, voluntary, consensual, and bottom-up, all values the Internet governance community holds dear. Yet, at the same time, it has achieved broad adoption. We conclude that the well-established methods of blocklisting provide the best mechanism for sanctioning both IP routes and traffic and domain names, and that this mechanism, if implemented normally by subscribing entities, has no significant costs or risks. Our conclusion is that blocklisting of IP addresses, Autonomous Systems, and domain names upon which the multistakeholder community can establish consensus is effective and carries no inherent danger of being over-broad. Once decided upon, it is easily invoked—and equally easily rolled back once the problem is resolved. Most important, it carries no significant costs or risks and is aligned with the Internet’s multistakeholder governance values and principles. References: [1] https://eump.org/media/2022/Goran-Marby.pdf [2] https://www.icann.org/en/system/files/correspondence/marby-to-fedorov-02mar… [3] https://www.ripe.net/publications/news/announcements/ripe-ncc-executive-boa… [4] https://www.eff.org/files/defconssliverse.pdf [5] https://www.techrepublic.com/article/compromised-certificate-authorities-ho… Best, Niels -- Niels ten Oever, PhD Postdoctoral Researcher - Media Studies Department - University of Amsterdam Affiliated Faculty - Digital Democracy Insitute - Simon Fraser University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail(a)nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 Read my latest article on Internet infrastructure governance in Globalizations here: https://www.tandfonline.com/doi/full/10.1080/14747731.2021.1953221

2 1

Appeal of the European Network Engineers
by Daniel Karrenberg 10 Mar '22

10 Mar '22

Keep the Internet Open ====================== Appeal of the European Network Engineers ---------------------------------------- We have worked hard to keep the Internet available in Europe and surrounding areas during the Covid pandemic. The Internet infrastructure is essential for the safety, security and well-being of all people living here. Due to the growing international tensions in this part of the world we hear calls to deliberately harm interconnections and the functioning of the network. We realise that the Internet is being used for purposes that many of us deplore. However this cannot be a reason to harm the infrastructure itself and prevent the good and often essential things that depend on it. We urge everyone to consider this carefully and not only refrain from harming the operation and interconnection but to actively work to keep the Internet running and maintain interconnections with all parts of our region. In particular we call on all governments and everyone involved with the governance of the Internet to do everything they can to enable us to keep the Internet infrastructure operational throughout the RIPE region. We will do our part as well as we can. <Signatures> ------------------------------------------------------------------------ The purpose of this appeal is to influence everyone considering actions that would make it harder for us to keep the Internet running. In particular it is intended to provide guidance and support to Internet governance bodies like the RIPE NCC. It will only work if many individuals sign up to it publicly. Individuals considered close to the current conflicts will have special weight here! You can sign this appeal by mailing a signature line of the form Name, Place, Countrycode to <sign(a)keepitopen.net>. Please add a very short statement why you consider yourself a network engineer. Choose the place that best describes who you are; you do not have to be there right now. We will only publish the signature line and nothing else. We will delete your e-mail messages as soon as they are processed. Signatures will start to be published when we have collected at least 256 originating from throughout the region. We will start publicising this appeal once we have at least 1024 signatures. [Please spread the word.](https://keepitopen.net) Thank you for your support! Daniel Karrenberg, Roermond, NL

2 2

New on RIPE Labs: The RIPE Chair Team Reports - February 2022
by Alun Davies 07 Mar '22

07 Mar '22

Dear colleagues, The RIPE Chair Team shares updates on events and developments that have been taking place across the RIPE community this February. Read more on RIPE Labs: https://labs.ripe.net/author/mirjam_kuhne/the-ripe-chair-team-reports-febru… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

RIPE Community session on proposed revised PDP - Minutes and draft version 2
by Mirjam Kuehne 06 Mar '22

06 Mar '22

Dear colleagues, On 26 January we held an online meeting to gather feedback about the revised Policy Development Process (PDP). The recordings, minutes and slides can be found here: https://www.ripe.net/participate/ripe/ripe-community-plenary/minutes/revise… Below you can find a short summary of the main points discussed at the meeting. Based on this feedback we adjusted the draft document and created a new red-lined version: https://www.ripe.net/publications/docs/ripe-documents/other-documents/polic… Please review the changes carefully and provide any additional feedback before 16 March 2022. Kind regards, Mirjam Kühne ============ Meeting Summary: The overall sentiment was to rely on community consensus and common sense as much as possible and to keep formalism at a minimum. 1. Author and Ownership of the Document There was general agreement to make a distinction between the author and owner of the PDP: the community should be listed as owner of the PDP and the RIPE Chair as the author of the document. [1] 2. Scope of the Document There was agreement to shorten the introduction of the document to clarify that the PDP only refers to policy. There was also agreement to keep the section about values and principles. 3. Changes to PDP Most people agreed that the scope of the Policy Development Process should be limited to creating policy. It should not be used to change the PDP itself or other RIPE governance documents. It was suggested however to carefully manage the change process including clear deadlines and announcements to ensure proper community consensus building. 4. Re-introducing Informal Discussion Step There was strong agreement to re-introduce this step and that gathering support prior to a formal proposal is crucial. 5. Appeals Procedure – Process, Deadlines, Recusals There was general agreement to have a well defined appeals procedure with clear deadlines and a certain level of formalism. Some people suggested to create a separate appeals body. Others felt that it will be difficult to find people and that the WG chairs tend to have experience with the PDP. 6. Editorial Changes There was no disagreement about the suggested editorial changes. --- [1] There was a question if the RIPE Vice Chair should also be listed. However, ripe-714 provides the option for the RIPE Chair to delegate to others, e.g. a Vice Chair.

2 1

Offer of help for Ukrainian providers. Please help us share this message widely.
by Simon Besteman 03 Mar '22

03 Mar '22

To whom it may concern, please help us share this message widely among the Ukrainian internet community. The Dutch Cloud Community offers technical assistance to the Ukrainian hosting and cloud industry to help them continue their operations during the attack on their nation. The hosters and cloud providers from the Netherlands acknowledge the extreme hardship of our Ukrainian colleagues. As a community, we passionately believe in a free and open internet, and we want to offer our help to keep the Ukrainian internet safely up and running during these dark hours. Effective immediately, Ukrainian hosting and cloud companies, local and national governments and IT companies are invited to submit requests for assistance through the email address: ukraine(a)dutchcloudcommunity.nl Our members collectively are offering a variety of services at no cost for the requester: backups, virtual servers, hosting of websites, mail services, DDOS protection, IPv4 space, Discord services, datacenter services and a range of other services. Just contact us and we’ll coordinate the requests among the Dutch companies that have offered to help. Important to know: we will offer our services to the best of our ability, but we can and will not assist you in setting up offensive activities. For instance, do not ask us to coordinate DDOS attacks or hacking of sites. We will not allow any spam / scanning activities or hosting of malware or other criminal activities and will act upon this if noticed. We want to help you keep your businesses operating, and we want to help information flow freely. Incoming requests will be evaluated on technical and safety requirements, and then spread among the participating companies in our community. We invite you to contact us and submit your requests for assistance, we are ready to start working to help you with your operation. A reminder of the email address we have created: ukraine(a)dutchcloudcommunity.nl. Do not hesitate to submit requests, however large or small. On behalf of the Dutch Cloud and Hosting community, wishing you all the best at this difficult time in your country’s history Simon Besteman Director Dutch Cloud Community

1 0

RIPE NCC Executive Board Resolution on Provision of Critical Services
by Christian Kaufmann 03 Mar '22

03 Mar '22

Dear members, At its meeting yesterday, the RIPE NCC Executive Board approved the following resolution: The RIPE NCC provides critical services to its membership spread across a diverse geographical and political region. The Executive Board of the RIPE NCC believes that the means to communicate should not be affected by domestic political disputes, international conflicts or war. This includes the provision of correctly registered Internet numbering resources. The Executive Board of the RIPE NCC is committed to taking all lawful steps available to ensure that the RIPE NCC can provide undisrupted services to all members across our service region and the global Internet community. The RIPE NCC will publicly document all its efforts to ensure that the registry is not negatively affected by laws, regulations or political developments. —- It is crucial that the RIPE NCC remains neutral and does not take positions with regard to domestic political disputes, international conflicts or war. This guarantees equal treatment for all those responsible for providing Internet services. This is a fundamental reason why the RIPE NCC has been able to maintain its operations in the way it has for the past three decades. It also means that the information and data provided by the RIPE NCC can be trusted as authoritative and free from bias or political influence. Failure to adhere to this approach would jeopardise the very model that has been key to the development of the Internet in our service region. The Executive Board also expresses solidarity with those operators who have the difficult task of maintaining Internet access to assist the people suffering from the terrible effects of armed conflicts and war. Kind regards, Christian Kaufmann Chairman of the RIPE NCC Executive Board

7 6

Register now for RIPE 84!
by RIPE NCC Event Team 02 Mar '22

02 Mar '22

Dear colleagues, We are happy to let you know that registration for RIPE 84 is now open! This RIPE Meeting will take place in a hybrid format in which online and onsite participants can interact with each other using a common platform. Berlin is set to be another exciting host city https://ripe84.ripe.net/register/ RIPE 84 will take place at the InterContinental Berlin from 16 – 20 May 2022: https://ripe84.ripe.net/venue/meeting-venue/ ------------- Ticket Options ------------- Week ticket: EUR 350 Day ticket: EUR 125 Student (week) ticket: EUR 50 Online Attendance: Free! Are you a new LIR? If so, did you know that you have two free tickets to a RIPE Meeting? If you haven’t used them yet, make sure you do for RIPE 84. Find more information at: https://www.ripe.net/participate/member-support/become-a-member/free-ticket… ------------- Accommodation ------------- The InterContinental Berlin is offering RIPE 84 attendees discounted room rates. You can book your accommodation at: https://ripe84.ripe.net/venue/accommodation/ Please note that there are also several other hotels nearby. ------------- Call for Presentations ------------- The RIPE Programme Committee (PC) is seeking presentation proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), workshops, tutorials, and lightning talks at RIPE 84. Find out how to submit a proposal at: https://ripe84.ripe.net/cfp/ Proposals must be submitted using the meeting submission system and no later than 20 March. Proposals submitted after this date will be considered on a space-available basis. ------------- Call for Sponsors ------------- Supporting a RIPE Meeting through sponsorship gives your organisation fantastic exposure in the global Internet community. We offer a range of options aimed to suit organisations of all sizes: https://ripe84.ripe.net/sponsors/become-a-sponsor/ ------------------- RIPE Labs Competition ------------------- RIPE Labs is offering you a free ticket, travel and accommodation to RIPE 84! Submit your article sharing your work and insights about the past, present and future state of the internet for a chance to join us at RIPE 84 in Berlin. You can find out more about the competition and how to enter here: https://labs.ripe.net/author/alun_davies/the-ripe-labs-article-competition/ ---- More information on RIPE 84 can be found at: https://ripe84.ripe.net/ We look forward to seeing you in Berlin or online! For updates about the meeting, follow us on Twitter: @ripemeeting, #RIPE84 Kind regards, RIPE Meetings Organisation Team

1 0

New on RIPE Labs: IPv4 Allocations - Is Fairness Still the Goal
by Alun Davies 02 Mar '22

02 Mar '22

Dear colleagues, An interesting discussion took place last December on whether current policies and procedures for the allocation and transfer of IPv4 resources in the RIPE NCC service region are in line with the original policy intent. To help lend clarity on the issue, Angela Dell’Ara (RIPE NCC Policy Officer) gives an overview of the relevant changes that have come into effect since the RIPE NCC started distributing the last /8 we received from IANA: https://labs.ripe.net/author/angela_dallara/ipv4-allocations-is-fairness-st… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0