Re: [regext] TLD Phase Discovery

"Gould, James" <jgould@verisign.com> Tue, 08 August 2017 14:25 UTC

Return-Path: <jgould@verisign.com>
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 C10351324AC for <regext@ietfa.amsl.com>; Tue, 8 Aug 2017 07:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 KmGDGNUCbzlr for <regext@ietfa.amsl.com>; Tue, 8 Aug 2017 07:25:44 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E9AC1324A6 for <regext@ietf.org>; Tue, 8 Aug 2017 07:25:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7600; q=dns/txt; s=VRSN; t=1502202344; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=bPn1ffCQE4dNA0ILsl/lCZa27hFgWZpKODq1Kra/QJk=; b=T3XYDr+p0KuG4DEMZFgOm2VMukmg9WbZ2LcNyxsrFZzm+3iJYigDX0Qh brXks3UjFTJBXxzkoUA/7V+PFVYOKMiOgPUT9gCHGmX4gXhL4s8zOj0BW hX30zs7Kqca6aJ625w1cMDXDBwNTDNP94ufYIToQgLH7HUDWUqVs0Ohwe /1CZsPH6bXI5xsQKQnMuAW33FnbpenQyL6C0m5OFfOebDbzKH3xcF4w1P zzNDLpGbULdv8W/Wbzbd30tkuEHB0w7urcMQEa4vyT2jIlI9790bYSYh7 6uPu9hb97SJEmtZgQmQKPRa/P44zwSqUoJjaVKh495mHjxKfqdbllz0yR w==;
X-IronPort-AV: E=Sophos;i="5.41,343,1498521600"; d="scan'208";a="4201258"
IronPort-PHdr: 9a23:TdP5lhZDSM9ozm7slPIg3AD/LSx+4OfEezUN459isYplN5qZpsy5ZR7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hygbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2hYYsTAeQPPuhYoIvzqFsPsRSwCgajCfjzyjBTg3/6wbE23v4jHAzAwQcuH8gOsHPRrNjtOqscUOe1zLTMzTred/9dxDPz55LNch8/uvGAU697fM3TyUkgEAPFk1GQppH+MjOLyOsNqWmb7/FhVeKgjW4rsR1+oj+qxso1jITCm4wbylfB9SpjwYY1I8W1SFBlbt6+EZtQrCCaN4RwQsMjRWFnpDw2xaEBuZ6+ZCQKyYooxwLRa/CddIiI+B3jWeCMKjl7nHJoYK+ziwqo/US9yODxWNO43EtKoydLiNXAqH8A2hPL5sSaVvdx5Fqt1DST2wzJ9+1JLkM5mbDGJ5MixLM7i4Advl7ZHiDsnUX7lKqWdkI59ee28+nnebDmpoOEN49zlwH+LrwimsyhDuQ8NQgDR3OU+f661LH++U34T7BKgec3kqndt5DaONgbqrKkDwNPzIYs9Qy/Dza90NQZknkHKkhJdw6Aj4jsI13OIfb4Aumjg1m0jTtn2+rKMqDjD5jDNHTPjbfscLhn50JCxwc+wshT55dOBbEAJPLzVFXxtNvdDhIhMQy0zOHnCMh51owDQm+PHLGWMLnTsV+T5+IvLO+MaJUJtzb6Lvgp/+TugmMhmV8BYamp2oMaaGulHvR+O0WZZmDsgssaHGcWpAU+SuPqiFqbXT5JfHa+Rb4z5jY+CIi+F4fMWpitgKCd3Ce8BpBWfH5JCl+SHnbna4WJQPYMZzyOIs9viDAEUqKhS4A53xG0qAD606ZnLvbT+iAAq5zj1N915+jJmhEp7zB5EcOd03uRT25qhW4IRDk23KFnoUxl0FuMzLZ30LRkEolv5/RMWxxyHpnG0+EyX+zyXQfIZZGiT0y6T/2lBzApVpQ9zolKKwxnFtqvngzr3ie2DfkSjbPBTMgu/63Rz2TZJsthxTDBzqZ33Hc8Rc4af0Khm6pzs0DxDovEiA/Rw6SlcrkY0AbT+X2C1muBugdTVwsmAvaNZmwWekaD9Yex3UjFVbL7TO1/agY=
X-IPAS-Result: A2FUAADTyIlZ//SZrQpZAxoBAQEBAgEBAQEIAQEBARUBAQEBAgEBAQEIAQEBAYMCgRGBFAeOCJF1lhWBTxshByELhExPAhqFERgBAQEBAQEBAQEBAQKBEIIzJAENRiEFAQUBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCAIIBy8SAQEZAQEBAgEBASEROgsOAgIBCA0NAiYCAgIZDAsVEAIEAQ0FG4oMGKwkgiaLUAEBAQEBAQEBAQEBAQEBAQEBAQEBAR0FgQaCHYNPgg2BcIEMhHMXCiaCTDCCMQWQeI8YBgKHUYNSiyBZhQSKY4t9ig4fgUN3FUkSAYUEHIFndoh8gQ8BAQE
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v78EPgMf011894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 Aug 2017 10:25:42 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Tue, 8 Aug 2017 10:25:42 -0400
From: "Gould, James" <jgould@verisign.com>
To: Thomas Corte <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
CC: "support@tango-rs.com" <support@tango-rs.com>
Thread-Topic: [EXTERNAL] Re: [regext] TLD Phase Discovery
Thread-Index: AQHTD5oCG0SBgKxuqUGrZkMUR8ax/qJ5XSCA///hGYCAATI+AIAAFMGA
Date: Tue, 08 Aug 2017 14:25:41 +0000
Message-ID: <71D1C6B2-F9AC-416C-A024-C226B036B52C@verisign.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> <44f0fdc8-d665-6179-41b7-855fd41f460d@knipp.de> <SN1PR0201MB1792004419E7E4B6047D4F5DBFB50@SN1PR0201MB1792.namprd02.prod.outlook.com> <301b4b49-c836-b107-7e84-d384f5536f6d@knipp.de> <80F5AA8E-EAC3-4FFA-B9C2-665D2B278727@verisign.com> <8ed43988-5b06-1803-2b76-753b531821c5@knipp.de>
In-Reply-To: <8ed43988-5b06-1803-2b76-753b531821c5@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <35EA22B11F119F4AAD263B6E92DAF841@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/DMwOIA5h6tZ-dRNxLArStEsEyAc>
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: Tue, 08 Aug 2017 14:25:47 -0000

