IETF Logo Mail Archive

Re: [eppext] [gtld-tech] RDAP server of the registry

Kaveh Ranjbar <kranjbar@ripe.net> Tue, 06 October 2015 14:05 UTC

Return-Path: <kranjbar@ripe.net>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F001ACD0E for <eppext@ietfa.amsl.com>; Tue, 6 Oct 2015 07:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Level:
X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, 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 xHHG76fZ93t6 for <eppext@ietfa.amsl.com>; Tue, 6 Oct 2015 07:05:09 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650581ACD14 for <eppext@ietf.org>; Tue, 6 Oct 2015 07:05:04 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <kranjbar@ripe.net>) id 1ZjSrU-0007W6-9b; Tue, 06 Oct 2015 16:05:01 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::1c3]) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <kranjbar@ripe.net>) id 1ZjSrT-0002ja-NZ; Tue, 06 Oct 2015 16:05:00 +0200
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D836E2F5-B908-49B6-A584-5048F58367E2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5
From: Kaveh Ranjbar <kranjbar@ripe.net>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A0A9B8A@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
Date: Tue, 06 Oct 2015 10:04:55 -0400
Message-Id: <9FBF2B96-1FF2-4A5F-9697-388AEA71BF67@ripe.net>
References: <D23802A0.C0D5E%gustavo.lozano@icann.org> <831693C2CDA2E849A7D7A712B24E257F4A0A9B8A@BRN1WNEXMBX02.vcorp.ad.vrsn.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
X-Mailer: Apple Mail (2.2098)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message
X-RIPE-Signature: 98103304a313f58a8eac8a386a982e5b5f05c2114a66e4c938f5bd914a6943e0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/mchWdOiNZpgSy-owb5YWQfY0V-E>
X-Mailman-Approved-At: Fri, 09 Oct 2015 04:32:48 -0700
Cc: "gtld-tech@icann.org" <gtld-tech@icann.org>, "eppext@ietf.org" <eppext@ietf.org>, Gustavo Lozano <gustavo.lozano@icann.org>
Subject: Re: [eppext] [gtld-tech] RDAP server of the registry
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Oct 2015 14:05:11 -0000

Hi Scott,

With all due respect I disagree. The intent of the document is to outline ICANN’s “policy” towards it’s Registries and Registrars. It basically points out the RFC’s they have to comply with and outlines a few issues and provisions, mostly ICANN specific requirements (for example details of address information) which IMHO is out of scope of an I-D.

On the other hand, there are few issues pointed out in the document (specially the ones from Appendix A) which are good candidates for IETF discussions and possibly updating (or writing new) RFCs.

All the best,
Kaveh.

> On 05 Oct 2015, at 13:11, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> 
> Gustavo, I’d very much prefer to see the profile described in an I-D and developed using the IETF’s consensus process. I’m also willing to back up that preference with writing help as needed. I’ll have specific comments on the profile itself “soon”.
> 
> Scott
> 
> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gustavo Lozano
> Sent: Monday, October 05, 2015 10:34 AM
> To: gtld-tech@icann.org
> Cc: eppext@ietf.org
> Subject: [eppext] RDAP server of the registry
> 
> Hello,
> 
> The first version of the ICANN gTLD profile was published days ago, (see:http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html <http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html>), this document describes basic parameters and objects to be implemented by ICANN-contracted parties.
> 
> The gTLD Whois output contains a field with the Whois server of the Registrar. In the case of thin registries, this allows the end user to get the registration data from the registrar, and in the case of thick registries, this allows the end user to query for extra Whois fields (e.g. registrar expiration date).
> 
> The gTLD profile support the same functionality with the following mechanism:
> 
> The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL for the queried domain object.
> 
> Questions for this group:
> 
> * What do you think about this proposal? If you have different ideas on how to provide this functionality, please share it with the group.
> * What is your opinion about documenting this mechanism in an I-D?
> 
> 
> Regards,
> Gustavo Lozano
> ICANN

v2.23.0 | Report a Bug | By Email