NWI proposal: adjusting contact method requirements and adding new methods
Hi, A while back Cynthia, Dmitry and I looked at the possibility of adding new contact methods. Dmitry presented this at RIPE 88: https://ripe88.ripe.net/archives/video/1347/ I've tried to put this into a more complete NWI and offer it for discussion. The TLDR is: 1) Align the requirement levels for contact methods 2) Let people use new contact methods, like Signal We hope that by offering the methods people want to use, the contact data in the RIPE Database can be as useful as is possible. Kind regards, Leo ## Problem statement The requirement level for contact methods for person and role objects are inconsistent. This is both confusing and inconvenient. This is a proposal to add flexibility to the contact methods offered at the database level. It is not a proposal to change policy requirements for contact methods. This proposal is limited to admin-c and tech-c contact types. Our world offers more contact methods than were available when the currently supported methods were chosen for the RIPE Database. User acceptance of these methods differ by country and generation. Whether this proposal is accepted or not, it is good to review the rationale for these rules and have an updated rationale published. 1. Person and role objects have four contact methods. A postal address is mandatory for both. A phone is mandatory for person objects but not role objects. E-mail is mandatory for role but not person objects. 2. Postal mail is less useful than it was 20 years ago. Some countries are reducing the frequency of postal deliveries. And geographically distributed teams find postal mail less useful. 3. The telephone is becoming less useful, too. Call volumes are dropping and popular psychology publications explain why calls are less likely to be answered: - https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-co... - https://www.bbc.com/news/articles/ckg8jllq283o - https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-t... ## Proposal We should provide contacts with more flexibility. We should also add new options that were not available when the RIPE Database's contact methods were last reviewed. The three elements below follow on from NWI-15, which is based on the RIPE Database Requirements Task Force recommendations for what should be published about resource holders. The registry needs to retain the full set of required data. The DBTF report did not mention contacts methods for the resources. 1. Align the contact method requirements between role and person objects used in admin-c and tech-c attributes. Make all contact methods optional for the public RIPE Database as long as one is chosen. There is no point publishing a contact method that will not be used. That would just waste the time of people trying to make contact. 2. Add support for new contact methods in the RIPE Database, including SIP (RFC 3969), Signal, Telegram, and WhatsApp. 3. Add support for RFC 8605 (ICANN Extensions for the Registration Data Access Protocol) and show the HTTPS intermediary and/or private URI where one is available. Making these changes will require updates to the RPSL and RDAP publication methods. The RIPE NCC should manage the specifics of the design and implementation. ## Recommendation for Impact Assessment The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement. The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.
Hello, Thanks to the authors for your work on this. This is a mostly solid proposal, and will improve the quality and usefulness of the RIPE database, and reduce unnecessary and incorrect information in it. But I do have a concern. If I read this right, e-mail would also be optional, and it would be fine for a network's only contact to be WhatsApp, for instance. This means that to contact another network operator, one operator would have to bind themselves to the Meta terms and conditions, which does not feel right to me as a requirement. Having no fixed required methods also risks fragmentation. Now, I can reach most operators through email. If I regularly reach out to other networks, I'd need a Signal, Telegram, WhatsApp, Discord, Matrix, etc. account as everyone has a different contact method. The RIPE NCC also occasionally reaches out to operators in bulk, e.g. for MD5 changes, and may have to add bots to support all those platforms to reach contacts. Therefore, I feel we should keep e-mail mandatory. It is widely established and used, and not (or at least limited) tied to complex T&C. I know it's not everyone's favorite method, but to me it seems like the one we can all tolerate. On 26 May 2025, at 00:49, Leo Vegoda <leo@vegoda.org> wrote:
This proposal is limited to admin-c and tech-c contact types.
Are you intentionally leaving out zone-c and abuse-c, which, if I'm not mistaken, are also references to role or person objects? I understand the abuse-mailbox attribute being a special additional requirement, but reading your proposal literally, we would still require a postal address when a role is used as abuse-c and tech-c, but not when it's only used for tech-c. I don't know whether part of this is oversight or intent, but I think the NWI should at least explicitly mention zone-c/abuse-c. Sasha
Hi, On Mon, May 26, 2025 at 09:53:53AM +0200, Sasha Romijn via db-wg wrote:
Therefore, I feel we should keep e-mail mandatory. It is widely established and used, and not (or at least limited) tied to complex T&C. I know it's not everyone's favorite method, but to me it seems like the one we can all tolerate.
Seconded. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Hi, On Mon, 26 May 2025 at 00:54, Sasha Romijn via db-wg <db-wg@ripe.net> wrote: [...]
Therefore, I feel we should keep e-mail mandatory. It is widely established and used, and not (or at least limited) tied to complex T&C. I know it's not everyone's favorite method, but to me it seems like the one we can all tolerate.
One reason I left it as optional in the text is some pushback I had when drafting it from people who told me that they almost never used e-mail any more. I'm not convinced that e-mail is as common as many would like. Nonetheless, there's no need to run. A walking pace is fine. I have no objection to e-mail being retained as mandatory.
On 26 May 2025, at 00:49, Leo Vegoda <leo@vegoda.org> wrote:
This proposal is limited to admin-c and tech-c contact types.
Are you intentionally leaving out zone-c and abuse-c, which, if I'm not mistaken, are also references to role or person objects? I understand the abuse-mailbox attribute being a special additional requirement, but reading your proposal literally, we would still require a postal address when a role is used as abuse-c and tech-c, but not when it's only used for tech-c.
I don't know whether part of this is oversight or intent, but I think the NWI should at least explicitly mention zone-c/abuse-c.
My thought was to work in Database WG to establish the capability. Then, if the people in the DNS and Security WGs want to take advantage of it they can do so. Thanks, Leo
El 26/05/2025 a las 15:21, Leo Vegoda escribió:
Hi,
On Mon, 26 May 2025 at 00:54, Sasha Romijn via db-wg [<db-wg@ripe.net>](mailto:db-wg@ripe.net) wrote:
[...]
Therefore, I feel we should keep e-mail mandatory. It is widely established and used, and not (or at least limited) tied to complex T&C. I know it's not everyone's favorite method, but to me it seems like the one we can all tolerate.
One reason I left it as optional in the text is some pushback I had when drafting it from people who told me that they almost never used e-mail any more. I'm not convinced that e-mail is as common as many would like. Nonetheless, there's no need to run. A walking pace is fine.
I have no objection to e-mail being retained as mandatory.
Therefore, if email is mandatory, the rest of the options can be optional. I agree with this proposal. Rodolfo García (kix)
Hi, On 26 May 2025, at 15:21, Leo Vegoda <leo@vegoda.org> wrote:
One reason I left it as optional in the text is some pushback I had when drafting it from people who told me that they almost never used e-mail any more. I'm not convinced that e-mail is as common as many would like. Nonetheless, there's no need to run. A walking pace is fine. I have no objection to e-mail being retained as mandatory.
Yes, to some degree the fragmentation in contacts already exists, but I would prefer the RIPE database not to facilitate it too much. Especially when it involves closed platforms owned entirely by a single corporation. I do not see an ideal solution, but keeping e-mail mandatory for now feels reasonable.
Are you intentionally leaving out zone-c and abuse-c, which, if I'm not mistaken, are also references to role or person objects? I understand the abuse-mailbox attribute being a special additional requirement, but reading your proposal literally, we would still require a postal address when a role is used as abuse-c and tech-c, but not when it's only used for tech-c.
I don't know whether part of this is oversight or intent, but I think the NWI should at least explicitly mention zone-c/abuse-c.
My thought was to work in Database WG to establish the capability. Then, if the people in the DNS and Security WGs want to take advantage of it they can do so.
That does not sound practical to me. We should not end up with radically different layouts and validation rules for a role/person in the DB, depending on whether it is referenced from a tech-c or a zone-c. If we want to defer zone-c/abuse-c to other WGs, they should at least be involved early - I would prefer us to adjust role/person in a single change to a new set of requirements. It would be confusing to say to users "yes, your role object is valid, but you tried to use it in a zone-c, and you can't do that until you remove the signal contact attribute". Sasha
On Wed, 28 May 2025 at 08:09, Sasha Romijn via db-wg <db-wg@ripe.net> wrote: [...]
That does not sound practical to me. We should not end up with radically different layouts and validation rules for a role/person in the DB, depending on whether it is referenced from a tech-c or a zone-c. If we want to defer zone-c/abuse-c to other WGs, they should at least be involved early - I would prefer us to adjust role/person in a single change to a new set of requirements. It would be confusing to say to users "yes, your role object is valid, but you tried to use it in a zone-c, and you can't do that until you remove the signal contact attribute".
Good point! I think you are right. Thanks, Leo
On 25 May 2025, at 23:49, Leo Vegoda wrote:
## Recommendation for Impact Assessment
The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement.
The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.
These seem to me to be sound recommendations. Following them may reveal the need to develop revised policy, rather than just to agree a new NWI. RIPE has a tradition of finding a good balance between formality and pragmatism; I expect that the WG and NCC will find the right path in this case too. Best regards, Niall RIPE Vice-Chair
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. I suggested years ago that we should have a RIPE Database Policy. This could be a good moment to create one. Even if, for now, communication methods was the only article in the policy. Although we could merge RIPE-705 Abuse Contact Management in the RIPE Database with it. RIPE-705 also only has a single article in the policy. So we could start with: ------------------------------------------------------ RIPE-nnn RIPE Database Policy 1.0 Abuse Contact Information bla bla bla 2.0 Communication Methods bla bla bla ------------------------------------------------------ I am sure more articles will follow. cheers denis On Thu, 29 May 2025 at 11:54, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
On 25 May 2025, at 23:49, Leo Vegoda wrote:
Recommendation for Impact Assessment
The impact assessment provided by the RIPE NCC should note any contact method requirements specified in policy. It should also note where the policy does not specify a contact method requirement.
The RIPE NCC might want to note the impact of enforcing policy requirements when more user choice is offered at the database layer.
These seem to me to be sound recommendations. Following them may reveal the need to develop revised policy, rather than just to agree a new NWI.
RIPE has a tradition of finding a good balance between formality and pragmatism; I expect that the WG and NCC will find the right path in this case too.
Best regards,
Niall RIPE Vice-Chair ----- 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/
Hi Denis, On Mon, 2 Jun 2025 at 18:16, denis walker <ripedenis@gmail.com> 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
Hi Everyone, I would go ahead and say that this can be declared NWI-20. I think enough time has passed to give all working group participants the opportunity to voice their opinion on this. Leo's original Email defines a problem and already touches on a solution definition, which would be phase two of the NWI process. As the working group participants have already started talking about potential implementation details, I will declare consensus on the problem definition Leo has posted. With this we can move to phase two of the NWI process, where I would like to ask the RIPE NCC for further input on potential solutions, as, for example, certain contact types being a legal requirement within the RIPE service region has not been evaluated yet. Thank you for all your input on this proposal. Have a nice week, everybody. On 6/3/25 4:15 AM, Leo Vegoda wrote:
Hi Denis,
On Mon, 2 Jun 2025 at 18:16, denis walker <ripedenis@gmail.com> 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/
Dear David,
On 21 Jul 2025, at 19:51, David Tatlisu via db-wg <db-wg@ripe.net> wrote:
Hi Everyone,
I would go ahead and say that this can be declared NWI-20.
We've added NWI-20 to the Numbered Work Item page, including a link to the problem statement: https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items/
I think enough time has passed to give all working group participants the opportunity to voice their opinion on this.
Leo's original Email defines a problem and already touches on a solution definition, which would be phase two of the NWI process. As the working group participants have already started talking about potential implementation details, I will declare consensus on the problem definition Leo has posted.
With this we can move to phase two of the NWI process, where I would like to ask the RIPE NCC for further input on potential solutions, as, for example, certain contact types being a legal requirement within the RIPE service region has not been evaluated yet.
The DB team will start work on potential solutions and an impact analysis for review by the DB-WG. If anything is unclear we'll ask the DB-WG for clarification. Regards Ed Shryane RIPE NCC
Thank you for all your input on this proposal.
Have a nice week, everybody.
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 <leo@vegoda.org> wrote:
Hi Denis,
On Mon, 2 Jun 2025 at 18:16, denis walker <ripedenis@gmail.com> 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
Colleagues I guess no one has an opinion on any of this. You are happy to continue with an NWI to create an unenforceable mandatory email address. You don't see any problems adding a new mandatory attribute across, potentially, millions of objects. And you are all OK to continue adding and maintaining an existing mandatory email in millions of objects, even though none of you have any idea what that attribute means. I don't think anyone has time to consider RIPE Database issues any more. As long as it still, just about, works then leave it alone. Well good luck with this project. You will need it if you go ahead with it. cheers denis On Fri, 5 Sept 2025 at 12:27, denis walker <ripedenis@gmail.com> wrote:
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 <leo@vegoda.org> wrote:
Hi Denis,
On Mon, 2 Jun 2025 at 18:16, denis walker <ripedenis@gmail.com> 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
Dear colleagues,
On 18 Sep 2025, at 14:41, denis walker <ripedenis@gmail.com> wrote:
Colleagues
I guess no one has an opinion on any of this. You are happy to continue with an NWI to create an unenforceable mandatory email address. You don't see any problems adding a new mandatory attribute across, potentially, millions of objects. And you are all OK to continue adding and maintaining an existing mandatory email in millions of objects, even though none of you have any idea what that attribute means. I don't think anyone has time to consider RIPE Database issues any more. As long as it still, just about, works then leave it alone. Well good luck with this project. You will need it if you go ahead with it.
cheers denis
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further. Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so. Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again. Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately. Regards Ed Shryane RIPE NCC
Hi Everybody, Depending on the interpretation of ripe-508, email addresses might already be a mandatory but unenforced part of PERSON objects. In the context of Internet number resources, the policy states:
In case the Status is either "Allocated" or "Legacy", the following information is also mandatory: […] Contact information for matters of an administrative nature, and for matters of a technical nature. This information consists of an email address and a telephone number
I read this as "The mandatory attributes admin-c and tech-c must have an email address and telephone number." The backend allows referencing a PERSON object not containing an email address as well as a ROLE object that does not include a phone number for these two attributes, which would make a policy violation possible by my interpretation. Edward has looked through the RIPE policies behind the scenes and did not find any other policy that would need changes because of this change. I might be misunderstanding this and would love to hear additional input from the community on this matter. Assuming I did not misunderstand, this would make a policy change unnecessary to proceed. Please correct me in case I misunderstood. Regardless of the topic above, changing about a million PERSON objects is not a small task. I, personally, agree with Ed here. I do not see a way of implementing this without a gradual multi-step plan, if at all possible. I am more than happy to allocate time for this in the RIPE 91 agenda or start planning another interim working group session to discuss this issue further. Best regards, David DB-WG Chair On 9/19/25 9:42 AM, Edward Shryane wrote:
Dear colleagues,
On 18 Sep 2025, at 14:41, denis walker<ripedenis@gmail.com> wrote:
Colleagues
I guess no one has an opinion on any of this. You are happy to continue with an NWI to create an unenforceable mandatory email address. You don't see any problems adding a new mandatory attribute across, potentially, millions of objects. And you are all OK to continue adding and maintaining an existing mandatory email in millions of objects, even though none of you have any idea what that attribute means. I don't think anyone has time to consider RIPE Database issues any more. As long as it still, just about, works then leave it alone. Well good luck with this project. You will need it if you go ahead with it.
cheers denis
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further.
Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so.
Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again.
Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately.
Regards Ed Shryane RIPE NCC
----- 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/
Dear colleagues, After reading the discussion on NWI-20, I would like to explain why I think the NWI process is suitable for finding consensus on the proposed changes: - With the exception of abuse-c, there is no current policy defining which contact methods are mandatory and which are optional. This has always been defined by the RIPE Database rules. - Only objects managed by RIPE Database users are in scope because the RIPE NCC does not maintain person or role objects. - Only those person and role objects created, modified and referenced as admin-c and tech-c after the implementation would be affected by the proposed changes. Please note that I do not see this as excluding use of the PDP for future registration policies, which might describe actions the RIPE NCC must undertake to verify compliance. I hope this helps, Kind regards, Angela Angela Dall'Ara Policy Officer RIPE NCC On 20/09/2025 11:46, David Tatlisu via db-wg wrote:
Hi Everybody,
Depending on the interpretation of ripe-508, email addresses might already be a mandatory but unenforced part of PERSON objects.
In the context of Internet number resources, the policy states:
In case the Status is either "Allocated" or "Legacy", the following information is also mandatory: […] Contact information for matters of an administrative nature, and for matters of a technical nature. This information consists of an email address and a telephone number
I read this as "The mandatory attributes admin-c and tech-c must have an email address and telephone number." The backend allows referencing a PERSON object not containing an email address as well as a ROLE object that does not include a phone number for these two attributes, which would make a policy violation possible by my interpretation.
Edward has looked through the RIPE policies behind the scenes and did not find any other policy that would need changes because of this change.
I might be misunderstanding this and would love to hear additional input from the community on this matter.
Assuming I did not misunderstand, this would make a policy change unnecessary to proceed. Please correct me in case I misunderstood.
Regardless of the topic above, changing about a million PERSON objects is not a small task. I, personally, agree with Ed here. I do not see a way of implementing this without a gradual multi-step plan, if at all possible.
I am more than happy to allocate time for this in the RIPE 91 agenda or start planning another interim working group session to discuss this issue further.
Best regards, David DB-WG Chair
On 9/19/25 9:42 AM, Edward Shryane wrote:
Dear colleagues,
On 18 Sep 2025, at 14:41, denis walker<ripedenis@gmail.com> wrote:
Colleagues
I guess no one has an opinion on any of this. You are happy to continue with an NWI to create an unenforceable mandatory email address. You don't see any problems adding a new mandatory attribute across, potentially, millions of objects. And you are all OK to continue adding and maintaining an existing mandatory email in millions of objects, even though none of you have any idea what that attribute means. I don't think anyone has time to consider RIPE Database issues any more. As long as it still, just about, works then leave it alone. Well good luck with this project. You will need it if you go ahead with it.
cheers denis
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further.
Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so.
Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again.
Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately.
Regards Ed Shryane RIPE NCC
----- 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/
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/
Hi David Thanks for the update. I think there are several misunderstandings here. Let me offer an alternative view from someone who has spent decades studying and debating these documents :) On Sat, 20 Sept 2025 at 11:46, David Tatlisu <dbwg@tatlisu.eu> wrote:
Hi Everybody,
Depending on the interpretation of ripe-508, email addresses might already be a mandatory but unenforced part of PERSON objects.
First of all ripe-508 is a RIPE document but it is not a RIPE policy. So anything it says is for guidance only.
In the context of Internet number resources, the policy states:
'document' states
In case the Status is either "Allocated" or "Legacy", the following information is also mandatory: […] Contact information for matters of an administrative nature, and for matters of a technical nature. This information consists of an email address and a telephone number
OK so we are talking about allocations here. It gets a bit confusing here because of the history and mistakes in documentation and the communities 'lost' understanding of the whole subject of contacts (the wider picture I referred to). When I completely re-wrote the RIPE Database documentation in about 2014 I added the attribute property of 'required' [1]. We had always had this property but never defined it. This is where an 'optional' attribute is 'required' to be present in some cases because of (software) business rules. For the INETNUM object "org:" is a 'required' attribute. (I am sure I did change this in the object templates. But in the documentation of the INETNUM object [2] and in the 'whois -t' output it has gone back to 'optional'.) So for an allocation there must be a referenced ORGANISATION object. This object has a mandatory "e-mail:" attribute. This is defined [3] as "Specifies an email address of a person, role, organisation or IRT team." Although this could be absolutely anyone, it 'could' be a technical or administrative contact. It is a multiple attribute so it could cover both. Even though we have no inheritance on this attribute or query option to easily find it, it can still be (indirectly) found for an allocation. Therefore the guidance of ripe-508 is satisfied. While we are here, one could ask "who or what is an admin-c or tech-c of an organisation, as represented by the "admin-c:" and "tech-c:" optional attributes in the ORGANISATION object? More of the lost understanding of the whole contact details swamp.
I read this as "The mandatory attributes admin-c and tech-c must have an email address and telephone number." The backend allows referencing a PERSON object not containing an email address as well as a ROLE object that does not include a phone number for these two attributes, which would make a policy violation possible by my interpretation.
Again this is where inheritance of this information from the ORGANISATION object is a better option, with enforcement done by the software business rules as it is for "abuse-c:". Now you could also argue that rfc 2622 Routing Policy Specification Language (RPSL) [4] has both phone and email as mandatory in the PERSON and ROLE classes. But, as we say in the RIPE Database documentation [5] "over the years, practical operations have resulted in a number of deviations from the basic RPSL definition." Changing the syntax of the ROLE and PERSON objects come into this.
Edward has looked through the RIPE policies behind the scenes and did not find any other policy that would need changes because of this change.
The document ripe-508 does not need to be changed as we already satisfy the guidance it offers.
I might be misunderstanding this and would love to hear additional input from the community on this matter.
Assuming I did not misunderstand, this would make a policy change unnecessary to proceed. Please correct me in case I misunderstood.
Regardless of the topic above, changing about a million PERSON objects is not a small task. I, personally, agree with Ed here. I do not see a way of implementing this without a gradual multi-step plan, if at all possible.
It is not at all possible. Some of the ERX data still hasn't been 'fixed' by resource holders after 20 years. This data was only in the thousands, not millions. But then we also should not have 2 million PERSON objects in this database, many representing people who have NOT given their 'clear consent'. Yet again this is partly due to a community lack of understanding of what 'contact data' actually means now. One of many issues that this community refuses to even discuss.
I am more than happy to allocate time for this in the RIPE 91 agenda or start planning another interim working group session to discuss this issue further.
(Just as an aside, I noticed that the RIPE Database documentation's description of the status 'AGGREGATED-BY-LIR' [2] is completely incompatible with the description in the address policy [6].) References: [1] https://docs.db.ripe.net/RIPE-Database-Structure/Attribute-Properties [2] https://docs.db.ripe.net/RPSL-Object-Types/Descriptions-of-Primary-Objects#d... [3] https://docs.db.ripe.net/Appendices/Appendix-A--Syntax-of-Object-Attributes [4] https://www.rfc-editor.org/rfc/rfc2622#section-3.2 [5] https://docs.db.ripe.net/RIPE-Database-Structure/Database-Object [6] https://www.ripe.net/publications/docs/ripe-826/#70-types-of-address-space cheers denis
Best regards, David DB-WG Chair
On 9/19/25 9:42 AM, Edward Shryane wrote:
Dear colleagues,
On 18 Sep 2025, at 14:41, denis walker<ripedenis@gmail.com> wrote:
Colleagues
I guess no one has an opinion on any of this. You are happy to continue with an NWI to create an unenforceable mandatory email address. You don't see any problems adding a new mandatory attribute across, potentially, millions of objects. And you are all OK to continue adding and maintaining an existing mandatory email in millions of objects, even though none of you have any idea what that attribute means. I don't think anyone has time to consider RIPE Database issues any more. As long as it still, just about, works then leave it alone. Well good luck with this project. You will need it if you go ahead with it.
cheers denis
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further.
Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so.
Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again.
Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately.
Regards Ed Shryane RIPE NCC
----- 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/
Hi Denis, Thanks for your feedback, I will try to answer some of the points you raised.
On 29 Sep 2025, at 07:28, denis walker <ripedenis@gmail.com> wrote:
Hi David
Thanks for the update. I think there are several misunderstandings here. Let me offer an alternative view from someone who has spent decades studying and debating these documents :)
On Sat, 20 Sept 2025 at 11:46, David Tatlisu <dbwg@tatlisu.eu> wrote: Hi Everybody,
Depending on the interpretation of ripe-508, email addresses might already be a mandatory but unenforced part of PERSON objects.
First of all ripe-508 is a RIPE document but it is not a RIPE policy. So anything it says is for guidance only.
In the context of Internet number resources, the policy states:
'document' states
In case the Status is either "Allocated" or "Legacy", the following information is also mandatory: […] Contact information for matters of an administrative nature, and for matters of a technical nature. This information consists of an email address and a telephone number
OK so we are talking about allocations here. It gets a bit confusing here because of the history and mistakes in documentation and the communities 'lost' understanding of the whole subject of contacts (the wider picture I referred to).
When I completely re-wrote the RIPE Database documentation in about 2014 I added the attribute property of 'required' [1]. We had always had this property but never defined it. This is where an 'optional' attribute is 'required' to be present in some cases because of (software) business rules.
This is still the case. An 'optional' attribute can become 'required' due to some business rules. If an attribute is 'required' then it's always required regardless of the business rules.
For the INETNUM object "org:" is a 'required' attribute. (I am sure I did change this in the object templates. But in the documentation of the INETNUM object [2] and in the 'whois -t' output it has gone back to 'optional'.)
The inetnum 'org:' attribute must be listed as 'optional' in the object template because it's only 'required' in some cases (due to the business rules). The business rules for "org:" are listed in the documentation: https://docs.db.ripe.net/Database-Support/Database-Business-Rules "On inet(6)num objects for allocations or End User assignments made by the RIPE NCC, the "org:" attribute is mandatory." In the "Description of Attributes Specific to the INET6NUM Object" section, I think that "org:" is incorrectly described as required, i.e. ""org:" – single valued to make sure that only one organisation is responsible for this resource. This is a required attribute. In some cases, there are business rules to ensure that it is present. If the inet6num object is (jointly) maintained by the RIPE NCC then the object must have an “org:” attribute." Also similar text in the "Description of Attributes Specific to the INETNUM Object" section. I think we should correct this to state: "This is an optional attribute. In some cases, there are business rules to ensure that it is present."
... (Just as an aside, I noticed that the RIPE Database documentation's description of the status 'AGGREGATED-BY-LIR' [2] is completely incompatible with the description in the address policy [6].)
The documentation text for INETNUM AGGREGATED-BY-LIR was mostly copied from the existing INET6NUM description, because the policy proposal 2023-04 mostly used the same wording as in the IPv6 policy. I reviewed the documentation description for INETNUM AGGREGATED-BY-LIR and noticed we don't state that the "assignment-size:" is optional for INETNUM, we will clarify this. Also we don't allow two levels of "AGGREGATED-BY-LIR" in inetnum, but only one. We will correct this. Please let me know how we can otherwise improve the text (e.g. should we quote the policy text directly?). Regards Ed Shryane RIPE NCC
Hi Ed Thanks for the update. However I have a number of concerns about the direction here. You seem to have assumed that the way forward is to make e-mail mandatory in the PERSON object. That is simply not going to happen, as I have explained in other responses. If you attempted that by any means it is unlikely to succeed. I also don't think it is a good idea from either a privacy or data accuracy pov. Adding another million items of personal data to the RIPE Database is a very bad idea. I already have doubts about how much of the existing contact data is there with 'clear consent'. PERSON objects are by their very nature personal. If you try to force people to give an email address when they don't want to, it is unlikely to be a valid address. The quality of contact data may plunge to new depths. Again a lot of this comes down to understanding contact data. What type of contact information do we need and how and where should it be referenced from in the database? What is the difference between the ROLE and PERSON objects? How much actual 'personal' information is needed? We don't have answers to any of these types of questions. Another possibility is to make the "tech-c:" attribute in the ORGANISATION object a required attribute, like "abuse-c:". So for ORGANISATION objects with type 'LIR' it effectively becomes a mandatory attribute. We could then require it to reference a ROLE object where "e-mail:" is already mandatory. Apply the same hereditary mechanism we use for "abuse-c:" and we have a default technical contact e-mail address available for all resources. As you go down into the more specific INET(6)NUM objects, they already have a mandatory "tech-c:" attribute. Often these are just copies of the resource holder's information. Endlessly duplicated information. As with "abuse-c:" we could make "tech-c:" optional in the INET(6)NUM objects. If it is not there we inherit from the resource holder's ORGANISATION object. Or you can add in an optional localised "tech-c:" We know this is a manageable possibility to achieve. We did it with "abuse-c:". So we do the same with "tech-c:" in the ORGANISATION objects for resource holders, forcing a reference to a ROLE object. Then we make "tech-c:" optional in INET(6)NUM objects. For this purpose we completely ignore the PERSON objects. It will again take a few years to deploy the mandatory ORGANISATION data. Then many more years for the duplicated, now optional, INET(6)NUM data to fade away. But for that it doesn't matter how long it takes. It is optional and it is just duplicated data. It doesn't matter if it is there or not. Because we will then be forcing the addition of mandatory data into the LIR's ORGANISATION objects, as we did with "abuse-c:", with RIPE NCC follow ups, it would need to be done as a policy, not an NWI. Adding additional contact methods could be done in parallel to this. We could also add a rule that the new contact methods can only be added to a ROLE object and not a PERSON object. So anyone wanting to use a new contact method may have to switch from PERSON to ROLE, which has the mandatory e-mail and optional phone. So some of the false phone numbers may disappear. cheers denis On Fri, 19 Sept 2025 at 09:42, Edward Shryane <eshryane@ripe.net> wrote:
The DB team are working on a Solution Definition for NWI-20 and I'd like some feedback on the points that Denis has rasied before we proceed further.
Firstly, do we need to use the Policy Development Process to make e-mail mandatory on person objects? E-mail is already mandatory on organisation and role but not on person. I couldn't find a reason for this inconsistency in existing policies, or any requirement to make it so.
Secondly, do we need to cleanup existing person objects if e-mail is changed to be mandatory? Half of the existing 2 million person objects do not have an e-mail attribute. It seems unlikely that maintainers will add e-mail retrospectively. We could add validation to require e-mail only when person objects are updated, however most person objects are created and never updated again. We could add validation to require e-mail when a person is added as a contact on another object, however most exising persons are referenced from a single assignment and then never referenced again.
Thirdly, should mandatory e-mail remain part of NWI-20, in addition to creating new contact types? Multiple people in this thread have asked for it, but perhaps the changes can be made in phases, and the wider issues that Denis has raised can be tackled separately.
Regards Ed Shryane RIPE NCC
Hi, Denis. On 29 Sep 2025, at 9:17, denis walker wrote:
Because we will then be forcing the addition of mandatory data into the LIR's ORGANISATION objects, as we did with "abuse-c:", with RIPE NCC follow ups, it would need to be done as a policy, not an NWI.
If there were an existing policy which limited such addition of new mandatory data (or newly-mandatory data) into an object, this would be true. Can you cite which existing policy does this? All the best, Niall
Hi Niall On Monday, 29 September 2025, Niall O'Reilly <niall.oreilly@ucd.ie> wrote:
Hi, Denis.
On 29 Sep 2025, at 9:17, denis walker wrote:
Because we will then be forcing the addition of mandatory data into the LIR's ORGANISATION objects, as we did with "abuse-c:", with RIPE NCC follow ups, it would need to be done as a policy, not an NWI.
If there were an existing policy which limited such addition of new mandatory data (or newly-mandatory data) into an object, this would be true.
Can you cite which existing policy does this?
Let me reverse the argument. There was no existing policy that limited the addition of a new mandatory (in some situations according to business rules) abuse-c attribute. But to do this we created an abuse-c policy. Why did we do that if it wasn't considered necessary? Didn't that set a precedent? I think we are on the borderline here of what policy means vs a simple technical change to the database semantics. We are telling network operators that they must do something and we will change the software to force this behaviour. If you don't comply with existing data, the RIPE NCC may follow up and push you to make changes. Where does the authority come from to force this behaviour? A decision lost in the archives of a mailing list? Or a published policy document that all resource holders are committed to following? It's not the same as adding an optional attribute like geofeed? You can just ignore that. We are not forcing anyone to do anything. If we create a guideline it's different. Maybe we say it would be nice if you provide an email so people don't need to open a WhatsApp account to contact you. Then it's your choice if you do anything. Cheers Denis
All the best, Niall
On 29 Sep 2025, at 18:17, denis walker wrote:
Let me reverse the argument.
No. If you won't offer an argument to support your opinion that a this adjustment "would need to be done as a policy, not an NWI", you're not engaging in a debate, and no-one owes you an answer, much less a refutation. /Niall
Hi Niall What i am saying IS an argument to support my opinion. AFAIK adding abuse-c was the only time we've added a mandatory attribute in the last 10+ years. One where we subsequently required all resource holders to make changes to their data. We made a statement that all resources must reference an email where abuse reports can be sent. What we are suggesting now is that we add another mandatory attribute/value. One where we will subsequently require all resource holders to make changes to their data. We are making a statement that all resources must reference an email where details of technical issues can be sent. It is exactly the same situation. We know that many resource holders don't follow all the individual working groups. Some of them may still follow policy announcements so they can comply with policy. We have in the past removed mandatory attributes. We have done this several times. The RIPE NCC did a mass update across the database to remove them. We did not force resource holders to make changes to their data. You have three problems here. Making people aware of the need to change their data. Pointing them to the authority to force this change on them. Getting them to take action. NWIs were introduced to offer a lightweight process to make simple technical changes to the database operation and usage. Policy is where you lay down the rules that all resource holders must comply with. From whatever angle you look at this, requiring all resource holders to provide an email address where details of technical issues can be sent is a policy change. Anyway, I've made my point. Now it's up to the handful of people who follow this mailing list to decide, or ignore. Good luck. Which ever way you go, you will need it. Cheers Denis On Tue, 30 Sept 2025, 11:58 Niall O'Reilly, <niall.oreilly@ucd.ie> wrote:
On 29 Sep 2025, at 18:17, denis walker wrote:
Let me reverse the argument.
No.
If you won't offer an argument to support your opinion that a this adjustment "would need to be done as a policy, not an NWI", you're not engaging in a debate, and no-one owes you an answer, much less a refutation.
/Niall
Hi Denis, I’ve read your points and I completely agree with them. To sum up: - Using NWI for a change that would introduce a mandatory attribute across potentially millions of objects seems risky and unenforceable. - There are still a lot of unclear details about how a mandatory email would work. - Keeping or adding mandatory email addresses without really understanding their purpose doesn’t seem wise. - Before adding any new attributes, it makes sense to first define what contact information is actually needed and document it clearly in a proper RIPE Database Policy. All of this makes sense to me, and I don’t see any reason to handle it via NWI instead of PDP. Regards, Arash On Fri, 5 Sept 2025 at 20:27, denis walker <ripedenis@gmail.com> wrote:
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 <leo@vegoda.org> wrote:
Hi Denis,
On Mon, 2 Jun 2025 at 18:16, denis walker <ripedenis@gmail.com> 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/
participants (10)
-
Angela Dall'Ara -
Arash Naderpour -
David Tatlisu -
denis walker -
Edward Shryane -
Gert Doering -
Leo Vegoda -
Niall O'Reilly -
Rodolfo García Peñas (kix) -
Sasha Romijn