Subject: [weirds] RDAP registrar entities

From: Brian Mountford <[email-masked]>
Date: Fri, 30 Oct 2015 12:01:41 -0400

Hello, all. I have been directed to this list as a possible place to get
some RDAP questions answered. Here's one, regarding RDAP entities, which
appear to include both contacts and registrars. In our system internally,
the two are quite separate, and in fact registrars can themselves have
multiple contacts, just as a domain can. So I'm trying to figure out how to
fit the data into the RDAP format.

First of all, is there a reason why registrars and contacts were lumped
together into one type of thing? Just curious.

The example in RFC 7483 for a registrar included several addresses and
phone numbers, as if the sample registrar also had contacts associated with
it. But none of the addresses and phone numbers were marked with anything
that would distinguish between the contacts (e.g. a type of "admin",
"tech", etc.). Should we just take all the data we have for a registrar,
including all addresses of associated contacts, and throw them into the
entity JSON object one after another? Can we mark them with the contact
role as a type? Or does type always need to be "home" or "work"?

RFC 7482 describes searching for an entity by name. In the case of our
registrars, we have two things that could be a "name": the name of the
registrar itself, and the name of any associated contact. Am I correct that
the search is confined to the registrar name? Or are we supposed to look
through to the contact names, and pass back any registrar with a matching
contact?

Thanks.

Brian

---

From: Andy Newton <[email-masked]>
Date: Fri, 30 Oct 2015 17:09:38 +0000

Hi Brian,

On Oct 30, 2015, at 12:01 PM, Brian Mountford <[email-masked]<mailto:[email-masked]>> wrote:

First of all, is there a reason why registrars and contacts were lumped together into one type of thing? Just curious.

The reason is quite simple. All sorts of organizations end up being modeled the same way, with only a relationship qualifier differentiating them.

The example in RFC 7483 for a registrar included several addresses and phone numbers, as if the sample registrar also had contacts associated with it. But none of the addresses and phone numbers were marked with anything that would distinguish between the contacts (e.g. a type of "admin", "tech", etc.). Should we just take all the data we have for a registrar, including all addresses of associated contacts, and throw them into the entity JSON object one after another? Can we mark them with the contact role as a type? Or does type always need to be "home" or "work”?

This is similar to how some RIRs model ISPs. The ISP is an entity, that then has child entities for the contacts.
See http://rdap.arin.net/registry/entity/ARINOPS as an example.

This type of thing may not be so obvious in the RFC because of the way the JSON is described. I have an RDAP JCR draft that might make it more readable.
https://tools.ietf.org/html/draft-newton-rdap-jcr-00

RFC 7482 describes searching for an entity by name. In the case of our registrars, we have two things that could be a "name": the name of the registrar itself, and the name of any associated contact. Am I correct that the search is confined to the registrar name? Or are we supposed to look through to the contact names, and pass back any registrar with a matching contact?

How you limit or broaden the search is your choice. RDAP just specifies how the query is formulated by the clients. You may have requirements from a policy body about how that is to work, but the protocol is not that proscriptive.

I hope that helps.

-andy

---

From: Brian Mountford <[email-masked]>
Date: Fri, 30 Oct 2015 13:30:27 -0400

I see. So an array of child entities is legal inside an entity or
nameserver, not just a domain, correct?

On Fri, Oct 30, 2015 at 1:09 PM, Andy Newton <[email-masked]> wrote:

> Hi Brian,
>
>
> On Oct 30, 2015, at 12:01 PM, Brian Mountford <[email-masked]>
> wrote:
>
> The reason is quite simple. All sorts of organizations end up being
> modeled the same way, with only a relationship qualifier differentiating
> them.
>
> role as a type? Or does type always need to be "home" or "work”?
>
>
> This is similar to how some RIRs model ISPs. The ISP is an entity, that
> then has child entities for the contacts.
> This type of thing may not be so obvious in the RFC because of the way the
> JSON is described. I have an RDAP JCR draft that might make it more
> readable.
> How you limit or broaden the search is your choice. RDAP just specifies
> how the query is formulated by the clients. You may have requirements from
> a policy body about how that is to work, but the protocol is not that
> proscriptive.
>
> I hope that helps.
>
> -andy
>
>

---

From: Brian Mountford <[email-masked]>
Date: Fri, 30 Oct 2015 13:47:05 -0400

In a related question, I'm trying to figure out how to return information
about contact roles. RFC 7483 includes a roles field at the entity level.
If we are returning information for a domain, that works fine. What do we
put in the roles field, though, if the user queries for the contact
directly? The role would depend on which, if any, domain is referencing the
contact. The contact could be a stand-alone entity with no referencing
domains at all. Is it expected that the registry will loop through all
domains, looking for any that reference the contact, and build a union of
all roles that the contact plays in any domain? That seems inefficient.

On Fri, Oct 30, 2015 at 1:30 PM, Brian Mountford <[email-masked]>
wrote:

>> This type of thing may not be so obvious in the RFC because of the way
>> the JSON is described. I have an RDAP JCR draft that might make it more
>> readable.

---

From: Andrew Newton <[email-masked]>
Date: Sat, 31 Oct 2015 17:08:51 -0400

> nameserver, not just a domain, correct?

Yes, that is true for all object classes. Even entities can have entities.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Sat, 31 Oct 2015 17:13:08 -0400

On Fri, Oct 30, 2015 at 1:47 PM, Brian Mountford <[email-masked]> wrote:
> about contact roles. RFC 7483 includes a roles field at the entity level. If
> we are returning information for a domain, that works fine. What do we put
> in the roles field, though, if the user queries for the contact directly?

Most likely nothing.

> The role would depend on which, if any, domain is referencing the contact.
> The contact could be a stand-alone entity with no referencing domains at
> all. Is it expected that the registry will loop through all domains, looking
> for any that reference the contact, and build a union of all roles that the
> contact plays in any domain? That seems inefficient.

I would hope your indexes aren't built in such a way that you are
scanning all of your domains. Regardless of the inefficiency, roles do
not make sense in the context of an entity query. They are meant to
describe the relationship between an entity and the object instance
containing them.

I hope that helps explain it.

-andy