Re: [eppext] launchphase + domain check

Michael Holloway <michael.holloway@comlaude.com> Tue, 14 July 2015 08:11 UTC

Return-Path: <michael.holloway@comlaude.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D951A9055 for <eppext@ietfa.amsl.com>; Tue, 14 Jul 2015 01:11:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 VbjDktdfbFHK for <eppext@ietfa.amsl.com>; Tue, 14 Jul 2015 01:11:42 -0700 (PDT)
Received: from smtp107.iad3a.emailsrvr.com (smtp107.iad3a.emailsrvr.com [173.203.187.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA101A9053 for <eppext@ietf.org>; Tue, 14 Jul 2015 01:11:42 -0700 (PDT)
Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 44E722801F0 for <eppext@ietf.org>; Tue, 14 Jul 2015 04:11:41 -0400 (EDT)
X-SMTPDoctor-Processed: csmtpprox beta
Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 411732801F4 for <eppext@ietf.org>; Tue, 14 Jul 2015 04:11:41 -0400 (EDT)
Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id AE0C42801F0 for <eppext@ietf.org>; Tue, 14 Jul 2015 04:11:40 -0400 (EDT)
X-Sender-Id: m4bh@comlaude.com
Received: from [192.168.1.10] (p4FE4F686.dip0.t-ipconnect.de [79.228.246.134]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 14 Jul 2015 08:11:41 GMT
Message-ID: <55A4C43B.7030907@comlaude.com>
Date: Tue, 14 Jul 2015 10:11:39 +0200
From: Michael Holloway <michael.holloway@comlaude.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: eppext@ietf.org
References: <C80127C588F8F2409E2B535AF968B768BA1E963F@kambx2.SIDN.local> <19F54F2956911544A32543B8A9BDE07546868665@NICS-EXCH2.sbg.nic.at> <C80127C588F8F2409E2B535AF968B768BA1E9F52@kambx2.SIDN.local>
In-Reply-To: <C80127C588F8F2409E2B535AF968B768BA1E9F52@kambx2.SIDN.local>
Content-Type: multipart/alternative; boundary="------------030005060706030304020509"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/v0BL72v5wo7NJJ0Th22SqVsNSVg>
Subject: Re: [eppext] launchphase + domain check
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 08:11:45 -0000

Yes, most registries have implemented it this way (but from memory one 
or two do require the extension during claims), so I agree with the 
wording change.

Additionally, I think the correct action when the extension is omitted 
at any stage would be for the server to always return the availability 
check form (default for launchphase extension) in the currently active 
phase unless there are multiple active phases - in which case it should 
return an error only if the availability of the domain depends on the 
phase (which is rare, but could be some sort of limited release). In 
other words, only complicate the issue if need be. Not sure if / how 
that can be worded.

Cheers,
Michael


On 07/14/2015 09:48 AM, Rik Ribbers wrote:
>
> Alexander,
>
> Thanks for your reply. I suggest to add an extra explanation to the 
> draft as all of the implementers I know of have this behavior.
>
> Something like this:
>
> The <launch:phase> element MUST be included by the client to define 
> the target launch phase of the command when using one the special 
> check forms as defined in Section 3.1 of this I-D.
>
> Kind regards,
>
> Rik
>
> *From:*Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at]
> *Sent:* dinsdag 14 juli 2015 8:57
> *To:* Rik Ribbers; eppext@ietf.org
> *Subject:* AW: [eppext] launchphase + domain check
>
> Hello Rik,
>
> We understand that the element MUST only be included by the client 
> when one of the „special“ check forms is used. Therefore, we do allow 
> „vanilla“ EPP domain checks for the whole runtime of the registry, 
> including all “launch phases”.
>
> This also seems what registrars are expecting even during the Claims 
> period, because they usually perform a “normal” check before they 
> attempt a create, and only when that fails, they re-query with the 
> Claims check form..
>
> Alex
>
> *Von:*EppExt [mailto:eppext-bounces@ietf.org] *Im Auftrag von *Rik Ribbers
> *Gesendet:* Montag, 13. Juli 2015 17:26
> *An:* eppext@ietf.org <mailto:eppext@ietf.org>
> *Betreff:* [eppext] launchphase + domain check
>
> All,
>
> I've had a very interesting discussion regarding the launchphase 
> draft. The discussion focusses around the domain check and the TMCH 
> claims period. Section 2.3 of the I-D states that:
>
> ** quote on **
>
> The server MAY support multiple launch phases sequentially or 
> simultaneously.  The <launch:phase> element MUST be included by the 
> client to define the target launch phase of the command.
>
> ** quote off **
>
> So when doing a domain check during a TMCH claims period the domain 
> check in the "Claims check form", "Availability Check Form" and 
> "Trademark Check Form" must contain the <launch:phase> element 
> describing the active phase.
>
> So far so good. But what about the "normal operation" domain check. 
> This is the standard epp domain check (without the launchphase 
> extension). The draft does not explicitly say anything about it, but 
> according to Section 2.3 one could argue that this is not allowed 
> during a TMCH claims period as there is no <launch:phase> element 
> provided.
>
> I would love to here from other WG-members what they think about this...
>
> Kind regards,
>
> Rik Ribbers
>
>
>
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext