Re: [regext] TLD Phase Discovery

Jody Kolker <jkolker@godaddy.com> Mon, 07 August 2017 16:29 UTC

Return-Path: <jkolker@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 D17BF132338 for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 09:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 IhtZw6Dnhimn for <regext@ietfa.amsl.com>; Mon, 7 Aug 2017 09:29:26 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0091.outbound.protection.outlook.com [104.47.34.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE1E13259F for <regext@ietf.org>; Mon, 7 Aug 2017 09:29:26 -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=cQNC9UoOk9WMghWemrbvrtZFVb4Kbk4PtDC2d7Ikaho=; b=80gDttQFn2NmieE2LQ7DmL18hC/aqk8GtuzlxrUbuQca9lNtv/XUQtbbF0x0KqOjeW33N4zkRDx4z9Dn0P5dABw7nhJRgdOsqa7kAj4zKZ3iUGEGusyBmgIOpRQ5tCDVHAIUtjhrQPT/qeTMu7caSYisNjn1G+YR7cftnU8kGRk=
Received: from SN1PR0201MB1792.namprd02.prod.outlook.com (10.162.228.24) by SN1PR0201MB1792.namprd02.prod.outlook.com (10.162.228.24) 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:29:25 +0000
Received: from SN1PR0201MB1792.namprd02.prod.outlook.com ([10.162.228.24]) by SN1PR0201MB1792.namprd02.prod.outlook.com ([10.162.228.24]) with mapi id 15.01.1320.018; Mon, 7 Aug 2017 16:29:25 +0000
From: Jody Kolker <jkolker@godaddy.com>
To: Thomas Corte <Thomas.Corte@knipp.de>, "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
CC: "support@tango-rs.com" <support@tango-rs.com>
Thread-Topic: [regext] TLD Phase Discovery
Thread-Index: AQHTDHNVJnkAGVdue0m4+ZVg/2xna6J0DkUAgAA9CACABFkmgIAAY4AAgAAK64CAAAiYkA==
Date: Mon, 07 Aug 2017 16:29:25 +0000
Message-ID: <SN1PR0201MB17922BA92D11CA70F89EFFE2BFB50@SN1PR0201MB1792.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=jkolker@godaddy.com;
x-originating-ip: [64.202.161.57]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1PR0201MB1792; 6:W6J03/KDo6iZH94n2FUtWFQsXAw3QVh9YJxJQPgUD3Gi9N2P+Zrtl75Ew78SYGFUSdA/p1u7It4D7r4k3KqiOcJcXZ8xRDbmeAJJnNr0xwAIad2Imx/2YGn+9O9JwZK9b7fXqQUuybAnVPF+fkDBcrE59TIo+XEXB7UNo89ExbyXpozbJIP/q8XkEkhDT8+JrPa6npSyKCwHCKOegQRFisk3HRsyk0HwnluQZwEFesZCPX+61gVxRzqLNbyWQiPhC11hZ67QLb1hOxNnIjD5kyl0ke5PrPbFeLGRl+tQuo3B1DD1o5UWcOPuOVZ48ikLp5sGz+SCAT8K787P7NZYUw==; 5:6AML/8Uvp8T/XCLWGfr5bJyCg/BWrbBwAcHmT51TpZpTuzovrcbVKi61inZib4SQDIdu2aJ3W3opsWx/oIeySDU979NxZsoJQQR+0tkhRROjcAQul+43MGxcPWngzXAWPQVIIbiuhpqVddgiUYc31w==; 24:TSR8omR0R3746e8ska0BCJKLwN7AHB30QrS8LfEW9o0QeGKBcGy+7v1k/y9V6+qZKPadCx5b+W+6ueyXH/c0pldsFYC33MC1Od0Q/+/ASNk=; 7:mIato40jBjAfhdjG8Sw+B1m9xDy+TTYQl+dYFAAOfr80Q7Kbj0z/31YUshWIR4UEWxYnXnhyfIKQ088SAe8T+2yocsbs1pKcF7DCaCOque7nv+KxcD16yDgqrAkJ8vKR4B2amH0kpLcFYW1q2GcgLIIjJ+IuzxJZ+21A0aTxZ5aHWcLBYdKo7p6l7ZnVdgJYJ0MrozzOENWWhy9k3kaA23gCXAvmoMezaXfb5NcCp7o=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: cf5c3168-bf4e-4209-8066-08d4ddb177a8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:SN1PR0201MB1792;
x-ms-traffictypediagnostic: SN1PR0201MB1792:
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-microsoft-antispam-prvs: <SN1PR0201MB17927D9C37F9979EE1D7F43FBFB50@SN1PR0201MB1792.namprd02.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR0201MB1792; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR0201MB1792;
x-forefront-prvs: 0392679D18
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39860400002)(39850400002)(39410400002)(39840400002)(252514010)(199003)(24454002)(13464003)(377454003)(189002)(6306002)(9686003)(5660300001)(7696004)(81156014)(81166006)(8676002)(2501003)(305945005)(38730400002)(50986999)(76176999)(54356999)(6246003)(101416001)(8936002)(99286003)(25786009)(33656002)(66066001)(2900100001)(53936002)(102836003)(3846002)(6116002)(3280700002)(93886004)(3660700001)(6436002)(106356001)(55016002)(105586002)(7736002)(4326008)(68736007)(6506006)(478600001)(2906002)(189998001)(229853002)(74316002)(77096006)(97736004)(966005)(2950100002)(53546010)(14454004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0201MB1792; H:SN1PR0201MB1792.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: godaddy.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 16:29:25.1513 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0201MB1792
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/_rUV9fv7Y1f3LObz406FEg-OtbQ>
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:29:33 -0000

Sorry for the spread out questions.

Thomas - In your implementation, is the premium phase specified in the "phase" attribute or in the "subphase" attribute?

Thanks,
Jody Kolker



-----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
Germany

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext