Re: [weirds] Scrap Bootstrapping

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 12 November 2013 17:49 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7445F21F9C78 for <weirds@ietfa.amsl.com>; Tue, 12 Nov 2013 09:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrce9ffXul-8 for <weirds@ietfa.amsl.com>; Tue, 12 Nov 2013 09:49:09 -0800 (PST)
Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1439221F8423 for <weirds@ietf.org>; Tue, 12 Nov 2013 09:49:08 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUoJqE6f4v4vmn2QgfZiTKVQTsIL1iZTe@postini.com; Tue, 12 Nov 2013 09:49:09 PST
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rACHn7Jt029155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 12:49:07 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 12 Nov 2013 12:49:06 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Simon Perreault <simon.perreault@viagenie.ca>
Thread-Topic: [weirds] Scrap Bootstrapping
Thread-Index: AQHO37tcKigHNXvKBUmx4fl+o+mMV5oh34CS
Date: Tue, 12 Nov 2013 17:49:06 +0000
Message-ID: <3AB57011-7136-4823-B7F5-59364C4C5A85@verisign.com>
References: <831693C2CDA2E849A7D7A712B24E257F492D165C@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <52824844.2010609@viagenie.ca>
In-Reply-To: <52824844.2010609@viagenie.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Scrap Bootstrapping
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 12 Nov 2013 17:49:15 -0000

(Sorry, using a UI- constrained device)

Scott

> On Nov 12, 2013, at 10:25 AM, "Simon Perreault" <simon.perreault@viagenie.ca> wrote:
> 
> Le 2013-11-12 06:59, Hollenbeck, Scott a écrit :
>> how do we bootstrap queries for entities?
> 
> There's no global namespace for entities, contrary to domain names and IP addresses. Entities are specific to a particular RDAP server. So IMHO bootstrapping entities is a non-issue.
> 
Actually, I think this is part of the whole issue. Bootstrapping as currently envisioned only works for a portion of the query space. What good is a partial solution?

>> Maybe it would be easier to create an IANA
>> registry of servers that includes a URL to the service, a text field
>> that identifies the server operator, and a text field that includes a
>> list of tokens that identify the objects for which the server
>> contains information. Clients can retrieve and parse the list,
>> present that information to a user or program, and let the
>> user/program pick the server to send the query to.
> 
> IMHO the proposal from draft-blanchet-weirds-bootstrap-ianaregistries is simpler and cleaner.

Perhaps it is. If one solution works for all query types it'll make client implementation much easier - but again, I don't see how this works for all query types.

Scott