Re: [weirds] RDAP registrar entities

Brian Mountford <mountford@google.com> Fri, 30 October 2015 17:47 UTC

Return-Path: <mountford@google.com>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1881B2DDC for <weirds@ietfa.amsl.com>; Fri, 30 Oct 2015 10:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-D1NfeVW4S6 for <weirds@ietfa.amsl.com>; Fri, 30 Oct 2015 10:47:26 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36E51B2D5C for <weirds@ietf.org>; Fri, 30 Oct 2015 10:47:25 -0700 (PDT)
Received: by vkex70 with SMTP id x70so51785714vke.3 for <weirds@ietf.org>; Fri, 30 Oct 2015 10:47:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H8hPHS+grRexAgnRhpOAMre180axQTgjePIyreJwYYU=; b=btMtvpd4gKRGBamtgxOkh0NXW3EPmCf5ZQoejt2QmDxK82lceKYyb218L35wxwWm6P YMwYhIa/prbUgOau5hcvLhb0lXOJkaL/IeeCKvt0YSfXjw6EDT7lKd9jUWi8503zRusI RtZgmTc/xdAeFiy48UIK9FqP/5YlBWinaTNeQFTyqjwHLdB2rADSt3zPgOAMh9MB+nYT CDjKDa6HwBSzSY2yAYZINIzy46afHGv+TcJZC+KCgmxEtuGuHD1mpvXXugs28Fjap++6 TZ+bDmOXfDcdyvE3DeJxPVoZceaZvldzSrl6GbjLkxr68tMvk9Vd1ZQVmd6S0bpHB9Nr 6/+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H8hPHS+grRexAgnRhpOAMre180axQTgjePIyreJwYYU=; b=O42VNg0Q8FnO6HihMtz/1kXV+xQ/t/eY4Pl8Sxqjn1jySdSrATlnqypyOTVswCld4M XulQXQWBkP5rYkcFYMyo0QSImT4Odex8x1xMAvY8JE/jmf2wyj5yK6HL/zDx+f0mUVb5 0jU16CFqzEAeNzunCZ4WkcSMyZDERGsBQb2ZiCIGnUXJ+Iu/wH489yrD+W0M3IZAAJm2 0WxtLjJYOhKljXPXemfUX5dyKJigmz13QrkjBQi2uZLHs5vsDTwrevlmX4gc844GAXrS fKkjEal5MusvMoSTQIEiQuP3vAQbzHgckXr0eVL+Azy5UcG62ROdCVE+Anl0NZ4fPllf K7TA==
X-Gm-Message-State: ALoCoQl64MmTciROGVjAAjCSi3T0ZjDIFxHeJxWHvOmmlWhOIs+b4Q4vj/TGE08jQSyW23NdtJ3m
X-Received: by 10.31.188.142 with SMTP id m136mr6277584vkf.36.1446227244874; Fri, 30 Oct 2015 10:47:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.230.68 with HTTP; Fri, 30 Oct 2015 10:47:05 -0700 (PDT)
In-Reply-To: <CALRmJyivuXZtmcKBUjdZ+go_9yvXZjUmRZQ2Bf89umcr9U+0tA@mail.gmail.com>
References: <CALRmJyhTqpJ4NGhrZ4kWv9oenwpA6X=7Ld2S_dg5KGXFeTs8_g@mail.gmail.com> <88D41CC9-BC39-4936-A47E-3618695FB8A9@arin.net> <CALRmJyivuXZtmcKBUjdZ+go_9yvXZjUmRZQ2Bf89umcr9U+0tA@mail.gmail.com>
From: Brian Mountford <mountford@google.com>
Date: Fri, 30 Oct 2015 13:47:05 -0400
Message-ID: <CALRmJyiDiFdY2KPyMOANhSCTQf8zBCqfnK4=UC0EVezyiV8YNA@mail.gmail.com>
To: Andy Newton <andy@arin.net>
Content-Type: multipart/alternative; boundary=001a1143026e3247a20523560591
Archived-At: <http://mailarchive.ietf.org/arch/msg/weirds/POrr2lw3Hmo8-0JXd96KSCjbsiY>
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] RDAP registrar entities
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/weirds/>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2015 17:47:27 -0000

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 <mountford@google.com>
wrote:

> 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 <andy@arin.net> wrote:
>
>> Hi Brian,
>>
>>
>> On Oct 30, 2015, at 12:01 PM, Brian Mountford <mountford@google.com>
>> 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
>>
>>
>