Re: [regext] TLD Phase Discovery

Thomas Corte <Thomas.Corte@knipp.de> Fri, 04 August 2017 11:20 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 E2026126CC4 for <regext@ietfa.amsl.com>; Fri, 4 Aug 2017 04:20:04 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] 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 FRAIy_I8nOQY for <regext@ietfa.amsl.com>; Fri, 4 Aug 2017 04:20:01 -0700 (PDT)
Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E46D132161 for <regext@ietf.org>; Fri, 4 Aug 2017 04:20:01 -0700 (PDT)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4B8349832; Fri, 4 Aug 2017 13:20:00 +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 WjYf2+cWiZkj; Fri, 4 Aug 2017 13:19:51 +0200 (MESZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 0BD459830; Fri, 4 Aug 2017 13:19:51 +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 E887C76C90; Fri, 4 Aug 2017 13:19:50 +0200 (MESZ)
To: regext@ietf.org
References: <8CC3F09A-084F-41A1-9BE7-F44A293BA665@verisign.com>
Cc: support@tango-rs.com
From: Thomas Corte <Thomas.Corte@knipp.de>
Message-ID: <d4945015-3413-68a4-18ea-ebbb5f28e315@knipp.de>
Date: Fri, 04 Aug 2017 13:19:50 +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: <8CC3F09A-084F-41A1-9BE7-F44A293BA665@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/xFEwJvZ6Jc6vBkmaOokW9XuLhxs>
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: Fri, 04 Aug 2017 11:20:05 -0000

James,

On 03/08/2017 18:12, Gould, James wrote:

> Roger,
> 
> I believe TLD level EPP policies is relevant, but is best suited for
> something outside of the Launch Phase or Registry Fee command-response
> extensions.   An example policy EPP mapping is the Registry Mapping
> (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html)
> that does provide launch phase schedule information at the TLD (zone)
> level.  Something like the Registry Mapping with extensions to define the
> features and policies of EPP extensions like the Launch Phase or Registry
> Fee extensions is best suited for defining and discovering the features
> and policies.    

This "Registry Mapping" extension seems suitable to discover the more
"static" properties of a registry's setup (including the generally
supported phases).

However, what I'd also like to see is a more "dynamic" phase discovery.
In particular, we should cover cases in which a specific domain name may
only be available when created in specific launch phases, and provide a
way to determine these phases (this functionality was unfortunately
removed from the fee extension in draft-ietf-regext-epp-fees-06).

To me, such a feature seems closely tied to the "Availability Check Form"
defined in the launch phase extension, which is defined exactly for that
purpose (from the launch phase extension draft: "Domain names may be made
available only in unique launch phases, whilst remaining unavailable for
concurrent launch phases.").
The only problem is that the "Availability Check Form" forces registrars
to perform trial-and-error probing, since it requires the specification
of a launch phase and will only tell whether or not that phase is
suitable. Registrars need to check all known launch phases in turn until
a suitable one is found.

The problem of launch phase discovery for specific names could therefore
be solved as an extension of the launch phase extension, e.g. by making
the specification of the phase for the "Availability Check Form"
*optional* and, if not specified, allowing the command to return a list
of suitable launch phases for the name.

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