March 2024 - db-wg - mailman.ripe.net

Phone number requirement for person objects
by Cynthia Revström 06 Aug '24

06 Aug '24

Hi, In the DB-WG interim session I mentioned that there's currently a discrepancy between person objects and role objects with regards to contact information. More specifically, person objects currently require a phone number while role objects require an email address. I think we should try to bring person objects more in line with role objects by removing the phone number requirement. Ideally I would want it to be mandatory to have either a phone number or an email address in order to not lose any flexibility but I'm not sure if that is possible. During the session I asked if anyone was opposed to the idea and no one said they were so I would assume that this is relatively uncontroversial but please let me know what you think. -Cynthia

4 6

Proposal to allow non-ASCII characters in "org-name:", "person:" and "role:" attributes
by Edward Shryane 28 May '24

28 May '24

Dear colleagues, Currently the RIPE database only allows a subset of ASCII characters in the "org-name:", "person:" and "role:" attributes, for a few reasons including: * These attributes are also a look-up key and the Whois protocol does not allow specifying character sets in queries. * RPSL names are ASCII according to RFC2622 * Using a normalised name makes the object easier to query * Reading a normalised name is easier to interpret However there are some drawbacks to forcing names to only use a subset of ASCII characters: * Organisations, roles and persons cannot use their actual name if it includes characters outside this subset. * Normalisation is not standard, but is an interpretation done by each maintainer, e.g. characters could be excluded or converted in different ways. Since we support the Latin-1 character set in the RIPE database, I propose we also allow non-ASCII Latin-1 characters in these attributes. Querying for a name can be done either using the latin-1 characters (proposed) or a normalised, ASCII representation (currently). The normalised version will be generated by Whois and stored in a database index for querying. The primary key will also be generated from the normalised version. Please let me know your feedback. Regards Ed Shryane RIPE NCC --- Whois attribute verbose description (copied from the help text). org-name -------- Specifies the name of the organisation that this organisation object represents in the RIPE Database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word. person ------ Specifies the full name of an administrative, technical or zone contact person for other objects in the database. It should contain 2 to 10 words. A word is made up of ASCII alphanumeric characters and additionally: .`'_- The first word should begin with a letter. At least one other word should also begin with a letter. Max 64 characters can be used in each word. role ---- Specifies the full name of a role entity, e.g. RIPE DBM. A list of 1 to 30 words separated by white space. A word is made up of ASCII alphanumeric characters and additionally: ][)(._"*@,&:!'`+/- A word may have up to 64 characters and is not case sensitive. Each word can have any combination of the above characters with no restriction on the start or end of a word.

9 17

Preferred names in the database
by Harry Cross 22 May '24

22 May '24

Dear all (copying this to both the Diversity list and the Database list), I hope you’re having a wonderful weekend and recovering from Rome. I’d like to begin thinking about a proposal for preferred names in the database/on resources. Some may have noticed this week (and for a bit prior), I have begun going by Harri instead of Harry. At the moment there is no correct way for me to represent this in the database, as an LIR the details have to match my legal name. I may think about going through the legal processes to change this soon (albeit in the UK this is easier than a lot of places). I know a few people hold their resources under a shell company for this purpose, (e.g I could incorporate Harri Cross Limited to hold the resources and be in the database). This applies to end users who hold PI or ASNs alongside LIRs. It would be good for us to think about a way for these preferred names (and pronouns?) to be shown in the database alongside the process for changing the name of an end user. I know the preferred way a lot of people in this situation would like this to be handled is to totally mask the legal name in the database. The NCC could still validate legal names to know who they are working with - and we will need some compromise here I suspect. A complete lack of verification is of course a bad thing. I have experienced talking to the NCC when handling end users in these situations who have legally name changed and the process seems to be incredibly hard with the lack of understanding on documentation for name changes. Responses from the Registry have included “How can we be sure that <oldName> and <newName> are not identical twins?” (Which in my mind, is rather disrespectful). I also have another name change in process that is being stonewalled by a lack of understanding of documents in different jurisdictions for this. Kind Regards, Harri Sent from Outlook for iOS<https://aka.ms/o0ukef>

