Enable different data models

[pawel-kow]

From https://mailarchive.ietf.org/arch/msg/rpp/f8QgT3OiLgqQosR-dlWBDDeQqVc/

Hi Jaromir,

The protocol should enable such use-cases (and I also put it down as proposal for the requirements after the CENTR meeting).

https://mailarchive.ietf.org/arch/msg/rpp/kZqBi_wvax7PRM-IwjMIIFhMNHc/

However, EPP already tried to enforce the "pets" data model and it seems it failed, so let's face it an consider in RPP if enforcing it is still the best idea. "pets" scenario should be still equally possible in RPP and this is the most important part I guess.

I think there might be some renaissance of "pets" approach together with regulations like NIS-2 related to data verification when there are benefits for both registries and registrars of doing so. This would then remain their decision, not the protocol designer's decision.

Kind Regards,

Pawel

On 11.11.24 09:12, Jaromir Talir wrote:

Hi Gavin,

I agree that contact management is topic that needs special attention
in this new protocol but I'm not convinced that removing many to one
relationship and spreading contact data all around the registry
database is the way forward.

Contrary, I believe in the opportunity to take advantage of progress in
digital identity and authorization protocols (oauth family) where both
registries and registrars will use it not just for keeping contact data
accurate but also for handling all important authorization decisions
(as a replacement for the process of passing around auth_info codes).

Following example in your presentation, let's focus on making contact
data pets instead of cattle 😉

Regards,
Jaromir

On Sun, 2024-11-10 at 09:29 +0000, Gavin Brown wrote:

Hi Jim,

On 8 Nov 2024, at 21:09, Gould, James [email protected] wrote:

Considering that there are a large set of systems using the data
model and operations that exist in EPP, defining a provisioning
protocol that doesn’t target functional parity is missing the
mark. My recommendation is to include language in the charter to
ensure that the work has the appropriate target. --
While I am sympathetic to this, we have an opportunity to review the
functionality that was built into EPP that has become (to use the
term used in the chat room this week) "legacy", for example, contact
transfers. I can think of several others.

Some years ago I presented some findings [1] that showed that the
"many to one" relationship between contact and domain objects that
EPP assumes did not reflect reality. Partly that is a consequence of
EPP's design, but it's worth considering the possibility that contact
information should not be managed separately from domain
registrations.

G.

[1]
https://regiops.net/wp-content/uploads/2017/05/ROW6_Brown_Contact-Object-Management-by-Registrars.pdf

--
Gavin Brown

[pawel-kow]

This seems to be related to #18.

[anewton1998]

I agree a pets vs cattle discussion is worthwhile for requirements but not the charter.

[anewton1998]

As there have no further comments on this issue, I am closing it. The pets vs cattle issue will be part of the requirements discussion.