Re: [regext] TLD Phase Discovery

"Gould, James" <jgould@verisign.com> Fri, 18 August 2017 17:56 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 662DB13217D for <regext@ietfa.amsl.com>; Fri, 18 Aug 2017 10:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 0MqP7iy_O3zC for <regext@ietfa.amsl.com>; Fri, 18 Aug 2017 10:56:33 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4846126B71 for <regext@ietf.org>; Fri, 18 Aug 2017 10:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8462; q=dns/txt; s=VRSN; t=1503078989; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=Hchc8yW74XvyJ45aT4iBmN8td4ye08/HStOcXiK1my8=; b=SkWIHguqsZ5SGJrNaCcpAbsWyB/zlB60CIcZqZw8b6DeZTUpSP6Fo6kR vf7li9wGDlykX/FG5qntNCKiA+xIb3/m1ePDh+drrakuS8cEU2AVSxEc+ H5YDOWm0IOriGmXI0mZgy2HmFsrg4WeiGFJQps9barKc2kCzMnSOcC8+J eoaNdVFit6ZQPEoCaI9KuHvQzp73ZbW25mGiV650ALqv6X2mUwWP9NlmX E19AlrmSiAQAn3A9bnYmSBLc3NpkJCoI2ZlTf9q/zzV/1Vlefonz/72xw hINBedYpHp0DPL55hT+DhBdYQycKE4iAOBoV8u7bHDujSsOoXV2xHzBaz w==;
X-IronPort-AV: E=Sophos;i="5.41,393,1498521600"; d="scan'208";a="2267603"
IronPort-PHdr: 9a23:EPikvxda/C2yYzRNgmYv70RWlGMj4u6mDksu8pMizoh2WeGdxcW+bB7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v6bpgRh31hycdLzM38H/ZhNFsjKxVoxyhqR5wzIDVYI6JO/RxcbjQfc8BSmpEQspdSzZMD4G6YoASD+QBJ+FYr4zlqlcArBW+AhSsBOfyxTNQm3T42bc10+E/HgHd0gArAtUDsHbbrNXyKacSVf26wbLWzTrddfNW2Cz96InHchAnu/2DQbVwcc/IxEQpCgjLgFKQqYn/MDOU0OQAq3ab4PR6VeKukG4nqg5xoj6uxscqlobFnJ4aylfB9Slh3Ik6O9u4SFJhYdG+FJtQsSCaOJdsTsw+RGFovT42yrwYtp6ncigG0pMnxwTQa/GBboOG4QrjWf6MLTtknn5pZbCyihio/US9yuDxWNO43EhFoydFitXAq2wB2wbO5sWFVvdx5Fqt1DmM2gzJ9+1JIkY5nrfBJZE72L4/jJ8TvFzGHi/xhUr5krebdl4h+ui08+TnZajmpoOEO490lA7+NqMul9SkDuQiNAgCQmyb+Ou51LL5/E35RLJKjuAqkqXFrpzWP9obqbCjAw9UyYYj6hm/DzG83NsEmnkHKUpJeBOBj4f3J1HDOO30Aeulj1ixkjpmyerKMqDhD5jDNHTPjrjscLZl505Z0gUzzNRf55xOCrEGJfL+Qk3xtNPfDh8kNwy73v3qCMtj2YMEWGKPGa6ZMKzUsVOS+u0vJOyMaJcPuDnhM/gl++LujXghlF8HY6ap0oUYaX+kHvl9IkWWf2bsgtkbHWcNpAo+Q/TgiEeeXj5Le3ayQ6U86yk6CI24EYfDSJugj6aH3CenGZ1WZ2ZGBkqKEXfsJM24XKIlbj6VI8kprDEeTrOhVpUs01n6tQLmxZJuKPbT+ytes5a1kJA//eDcmAEu3T15E8rb1HuCBSkghG4HSi8q9KFyvUI7zU2Mh/tWmftdQJZ84O5NXkNyF5fZwvcwQ4TwVQXcetuhVlu8Q86nDjd3RdU0lYxdK31hEsmv20iQlxGhBKUYwuSG
X-IPAS-Result: A2EcAQBSKZdZ//WZrQpaAxoBAQEBAgEBAQEIAQEBARQBAQEBAQEBAQEBAQcBAQEBAYMCgRGBFQefaiKXaxshByELhExPAhqEFBUBAQEBAQEBAQEBAQKBEIIzIhBGIQUBBQEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEIAggHLxIBARgBAQEBAgEBASEROhsCAQgNAQoCAiYCAgIlCxUQAgQBEoooGKxtgiaLYgEBAQEBAQEDAQEBAQEBAQEBAQEdgQuCHYNPgWIrC4FlgQyEUCMXCiaCTDCCMQWRF48wBgKHUoNViylZhQiKbYwHihc1gS13FUkSAYcHdokogQ8BAQE
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v7IHuUqa020450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2017 13:56:30 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 18 Aug 2017 13:56:30 -0400
From: "Gould, James" <jgould@verisign.com>
To: Antoin Verschuren <ietf@antoin.nl>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] TLD Phase Discovery
Thread-Index: AQHTFSrzu9Mqps0XzEeeFNWnAht24KKFsVoAgATKOID///C6gA==
Date: Fri, 18 Aug 2017 17:56:29 +0000
Message-ID: <1608AA8C-5147-4557-B217-AA0A814BA4A5@verisign.com>
References: <D0517C3D-1E10-472B-B90A-A3A4D4A7AA13@verisign.com> <2320d779-3c0e-3b1e-4d03-d4bc3b11467c@centralnic.com> <1453C47F-67D1-4473-9434-5085F7AB46FF@antoin.nl>
In-Reply-To: <1453C47F-67D1-4473-9434-5085F7AB46FF@antoin.nl>
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: <A4EBF53A1B2A8C4B8052D998EAA14BDB@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/BCjvVQfXpUYEx1eNYWlUNGa_NAc>
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, 18 Aug 2017 17:56:35 -0000

