- ripe-list - mailman.ripe.net

RIPE Database Requirements Task Force: Final Draft Published
by Bijal Sanghani 26 Oct '21

26 Oct '21

Dear Colleagues, We have now published the final draft of the RIPE Database Requirements Task Force: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/requirements-f… This version takes into account the feedback received from the community on our intermediate draft published in July. Thank you all for providing feedback. Here are the main changes/additions; - Added a word about ENUM and geolocation - Added a section to explain the document structure - Clarified when the historical data was first added to the RIPE Database and when it was made available to users - Rephrased the research purpose and added a separate section Please note that each recommendation will be considered separately by the community and the relevant working groups. Kind regards, Bijal Sanghani For the RIPE Database Requirements Taskforce

3 2

New on RIPE Labs: SEE Community Resilience in the COVID Crisis – Were We Ready?
by Antony Gollan 21 Oct '21

21 Oct '21

Dear colleagues, In a new article on RIPE Labs, Jelena Cosic reports back from the recent SEE 9 virtual meeting and looks at how the community has fared under COVID-19: https://labs.ripe.net/author/jelena/see-community-resilience-in-the-covid-c… Kind regards Antony Gollan Communications Team Manager RIPE NCC

1 0

Reminder: NRO NC Call for Nominations
by Hans Petter Holen 14 Oct '21

14 Oct '21

Dear colleagues, This is a reminder that the call for nominations from the RIPE NCC service region to fill one seat on the Number Resource Organization (NRO) Number Council (NC) is open. The three-year term of Nurani Nimpuno ends on 31 December 2021. The election for this NRO NC seat will take place during the RIPE 83 meeting that will be held virtually from 22-26 November 2021. All members of the Internet community who are attending the RIPE Meeting (except Regional Internet Registry staff members) may vote in the election. The deadline for nominations is Wednesday, 27 October 2021. Any individual residing within the RIPE NCC service region is eligible for nomination, except Regional Internet Registry (RIR) staff members. Self-nominations are permitted. The nomination process is available at: https://www.ripe.net/nov-2021/nro-nc-nomination-process Please send your nominations to <nominations(a)ripe.net> by 23:59 UTC on 27 October 2021. All confirmed nominations will be listed on the RIPE NCC website by 1 November 2021. All nominees may submit a written statement in support of their nomination for publication on the RIPE NCC website. Other people can express support for nominated individuals by sending an email to <nominations(a)ripe.net>. Expressions of support will also be published on the RIPE NCC website. To find out more about the NRO NC and the election process, please see: https://www.ripe.net/nro-nc/nominations-nov-2021 Regards, Hans Petter Holen Managing Director RIPE NCC ---------------------- Important dates ---------------------- 27 October 2021: Deadline for NRO NC nominations 1 November 2021: Deadline for all confirmed nominees to be posted on the RIPE NCC website 22-26 November 2021: Election to fill NRO NC seat during the RIPE 83 Meeting 2 26 November 2021: Announce successful candidate at closing plenary of RIPE 83

1 0

New RIPE Code of Conduct
by Mirjam Kuehne 06 Oct '21

06 Oct '21

Dear colleagues, The RIPE Code of Conduct Task Force published the new draft code of conduct in July. The deadline for comments and feedback ended on 17 September. Both on the mailing list and during the online session the Task Force organised, we received positive feedback about this new version: https://www.ripe.net/participate/ripe/code-of-conduct A number of suggestions were made earlier that the Task Force incorporated in this final version of the code of conduct. I am confident that there is consensus now to move ahead and implement this new code of conduct. Starting tomorrow, 28 September 2021, it will apply to all participation in RIPE, including RIPE mailing lists and RIPE Meetings as described in the scope of the document. I would like to thank the Task Force members for the great work they’ve done so far. Having this updated code of conduct in place is an important and positive step for us as a community. The Task Force will now focus on the two remaining documents as described in their charter: https://www.ripe.net/participate/ripe/tf/code-of-conduct-task-force Kind Regards, Mirjam Kühne RIPE Chair

