Re: [regext] TLD Phase Discovery

Thomas Corte <Thomas.Corte@knipp.de> Mon, 07 August 2017 15:57 UTC

Return-Path: <Thomas.Corte@knipp.de>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4446132586 for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 08:57:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 WuirKKcRAaLu for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 08:57:54 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC8F131CE8 for <regext@ietf.org>; Mon, 7 Aug 2017 08:57:53 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id C0E48980A; Mon, 7 Aug 2017 17:57:50 +0200 (MESZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id kNZKvxzAHRlf; Mon, 7 Aug 2017 17:57:36 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id F3AC19808; Mon, 7 Aug 2017 17:57:35 +0200 (MESZ)
Received: from flexo.fritz.box (fw-intranet-eth3-0.do.knipp.de [195.253.2.17]) by hp9000.do.knipp.de (Postfix) with ESMTP id CE52470E1C; Mon, 7 Aug 2017 17:57:35 +0200 (MESZ)
To: "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
Cc: "support@tango-rs.com" <support@tango-rs.com>
References: <8CC3F09A-084F-41A1-9BE7-F44A293BA665@verisign.com> <d4945015-3413-68a4-18ea-ebbb5f28e315@knipp.de> <ED032B40-2895-4124-9755-26879D7FE5A6@verisign.com> <98dcc1e4-3bc4-0499-2f13-fdd73cb42aed@knipp.de> <673DD6EE-36B6-496B-BA7F-499DD09371D3@verisign.com>
From: Thomas Corte <Thomas.Corte@knipp.de>
Message-ID: <44f0fdc8-d665-6179-41b7-855fd41f460d@knipp.de>
Date: Mon, 07 Aug 2017 17:57:35 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <673DD6EE-36B6-496B-BA7F-499DD09371D3@verisign.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/9vK7x3miHQpkKdYM9iRnO9pKxIk>
Subject: Re: [regext] TLD Phase Discovery
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 15:57:56 -0000

James,

On 07/08/2017 17:18, Gould, James wrote:

> Thomas, 
> 
> My feedback is provided below with a “JG-“ prefix.  
> 
> From a high level, we need other registries and registrars to weigh in on this topic to answer the following:
> ... 

I can see the reasoning behind this outreach, though personally I
wouldn't subscribe to a strictly "democratic" approach with regard to
this topic (or any technical decision for that matter).

For example, in my experience as a registrar client developer, many
registries' EPP servers don't properly handle XML namespaces (in that
they're requiring clients to use the specific namespace prefixes used in
the RFC examples, but don't allow arbitrary other prefixes).
Other registries' EPP servers do occasionally send EPP responses that
violate the EPP schemas.
While these are clearly violations of the relevant specs, someone might
argue that EPP clients not using the "standard" XML namespace prefixes,
or EPP clients actively validating EPP responses against the schemas,
represent "corner cases" not worth supporting.
Needless to say, I wouldn't agree.

> JG-I believe the Available Check Form was added to fulfil the need of determining whether a domain is available in a specific launch phase.  The Availability Check Form should be lightweight and it should not be very difficult for a client to get what is needed once they know what the launch phases are either out-of-band or via an extension like the Registry Mapping.  

Sure, but no command is "lightweight" from the server's perspective if it
has to be sent multiple times to achieve its goal.

> JG-Yes, the question for this use case is whether the availability is strictly based on policy, meaning given the list of known launch phases would the domain name be available in each phase based on its policy?

In our use case, we simply modeled the concept of "premium" domain names
around launch phases. For each category of premium domain names, a launch
phase exists in which only the names from the category are available.
So here it's strictly policy (i.e., the lists or premium names in each
category) that determines a name's availability in a launch phase, not
whether or not the name already exists, or which data is passed along
with the registration.

Best regards,

Thomas


-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: support@tango-rs.com
Germany