- ripe-list - mailman.ripe.net

Re: [ripe-list] LAST CALL EXTENDED to 18 Feb: Draft Document: RIPE Task Forces - Definition and Guidelines
by denis walker 20 Feb '22

20 Feb '22

Colleagues I almost decided not to send these thoughts. But after a couple of other related emails this weekend I decided to go ahead with it. I hope they are received in the same good faith they were written in. This document on Task Forces (TF) is interesting, but one problem is that it assumes that a TF will always achieve it's goals. But what if it doesn't? There are many reasons why it may not do so. The goals may be unrealistic or unachievable. The scope may be too wide. The TF members may not have all the necessary skills. The TF may go off in the wrong direction or produce something that wasn't expected. This document does not include any option for a review or even a reset during the course of a TF's operation. Who would call for such a review and who would do it? It assumes the TF will simply run to it's own conclusion and then whatever it produces will become a RIPE document by default. This document will then be considered as the fulfilment of the TF goals. A TF should not work for long periods of time in a quiet, background mode. Keeping the community well informed of it's work and progress are important elements of a TF. You mention that a TF must have a mailing list for community feedback. I would add that it should be an open list. If the community cannot post to that list it is not a mailing list, it is an announcement board. Criticism is a part of life. Most people in most areas of work have their work periodically reviewed, by a manager or senior. Scientific and engineering papers are often peer reviewed, before or after publishing them. This is what keeps developments moving forward. In this community people who offer an honest, objective, professional critique are themselves sometimes criticised for being critical. To suggest something didn't achieve it's goals (sometimes a polite way of saying it failed) is often considered unacceptable. To criticise a piece of work can be seen as criticising the author, who may then feel offended. Everything that has ever been written has one or more authors, editors, contributors. If we can't criticise a piece of work for fear of offending the author then we can never criticise anything. TFs are no exception to this. Criticising the work of a TF in good faith should not be seen as criticising any member of the TF. The active element of this community is not very large. You may well know all the members of a TF and have a high regard for them as individuals. That does not obligate you to accept every piece of work they ever do. If it is wrong, it is wrong. It should not be wrong to say so. If criticism has a good foundation and strong arguments, then it doesn't matter how extensive the criticism is. It is the piece of work that is being criticised, not the people who produced it. If we can't accept that difference then we are in trouble. A TF is not about being praised for effort. On a personal level that is nice, but if you join a TF it is also expected. A TF is about achieving the stated goals. If they are not achieved it should be OK to say that. To praise a piece of work, that you don't believe is correct, simply because of the effort put into it, does not benefit anyone. This is why it is important for a TF to have regular communication with the community, especially over a long period of operation. When criticisms are made a TF should address those concerns. By saying 'address' it does not mean they must agree with the criticism. But they must acknowledge it and either accept it or provide arguments against or justify dismissing the criticism, just as we would in a policy proposal discussion. For a TF to ignore criticism is not acceptable. Someone needs to oversee this. If a TF does not address criticism, that in itself needs to be addressed. This document covers the issue about not meeting the deadlines for the TF operation. But what about a TF that does not follow it's methodology or charter? Who should monitor this and what actions should be taken? Looking at the various TF web pages they are all different. They have similar sections but with different headings. In some cases it is not easy to determine the goals of the TF. These pages need to be standardised. You refer to RIPE NCC staff members as 'support staff'. Why can they not be full and active members of a TF? For the Data Protection TF, Jochem and I were full members of the TF. At the time we were staff members. Chairs should also be eligible as TF members if they have the appropriate knowledge, experience and/or skills, even if the TF relates to their own working group. TF members should always be listed on the web page. You say TF members should make the RIPE Chair aware of any potential conflicts of interest. These should be published on the TF web page for transparency. You say the TF should give regular updates to the RIPE Chair. They should also regularly update appropriate working group chairs. You only refer to consensus in terms of the final report or a community document. There is no acknowledgement that a TF may need to build a clear community consensus at various stages of it's work. Especially when the absence of such consensus may mean the TF is making fundamental decisions which may affect the validity of the later work. Where consensus is needed on a significant point in the work of a TF, that should probably be discussed in a relevant working group with the chairs determining consensus. I am not trying to put people off being part of a TF, but we do need to define what it means to be a part of one...and accept that a TF may not always be successful, no matter how much effort you put into it. cheers denis co-chair DB-WG > Dear colleagues, > > I believed I had sent this message to you all on 21 January, but > discovered only today > that I had picked the wrong recipient, from the list of those beginning > with “RIPE” > which my mail app presented. > > At that time, Mirjam and I felt that a two-week extension to the last > call would be > appropriate, as the suggestions received in advance of the original > deadline > appeared uncontroversial, but ought of course to be subject to community > review. > > This extension would have expired tomorrow. > This would clearly be unreasonable, so we have set 18 February 2022 as > the new deadline, > > Please accept my apologies for my mistake. > > On 16 Dec 2021, at 15:21, I (Niall O'Reilly) wrote: > > > On 19 Nov 2021, at 8:48, Mirjam Kuehne wrote: > > > > Based on experiences and feedback received from existing Task Forces > > and > > other community members, we put together a document describing what a > > RIPE Task Force is and how it usually operates: > > > > https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-… > > > > Please let us know if you have any questions or suggestions. This will > > be published as a RIPE Document. > > > > Mirjam and I have updated our draft in line with the suggestions we > > received. > > The new version has been placed at > > https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-…. > > > > We consider that it is now time to make a LAST CALL for further > > comment, > > with a deadline of 17:00 UTC on Friday, 14 January 2022. > > > > Shortly after this deadline, we plan to declare that this document has > > Community Consensus and to arrange for its publication as a RIPE > > Document. > > We have updated the text to take account of some suggestions received > during the last call period, and are therefore extending the last call > period until 17:00 UTC on Friday, 18 (not 4) February 2022 to allow > comment > on the latest changes only. > > Updated draft: > https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-… > Tracked changed (PDF): > https://www.ripe.net/resolveuid/4ce5895954d249f59bbb5aaa9f71a421 > > Thanks to Cynthia Revström and Randy Bush for their helpful > suggestions, > and to Boris Duval of the RIPE NCC for preparing the updated document. > > Best regards, > > Niall O’Reilly > RIPE Vice-Chair >

2 1

The RIPE Code of Conduct
by Mirjam Kuehne 20 Feb '22

20 Feb '22

Dear colleagues, I have been thinking about what was said on this list about people being afraid of the Code of Conduct. I did not hear people were afraid of adopting a RIPE Code of Conduct. Instead I heard broad consensus and I believe we managed to build a Code of Conduct that encourages "good behaviour" and positive and constructive engagement. I think as a community we can be proud of that achievement. I have the impression however, that the pure existence of a Code of Conduct can be interpreted in different ways. Some people might see a Code of Conduct as guidance that is there in the background to remind us all how we want to treat each other. In that scenario it might make sense to refer to it from time to time and to nudge each other in a friendly way. Other people might see a Code of Conduct as a threat and as a last resort in case people misbehave badly. In that scenario the Code of Conduct would be used in very exceptional cases only and would potentially have severe consequences for a community member. I believe that the tone in which the RIPE Code of Conduct is written and the way it was accepted and agreed by the community, should make people feel safe and that it would be interpreted more in the former way. I understand from reactions to the list that this is not necessarily the case. How can we change that? I would like to remind you that the work of the RIPE Code of Conduct Task Force is not finished yet and that they are working on the implementation process. I would very much appreciate any feedback from you to make sure we all feel comfortable and safe and protected by a Code of Conduct. It should not be seen as a threat. Kind Regards, Mirjam RIPE Chair

5 5

Draft Document: RIPE Task Forces - Definition and Guidelines
by Mirjam Kuehne 20 Feb '22

20 Feb '22

Dear colleagues, Based on experiences and feedback received from existing Task Forces and other community members, we put together a document describing what a RIPE Task Force is and how it usually operates: https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-… Please let us know if you have any questions or suggestions. This will be published as a RIPE Document. Kind regards, Mirjam Kühne RIPE Chair

4 5

SEE10 RIPE regional meeting CfP
by Jan Zorz - Go6 17 Feb '22

17 Feb '22

The SEE 10 Call for Presentations is now open! The SEE Programme Committee (PC) is now seeking content proposals from the community for the talks at SEE 10. Proposals for plenary session presentations, panels, lightning talks and workshops must be submitted for full consideration no later than 20 February 2022 using the meeting submission system: https://meetings.ripe.net/see-pc/submit-topic/submission-form/ Sorry for late CfP announcement here, it is completely my fault. Please read more at: https://www.ripe.net/participate/meetings/regional-meetings/see/see-10/call… We hope to get from you all as many presentations as possible and finally see again each other at the proper in-person meeting in April in Ljubljana! Cheers, Jan Žorž RIPE SEE PC chairman -- Anything that can be configured can be misconfigured. [RFC5505]

1 0

The RIPE Labs Article Competition is Live
by Alun Davies 15 Feb '22

15 Feb '22

Dear colleagues, We're pleased to announce the launch of the first RIPE Labs Article Competition. To encourage people to share their work and insights about the past, present and future state of the Internet on RIPE Labs, we’re offering as first prize a free trip to come join us at RIPE 84 this May in Berlin, Germany. 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/ Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Rob Blokzijl Award 2022
by Eileen Gallagher 09 Feb '22

09 Feb '22

Hi all, a reminder that the nominations period for the Rob Blokzijl Award 2022 remains open until 18th March at 23:59 UTC. Please give some consideration to nominating someone in your own community and/or the wider industry in the RIPE region who, in your opinion, deserves to be recognised for their work to make the internet and/or internet community better. The Award Committee <https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/> are particularly interested to receive nominations of individuals who, in addition to their own contributions have also supported and enabled others anywhere in the world. That may have been discreetly behind the scenes or as the fundamental part of a larger team effort but deserves recognition in your opinion. While you might think your choice may not be the overall winner, please do take the time to nominate them and share with the Award Committee what good you see they have done and what they have achieved either in their local community, the RIPE community or across the world. For the person nominated, it may be a wonderful boost and after all these months (years) of not seeing people at events, it's a nice gesture to let them know you believe they should be considered for this great award and you never know! We are looking forward to reading their stories. Full details here: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes Eileen (on behalf of the Award Committee) -- Eileen Gallagher CEO INEXwww.inex.ie + 353 87 911 9954 Twitter: @comepeerwithme Internet Neutral Exchange Association Company Limited by Guarantee Registered in Ireland No. 253804. Registered Office: 1-2, Marino Mart, Fairview, Dublin 3.

1 0

Call for Public Comments on the 2021 IANA Performance Matrix Summary Report
by Ulka Athale 07 Feb '22

07 Feb '22

This message is sent on behalf of the Number Resource Organization (NRO) ------------------------------------------ More information can be found on the NRO website: https://www.nro.net/call-for-public-comments-on-the-2021-iana-performance-m… ------------------------------------------ Dear colleagues, As a result of the successful IANA Stewardship transition in 2016, the IANA Numbering Services are currently managed through a Service Level Agreement between ICANN and the five Regional Internet Registries (RIRs). As part of the result of the IANA Stewardship transition, the IANA Numbering Services Review Committee (IANA RC) (https://www.nro.net/iana-rc) was established in 2016. The IANA RC is composed of representatives from each RIR region and advises and assists the RIRs in the review of the IANA Numbering Services. The IANA services are currently provided by Public Technical Identifiers (PTI) (https://pti.icann.org/), which publishes monthly performance reports on the IANA Numbering Services website (https://www.iana.org/performance/numbers). Based on these monthly performance reports, the five RIRs have produced the 2021 IANA Performance Matrix Summary Report, available at: https://www.nro.net/2021-IANA-Performance-Matrix-Summary-Report ------------------------------------------ 30-Day Public Comment Period ------------------------------------------ The IANA RC is now launching a 30-day public comment period to seek comments and input from the community on the IANA numbering services performance and the 2021 IANA Performance Matrix Summary Report, which can be viewed at: https://www.nro.net/2021-IANA-Performance-Matrix-Summary-Report The IANA RC encourages all members of the Internet number community to review the public IANA Performance Matrix Summary Report. Comments on the IANA service performance should be sent to: iana-performance [at] nro [dot] net. The IANA RC will publish an annual report in March 2022 as advice to the NRO EC with its evaluation of the IANA Numbering services. The report will be based on the IANA Performance Matrix Summary Report and on any input gathered from the global number community. The public comment period ends on *Wednesday, 9 March 2022 at 23:59 UTC*. All public comments will be published on the NRO Website in the dedicated IANA RC section (https://www.nro.net/iana-rc-reports) and will be considered as input to the final report by the IANA. At the end of the 30-day public comment period, the IANA RC will meet and evaluate all input to the final report. Kind regards, Martin Hannigan Chair, IANA Numbering Services Review Committee ------------------------------------------ Further Information ------------------------------------------ • IANA Numbering Services Review Committee: https://www.nro.net/iana-rc • Public Technical Identifiers (PTI): https://pti.icann.org/ • IANA Stewardship Transition Archive: https://www.nro.net/internet-governance/iana/iana-stewardship-transition/ • The SLA for the IANA Numbering Services: https://www.nro.net/sla • IANA Stewardship Transition Number Community Proposal: https://www.nro.net/crisp-final-proposal • IANA RC Reports 2017-2020: https://www.nro.net/iana-rc-reports ------------------------------------------ Regards, Ulka Athale Senior Communications Officer RIPE NCC

1 0

DNS4EU Open House: summary and recording
by Chris Buckridge 02 Feb '22

02 Feb '22

Dear colleagues, Thank you to all who joined for the RIPE NCC Open House discussion of DNS4EU on Monday, 31 January. We have posted a summary of some key points and links to the video archive here: https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/ Cheers Chris

1 0

LIR and Member Agreements
by Alex de Joode 01 Feb '22

01 Feb '22

Hi Dennis, Thanks for the lengthy mail, you touch upon many valid points, however one point is not valid: 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. Actually, they can. Under Dutch law you have the option to update the T&C, inform your customers about the change and give them some time (3 months is standard) to either accept or move out. Customers can accept the updated T&C, by either doing nothing or by accepting them explicitly, so the new T&S will be come active on the communicated date. Or they can reject the changes, this means normally the agreement ends. This is a real shocker to many foreign companies (I know from experience), but it is possible and common practise in NL based contracts. -- IDGARA | Alex de Joode | alex(a)idgara.nl | +31651108221 On Mon, 31-01-2022 16h 20min, denis walker <ripedenis(a)gmail.com> wrote: > 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 > >

1 0

RIPE community session on proposed revised PDP - Next Steps
by Mirjam Kuehne 27 Jan '22

27 Jan '22

Dear colleagues, Many thanks to those who particpated in this very productive session yesterday. The recording, slides and minutes will be published soon. I will then send a summary to this list so we can continue the discussion here. Based on that we will publish a new draft Policy Development Process (PDP) document and share it with you. Kind regards, Mirjam RIPE Chair

1 0