- db-wg - mailman.ripe.net

RIPE Policy document updated “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (ripe-826)
by Angela Dall'Ara 20 Jun '24

20 Jun '24

Dear Colleagues, The RIPE policy “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” has been updated to align with the implementation of NWI4, done in Whois release 1.112, which added the option to change the status of an IPv4 allocation object in the RIPE Database from “ALLOCATED PA” to “ALLOCATED-ASSIGNED PA” when the whole address space is assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. The new document is called ripe-826 and is available at: https://www.ripe.net/publications/docs/ripe-826/ Please note that also the following has been updated: 1) In the Abstract: The link to the webpage where to find information on the Address Policy WG from https://www.ripe.net/participate/ripe/wg/ap to https://www.ripe.net/community/wg/active-wg/ap/ 2) In 1.1 Scope: The link to the webpage listing the RIPE community’s policies: from https://www.ripe.net/ripe-policies to https://www.ripe.net/publications/docs/ripe-policies/ 3) In 5.3 Sub-Allocations The option to ask for a conversion of PI to PA via LIR Portal has been added. Kind regards, Angela Dall'Ara Policy Officer RIPE NCC

1 0

So what happened last night to the DB?
by Hank Nussbacher 17 Jun '24

17 Jun '24

3 2

Re: [db-wg] So what happened last night to the DB?
by Lutz Donnerhacke 17 Jun '24

17 Jun '24

> I have thought about doing it so, as I was also included as the > maintainers of the object. The real question is: why did blake66 made > such an object ? And how could we prevent something alike to happen > again (not an easy question -- maybe limiting the amount of mnt-by ?) Especially the DB should not process backscatter messages from MAILER-DAEMON.

1 0

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

29 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

Historical data on deleted objects
by Yang Yu 27 May '24

27 May '24

Hi, According to https://apps.db.ripe.net/docs/Types-of-Queries/Historical-Queries/ , historical query doesn't return data on deleted objects. This behavior makes it difficult to distinguish whether a resource was squatted on / analyze history associated with abuse on the resource. And it is not consistent with other RIR's whowas behavior. Currently on RIPE whowas UI unallocated and deleted objects look exactly the same. https://stat.ripe.net/widget/historical-whois#w.resource=as199256 Last time the discussion came up appears to be https://www.ripe.net/ripe/mail/archives/db-wg/2013-November/004195.html Can history support for deleted objects get implemented? Thanks. Yang

3 5

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

RIPE 88 chair selection
by David Tatlisu 22 May '24

22 May '24

Dear colleagues, This is a brief reminder that the DB WG co-chair selection will happen at the Database Working Group session on Thursday. Please have your personal Meetecho link ready. We planned a time slot to discuss the recent changes in the chair selection process, as there has been a lot of discussion between the chairs. Kind regards, David RIPE DB WG co-chair

1 0

Whois Release 1.112
by Edward Shryane 21 May '24

21 May '24

Dear colleagues, RIPE Database release 1.112 has been deployed to the Release Candidate environment for testing. We plan to deploy to production on Thursday 16th May. The 1.112 release has the following main changes: * NWI-4: Add ALLOCATED-ASSIGNED PA inetnum status (#1432) * Set Charset Flag (#1450) * Don't allow "mnt-lower" on assignments (#1452) * Fixed Syncupdates HELP Bug (#1453) * RDAP Link Title is a String not List (#1445) * Route ROA checker (#1416) * Allow inverse query for sponsoring-org from all addresses (#1431) * Return 404 on invalid NRTMv4 notification file path (#1422) The release notes are on the website: https://rc.db.ripe.net/docs/Release-Notes/#ripe-database-release-1-112 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 30th April. Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

2 5

Agenda RIPE88 - Database Working Group [REVISED]
by William Sylvester 17 May '24

17 May '24

All, Here is the revised agenda for the Database Working Group for RIPE88. If you would like to present, have questions, comments, or requested changes please let the chairs know. Best regards, William, Denis, & David DB-WG Chairs A. Introduction - 15 min * Welcome * Scribe * Agenda B. Operational Update– 20 mins Edward Shryane, RIPE NCC C. Adding Contact Methods in Whois & RDAP – 15 mins, Cynthia Revström, Dmitry Kohmanyuk, Leo Vegoda C. NWI Review – 15 mins, WG Chairs D. WG Discussion – 25 mins, WG Chairs Z. AOB (open discussion)

1 0

Update to RIPE Database Terms & Conditions
by denis walker 17 May '24

17 May '24

Colleagues In the Impact Analysis (IA) for 2023-04, the RIPE NCC legal team expressed rules for entering personal data into the RIPE Database that are quite different to our previous understanding. This legal IA was relied on heavily by the proposers of 2023-04 and constantly referred to by them during the policy discussions. Based on the discussions and the IA, the chairs of the AP-WG have now approved the proposal 2023-04. We MUST now update the RIPE Database Terms and Conditions to reflect this new understanding on personal data. In the IA the legal team said this: "Inserting any personal data in the RIPE Database must be in compliance with the RIPE Database Terms and Conditions, even when it relates to the contact details of the member’s own contact person(s). In particular, before anyone updates the RIPE Database with personal data, they must obtain the contact person’s informed and expressed consent and ensure this data is kept accurate and up-to-date." Article 6.3 of the RIPE Database Terms and Conditions currently says: "The Maintainer who enters personal data into the RIPE Database has a responsibility to inform the individual to whom the data pertains and to obtain their explicit consent for the entry in the public RIPE Database if required by law." This article does not accurately reflect the statement in the IA by the legal team. The text "if required by law." must be removed. This suggests that some personal data may not need the 'contact person’s informed and expressed consent'. The IA makes it clear that all personal data entered into the RIPE Database must have the 'contact person’s informed and expressed consent'. There are no exceptions or caveats to this consent. Also the responsibility must not be restricted to the 'Maintainer'. ANYONE has the capability to enter personal data into the RIPE Database. This personal data can then be referenced by a Maintainer of resource data. I would suggest Article 6.3 says something like this: "Anyone who updates the RIPE Database with personal data must obtain the contact person’s informed and expressed consent to enter their personal details into a global, freely accessible, public database. This consent cannot be subject to any conditions. If the consent is withdrawn, the personal data must be removed from the RIPE Database in a reasonable time frame. The personal data must be kept accurate and up-to-date. The right to use some Internet resources requires a consenting contact. If no such contact person is available, the right to use some Internet resources may be revoked." This is a clear and honest statement that fully reflects the IA understanding of the use of personal data in the RIPE Database. I would like to ask the RIPE NCC legal team to make arrangements for this update to the Terms and Conditions. cheers denis co-chair DB-WG ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================

2 5