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.
participants (8)
-
David Tatlisu -
denis walker -
Edward Shryane -
Gert Doering -
Leo Vegoda -
Niall O'Reilly -
Rodolfo García Peñas (kix) -
Sasha Romijn