Re: [weirds] Scrap Bootstrapping

Marc Blanchet <marc.blanchet@viagenie.ca> Tue, 12 November 2013 16:08 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 3F48D21E828B for <weirds@ietfa.amsl.com>; Tue, 12 Nov 2013 08:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 9lbJtTYgN7xK for <weirds@ietfa.amsl.com>; Tue, 12 Nov 2013 08:08:27 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 07AFA21E8257 for <weirds@ietf.org>; Tue, 12 Nov 2013 08:08:22 -0800 (PST)
Received: from [IPv6:2620::230:c000:b8e8:f0f9:f16e:c10b] (unknown [IPv6:2620:0:230:c000:b8e8:f0f9:f16e:c10b]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6CFCB403D0; Tue, 12 Nov 2013 11:08:21 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <20131112155826.70529.qmail@joyce.lan>
Date: Tue, 12 Nov 2013 11:08:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC23A057-E576-4A7A-BF84-6C041B58AE30@viagenie.ca>
References: <20131112155826.70529.qmail@joyce.lan>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1822)
Cc: "weirds@ietf.org Group" <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 16:08:28 -0000

Le 2013-11-12 à 10:58, John Levine <johnl@taugh.com> a écrit :

>> If we can't come up with one way to bootstrap all queries we should just forget the idea and
>> explore other ways to make it easier for a client to find servers.
> 
> I halfway agree.  For numbers, experience suggests that faking it will
> work, starting with a coarse fixed bootstrap, e.g. for IPv6 a table
> derived from
> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
> which hasn't changed since 2006.  I understand the possibility that
> there might someday be a lot of top level xIRs who don't talk to each
> other, but we'll have to burn that bridge when we get to it.
> 
> I'm more concerned about TLD bootstraps, in particular the ones for
> the new ICANN TLDs.  For the existing ICANN TLDs, there are under 20
> of them, and the servers rarely change.  

our solution should be agnostic to the fact that a TLD is a new/old gTLD or ccTLD. it is a TLD.

> For ccTLDs, most don't
> provide WHOIS at all, or don't provide any details beyond the fact
> that it's registered, and the few that do like .US and .CO rarely
> change, so again we can fake them with a fixed table.  

The fact that data change rarely is good, but going to the conclusion that it should be burned is not good. Because then, you can not update.  
The decision of an implementer on how it will update its own table is implementer decision. What we ought to achieve is to define a method that provides accuracy and reliability of the data, therefore our method should always return the right data. If the implementer decides to cache some data, then fine, but that is an implementation decision.

> 
> For the new TLDs, though, they'll all have RDAP if ICANN tells them to
> which seems likely.  But since they all are ICANN contracted, how about
> if we ask ICANN to add an RDAP field to the IANA data,

this is what in the internet draft draft-blanchet-weirds-bootstrap-ianaregistries: add a column with rdap, similar to the whois entry already in the current table of TLDs.

> and we scrape
> that every once in a while?

if we agree on the iana registries, then i have already some text to give guidelines to the client on what to do with the registry: fetch it often, not often, cache it, etc... This is the extent we can do.

Marc.

> 
> If we can do that, we should be able to fake the whole thing.
> 
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds