RIPE Chair Selection - Next Steps
• 8 min read
Please find below an update from the RIPE Nominating Committee. Three of the NomCom members answer some of the questions you might have about the next steps in the selection process.
Daniel Karrenberg
Based in Western Europe, NL&DE mostly
36
Articles
30
Likes on articles
Based in Western Europe, NL&DE mostly
>>>>>>>>>>>> https://www.ripe.net/about-us/press-centre/publications/speakers/daniel-karrenberg <<<<<<<<<<<< Ample information about his past sins can be found using your favourite search engine. Following are a few additional keywords you might use, arranged by decade: 1980s: GUUG EUUG EUnet unido mcvax cwi RARE iepg RIPE; 1990s: RIPE+NCC rir iana postel terena ebone centr k.root-servers.net; 2000s: dnsmon nsd ris internet+society rssac; 2010s: ripe+labs ripestat ripe+atlas
RIPE NCC Cloud Strategy Framework
• 7 min read
Our cloud strategy framework provides a starting point that we will use when developing cloud implementations in the future. It also forms a solid basis for discussions with the community on specific proposals relating to our services.
Facebook Down and Out in BGPlay
• 4 min read
Following the Facebook outage that took place on 4 October, we saw people looking to BGPlay to get a better view of what went on. Here's a look at what the RIPEstat visualisation has to show us about the event in question.
RIPE NCC and the Cloud: Draft Principles, Requirements and Strategy Framework
• 11 min read
Our draft cloud strategy framework is an attempt to bring everything together in a way that sets out some boundaries, identifies critical elements, and indicates where we need to be strict vs where we can afford to be a little more relaxed. This should hopefully support more clarity regarding how w…
RIPE NCC and the Cloud: Let’s Start Again
• 8 min read
The community’s reaction to our cloud proposal at RIPE 82 was stronger than we expected. We think it’s worth re-starting this discussion, and the first step is to check that we’ve heard you correctly.
CENTR and the RIPE NCC: Two Organisations with a Shared History
• 4 min read
At the Internet Governance Forum this week, we signed an MoU with CENTR, the European association of country-code Top Level Domains (ccTLDs). This seemed like a good opportunity to revisit some of the shared history between our two organisations.
Ethics of RIPE Atlas Measurements
• 8 min read
This article is intended to make RIPE Atlas users aware of ethical issues that could arise when using RIPE Atlas. We do not intend to propose any new formal processes or procedures to address the relevant ethical issues, but we do want to encourage members of the RIPE Atlas community to consider th…
The AMS-IX Outage as Seen with RIPE Atlas
• 3 min read
During the RIPE 70 Meeting in Amsterdam this week (on 13 May around 10:00 UTC), we experienced a network outage at AMS-IX. Let's see how this was monitored by various tools.
IPv6 Darknet Experiment
• 2 min read
Similar to an experiment done for IPv4 address space, Merit is now performing a darknet experiment with the IPv6 ranges that have been allocated to the RIRs. This also includes prefixes allocated to the RIPE NCC.
Registry Data Quality Assessment – Phase 2
• 7 min read
In order to ensure accurate and up-to-date registration data, the RIPE NCC started to evaluate Registry Data Quality (RDQ) in 2009. The second phase has now been finalised and the results are encouraging.
“Daniel One of the contradictions that I have observed in the IETF is that the community maintains a position that it addresses technical issues and not policy, when in reality it sometimes does address policy matters quite explicitly (eg RFC 7258 - Pervasive Monitoring is an Attack) and often does so implicitly (many of the technical decisions have policy implications). Suggesting therefore that it is unreasonable to highlight changing circumstances in legislation etc (the imminent adoption of online safety regulation in the UK and EU) as a possible reason to revisit previous community consensus positions, especially if some time has passed since those positions were reached, seems itself to be unreasonable. The IETF does not operate in a vacuum! Separately, the research referenced by Dan mentions the lack of diversity within the IETF community on a number of axis including gender, ethnicity, geography and thought. It is something of an outlier compared to, for example, the IGF, in that regard and has yet to find a way to embrace the multistakeholder model despite some proposals from the IAB (see RFC 8890 - the Internet is for End Users). I note that we also have a problem engaging newcomers, with significant attrition after they have attended a single meeting. Whilst some of this will be due to some taking advantage of the proximity of a particular meeting with their home base, the culture of the community must also take some of the blame. It should be possible to address the cultural challenges. From my own limited experience of RIPE, the community feels very welcoming, and I'm told that the same is true is other organisations such as ETSI. If we are to cite consensus documents as the reason for doing (or not doing) something, we should take care to ensure that the community is as diverse and representative as possible, otherwise our consensus will not carry very much weight. Andrew”
Andrew, you are not really engaging with my comments, so I assume this was posted as a response to them by mistake.
“Disclosure: I am one of the founders of RIPE and both the first and a current employee of the RIPE NCC. I have also been an IETF participant, working group chair and chair of the Internet Society board of trustees and as such have played a role in IETF governance. Dan, No, the IETF is not perfect and neither is the RIPE community. We all carry the history of actions and prejudices of our individual and collective past into our current structures and attitudes. This is no different elsewhere. As an exercise I advise any representative democracy and their rites, unwritten laws and sometimes obscure networks. Whenever I wish to engage a new group I have to do my homework like you started to do. Nowhere have I succeeded in demanding to re-visit previous beliefs and decisions without knowing them and basing my proposals for a big part on the previous work and traditions of the group I am engaging. Neither have I had much success with challenging the attitudes and customs of the group I wish to engage. "As a new attendee, I argued both that I was not part of or aware of previous discussions (which is reason in itself to reassess the previous consensus), and also that the imminent adoption of online safety regulation in the UK and EU is a strong reason to revisit these discussions." will get you nowhere, neither here nor at the IETF and for a reason. Best Daniel”
A friend has pointed out to me that "Neither have I had much success with challenging the attitudes and customs of the group I wish to engage." was a little to terse. What I meant to say is better expressed like this: Neither have I had much success with starting a new engagement by loudly challenging the attitudes and customs of the group I wish to engage without first making it very very clear that I understand and respect the traditions and beliefs of that group. Of course it is OK to express disagreement, but not without showing appropriate respect for said traditions and beliefs. Again, just friendly suggestions.
“I was at the same side meeting and had a different impression. My article in French: https://www.bortzmeyer.org/filtrage-vie-privee.html”
Spot on! With French style. Cordialment Daniel
Disclosure: I am one of the founders of RIPE and both the first and a current employee of the RIPE NCC. I have also been an IETF participant, working group chair and chair of the Internet Society board of trustees and as such have played a role in IETF governance. Dan, No, the IETF is not perfect and neither is the RIPE community. We all carry the history of actions and prejudices of our individual and collective past into our current structures and attitudes. This is no different elsewhere. As an exercise I advise any representative democracy and their rites, unwritten laws and sometimes obscure networks. Whenever I wish to engage a new group I have to do my homework like you started to do. Nowhere have I succeeded in demanding to re-visit previous beliefs and decisions without knowing them and basing my proposals for a big part on the previous work and traditions of the group I am engaging. Neither have I had much success with challenging the attitudes and customs of the group I wish to engage. "As a new attendee, I argued both that I was not part of or aware of previous discussions (which is reason in itself to reassess the previous consensus), and also that the imminent adoption of online safety regulation in the UK and EU is a strong reason to revisit these discussions." will get you nowhere, neither here nor at the IETF and for a reason. Best Daniel
As a community we know quite well what RIPE is about. People are here for a reason. I am not convinced that we need another meta discussion. Talking about principles we should remind ourselves of those we have had from the very beginning of RIPE: the "RIPE Terms of Reference" https://www.ripe.net/publications/docs/ripe-001. For a document written in 1989 this co-author believes that it holds up pretty well. Even the essence of "a globally interoperable, unfragmented Internet" is there, worded more than 30 years ago as: "RIPE promotes and coordinates interconnection of IP networks within Europe and to other continents." Personally I am happy with these principles even after more than 30 years. They guide us well. Maybe we just need to remind ourselves of these principles from time to time and interpret them in the current context. Should we agree that we need to work on revising our principles, we should start from ripe-001 and word them as much as possible in terms of what we actually *do* .
Deliberate change requires setting goals, working towards them and checking progress. So what diversity goals should we set ourselves. In gender diversity the popular/simplistic goal has been to reflect world population: classical 50/50 or contemporary with more categories. Shane also voices this in the podcast. But is this the right benchmark? Shouldn't we set goals based on the diversity of groups that are closer to our community? I have seen some organisations setting diversity goals based on current ratios: "We will double the percentage of female graduates in five years time." Others base their goals on statistics of a larger population they serve: "We will have double the percentage of female graduates compared with the average of similar programs in Europe." I strongly believe we should set ourselves realistic goals. I also believe that diversity has other parameters than gender and that our efforts on gender diversity should not lead to a loss of other diversity we have already achieved.
Thank you Alexander for the detailed information. Maybe it would be a good idea to develop some recommendations for ISPs outside Russia on how to deal with these developments. Do you think RIPE could and should help to do this?
It is good to hear that the RIRs as institutions organise support for AFRINIC as a fellow institution. My personal thoughts are first and foremost with the AFRINIC staff; they need to pay the bills and sustain their families. I understand that so far AFRINIC has been able to pay salaries. As a community we should stand ready to help the *people* of AFRINIC if that should become necessary. I am aware of a fundraising campaign (https://www.tespok.co.ke/?page_id=14001) and I have personally contributed a small amount. Some AFRICAN friends from the early days suggested that we visibly do something similar as a sister community *if it should become necessary*. Our African friends should know that we stand ready do so if necessary!
Very nice article considering that you have to say 'Do not call us!'. ;-) When using IP addresses to identify the source of abuse it is important to keep in mind the possibility of the source address being 'spoofed'. Especially in denial of service attacks what appears to be the address of the source may in fact be the address of the victim. Designers and implementers of automated processes that use IP addresses should take great care about the semantics of IP addresses too. As an author of RFC1918 I regularly get e-mails from automated tools asking me to stop hacking or attacking someone. The only positive development here is that I have not had a query from an LEA about private IP addresses in the past two years or so.
I cannot resist to point out that the privacy policy on the web site of this initiative says: 'Privacy Policy coming soon'.
Showing 22 comment(s)