3 4

PRESS ARTICLE: Africa internet riches plundered, contested by China broker
by Carsten Schiefner 05 Oct '21

05 Oct '21

All - as this has been mentioned on the list before, I'd like to draw your attention to this Associated Press article of 1 Oct 2021: Africa internet riches plundered, contested by China broker https://apnews.com/article/technology-business-africa-china-uganda-5462f03b… which I found helpful to better understand some details and the background of the issue. The article has been republished by various newspapers - resp. on their respective websites. Best, -C.

1 0

Re: [ripe-list] [db-wg] Reminder: RIPE Database Requirements Task Force – Draft Report Published
by Bijal Sanghani 04 Oct '21

04 Oct '21

Dear Denis, Thank you for your feedback. You will find the task force’s reply to your suggestions and comments below. If you need clarifications feel free to contact us. -- Data management principles Regarding data accuracy, we decided to stick with the current wording as we think it encompasses all database users and not only network operators. Regarding data minimisation, the question of “data inheritance” is interesting but probably out of scope for this document. -- Purposes We chose to use existing RIPE Database purposes to build our requirements list as they were still relevant. Even though there is a use case for geolocation, we didn’t think that it constituted a purpose. The RIPE Database only offers partial geolocation data and the “geoloc:” attribute data is user-maintained and mainly unreliable. The task force suggested to rephrase the research purpose to “enabling research and analysis into IP networking in the RIPE region”. This way, it will also include IP research from the general public which was one of your suggestions. We will also give this purpose its own section and add more background information. — Requirements 5.1.2 Requirement: IPv4 PA assignments Under the current policy which we are recommending to remove, for reasons previously explained (https://ripe82.ripe.net/archives/video/542/ <https://ripe82.ripe.net/archives/video/542/>), there are a lot of discrepancies in how resource holders document assignments and it’s already possible for them to delete assignments. Also, removing this policy requirement will be in line with the data minimisation principle. 5.1.3 Other consideration: Using the RIPE Database as an IPAM solution As stated in the document, IPAM goes against the data minimisation principle and is not directly matching the purposes of the RIPE Database. This is why we didn’t consider it as a requirement. 5.1.4 Requirement: Historical data and personal data filtering The historical data was added since 2001, but we implemented a feature to return historical data in 2013. We will edit the draft to make the distinction. We also appreciate your suggestion regarding historical data to: “Make as much historical data publicly available as is legally permitted.” but decided to stick with the current recommendation. This recommendation came as the result of discussions we had at previous BoFs and seems to be responding to the needs of the community. 5.2 Purpose: Provisioning of Reverse Domain Name System (rDNS) We didn’t identify any specific requirements that will be worth mentioning in this section. Regarding ENUM data, we will mention it as a side note in the document as it holds a special status in the RIPE Database. 5.3.1 Requirement: Routing information and 5.3.2 Requirement: Maintaining accurate routing origin information These requirements were developed in line with today’s best practices and might indeed reflect some of the status quo. 5.3.3 Other Consideration: Routing Policy Specification Language (RPSL) We do think that it’s worth clarifying that RPSL is not a requirement of the RIPE Database and that the relevant working groups should look into deprecating this old standard. 5.4 Purpose: Facilitating Internet operations and coordination Adding a stakeholder list is complicated as you’ll always end up excluding some people even if it’s a non-exhaustive list. This is why the task force decided to stick with a broader definition of RIPE Database users. Kind regards, Bijal Sanghani > On 11 Aug 2021, at 13:50, denis walker via db-wg <db-wg(a)ripe.net> wrote: > > Colleagues > > The DBTF asked for comments about their latest draft document by 13 > August. So far I have seen only one comment. So I am taking off my > co-chairs hat and putting my devil's advocate hat on again and I will > make some comments of my own and raise a number of questions. I make > no apologies for the length of this email and I accept some people > won't read it for that reason. But as the DBTF is approaching the end > of it's work, there are many things that need to be said about this > document. Whether the DBTF can or will or should take these into > account is for others to decide. The document can be found here > https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… > > '4.1 Data accuracy' > Here you say data should be accurate for "all parties involved in > network operations.". But In section 3 you accept that there are > different user groups who use the database now. So data should be > accurate for "all parties.". It may sound irrelevant, but you also > accept in section 3 that there is friction between different user > groups. If this document appears to favour one user group, network > operators, it may be used in the future to argue against changes that > benefit user groups other than network operators. > > '4.3 Data minimisation' > You only refer to personal data and your definition only relates to > limiting data to match the purposes. While they are valid examples, > they are not the only issues regarding data minimisation. You haven't > covered the issue of inheritance for example. Having one "tech-c:" > attribute which is inherited by 10,000 INETNUM objects is far better > than having 10,000 identical copies of that one piece of data. The > concept of inheritance is certainly within scope of the business > requirements as it can lead to improved data accuracy. > > '5. Purposes, Requirements and Recommendations' > You start by saying: > > "To produce its requirements, the task force looked at four purposes > of the RIPE Database. > > ● Providing authoritative and accurate registration of Internet number resources > ● Provisioning of the Reverse Domain Name System (rDNS) > ● Publishing routing policies by network operators (RIPE IRR) > ● Facilitating Internet operations and coordination > > Even though this document is based around the four purposes mentioned > above, the task force is aware that there is a fifth purpose that > should be taken into consideration: > ● Enabling scientific research into network operations and topology" > > This suggests that the DBTF considers that these 5 items are the only > purposes of the RIPE Database. Although you say the fifth purpose > "should be taken into consideration", you don't consider it in this > document. This confuses me about the nature of this document. If it is > to be the business requirements of the RIPE Database how can you not > discuss one of the defined purposes? > > When I wrote the first set of Terms & Conditions for the RIPE Database > 10+ years ago (which were approved at the time by the community) the > purposes were listed as: > > ● Ensuring the uniqueness of Internet number resource usage through > registration of information related to the resources and Registrants > ● Publishing routing policies by network operators (IRR) > ● Facilitating coordination between network operators (network problem > resolution, outage notification etc.) > ● Provisioning of Reverse Domain Name System (DNS) and ENUM delegations > ● Providing information about the Registrant and Maintainer of > Internet number resources when the resources are suspected of being > used for unlawful activities, to parties who are authorised under the > law to receive such information. > ● Scientific research into network operations and topology > ● Providing information to parties involved in disputes over Internet > number resource registrations to parties who are authorised under the > law to receive such information. > > Do you not regard these items as valid purposes of the RIPE Database now: > > ● Providing information about the Registrant and Maintainer of > Internet number resources when the resources are suspected of being > used for unlawful activities, to parties who are authorised under the > law to receive such information. > ● Providing information to parties involved in disputes over Internet > number resource registrations to parties who are authorised under the > law to receive such information. > > All of the 5 purposes you have listed are the historic purposes of the > RIPE Database. Has the DBTF not recognised any new, valid purposes of > the RIPE Database? (Besides IPAM that you have rejected.) Accepting > that some historic purposes have been dropped (like forward domain > registrations) do you consider that the purpose of the RIPE Database > in 2021 has not moved on or developed from what it was, say, in 2001? > It seems to me that there is a fundamental piece of information > missing from this document. Who are the main user groups who enter > data into and consume data from the RIPE Database, for what purposes > and what data do they need? Do they have an equal stake or are there > priorities? Do conflicts exist between stakeholders and data > requirements? I don't see how you can document the business > requirements and functionality without first defining the main > stakeholders, actors, end users, data consumers and their data > requirements. (Technically the Business Enterprise Requirements would > be followed by the Stakeholder Requirements then the Solution > Requirements. But as this document is shifting between requirements > and functional review it seems to have merged all these into one, but > without including some key elements.) > > In section 3 you say: > > "Some database users, such as ISPs or IXPs, have been part of the RIPE > community for years, while others are relatively new, such as Law > Enforcement Agencies (LEAs) or regulators. These user groups have > different needs and expectations regarding the database which is > creating friction within the community." > > So you have recognised that there are new user groups with different > needs but this is not reflected in the historic purposes of the > database. The purposes clearly have changed but these changes have not > been recognised or formally accepted. Hence the friction you refer to. > Unless we address the purposes these new user groups want from the > database this friction is not going to be resolved. If these issues > are not addressed then I would consider this document does not fully > represent the business/stakeholder requirements. > > Geolocation is another purpose the database has long been used for and > this has taken on a higher profile recently by a significant user > group. This does not fit under the purpose 'Facilitating Internet > operations and coordination' as some other features do like abuse > contact definitions. Being a completely separate and external service > that requires some new data to be stored in the RIPE Database for this > service to function it is a different type of purpose to the other > defined purposes. This should be listed in this document as a new > purpose. > > Should it be generally accepted now that the RIPE Database is a public > registry of all users of blocks of IP addresses? This would be similar > to the public set of domain name registries. Anyone who wants to know > who operates a domain name can look it up in the appropriate domain > registry. It has become quite common that anyone who wants to know > who is using a block of IP addresses will look up those addresses in > the RIPE Database. Has it evolved from just being a tool for network > operators to a more general public service? Is it time to recognise > this as a purpose of the RIPE Database? > > '5.1.2 Requirement: IPv4 PA assignments' > You refer to "A core reason for registration of IPv4 PA assignments" > in the address policy. It should be pointed out that this is also a > 'historic' reason. Perhaps in 2021 it is not the only reason. If it is > accepted that the RIPE Database has evolved into a public service > registry and this is defined as a purpose of the database then that > provides another reason for documenting all assignments in the > database. > > For the DBTF to recommend not deleting assignments after making them > optional is like a government recommending wearing masks after > dropping the legal requirement. Most people don't wear masks now. Most > optional assignments will probably be deleted. Why would operators > spend time and money maintaining optional assignment data? Unless > there is a clear benefit to the operator or some greater need covered > by a requirement to provide assignments, I suspect most will simply > ditch this public data. This would destroy the RIPE Database as a > public service registry. If some operators maintained the optional > data and some deleted it then we end up with an incomplete and > inconsistent data set, which is what happened with forward domain > data. > > '5.1.3 Other consideration: Using the RIPE Database as an IPAM solution' > According to your survey results almost 54% of the respondents said > they use the RIPE Database for their IPAM. That is the second largest > percentage of all the listed uses. Only slightly behind general number > resource management at 57%. Given the level of usage, why do you not > accept IPAM as a valid, new purpose of the RIPE Database? Many years > ago forward domain data was stored in the database. Many of the > smaller domain registries used the database as their primary registry > database. Most of the bigger registries only published a limited data > set and used a referral mechanism to direct queries to their whois. > One of the main reasons for deleting this data was the inconsistent > and incomplete, public facing, data set. What is your reasoning for > recommending not accepting IPAM as a new purpose of the database and > maybe a resource holder benefit? > > '5.1.4 Requirement: Historical data and personal data filtering' > This is the third draft doc you have published containing this statement: > "Since 2013, the RIPE Database has stored historical data, as > requested by the RIPE community" > and this is the third time I have commented that this is simply not > correct. The database contains every version of every object that has > ever existed since April 2001. Historical queries were implemented in > 2013, but the data was already there going all the way back to 2001. I > trust the DBTF will finally correct this in the next draft. > > Your recommendation makes no sense whatsoever. Availability of > historical data should depend on the type of data, not on the use case > for accessing it. To suggest that researchers could be given more data > access on a case by case basis is madness. The principle of > availability of historical data is basically that operational data is > available, personal data and any data subject to privacy is not > available. There is no reason to limit any of the available data by > user group or use case. It should all be publicly available. No user > group or use case is going to make the excluded personal and privacy > data available to anyone for very strict legal reasons. (In particular > the right to be forgotten granted by GDPR. Of course that can be > overruled by a court order but that is an exceptional use case.) > > The recommendation should be to make as much historical data publicly > available as is legally permitted. I believe some of the data > currently redacted could still be made available. I won't go into > details here as it gets too technical for this doc. > > '5.2 Purpose: Provisioning of Reverse Domain Name System (rDNS)' > ENUM may be a small part of this but it is still significant and > should not be overlooked in terms of defining the purpose of the RIPE > Database. > > "The task force didn’t find the need for any requirements or > recommendations attached to this purpose and therefore recommend > maintaining the current status quo." > Comments like this really confuse me. It again makes me question what > is this document? If it is a business requirements document then you > cannot say there is no need to document any requirement for one of the > purposes of the database. > > '5.3.1 Requirement: Routing information' > The DBTF makes a long list of recommendations, but the whole list is > simply a definition of the status quo. If you want to document this > functionality that is fine, but that is then inconsistent with the way > you have handled other functionality. There is nothing new or > different in these recommendations so you could have said the same as > you did for rDNS "we recommend the status quo". > > '5.3.2 Requirement: Maintaining accurate routing origin information' > Again the list of recommendations are simply the status quo. I find > this very confusing. Initially you appear to be recommending > something. But you are only documenting the current practise. > > '5.3.3 Other Consideration: Routing Policy Specification Language (RPSL)' > I think this section is out of scope for this document. This is choice > of technology and technical implementation. First of all, what the > DBTF says here is not strictly accurate. The RIPE Database data model > is 'based' on RPSL and RPSLng. It never has been a strict > implementation. Although the RPSL standard may not have been > maintained for decades, the implementation in the RIPE Database has > been modified, added to and cut down many times according to the needs > of the RIPE community. The way data is input and output does not need > to exactly match the way data is stored internally in the database. > All the data, not only the routing information, is currently still > stored internally in an RPSL like format. This is because the > community has never had the appetite to redesign the data model, not > even with a small iterative approach (despite numerous attempts by > myself to push for this over the last 10 years). > > If this document is the business requirements then it may be in scope > to recommend a review of the format(s) of data input to and output > from the database. The internal representation of that data is > definitely out of scope. Even discussing what detailed routing > information is useful is more for the level of technical specification > than a high level business requirements document. > > '5.4 Purpose: Facilitating Internet operations and coordination' > "The RIPE Database should facilitate communication and cooperation > among stakeholders for the following reasons:" > This needs to say, "for reasons including the following:". The list is > not exhaustive now and there may well be other reasons in the future. > > 'Accuracy' > (hair splitting comment) RFC7020 does not define 'registration > accuracy'. It simply uses the words as in "provide accurate > registration information". So what 'accurate' means in terms of > registration information does not appear to have been defined > anywhere. I think correct would be a more appropriate word than > accurate. > > 'Resource Holder:' > It should say "allocated or assigned....from the RIPE NCC directly" to > be correct. > > General closing comment from me.. > Having read this document several times I am still confused about what > it is. It is not (some form of) a Requirements document, nor is it a > review of RIPE Database functionality. In either of those cases it > only presents a select subset of what would be needed. What it appears > to be, to me, is mostly a review of RIPE Database functionality that > has been the subject of (recent) discussion and has outstanding open > issues, with some requirements added in some cases. But even that is > not complete. > > I really do appreciate the work the task force members have done. I am > just not sure how to interpret the outcome. > > In the first bof in Iceland, Daniel's opening remark was "it is time > to stop tinkering around the edges...". Looking around the room at the > time I saw a lot of heads nodding in approval at that comment, even > from some of the 'old grandees' of the community. Unfortunately most > of this document, in my opinion, is still tinkering around the edges. > > I don't know if the DBTF was meant to document where we are now with > the database or produce a guiding light to move onwards and upwards. > Given that there are many recommendations it suggests it was to be the > way forward. For me it falls well short of taking me to the place I > imagined after listening to Daniel's inspiring speech. Perhaps an > opportunity missed....or maybe I misunderstood the destination and/or > route...or maybe that is the next step? > > cheers > denis > > On Wed, 11 Aug 2021 at 12:26, Bijal Sanghani via db-wg <db-wg(a)ripe.net> wrote: >> >> Dear all, >> >> A gentle reminder for feedback on the report the RIPE Database Requirements Task Force published last month. >> >> Please let us know if you have any questions or concerns on the draft or if you’re happy with our recommendations. This will give us input into finalising the report which we plan to publish before RIPE82. >> >> We look forward to your feedback, thank you for your time - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… >> >> Kind regards, >> Bijal Sanghani >> >> >> >> On 1 Jul 2021, at 13:31, Bijal Sanghani <bijal(a)euro-ix.net> wrote: >> >> Dear colleagues, >> >> The RIPE Database Requirements Task Force has just published a draft report for your review: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… >> >> In this third draft, we’ve added new recommendations and edited our document based on feedback received via emails, survey and during our third BoF in May. >> >> Please review this draft and share any comments on the ripe-list before Friday, 13 August 2021. >> >> The task force will reconvene in August to discuss the feedback received and work on its final report that will be published ahead of RIPE 83. >> >> We look forward to your feedback. >> >> Best Regards, >> >> Bijal Sanghani >> >> >> >> >> >> >

2 1

New on RIPE Labs: The RIPE Chair Team Reports - September 2021
by Alun Davies 04 Oct '21

04 Oct '21

Dear colleagues, With summer well and truly behind us, the community is back in full swing, coming together in a whole variety of endeavours and events to address old and new challenges in network operations, policy development, sustainability, and much more. Here's your September update from the RIPE Chair team: https://labs.ripe.net/author/mirjam_kuhne/the-ripe-chair-team-reports-septe… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Register now for RIPE 83
by RIPE NCC Event Team 29 Sep '21

29 Sep '21

Dear colleagues, RIPE 83 will be held as a virtual meeting and will take place from 22 – 26 November 2021. You can now register for free at: https://ripe83.ripe.net/attend/register/ ------------- RIPE 83 Conference Platforms ------------- We are pleased to inform you that the RIPE 83 Meeting will use Meetecho as its conference platform and SpatialChat as its virtual networking space. In addition to Meetecho, you will be able to watch the presentations live on the RIPE 83 website and on YouTube. Please note that in both cases, there will be no separate IRC channel or chat functionality. If you would like to participate in the discussions and ask questions, you will have to register for the meeting and join Meetecho. More information on how to participate to the meeting is available on the RIPE 83 website: https://ripe83.ripe.net/attend/how-to-participate/ ------------- Programme ------------- The RIPE 83 Meeting plan uses the CET time zone (UTC+1): https://ripe83.ripe.net/programme/meeting-plan/ -- Plenary Sessions The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, lightning talks and BoFs. https://ripe83.ripe.net/submit-topic/cfp/ -- WG Sessions Each working group has a dedicated session in the RIPE Meeting agenda for presentations on topics relevant to the working group’s agenda. If you want to present in one of the WGs, get in touch with the relevant WG chairs via email: https://ripe83.ripe.net/programme/ripe-wg-chairs/ ------------- RIPE Meeting Mentoring ------------- Experienced RIPE Meeting attendees can help newcomers make the most of their meeting by volunteering to be a mentor. We match mentors with mentees based on interests and areas of expertise. You can sign yourself up to be a mentor or mentee when you register for the meeting. The deadline is *7 November*. Learn more at: https://ripe83.ripe.net/attend/mentoring-programme/ ------------- Register to vote in the NRO NC election ------------- The election to fill one seat on the Number Resource Organization Number Council (NRO NC) will take place during RIPE 83. All members of the RIPE community who are checked in to attend the RIPE 83 Meeting, except Regional Internet Registry (RIR) staff members, may vote in the election. You will have the option to register to vote in the NRO NC election while completing your RIPE Meeting registration. More details are available at: https://ripe83.ripe.net/programme/parallel-events/nro-nc-elections/ ------------- Call for Sponsors ------------- Supporting a RIPE Meeting through sponsorship gives your organisation fantastic exposure in the global Internet community. Get in touch with the RIPE Meeting team if you are interested in sponsoring RIPE 83: https://ripe83.ripe.net/sponsors/become-a-sponsor/ ---- More information on RIPE 83 can be found at: https://ripe83.ripe.net/ For the latest updates, you can follow us on Twitter at @ripemeeting and by using the hashtag #RIPE83. Best regards, RIPE Meetings Team

1 0

Re: [ripe-list] [ncc-announce] [news] Using Third Parties to Automate Our Due Diligence
by Erik Bais 21 Sep '21

21 Sep '21

Hi Felipe, Thank you for the announcement. ( I cc: the RIPE list, as that will allow all RIPE community members to read the question and your reply. ) Could you provide insight in where those companies are located, which legal jurisdiction is used for the agreement with them and where the data is going to be stored that is send to them of the involved companies ? I assume that most of the parties involved the RIPE NCC are dealing with a Dutch entity .. but is that the case and is Dutch law applicable for the agreement between the RIPE NCC and them ? Especially as we are dealing with checking ID's .. the location where those are going to end-up .. is something that some of us might want to have that kind of info. Kind regards Erik Bais On 16/09/2021, 14:16, "ncc-announce on behalf of Felipe Victolla Silveira" <ncc-announce-bounces(a)ripe.net on behalf of fvictolla(a)ripe.net> wrote: Dear colleagues, We will soon begin working with third parties to fulfil our mandatory due diligence requirements in two key areas: sanctions screening and the validation of identification documents. To keep you informed, we have published an article on RIPE Labs that explains the relevant processes in more detail: https://labs.ripe.net/author/felipe_victolla_silveira/using-third-parties-t… You can find a summary of the key points below. -- Sanctions screening We need to perform sanctions checks whenever we receive a request to transfer, allocate or assign resources, or to open a new membership/LIR (this also includes End User requests). We need to check the company making the request, its director, the people on its board, and also any other companies or individuals with a share in that company. This adds up to a lot of checks requiring specialised skills and data, further complicated by the administrative and legal differences across our service region. Working with Altares Dun and Bradstreet and also Dow Jones, we will soon start to run automated checks against their databases to verify company information and to check if individuals, companies or any of their signatories are subject to sanctions. We will use the database run by Altares Dun and Bradstreet to quickly verify information about companies and individuals. Dow Jones maintains a list of all sanctioned entities around the world and we plan to run automated checks against this list. This collaboration will allow us to carry out our mandatory due diligence checks in a structured, complete and efficient way. For the vast majority of members, we expect that these checks will basically run in the background and not have any visible impact. We will only need to contact you if there is missing information in Altares Dun and Bradstreet’s database. In this case, we would let you know that they would like to contact you. This is voluntary, and there is no requirement to accept their call. -- Validation of identification documents Validating identification documents is a manual process that we want to automate. Until now, we have worked with fraud specialists to manually authenticate IDs that appear suspicious. We want to apply a uniform approach that verifies all ID information across the board. We will be working with iDenfy, a specialised provider in automated ID validation and remote identification services, to ensure a high standard of diligence and security across all ID documents that we process. Once this is ready, members will upload personal identification documents directly to the iDenfy system using a secure link that we send. In addition to maintaining a high level of security, iDenfy will ensure that this data is deleted within 14 days of being submitted. In line with GDPR, we remain the ‘data controller’. Work is currently underway to integrate our external request processes with iDenfy’s systems and we plan for this to go live on 23 September. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC

2 1

ASO AC Call for Nominations for Seat 10 on the ICANN Board of Directors
by Ulka Athale 16 Sep '21

16 Sep '21

This message is sent on behalf of the Number Resource Organization ------------------------------- This announcement can also be found on the ASO website: https://aso.icann.org/aso-ac-calls-for-nominations-for-seat-10-on-the-icann… ------------------------------- In line with the ASO Memorandum of Understanding and the ICANN Bylaws, the Address Supporting Organization Address Council (ASO AC) is calling for nominations for Seat 10 on the ICANN Board of Directors. The selected candidate will serve for a three-year term, which will begin at the conclusion of the ICANN Annual General Assembly to be held during the ICANN 75 Meeting, scheduled to be held in September 2022. ------------------------------- Eligibility Requirements ------------------------------- All nominated candidates must meet the selection criteria and conflict of interest requirements as outlined in Article 7 of the ICANN Bylaws and will undergo a due diligence review by an independent ICANN contractor. https://www.icann.org/resources/pages/governance/bylaws-en/#article7 ------------------------------- Nomination Process ------------------------------- Community members are invited to submit their nominations by email to <nominations(a)aso.icann.org> by Wednesday, 1 December 2021 at 23:59 UTC. Nominations must include the following information: - Full name of the person being nominated - Contact email address of the person being nominated - Contact telephone number (if available) of the person being nominated - Full name of the person making the nomination - Contact email address of the person making the nomination - Contact telephone number of the person making the nomination ------------------------------- Regional Restrictions ------------------------------- The ICANN Bylaws state that no two directors selected by a Supporting Organization can reside in the same geographic region. The current ASO AC selection for Seat 9, Alan Barrett, resides in the AFRINIC region. Therefore, nominations for Seat 10 will not be accepted from candidates residing in the AFRINIC region. ------------------------------- Important Dates ------------------------------- - Nomination Phase: 15 September 2021 – 1 December 2021 - Comments Phase: 30 December 2021 – 30 March 2022 ------------------------------- ICANN Due Diligence for Nominated Candidates ------------------------------- - Interview Phase: 29 January 2022 – 30 March 2022 - Selection Phase (deliberation): 1st April – 16 April 2022 - Selection Phase (voting): 19 - 25 April 2022 - Announcement of selected candidate: around 30 April 2022 ------------------------------- Further Information ------------------------------- Additional information and updated announcements will be added to the dedicated 2022 Seat 10 election page on the ASO website: https://aso.icann.org/icann-board/icann-board-elections/2022-icann-board-of… Detailed procedures for election of individuals to the ICANN Board of Directors by the ASO AC can be found in Section 9 of the ASO AC Operating Procedures: https://aso.icann.org/documents/operational-documents/aso-ac-icann-board-se… If you have any questions about the elections or the election process, please contact <secretariat(a)nro.net>. ------------------------------- References ------------------------------- - Address Supporting Organization Address Council (ASO AC): https://aso.icann.org/aso-ac/ - ASO Memorandum of Understanding: https://aso.icann.org/documents/memorandums-of-understanding/ - ICANN Bylaws: https://www.icann.org/resources/pages/governance/bylaws-en - 2022 ICANN Seat 10 Election on the ASO Website: https://aso.icann.org/icann-board/icann-board-elections/2022-icann-board-of… ------------------------------- Regards, Ulka Athale Senior Communications Officer RIPE NCC

1 0