3 2

Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
by Lutz Donnerhacke 13 May '24

13 May '24

* Denis Walker wrote: > But looking through lots of email notifications about changes that you > already know about, because you did them, and maybe in the middle is a > notification of an attempted security breach that failed on > authentication (that you may miss), doesn't that also eat up brain > cycles? Please do not assume that LIR activities are single handed everywhere. Several LIRs do have an automation (i.e. netbox) to update the RIPE DB. Others might have multiple independent people working with RIPE on their own behalf. So notifications, especially the notify: attribute are currently in use. > So how about a compromise. A full audit trail of all details of all > changes to all your data available by default to designated people > through your portal account. Plus a daily email summarising all the > changes also sent to people whose email addresses are set up in the > portal account. So still no notif email addresses needed all across > the database. This could even be done per maintainer. How about using the notify: attribute for notifications?

7 8

Proceeding with NWI-4
by David Tatlisu 02 May '24

02 May '24

Hi everyone, Following recent discussions the working group chairs have determined the new "status" option for NWI-4 garnered the most support. The working group chairs would like to ask the NCC to proceed with the implementation. Your feedback and engagement have been invaluable throughout this process, and we appreciate your continued involvement as we move forward with NWI-4. Kind regards, Denis, William, and David

2 1

email's disappeared from RDAP output
by Ben Cartwright-Cox 05 Apr '24

05 Apr '24

Hi everybody, I was just re-running some tests internally within bgp.tools and I've noticed that the RDAP responses from RIPE no longer include the email address of the person object. For example I used to (and expected) to get the email address in the object for https://rdap.db.ripe.net/entity/BC6775-RIPE, but it seems to have been removed from the output at some point. That does not appear to be a way to log in to authenticate trustworthiness of RDAP responses, is there any other way to get this information? I can see this information on the RIPE website ( https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=BC6775-RIPE&type=… ) but I do not want to scrape that, and this information is incredibly useful for helping users onboard ( with a trustworthy email address ) to services like bgp.tools. Is this an intended change? Have I done something silly? All of the above ;) ? By looking at the release info I can see it was added in November (#1333) Thanks Ben

7 18

Call for Volunteers for RIPE Database Working Group Co-Chair
by David Tatlisu 29 Mar '24

29 Mar '24

********************************************************************************** Please DO NOT reply to this message if you wish to propose a volunteer. ********************************************************************************** Dear colleagues, We would like to invite you to volunteer for the role of the co-chair of the RIPE Database working group. We will have two seats to fill at RIPE 88. Anyone can volunteer for this role. You can also nominate others. Please send a mail to db-wg-volunteers(a)tatlisu.eu before 22 April. Please DO NOT send your name directly to the DB WG mailing list. Please include your motivation and any ideas you might have for the future of the RIPE Database WG. I will then publish the list of volunteers to this mailing list no later than 24 April. Any statements of support on the mailing list are welcome. However, the selection will take place during the DB WG session at RIPE 88. You can find a job description for RIPE WG Chairs here: https://www.ripe.net/publications/docs/wgchair-job-description You can find an e-learning course about the role and responsibilities of RIPE Working Chairs here: https://academy.ripe.net/enrol/index.php?id=16 Please feel free to contact me directly if you have any questions about the role or the process. Kind regards, David RIPE DB WG co-chair

4 5

Whois Release 1.111
by Edward Shryane 28 Mar '24

28 Mar '24

