Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

Marc Blanchet <marc.blanchet@viagenie.ca> Thu, 20 June 2013 22:40 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 64CAE11E8121 for <weirds@ietfa.amsl.com>; Thu, 20 Jun 2013 15:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.55
X-Spam-Level:
X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 j6fhNrWIzqNB for <weirds@ietfa.amsl.com>; Thu, 20 Jun 2013 15:40:20 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C608B11E80E3 for <weirds@ietf.org>; Thu, 20 Jun 2013 15:40:20 -0700 (PDT)
Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3467B4159D; Thu, 20 Jun 2013 18:40:20 -0400 (EDT)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <alpine.BSF.2.00.1306201743410.62258@joyce.lan>
Date: Thu, 20 Jun 2013 18:40:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8CDE91C-4119-40BB-9466-4A6A1EA5A762@viagenie.ca>
References: <20130620161308.61121.qmail@joyce.lan> <89AED632-F3A5-4390-AEC9-4A3D0B626816@viagenie.ca> <alpine.BSF.2.00.1306201405120.61276@joyce.lan> <B77DC9CA-4604-49A7-903D-EED7E3799AA0@viagenie.ca> <alpine.BSF.2.00.1306201527580.61754@joyce.lan> <104DDCFC-DC19-47FC-8353-E1A43837F279@viagenie.ca> <alpine.BSF.2.00.1306201743410.62258@joyce.lan>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1508)
Cc: weirds@ietf.org
Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
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: Thu, 20 Jun 2013 22:40:21 -0000

Le 2013-06-20 à 18:03, "John R Levine" <johnl@taugh.com> a écrit :

>> an XML file is just a small file on the Internet. Cached, there is a copy everywhere.
> 
> I have a physical server in a nearby hosting center and some VPSes in Pennsylvania.  I'm fairly sure there are no http caches in front of any of them and even more sure there are no https caches.  IANA's web servers appear to be on a single physical network in California, not mirrored using Akamai or the like.

ok. I think we are getting way too deep here and becomes completly irrelevant. 

> 
> The RDAP clients I expect to use won't be full web browsers,

don't need to.

> and they're not on consumer ISPs with awful "transparent" web caches. I also have no interest in dragging a big XML parser into a tiny JSON application.

then, I'm against that argument. This is pretty straightforward parsing.

> 
> You know, if we assume that the TTL on the IANA file is a year or two, my baked-in+upgrade approach is functionally equivalent to yours and depends less on third parties who may not want to be volunteered.

there is implementation specificities (that are outside of the scope of the IETF) and there are interop stuff.

What I'm saying is that the client should get the data from the IANA registry. Does it do it often, not often, upgrade, etc... is not in IETF document. However, we should provide some guidance about what to do. The implementor may decide to use or not use the guidance. Therefore, baked-in+upgrade or whatever is irrelevant to me, as long as they use the same source, which is what I care.

marc.



> 
> R's,
> John
> 
>>> So in 2119-ese,
>>> 
>>> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client,
>>> 
>>> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and
>>> 
>>> clients MUST use <tld>.domain.rdap.arpa as an initial server for TLD.
>>> 
>>> In each case, the protocol is https.  Anyone who plans to run an RDAP server and won't be able to provide https should speak up now.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.