Re: [regext] TLD Phase Discovery

Roger D Carney <rcarney@godaddy.com> Mon, 07 August 2017 16:50 UTC

Return-Path: <rcarney@godaddy.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 3DD721321D2 for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 09:50:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secureservernet.onmicrosoft.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 7qflC-7DiQ3U for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 09:50:50 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0119.outbound.protection.outlook.com [104.47.40.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8413A1321CE for <regext@ietf.org>; Mon, 7 Aug 2017 09:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secureservernet.onmicrosoft.com; s=selector1-godaddy-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kwZh4OSiGAgnV8VeQyEPDglzZeKwuf0tcyAwyetVlHA=; b=rpcpVpinukZZoLqZ7WuHd6WbT3vnCR5jNgYbxXI4B0UQhX5T8QawMBKV6fKTMooDjsDWdn7pCvb5ezh+NeeqtmYP34uBPEwTqzCL86XLkoQ9vWgQPrKLrAw/G7kD3ZeiZaP6LzCgOynPqgHmxlWBJYoD4rEsamBcdqSDRwpUHVM=
Received: from BN6PR02MB2547.namprd02.prod.outlook.com (10.173.142.10) by BN6PR02MB2545.namprd02.prod.outlook.com (10.173.142.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.16; Mon, 7 Aug 2017 16:50:49 +0000
Received: from BN6PR02MB2547.namprd02.prod.outlook.com ([10.173.142.10]) by BN6PR02MB2547.namprd02.prod.outlook.com ([10.173.142.10]) with mapi id 15.01.1304.025; Mon, 7 Aug 2017 16:50:49 +0000
From: Roger D Carney <rcarney@godaddy.com>
To: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] TLD Phase Discovery
Thread-Index: AQHTDHNVJnkAGVdue0m4+ZVg/2xna6J0DkUAgAA9CACABFkmgIAAY4AAgAAK64CAAAaD4A==
Date: Mon, 07 Aug 2017 16:50:49 +0000
Message-ID: <BN6PR02MB25472A241C4FD4BF63BE4C00B1B50@BN6PR02MB2547.namprd02.prod.outlook.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>
In-Reply-To: <44f0fdc8-d665-6179-41b7-855fd41f460d@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcarney@godaddy.com;
x-originating-ip: [199.189.229.39]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR02MB2545; 6:syq/gMEOrD9/3xlXJqC+m+mdsJZPoWuWmYJ92n0JCVjPeXpvqAsGGTR/NRYl316N/rTaGbP7K/NPWKshpoq2qXkS/UVquxouV2JlF7bZTQV64jTGH6/O5Mh9UITzWpb8UG8VZmE6P6nMKZUyahm9j4BX18jA53EhoPIucJ+WBBGC6JOk2gHQzp2oNLkh91CmcyHKiLhf9p3ugwjWgQA/xtc3Br70K9JBFxlI4xQNMvBSq7jyA6TideAoxkcGCVD6PcqtK+Zc9iyGOqIqSS+VzCdAjN+6lRHHFPQJv0Hy9O4ylx5yw91Rz4MhMRY3UfPQ8do8THy9NXBWx8P85zH/QA==; 5:dePW4czaTQBHAX/BZZeYRWRxLeuTcObSwJQ9jEdidHJ92XOhQDjVTMKPva439+AafLmt02aJrFzy47Y1BKm2vCI9IjudUdVdGoXpukOQv0mcAPKxUQo86tP/1yaxnTGdz7KxtDi/ih+ELzuKKYUdhQ==; 24:NTu00quHufsgH97IXM9tBHvzaoGiozZJlauP+j48HkE+RzxUEV0no6BqYz4SoNkjtHqDBZw3eLGRUszdBvPQ8WnSkv+ksDRmbx4pB3iMRyE=; 7:LpCu/nN7vjcvC0T7/6116Fg/sXlbKNwIUebGZ3W1BX/jlpKtbaMPcdos/BrPcUTEoSqOWOfT+O7Ip7awLbOW+iiM3ENaJuDh44DeBscXXZ/kinknb3iA+d+P+ooNea1c8NrP5aGQt5QK7LHuZ+ZZZh2DAYJFiOLPB/K6NUHYFebuiBmSlMZoKD48tnsE1AOXlgX+wKxEXnIwTQzVZywZ5zDZbPEdR0RqoRScio0pRJc=
x-ms-office365-filtering-correlation-id: bca09a93-6e24-4793-0e09-08d4ddb47507
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR02MB2545;
x-ms-traffictypediagnostic: BN6PR02MB2545:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: <BN6PR02MB254599ABC4FA7CBF2A16F0E0B1B50@BN6PR02MB2545.namprd02.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR02MB2545; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR02MB2545;
x-forefront-prvs: 0392679D18
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(39400400002)(199003)(24454002)(189002)(13464003)(252514010)(377454003)(33656002)(2950100002)(6916009)(8936002)(7736002)(53936002)(38730400002)(2351001)(1730700003)(81166006)(81156014)(8676002)(3660700001)(606006)(74316002)(478600001)(93886004)(53546010)(966005)(86362001)(5660300001)(7696004)(2906002)(14454004)(3280700002)(6436002)(2900100001)(66066001)(229853002)(6306002)(54896002)(99286003)(236005)(50986999)(5640700003)(2501003)(68736007)(54356999)(53946003)(55016002)(76176999)(5630700001)(101416001)(25786009)(6506006)(97736004)(6246003)(6116002)(790700001)(110136004)(3846002)(102836003)(9686003)(105586002)(106356001)(77096006)(189998001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR02MB2545; H:BN6PR02MB2547.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR02MB25472A241C4FD4BF63BE4C00B1B50BN6PR02MB2547namp_"
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 16:50:49.2862 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR02MB2545
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/WEuJ-WoZ5ibNJYnveXkR1d_yb1Y>
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 16:50:53 -0000

Good Morning,



Thomas, I think the Fee draft can handle your use case of using launch phase for premium names (a premium string is only available in one phase/subphase combination so if client does not pass phase you should return that one valid combination). Can you provide examples where it does not work?





Thanks

Roger





-----Original Message-----
From: regext [mailto:regext-bounces@ietf.org] On Behalf Of Thomas Corte
Sent: Monday, August 07, 2017 10:58 AM
To: Gould, James <jgould@verisign.com>; regext@ietf.org
Cc: support@tango-rs.com
Subject: Re: [regext] TLD Phase Discovery



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<mailto:support@tango-rs.com>

Germany



_______________________________________________

regext mailing list

regext@ietf.org<mailto:regext@ietf.org>

https://www.ietf.org/mailman/listinfo/regext