Thomas,

My feedback is provided below “JG-“.  

Overall, I believe that “phase-agnostic” premium domain names is not a model that draft-ietf-regext-launchphase is designed for or should be designed for.  My recommendation is to focus on how draft-ietf-regext-epp-fees can meet your needs for premium domain names without coupling it with launch phases as an alternative for fee classifications.   
  
—
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 8/8/17, 5:11 AM, "regext on behalf of Thomas Corte" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> wrote:

    Hello James,
    
    On 2017-08-07 20:55, Gould, James wrote:
    
    > Use of the phase and sub-phase as a mechanism for clients to indicate
    > fee or domain grouping categories was not the intent in
    > draft-ietf-regext-launchphase.  At the IETF-98 REGEXT WG meeting it
    > was unclear when there would be overlapping launch phases.
    
    I think that the launch phase draft itself provides a use case. One of
    the examples for the availability check form contains the custom phase
    name "idn-release", which most likely refers to a registry introducing a
    new set of IDN tables (which may happen years after the TLD initially
    launched), making new domains available which were previously not
    available, potentially at a different price and most likely with a
    different registration model, i.e. as applications rather than immediate
    registrations. Such an "idn-release" phase would most likely be run in
    parallel to a (perpetually running) "open" phase for ordinary domain names.
    

JG- draft-ietf-regext-launchphase does support multiple launch phases in sequence or in parallel to meet the needs of launching a TLD, but what you describe is not a launch phase by releasing previously reserved domain names (e.g., “idn-release”).  There are many approaches that can be taken for the releasing of reserved domain names and I don’t see defining a parallel custom launch phase to the open launch phase as an effective one.  Someone could attempt to morph the releasing of reserved domain names into a launch phase, but it is not what draft-ietf-regext-launchphase was designed for. 

    > The launch
    > phase and sub-phase is meant to cover the launch of the TLD itself,
    > where your overlapping phases does not apply to the TLD but to groups
    > of domains within the TLD.
    
    The IDN rollout depicted above contains a use case (which as obviously
    anticipated by the launch phase draft authors) where groups of domains
    are available in different phases.

JG-The launch phases fundamentally define the registration flow that is expected of the client, so it is cross-cutting for a TLD that does not work well for a subset of domain names. 
    
    > I believe use of
    > draft-ietf-regext-epp-fees is the appropriate path forward for the
    > grouping of premium domains and not use of phases and sub-phases in
    > draft-ietf-regext-launchphase.  If you fully transition to leverage
    > draft-ietf-regext-epp-fees for premium domain grouping, do you have
    > any need for overlapping launch phases in
    > draft-ietf-regext-launchphase, and if so please describe why?
    
    A need for overlapping launch phases might always arise, see above.
    Also, nowhere in the launch phase extension draft has the use of
    overlapping launch phases been excluded or forbidden. On the contrary,
    at one point it is explicitly mentioned that "Domain names may be made
    available only in unique launch phases, whilst remaining unavailable for
     concurrent launch phases.".
    
    Of course, a "phase-agnostic" implementation of premium domain names is
    possible and can indeed be accomplished with the fee extension as it is
    currently drafted.
    That said, the refactoring efforts involved to migrate a registry system
    like ours which has been designed in a phase-centric way are
    non-negligible. As it currently stands, I'd rather try to stretch the
    interpretation of the launch phase/fee extension specs in order to make
    them work with our model if need be. That's why I'd rather see the specs
    offering a clean solution for our model than forcing us to work around them.
    
JG-I agree that there may be a use case where a domain name may be available in only specific launch phases, but it is a corner case that is already supported by draft-ietf-regext-epp-fees.  I don’t believe that “phase-agnostic” premium domain names is a model that draft-ietf-regext-launchphase is designed for or should be designed for.  My recommendation is to focus on how draft-ietf-regext-epp-fees can meet your needs for premium domain names without coupling it with launch phases as an alternative for fee classifications.   

    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
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext