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