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

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)

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

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 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/

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