Dear colleagues, RIPE Database release 1.111 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 28th March. The 1.111 release has the following main changes: * Don't send email to undeliverable addresses (#1404) * Add email unsubscribe support This release is *combined* with the 1.110 release, which we had planned to deploy in March. However as we have an upcoming deadline in April to comply with email anti-spam requirements, we decided to combine the releases. We will explain those changes separately. The 1.110 release has the following main changes: * Implemented RDAP Extension for Geofeed Data (draft-ietf-regext-rdap-geofeed-01) (#1366) * Improve RDAP documentation (#1373, #1388) * Implement RDAP RIR Search - Basic Search Features (#1379) * Enable e-mail in RDAP entity responses (in top level vcard) (#1384) * Add geofeed as a link to conform with v1 draft (#1374) * Separate secure connector for Client Certificate authentication (#1390) * Use clientip flag as remote address from trusted source (#1391) * Redirect HTTP(S) requests to whois.ripe.net to the DB web application query page (#1396) * Elasticsearch refreshed after update/create (#1367) * Document inet6num assignment-size maximum prefix (#1375) * Daily limit is configurable (#1401) The release notes are on the website: https://rc.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-111 More information on the Release Candidate environment can be found on our website: https://apps.db.ripe.net/docs/Release-Notes/ The data in the RC environment is a dummified copy of production from 19th February. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

Complying with Mail Provider Requirements When Sending Mail from Whois
by Edward Shryane 19 Mar '24

19 Mar '24

Dear colleagues, As part of the Whois 1.111 release planned for 28th March, we will make changes to comply with new requirements for bulk email senders from two of the large email providers, namely Google [1][2] and Yahoo [3][4]. The RIPE NCC are reviewing these requirements across all our services. Please refer to the RIPE Labs article published today [5]. We send a lot of mail from Whois, on average 30,000 messages a day (comprised mostly of update acknowledgements and notifications) which qualifies us as a bulk sender. We want to comply with these requirements as we depend on email for notifications but also to listen to our users wishes. There are nearly 900,000 email addresses in the RIPE Database. 65,000 are hosted by Google and 5,000 by Yahoo, so these addresses are directly affected by these requirements. In this release, we will implement mail bounce detection (i.e. an outgoing message has permanently failed delivery) and also unsubscription (i.e. one-click unsubscribe from a mail client). Once an address is undeliverable or unsubscribed, we will not send further Whois update acknowledgements or notifications to that address. However we will continue to send targeted notifications where required by RIPE policy (e.g. abuse-c validation, RIPE-NONAUTH route object cleanup etc.). Notification attributes in the RIPE Database (i.e. irt-nfy, mnt-nfy, notify, ref-nfy, upd-to) will be affected, as we will no longer send update notifications to an unsubscribed or undeliverable address. In update acknowledgements we will warn if any address is undeliverable or unsubscribed. Once unsubscribed, if you want to re-subscribe, for now you will need to contact RIPE NCC support [6]. The changes can already be tested in our Release Candidate environment [7]. We welcome feedback from the community. Regards Ed Shryane RIPE NCC --- References 1. Google announcement: https://blog.google/products/gmail/gmail-security-authentication-spam-prote… 2. Google email sender guidelines: https://support.google.com/a/answer/81126?hl=en 3. Yahoo announcement: https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-le… 4. Yahoo sender best practices: https://senders.yahooinc.com/best-practices/ 5. Enhancing Email Delivery at the RIPE NCC: https://labs.ripe.net/author/fergalc/enhancing-email-delivery-at-the-ripe-n… 6. Contacting the RIPE NCC https://www.ripe.net/support/contact/ 7. Release candidate environment https://apps.db.ripe.net/docs/Release-Notes/#release-candidate-environment

3 4

Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
by Lutz Donnerhacke 15 Mar '24

15 Mar '24

> In this release, we will implement mail bounce detection (i.e. an outgoing > message has permanently failed delivery) and also unsubscription (i.e. one- > click unsubscribe from a mail client). Once an address is undeliverable or > unsubscribed, we will not send further Whois update acknowledgements or > notifications to that address. However we will continue to send targeted > notifications where required by RIPE policy (e.g. abuse-c validation, RIPE- > NONAUTH route object cleanup etc.). Thank you for your ongoing work and please forgive my ignorance on this subject. IIUC, all addresses, which are unavailable for the sending RIPE MTA once, will be blocked until manual interference. The cause of this error might be located in the RIPE MTA, the RIPE uplink, a global network routing issue, a peering issue, our uplink, our local MTA, or even a DNS(sec) issue. In consequence we will not receive any notifications anymore unless we try to update the very object in question and read the warning box the RIPE-DB update web form. Hence we can't rely on the email notifications anymore?

2 1