Colleagues I fully support the idea behind all this. But there is a wider picture that needs to be considered. I think the time for that consideration has come. I want to raise three issues here.
1/ NWI vs PDP for RIPE Database issues 2/ Missing detail 3/ The wider picture I know we live in a world of headlines and soundbites. I know many of you hate long emails and generally refuse to read them. But sometimes substance and detail matters. We, collectively, have a responsibility to facilitate the management of internet operations. Many complex issues cannot be handled in soundbites. So let's begin. 1/ NWI vs PDP for RIPE Database issues Job and Piotr introduced the NWI about 10 years ago. It has proved to be a very useful tool for many technical changes made to the RIPE Database since then. But it does have limitations. For a purely technical change that is agreed by the small number of people who follow mailing lists, the RIPE NCC can then implement the change. The authority to make the change is generally only documented in the mailing list archives and can be difficult to find. Once implemented, often the database software will enforce, or guide, users to accept the change. Although even that is a more complex issue now we no longer need to document all address usage in the RIPE Database to the individual assignment level. A resource holder could simply create two aggregations under the allocation and set the tech contact in the aggregations to either the resource holder or the End User's contact. I see two types of changes to the RIPE Database and it's usage. Purely technical changes and changes that need policy backing. Assigning a whole allocation is a good example of a purely technical change. It was a relatively straightforward change to the software. It was an optional feature that most users could simply ignore. If many users had no idea the feature existed, it was not a problem. No enforcement was needed. But even this did require a change to the address policy where status values are defined. Adding geoloc was another example of a technical change. It is based on an RFC and involved adding a new, optional attribute. Again, it is optional and if you don't know it exists you can ignore it. Any user software that parses RIPE Database objects should be designed not to choke on unrecognised attributes. These purely technical changes can be handled with the NWI process. We also have changes that do require the backup of policy. Adding the "abuse-c:" attribute is a good example of such a change. While there is an optional element to it, there is also a mandatory part. All resources must be covered by an abuse-c. This required some enforcement by the database software. It also required follow up by the RIPE NCC where resource holders did not implement it. There are conditions that must be met in the deployment and positioning of these attributes. This requires policy to define the conditions. If we are going to introduce new contact methods, but require email to be mandatory, then there are conditions to be met in the same way as with abuse-c. I will discuss these conditions more in the next section on missing details. Something that is partly mandatory and partly optional, with multiple ways of deploying it does require a policy. So this suggested change does need to be considered via the PDP rather than the NWI process. In that respect I would suggest renaming the "Abuse Contact Management in the RIPE Database" as the "RIPE Database Policy" and add communication methods as a second article. Once we have a RIPE Database Policy it may encourage some people to start moving slowly into the area of privacy. I tried to tackle that in a single step a few years ago, as did someone else recently. That is never going to work. Small elements of the broader issue can be identified and possibly improved. 2/ Missing detail It is not clear how this mandatory email will be implemented. Yes the technical implementation detail is down to the RIPE NCC, but the community must define the rules. Where is this mandatory email going to be? Are we going to use the same inheritance that we use for the abuse contact? Can we have just one technical email contact for a whole hierarchy? Then it can be referenced from the resource holder's ORGANISATION object. Should that become a mandatory attribute in a resource holder's ORGANISATION object? Or do we need one reference for each allocation? Or maybe we must have an email for each address block associated with a public network? Then for an aggregation, do we assume all the aggregated networks have the same tech contact email address, maybe the resource holder's? Suppose an address block references a ROLE object, which then references three PERSON objects. Is it sufficient that any one of these four objects has an email? Now we need a query option that will find the most relevant email for a given IP address. This could be in any of the (in)directly referenced contact objects or somewhere less specific in the hierarchy. When any contact object is updated a check will need to be done to ensure the address block still has an email contact. Unless we have the one mandatory email contact in the resource holder's ORGANISATION object. Will we allow the local email for an assignment to be deleted and it then falls back to the inherited email of the resource holder? If all four objects have an email, should the new query option return all four email addresses? Will we distinguish between a personal email address of any of these referenced people and 'the mandatory' tech contact email address? There may not be an intermediate ROLE object. The assignment may simply reference the three PERSON objects directly as tech contacts. It is possible that none of those PERSON objects have an email attribute. An assignment holder may also have their own ORGANISATION object. Should we allow the tech email to be referenced from there? Over time this web of possible email addresses will not be maintained and the quality of contact email addresses will degrade. Another option is to add a specific "tech-email:" attribute to the INET(6)NUM and ORGANISATION objects. As we did with abuse-c. Then we can ignore all existing email addresses in the database and require this specific attribute to be added - somewhere. The RIPE NCC cannot implement this feature until the community defines the business rules. There is also one huge problem that may make this mandatory email impossible to implement. It is easy to add an optional feature. On day one, no one is using it, but that is acceptable. Those who don't want to use it or don't know it exists can live happily without it. Adding a mandatory feature is very different. On day one, no one is using it, but everyone must be using it. The abuse-c deployment involved a few 10s of thousands of objects. But even that took a few years to fully deploy. The RIPE NCC also had to follow up on those who didn't do what was required. Requiring a mandatory technical email contact, in some form or another, for all address blocks could potentially involve millions of objects. Monitoring this would be challenging, even if automated in some way. Expecting the RIPE NCC to do any kind of follow up would be impossible. Hoping for the best, that network operators throughout the RIPE address space would realise what is required and just do it, is also an impossibility. You only have to look back at the ERX project from 2004 (Early Registration Transfer) to see that, even after 20 years, some of that data has not yet been properly managed. One possibility is to look at reducing the total number of PERSON objects, leading to the eventual deprecation of this object. Then all contact details will be in a modified ROLE object. Some people may suggest that, where an assignment only references a PERSON object with no email, then if the operator for this assignment does not add the mandatory email address, it is no worse than what we have now. But do we really want to introduce a new system for contacts on the premise that 'it is no worse than what we have now'? When you look at the relative numbers of network objects to person and role objects, either many network objects reference the same role objects or many of them only refer to person objects. Probably it is a combination of both. In person objects email is optional. So currently many networks may not have an email contact. Maybe a mandatory email is simply not a viable option at the moment? Perhaps the best we can hope for is to advise all operators to have a technical email contact point. 3/ The wider picture One of the issues that arose from the 2023-04 discussions is that we, as a community, no longer understand what some of this contact data actually means. I had to search back 30 years to find documents that described what the admin-c meant, at that time. As the discussion progressed it was clear that the 30 year old definition could not, easily, be applied to today's networks. With 2023-04 there seemed to be some urgency to approve the policy change, which was never explained. Let's not make the same mistake again. There is no urgency to add whatsapp to the database. Why don't we take a step back? Let's re-examine what contact information we need in the RIPE Database for the multiple stakeholders to do what they need to do with it. Then let's write clear definitions into a RIPE Database Policy. Then we all understand what contacts are needed for and what they mean. That may make it easier to remove a substantial number of the unnecessary 2m PERSON objects we currently have. We can also address the difference between being able to 'contact' and/or 'identify' users. cheers denis On Tue, 3 Jun 2025 at 04:15, Leo Vegoda <[email protected]> wrote: > Hi Denis, > > On Mon, 2 Jun 2025 at 18:16, denis walker <[email protected]> wrote: > > > > Hi Guys > > > > I agree that this would be more suited as a policy clause rather than > just an agreed NWI documented in the mailing list archives. > > Are you suggesting that database capabilities should be documented in > policy? > > I can understand why we'd want to document registration requirements. > Documenting the database requirements in policy would mean that any > new features could only be added after a policy development process. > Why add friction? > > Regards, > > Leo >
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
