- db-wg - mailman.ripe.net

Cleanup Locked Person Objects in the RIPE Database (Implementation on 3rd June)
by Edward Shryane 29 May '20

29 May '20

Dear colleagues, As previously announced, the RIPE Database Team plan to clean up locked person objects in the RIPE Database. We will select person objects maintained by RIPE-NCC-LOCKED-MNT, which are referenced by inetnum allocations or assignments, and re-assign them to the resource maintainer, so they can be properly maintained, and it is clear who is responsible for them. We now plan to perform this cleanup on Wednesday, 3 June 2020. We have already notified the affected LIRs and resource maintainers by email. You do not need to take any action. For more information on the Locked Person Objects Cleanup, please refer to this RIPE Labs article : https://labs.ripe.net/Members/ed_shryane/cleaning-up-locked-person-objects-… Regards, RIPE NCC Database Team

1 0

Fw: Not yet NWIs: Support for IDNs
by ripedenis＠yahoo.co.uk 25 May '20

25 May '20

Please do Leo :) cheersdenis co-chair DB-WG On Friday, 22 May 2020, 18:02:07 CEST, Leo Vegoda via db-wg <db-wg(a)ripe.net> wrote: Hi Nick, On Fri, May 22, 2020 at 8:51 AM Nick Hilliard <nick(a)foobar.org> wrote: > > Leo Vegoda via db-wg wrote on 21/05/2020 23:35: > > At RIPE 80, Denis asked for feedback on some items that are not yet > > NWIs, including internationalized domain names. > > > > My feedback is that the RIPE Database should support internationalized > > e-mail addresses. The RIPE region includes a number of countries that > > use a non-Latin script. Most of these countries have an IDN version of > > their ccTLD and there are also a number of IDN gTLDs serving these > > language communities. > > this looks like an offer to write a brief NWI, no? :-) I am happy to draft some text for the problem statement and circulate it on the list. Kind regards, Leo Vegoda

3 3

Not yet NWIs: Support for IDNs
by Leo Vegoda 25 May '20

25 May '20

Hi, At RIPE 80, Denis asked for feedback on some items that are not yet NWIs, including internationalized domain names. My feedback is that the RIPE Database should support internationalized e-mail addresses. The RIPE region includes a number of countries that use a non-Latin script. Most of these countries have an IDN version of their ccTLD and there are also a number of IDN gTLDs serving these language communities. People who register in those domains will want to use them for e-mail. If an organization using an IDN is required to set up a secondary e-mail address to register information in the RIPE Database there is a greater risk that the published contact information will go stale as it is not the organization's primary domain. That would undermine the utility of the RIPE Database. Kind regards, Leo Vegoda

3 3

Fw: Regarding NWI-8 phase 2 - user defined auth groups
by ripedenis＠yahoo.co.uk 14 May '20

14 May '20

