Re: [eppext] launchphase + domain check

Rik Ribbers <rik.ribbers@sidn.nl> Tue, 14 July 2015 07:48 UTC

Return-Path: <rik.ribbers@sidn.nl>
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 BA6401A901E for <eppext@ietfa.amsl.com>; Tue, 14 Jul 2015 00:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.295
X-Spam-Level:
X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 ET_YxMB9aNsY for <eppext@ietfa.amsl.com>; Tue, 14 Jul 2015 00:48:43 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF5ED1A900A for <eppext@ietf.org>; Tue, 14 Jul 2015 00:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=g65gfXSQmCIHKS1UI4KCn1Ato6+aYXogt8mUUwhH1FA=; b=QIQa++FZpUpFiW/T5GY9SpdObnLw/LkDi1PdiTkz9jHWwpmSDhwO3x2gLkgIWYItdMhtS6yJbefkQrke9aknqjs4Hu+yWRdD7zSNyGRj7bLU/3v5ic6fISzDwhZE3hlXI0EPAlevX7Lgy8tB/EMfWPYZ8RL7oNpAtU+5d+P8phBJszeF9sAsEM9rNZLLaa233LPXtOYpmVpIj2h/9CPyZn2e7zask05bWh3Roq7eq145fZJ50sN3Uk7nIp8LMUV5Fizcm0Ms5E9gweM/AuSsaSvzxrxlcS31gzfgnkKQ/S6gv+iT/9KD5aXWzxgHPpPvZCs0+uo6EsugQXTOLyM93w==
Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id t6E7mexL029613-t6E7mexN029613 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 14 Jul 2015 09:48:41 +0200
Received: from KAHUBCASN02.SIDN.local (192.168.2.76) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 14 Jul 2015 09:48:45 +0200
Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0224.002; Tue, 14 Jul 2015 09:48:43 +0200
From: Rik Ribbers <rik.ribbers@sidn.nl>
To: 'Alexander Mayrhofer' <alexander.mayrhofer@nic.at>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] launchphase + domain check
Thread-Index: AQHQvgJJopja7uFNLEuqmFraRI+d5Z3ajk8g
Date: Tue, 14 Jul 2015 07:48:42 +0000
Message-ID: <C80127C588F8F2409E2B535AF968B768BA1E9F52@kambx2.SIDN.local>
References: <C80127C588F8F2409E2B535AF968B768BA1E963F@kambx2.SIDN.local> <19F54F2956911544A32543B8A9BDE07546868665@NICS-EXCH2.sbg.nic.at>
In-Reply-To: <19F54F2956911544A32543B8A9BDE07546868665@NICS-EXCH2.sbg.nic.at>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.171]
Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768BA1E9F52kambx2SIDNlocal_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/iO9XTQW7-7aSUAuTIsxMDSv06UI>
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 07:48:45 -0000

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