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 <[email protected]> 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 <[email protected]> wrote: > >> Hi Denis, >> >> On Mon, 2 Jun 2025 at 18:16, denis walker <[email protected]> wrote: >> > >> > Hi Guys >> > >> > I agree that this would be more suited as a policy clause rather than >> just an agreed NWI documented in the mailing list archives. >> >> Are you suggesting that database capabilities should be documented in >> policy? >> >> I can understand why we'd want to document registration requirements. >> Documenting the database requirements in policy would mean that any >> new features could only be added after a policy development process. >> Why add friction? >> >> Regards, >> >> Leo >> > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with > the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
----- 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/