Hi Tore Sorry if you misunderstood what I meant. I didn't say that 'you' proposed this. I said only 'the proposer' of having user defined groups wanted it. I couldn't remember who it was who suggested it. It may have even been myself who first suggested that this 'could' be extended to user groups and then picked up by someone else :) cheersdenis co-chair DB-WG On Thursday, 14 May 2020, 16:24:47 CEST, Tore Anderson via db-wg <db-wg(a)ripe.net> wrote: The following was stated in the db-wg session just now (https://ripe80.ripe.net/archives/video/377/ @ 1:03): «Phase 2 was user defined authentication groups. Nobody objected to this, but really only the proposer actually said it was a good idea.» This is categorically false. I did not propose this, nor did I think it was a particularly useful feature (at least not to myself). For the record, the thread where I proposed this feature starts here: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… I believe it was Nick Hilliard who initially came up with the group idea: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… While I did not have any objections per se to this feature being implemented as well, I did voice a concern that it would constitute feature creep that would potentially complicate the implementation of the core of my proposal (which in the end was implemented as phase 1, fortunately): https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… So let me for the record categorically state that I do not care about the user defined authentication groups phase of NWI-8. I am perfectly happy with the already implemented phase 1, as that covers everything I ever wanted from the «magic maintainer» proposal of mine that eventually became NWI-8. Tore

1 0

Regarding NWI-8 phase 2 - user defined auth groups
by Tore Anderson 14 May '20

14 May '20

The following was stated in the db-wg session just now (https://ripe80.ripe.net/archives/video/377/ @ 1:03): «Phase 2 was user defined authentication groups. Nobody objected to this, but really only the proposer actually said it was a good idea.» This is categorically false. I did not propose this, nor did I think it was a particularly useful feature (at least not to myself). For the record, the thread where I proposed this feature starts here: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… I believe it was Nick Hilliard who initially came up with the group idea: https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… While I did not have any objections per se to this feature being implemented as well, I did voice a concern that it would constitute feature creep that would potentially complicate the implementation of the core of my proposal (which in the end was implemented as phase 1, fortunately): https://www.ripe.net/participate/mail/forum/db-wg/PGExMTJhNDAyLWUxYTAtZDhlN… So let me for the record categorically state that I do not care about the user defined authentication groups phase of NWI-8. I am perfectly happy with the already implemented phase 1, as that covers everything I ever wanted from the «magic maintainer» proposal of mine that eventually became NWI-8. Tore

1 0

Agenda RIPE80 - Database Working Group
by William Sylvester 11 May '20

11 May '20

All, Db-wg members, Here’s the database working group agenda for our meeting this week. Best regards, DB-WG Chairs A. Introduction - 1 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 10 mins Edward Shryane, RIPE NCC C. Cloud Migration – 15 mins Edward Shryane, RIPE NCC D. NWI - Open Proposals – 20 mins Z. AOB (open discussion)

1 0

Whois Release 1.97.1
by Edward Shryane 06 May '20

06 May '20

Dear Working Group, RIPE Database release 1.97.1 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 6th May. This is a bugfix release, with no new functionality. The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Requirements Task Force BoF
by Bijal Sanghani 06 May '20

06 May '20

Dear colleagues, The RIPE Database Requirements Task Force (DBTF) will organise its BoF on Wednesday, 6 May from 14h00-15h00 CEST via Zoom. During this BoF, the DBTF will present its latest work and invite participants to discuss what functionality the RIPE Database should provide in the future. The presentation will include quick polls and will be followed by a moderated Q&A. You can register for the BoF at (no Zoom account required): https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog <https://ripe.zoom.us/meeting/register/tJMkd-yhrz4uHNDuOIBm8hGvcj8DSDK1Ybog> We look forward to discussing the future of the RIPE Database with you! Kind regards, Bijal Sanghani on behalf of the DBTF

2 1

New on RIPE Labs: Cleaning Up Locked Person Objects in the RIPE Database
by Mirjam Kuehne 30 Apr '20

30 Apr '20

Dear colleagues, Unmaintained person objects in the RIPE Database were locked by the RIPE NCC so they could not be used to hijack resources. Now we plan to set the correct user maintainer on those person objects. Please find more details in this RIPE Labs article: https://labs.ripe.net/Members/ed_shryane/cleaning-up-locked-person-objects-… Kind regards, Mirjam Kühne RIPE NCC

1 0

RIPE NCC Executive Board election
by Ronald F. Guilmette 17 Apr '20

17 Apr '20

Greetings all, I know that all is not right with the world right now, and that most of you, like me, have much more pressing things on your minds right now, but someone just sent me the following link and I cannot exactly ignore it: https://www.ripe.net/participate/meetings/gm/meetings/may-2020/confirmed-ca… I would like to call everyone's attention to the last of the three candidates who have, it seems, "qualified" as candidates for open seats of the RIPE NCC Executive Board. As I have already said, I know that things are bad in the world right now, but I must ask this question: Is there really no one other than these three candidates who is willing and/or able to stand for the three open seats on the RIPE NCC Executive board... three open seats that will be voted on at the next general meeting, 13-15 May 2020 ? If not, then it seems that RIPE NCC will soon be following in the new tradition, established first by AFRINIC only last year, of placing well and widely known crooks on it board. I desperately hope it won't come to that, but that is not for me to decide. The decision is in your hands dear friends. Regards, rfg

4 5

poetic-form mnt-by/creation
by Cynthia Revström 14 Apr '20

14 Apr '20

Hello DB-WG, I would just like to make the working group aware of the fact that currently anyone can create a new poetic-form and it doesn't require the LIM-MNT to be used. I am not sure if this is intended or not, but I thought it was worth posting about if anyone has input on it. Considering the poem objects require the LIM-MNT as mnt-by I don't think this was really the intended situation. - Cynthia

2 1

Whois Release 1.97
by Edward Shryane 01 Apr '20

01 Apr '20

Dear Working Group, RIPE Database release 1.97 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 1st April. The major change in this release is to open the NRTM service (regardless of membership status). The release notes are on the website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

4 4

Re: [db-wg] API keys for database maintenance
by Gunnar Guðvarðarson 23 Mar '20

23 Mar '20

Hey, My main issue with API Keys is them being attached to SSO accounts. What about when the employee leaves the company? He gets removed from auth on the mntner, all the apps he set-up break? Making admins hesitant about removing user access. API access needs to be bound to the mntner in some form imho. Additionally, would api keys allow querying the API and getting unfiltered data? Or would it just be for `post`ing updates to objects? -- I suspect the signed updates have little usage for two major reasons: * Figuring out if the update succeeded requires receiving and parsing emails * Figuring out if the object is up to date on the ripe database is practically impossible* due to filtering (auth: SSO# Filtered) Sending requests with x509 client cert auth means you know who is sending the request and you have no need to filter data (like the auth sso entries) out for objects the mntner has permissions for, making idempotent api clients so much easier to make. -- The logic i might want to implement, in pseudocode: while true mntners = database(mntners) foreach mntners as mntner objects = rest api request for all objects with mnt-by = mntner foreach objects as object if object not in database notify admin .... or delete it continue if object == database(object) continue rest api request to update object with data from database sleep for a while -- p.s. sorry about my earlier, mangled email, my email client seems to have gone a bit nuts... * okay not "impossible" but really annoying, you'd have to store the last updated timestamp from ripe, for all objects, and if it changes in the ripe db, then we'd have to post the object to see if it changes? ________________________________ From: Edward Shryane Sent: Wednesday, March 18, 2020 15:29 To: Gunnar Guðvarðarson Cc: Tore Anderson; db-wg(a)ripe.net Subject: Re: [db-wg] API keys for database maintenance Hi Gunnar, We're indeed also working on Client Certificate authentication (we have tested it, and now it's pending a security review). However, to make use of this, a user must: - Generate an X.509 certificate - Extract the certificate as text and create a key-cert object from it - Associate the key-cert with a maintainer in an auth: attribute - Configure the Whois client to send the client certificate when connecting to the REST API (or Syncupdates). This is not trivial to do, and we can see that although signed updates are supported in Whois, it has low usage. It is still worthwhile to support this, as the credential (secret) is only stored locally on the client. Hopefully API keys will be more "user friendly" and can be used in preference to MD5 hashed passwords. Regards Ed Shryane RIPE NCC > On 18 Mar 2020, at 09:45, Gunnar Gušvaršarson <gunnar.gudvardarson(a)advania.is> wrote: > > Hey,I think that if we get x509 client certificate authentication for the API working, it might even be easier. > All the UI to add certs and auth them on mntners is already there, the web services just need endpoints that request and use client provided certs. > https://github.com/RIPE-NCC/whois/issues/534

3 2

RIPE Database Requirements
by ripedenis＠yahoo.co.uk 19 Mar '20

19 Mar '20

Colleagues The RIPE Database Requirements Task Force recently published notes on their last meeting showing some of their current thinking and progress so far. This can be read here:https://www.ripe.net/ripe/mail/archives/ripe-db-requirements-tf/2020-M… I am going to play devil's advocate and make a few comments and raise a few questions on this and throw in some issues that may not have been discussed. Some of you may wish to make other comments or discuss some of the points... cheers denis co-chair DB-WG public - should all/some/none of the RIPE Database data content be public? As a public registry, what data is needed by which stakeholders for this to be a useful registry? It is clear from the recent survey that the RIPE Database is used for other purposes, like IPAM. It was suggested in the notes that this could be offered as a separate service. The RIPE Database involves a considerable amount of infrastructure to provide a very reliable and resilient service. Why duplicate that for another service or provide a lesser service if it can be incorporated into the RIPE Database as non public data? So a requirement could be that the RIPE Database will provide a range of IPAM (and maybe other) services to resource holders using non public data. Or perhaps a mix of (non)public data. RPSL - whether or not the RIPE Database stores data internally in RPSL format is a design/technical issue, not a requirement concern. The requirement could be that the RIPE Database uses a common, simple format for managing the data content. This format will be reflected in the user interfaces. Where RPSL is required, a conversion of data content into/from RPSL option will be provided. geolocation - This and the "language:" option were originally added as an experimental service without any concrete requirement. Although it has been discussed several times since, no decision was ever made about it. There were always a few people who liked it, a few who didn't, most had no opinion. Some questions that perhaps need to be answered are:-Once you have a definition of what geolocation means (in the context of the RIPE Database), can the RIPE Database provide a viable and accurate service within that definition?-Can it provide a service with additional/complementary benefits to existing 3rd party services, or will it simply replicate or conflict with existing services?-Is such a service of sufficient benefit to the community/public to justify the effort to maintain it (as an optional/mandatory service)? Postal and Legal address - The RIPE Database T&C says in Article 3 one of the purposes is:"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."Article 10 says the governing law is that of the Netherlands.-Does Dutch law permit such information to be given directly on request to any relevant party or only to/via the Dutch police or Dutch court? In particular other (pan)national LEAs?-The purpose in the T&C does not define the process. Does the Dutch law require this to be with a subpoena or will a formal letter be sufficient? person/role - I don't see the bigger questions being asked:-Is there a need for ANY personal data in the RIPE Database?-If so what, how much, for what purpose, which stakeholders need access to which parts of it?-Should personal data be public? irt - Perhaps we shouldn't get too hung up on numbers of objects or queries. They have a clearly defined role in a specialist area. The numbers are never going to be high. The main question seems to be:-is it a useful service to the (security) community? UTF8 - Something that may not have been discussed yet, but perhaps it is crying out to be considered at a requirement level. The technical aspect has been looked at several times by the RIPE NCC, but it never moves forward because of the social/political/registry/legal issues which cannot be resolved at the technical level:-Should we allow all/some/none of the data content to be in non Latin characters?-Is there some data content that must be in Latin characters (for the correct functioning of the registry?), some that can be duplicated in Latin and local characters, some that can be in any format chosen by the resource holder?-Who can make these decisions (this is the bit that has been missing ever since the subject was first raised)? RIPE Database Purposes - The DBTF preliminary list of purposes does not cover all the currently defined purposes in the RIPE Database T&C. Were the ommisions intentional?

1 0

API keys for database maintenance
by Tore Anderson 18 Mar '20

18 Mar '20

Hi WG. In the LIR Portal, at https://lirportal.ripe.net/api/, it is possible to issue API keys for use with several different RIPE NCC services. However, it is unfortunately not possible to issue API keys for the two APIs that are used for database maintenance; Syncupdates and the RESTful API. The documentation implies that the only authorisation [sic] method for those APIs is MD5-PW. I propose that the API keys mechanism is extended to Syncupdates and the RESTful API. The already existing default maintainer concept could be leveraged to accomplish this (similar to how NWI-8 was implemented). That is, using Syncupdates or the RESTful API with API keys will simply authenticate the client as the LIR's default maintainer. Authorisation should remain handled by in-band mnt-* object attributes, as is currently the case. It would be an acceptable limitation that API keys for database maintenance are unavailable for LIRs without a default maintainer. Assuming the WG agrees that this is a good idea, I request an NWI. Tore

6 12

RIPE DB V2 (Perl) code
by Joao Luis Silva Damas 17 Mar '20

17 Mar '20

Does anyone have a copy of the Perl version of the RIPE DB code. I am looking for some code that I know was there and worked well (was fully debugged) but the RIPE FTP site no longer has v2 or v3 code that I can find (while it still has a copy of the WAIS source code!) So, does anyone have a copy that they can send around, please? Joao

1 1

RIPE Database E-Learning Course Launched
by Evelien Schilder 26 Feb '20

26 Feb '20

Dear RIPE Database Working Group, On behalf of the RIPE NCC Academy team, I would like to let you know that we have launched the updated RIPE Database e-learning course. Here are some of the major changes: - We modularised the content. You can now learn a new topic whenever you have 15 minutes to spare. - The modules are more interactive, and include practical exercises and scenarios. - The Training Database has been upgraded to the latest version of the RIPE Database software. The RIPE NCC Academy, our free, open e-learning platform has been revamped. It has received a visual upgrade. You can visit it at: https://academy.ripe.net <https://academy.ripe.net/> Kind regards, Evelien Schilder E-Learning Developer RIPE NCC

1 0

Update RIPE MNT records
by Mohamed Eldemiri 22 Feb '20

22 Feb '20

Hello RIPE support , In the past few years, our organization has gone through a privatization program by the government of Kuwait. Kuwait Stock Exchange has been changed now to Boursa Kuwait our old domain was kuwaitse.com is now boursakuwait.com.kw. The MNT ID and email is still pointing to old inaccessible domain ID, Anyway, the phone number & address are still the same, and the contact person still with Boursakuwait looped in this mail with his new email id 'ybaniyan(a)boursakuwait.com.kw'. Do you have any idea how to change these records? I have contacted the local registrar LR: Fast Telco and they said this must be done through the RIPE and they are not authorized to change these registration parameters. We will adhere to provide all the supporting official documents and memos that RIPE might asking for this change. LIR : Fast Telecommunications Company W.L.L. P.O.Box 287 15453 Dasman KUWAIT phone: +96522256666 fax: +96522401925 e-mail: ripeadmin (at) fasttelco (dot) net Areas serviced: KW 195.137.174.0/24 AS# 49104 Domain : BoursaKuwait.com.kw<https://dnslytics.com/bgp/as49104> % Abuse contact for '195.137.174.0 - 195.137.174.255' is 'abuse(a)fasttelco.net' inetnum: 195.137.174.0 - 195.137.174.255 netname: Kuwait-Stock-Exchange country: KW org: ORG-KSE1-RIPE admin-c: YA443-RIPE tech-c: YA443-RIPE status: ASSIGNED PI mnt-by: RIPE-NCC-END-MNT mnt-by: MNT-Kuwait-Stock-Exchange mnt-routes: MNT-Kuwait-Stock-Exchange mnt-domains: MNT-Kuwait-Stock-Exchange created: 2005-09-20T07:36:57Z last-modified: 2016-04-14T08:28:19Z source: RIPE # Filtered sponsoring-org: ORG-FTC1-RIPE organisation: ORG-KSE1-RIPE org-name: Kuwait Stock Exchange org-type: OTHER address: P.O. Box 22235 - Safat - Kuwait abuse-c: AR25180-RIPE mnt-ref: MNT-Kuwait-Stock-Exchange mnt-by: MNT-Kuwait-Stock-Exchange created: 2005-09-19T11:59:15Z last-modified: 2014-11-17T21:01:58Z source: RIPE # Filtered person: Yousef Abbas address: Kuwait City phone: +965 22992576 nic-hdl: YA443-RIPE created: 2009-07-27T06:57:06Z last-modified: 2016-04-06T19:52:01Z mnt-by: RIPE-NCC-LOCKED-MNT source: RIPE % Information related to '195.137.174.0/24AS49104' route: 195.137.174.0/24 descr: Kuwait Stock Exchange origin: AS49104 mnt-by: MNT-Kuwait-Stock-Exchange created: 2009-04-16T10:13:58Z last-modified: 2009-04-16T10:13:58Z source: RIPE Regards, Mohamed Eldemiri Network Administrator [cid:image001.png@01D5E970.A74CE0E0] Address: Mubarak Al Kabeer Street, Kuwait City, Kuwait P.O.Box: 22235, Safat, 13083 Kuwait Telephone: +(965) 2299-2595 Mobile: +(965) 55266079 Fax: +(965) 2244-0476 www.boursakuwait.com.kw Disclaimer: This e-mail message and any files attached to it are intended only for the recipients named above. The information in this e-mail is confidential and may be legally privileged. If you are not the intended recipient or have received this e-mail by error, you must not use or disseminate the information and must promptly notify the sender and delete this e-mail immediately. Unless otherwise explicitly provided in the body of this e-mail, neither this e-mail nor any attachment hereto is intended to operate as a commitment of whatever type or to include an electronic signature of whatever form under any applicable law. Opinions, conclusions and other information in this email that do not relate to the official business of Boursa Kuwait. Shall be understood as neither given nor endorsed by Boursa Kuwait. Although this email and any attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that it is virus free. Boursa Kuwait accepts no responsibility for any loss or damage arising in any way from the use of this email.

1 0

NWI-1 overview of abuse contacts for resources
by ripedenis＠yahoo.co.uk 21 Feb '20

21 Feb '20

Colleagues I said at Ripe 79 that I would review the open NWIs. So lets start with NWI-1. This has been open and virtually static since 2016. The original summary is here:https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html The situation has changed since then with the "abuse-c:" attribute now allowed in resource objects. The main point I was making (as one of the authors of this NWI) is that there is no easy way for a resource holder to view all the abuse contact details for any of their resources. Hierarchical queries for abuse contacts only search 'up' the hierarchy. There is no easy way for the resource holder to search 'down' through the hierarchies to find all/any abuse contact details. These can now be added at any point in a hierarchy and forgotten about. But they are still active and may present the wrong information when people query for these details. The question now is "Do we need a search/query option or RIPEstat widget that will present an overview of all abuse contacts from a resource allocation down the hierarchy, or even for all of an organisation's resources?" cheers denis co-chair DB-WG

1 0

2018-06 Proposal Implemented (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
by Edward Shryane 31 Jan '20

31 Jan '20

Dear Working Group, The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up". We plan to deploy this to production on Wednesday 15th January. A nightly job will run from that evening onwards. We expect approximately 965 route objects will be initially marked for cleanup (which will happen 2 weeks after that). Regards Ed Shryane RIPE NCC > > From: Petrit Hasani <phasani(a)ripe.net> > Subject: [policy-announce] 2018-06 Proposal Accepted (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up) > Date: 6 November 2019 at 16:03:18 GMT+1 > To: policy-announce(a)ripe.net > > Dear colleagues, > > Consensus has been reached on 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up". > > This proposal aimed at creating a process to delete a non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2018-06 > > The new RIPE Document is called ripe-731 and is available at: > https://www.ripe.net/publications/docs/ripe-731 > > We estimate that this proposal will take around two to three months to fully implement. > > We will send another announcement once the implementation is complete and the new procedures are in place. > > Thank you to everyone who provided us with your input. > > Kind regards, > > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > >

4 4

NWI-10 country attribute
by ripedenis＠yahoo.co.uk 27 Jan '20

27 Jan '20

Colleagues The chairs of the DB-WG declared a consensus on NWI-10 at RIPE 79. This is to add a "country:" attribute to the ORGANISATION object which will be managed by the RIPE NCC in ORGANISATION objects for resource holders. This email is to document that consensus and ask the RIPE NCC to implement this change. cheers denis co-chair DB-WG

2 1

RIPE Database Usage Survey - Database Requirements Task Force
by Boris Duval 20 Jan '20

20 Jan '20

Dear Colleagues, The RIPE Database Requirements Task Force (DBTF) needs your feedback! The DBTF has just launched a survey to know more about how the RIPE Community uses the RIPE databases. The results will provide feedback to the RIPE Database Task Force to help understand the relevance of the database to the RIPE Community and to help shape future RIPE Database policy. You can take the survey at: https://www.surveymonkey.com/r/PC9HTYP <https://www.surveymonkey.com/r/PC9HTYP> The deadline to answer the survey is 31 January. Feel free to share it with your network. Many thanks! Best, Boris Communications Officer RIPE NCC

1 0

NWI-9: Making the Whois NRTM Service Public
by Edward Shryane 16 Jan '20

16 Jan '20

Dear colleagues, Last month, as part of the DB-WG NWI-9 proposal, the RIPE NCC Executive Board resolved to make the Whois NRTM Service public. The full minutes of the Board meeting are on our website: https://www.ripe.net/about-us/executive-board/minutes/2019/minutes-130th-ri… We will now start working on all aspects related to implementing this decision and will have more details for you soon. Regards Ed Shryane RIPE NCC

2 1

database support for ed25519 PGP keys
by Marco d'Itri 19 Dec '19

19 Dec '19

Can RIPE staff clarify if there are plans to support PGP authentication of database updates using ed25519 keys? This should require not much more that upgrading gnupg to a modern release. -- ciao, Marco

2 1

converting a C class from PI to PA
by Franco Tauceri 19 Dec '19

19 Dec '19

Hello. What's the right how-to convert an existing C class from PI to PA? According to this: https://www.ripe.net/manage-ips-and-asns/ipv4/converting-pi-to-pa "Members can request this update via the LIR Portal." ... but I was not able to find HOW this may be done (If I try to edit the object, the field "status" is locked, and I can't edit it anyway... while I can edit other fields as usual) Regards -- Franco Tauceri DomainRegister m: 39.3483064202 w: https://DomainRegister.international e: franco.tauceri(a)domainregister.it

3 2