Antoin,

Thanks for summarizing the points.  I provide feedback inline below.
  
—
 
JG



James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

On 8/18/17, 10:51 AM, "regext on behalf of Antoin Verschuren" <regext-bounces@ietf.org on behalf of ietf@antoin.nl> wrote:

    Hi all,
    
    In order to achieve progress, I’m trying to summarize the discussion:
    
    1. Most folks agree there may be a need for phase discovery.
    When there are multiple phases for registration, and there are real world examples for that, being able to discover the phase a domain is viable in through an availability check is at least "handy”, to avoid trial and error or out of bound discovery processes. This may be true for other EPP "knobs” as well though.

JG- draft-ietf-regext-launchphase supports determining the availability of a domain in a specified phase currently via the Availability Check Form.  I believe more generic discovery is handled better by an object mapping of the TLD (zone) like the Registry Mapping.  
    
    2. This need only arises in corner cases though.
    We’re not talking millions of domain names here. If we are, then there may be something wrong with the registry policy being too complex, and not the registration process.

JG-I view overlapping launch phases as a corner case, but draft-ietf-regext-launchphase already does support overlapping launch phases.
    
    3. The Launchphase draft and it’s check command was not meant to address this need.
    The launchphase process only describes how to do things once you know what you want to do.
    Can I conclude that the Launchphase draft should proceed as is?
    
JG-Yes

    4. The major demand for phase discovery is to discover the correct fee.
    I understand this business wise. You want to present your customer the correct fee during registration.
    But this one bugs me a little bit. <chair hat off>
    While I understand that a special launch phase may be accompanied with a different fee because of potential special handling, this should not be a differentiator to group fees imho though.
    A (launch) phase is meant to differentiate in a different allocation policy, like preference or limitation in registrants, equal distribution, respect for trademarks or other policy related allocation.
    When trying to discover a phase based on it’s fee, it feels like you are trying to ignore the policy as the true differentiator, almost saying the policy doesn’t matter, and for the right fee, we will try to comply to or even ignore the policy in stead of the intent of first complying to the policy and then care for the extra fee. </chair hat off>
    The question therefor is if the Fee document will be able to solve this?
 
JG-I don’t believe that a launch phase should be a replacement for a fee classification.  I’m not sure whether the registry fee extension will be able to solve the use of launch phases as a form of fee classifications.  I believe it’s best to consider how to handle overlapping fee classifications in support of premium domain names with the registry fee extension.  What is defined now should meet the need.
   
    The major question for the chairs now is if we can proceed with the Launchphase document.
    The chairs believe that there is majority consensus to not change the Launchphase document.
    If not, we would like to hear that before the end of next week so we can proceed that document to the IESG.
    
    The second question then is if there is a need to change the Fee document to accommodate the use case Thomas needs.
    Or that it needs a more generic phase discovery like the suggestion for a Registry Mapping document.
    We expect that this will be discussed during the interim meeting next wednsesday.
    
JG-I believe that the fee classifications and the fee information returned by the registry fee extension should be the basis for clients to make fee decisions and for the servers to apply fee policies.  Generic discovery of TLD (zone) level policies and features, including current and future launch phases, is best suited for an extension like the Registry Mapping.   

    Please comment if any of my conclusions on the consensus is incorrect.
    
    Regards,
    
    - --
    Antoin Verschuren
    
    Tweevoren 6, 5672 SB Nuenen, NL
    M: +31 6 37682392
    
    
    
    
    
    
    Op 15 aug. 2017, om 15:42 heeft Gavin Brown <gavin.brown@centralnic.com> het volgende geschreven:
    
    > On 14/08/2017 19:27, Gould, James wrote:
    > 
    >> As a co-author of Launch Phase Mapping going back 5 years and the one that added the “Domain names may be made available only in unique launch phases, whilst remaining unavailable for concurrent launch phases” language to the draft, I’m aware of the intent.  Wil and Gavin can also weigh in on the intent.  The intent was for the launch phases to be associated with the TLD (or zone), where there may be a policy for launch phases that differentiates the availability of domain names.  It was never intended or foreseen that a launch phase would be used to group a set of domain names as a form of fee classification.  We can agree to disagree on this topic.
    > 
    > I agree with Jim. The Launch Phase was not designed to deal with premium
    > names: I would not have created the fee extension if it were.
    > 
    > G.
    > 
    > --
    > Gavin Brown
    > Chief Technology Officer
    > CentralNic Group plc (LSE:CNIC)
    > Innovative, Reliable and Flexible Registry Services
    > for ccTLD, gTLD and private domain name registries
    > https://www.centralnic.com/
    > 
    > CentralNic Group plc is a company registered in England and Wales with
    > company number 8576358. Registered Offices: 35-39 Moorgate, London,
    > EC2R 6AR.
    > 
    > _______________________________________________
    > regext mailing list
    > regext@ietf.org
    > https://www.ietf.org/mailman/listinfo/regext