Re: [weirds] New Unified DNR/RIR Internet-Drafts

Byron Ellacott <bje@apnic.net> Wed, 05 September 2012 07:26 UTC

Return-Path: <bje@apnic.net>
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 9A48C21F8513 for <weirds@ietfa.amsl.com>; Wed, 5 Sep 2012 00:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtDUt84UE6lJ for <weirds@ietfa.amsl.com>; Wed, 5 Sep 2012 00:26:56 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id B702021F84F6 for <weirds@ietf.org>; Wed, 5 Sep 2012 00:26:55 -0700 (PDT)
Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 158E1B68FD; Wed, 5 Sep 2012 17:26:54 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_6CA4C5C6-B117-414A-918B-E96578024805"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Byron Ellacott <bje@apnic.net>
In-Reply-To: <CAL0qLwZp6yiTFkuudwz-Qfc5==quJpdSo_EJjDFYx4dMxAEt3Q@mail.gmail.com>
Date: Wed, 05 Sep 2012 17:26:53 +1000
Message-Id: <5DDEE74E-FE2F-42FD-AA75-C3AC9BC4FF4E@apnic.net>
References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <CAL0qLwZTUoiju=HSGm1zgfQbDLC4ByNRygfz8WDyh5gjAUydtw@mail.gmail.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org> <1346815773.1830.43.camel@zenus> <CAL0qLwZp6yiTFkuudwz-Qfc5==quJpdSo_EJjDFYx4dMxAEt3Q@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.1278)
Cc: weirds@ietf.org
Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts
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: Wed, 05 Sep 2012 07:26:56 -0000

Hi Murray,

On 05/09/2012, at 5:03 PM, Murray S. Kucherawy wrote:

> A fairly complete set would appear to be something like:
> 
> draft-designteam-weirds-using-http
> draft-hollenbeck-weirds-rdap-sec
> draft-hollenbeck-weirds-unified-rdap-query
> draft-newton-weirds-unified-json-response
> draft-kucherawy-weirds-requirements (but only if we want to keep a
> requirements document going)
> 
> The issues of redirection and service discovery don't appear to be
> covered in this set.  I seem to recall consensus ion Vancouver
> swinging in the direction of deciding that we don't want to tackle
> discovery on a first pass, but I can't recall where we landed on
> redirection.  (I also admit I haven't yet reviewed the JSON response
> document to know if it covers redirection.)  Please correct me if I'm
> wrong there.

Redirects can be found here:

http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-5.2

> So far response to the middle three has been entirely positive.  Can I
> get some comments on the first and last, and also on the issue of
> redirection, and a few more comments from people representing the name
> registries?

I think I missed a call or two here, so to be clear, I support WG adoption of all five drafts.

Regarding redirection, the text in using-http suggests 301 for permanent relocations, and 307 for all other situations.  I am in favour of specifying only this much about redirection, leaving matters like authentication to be dealt with by each server-client interaction separately.

  Byron