Re: [eppext] Working Group Last call for draft-ietf-eppext-launchphase

"Gould, James" <> Thu, 05 November 2015 14:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8FD531B2D41 for <>; Thu, 5 Nov 2015 06:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xyu8iyY5DdP3 for <>; Thu, 5 Nov 2015 06:15:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41E8B1B2D3C for <>; Thu, 5 Nov 2015 06:15:37 -0800 (PST)
Received: by oiww189 with SMTP id w189so1090138oiw.2 for <>; Thu, 05 Nov 2015 06:15:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=bstWRM9xkDehKRfBSRzAxUfcO4n95IeWhEuIKvt1yZU=; b=WDsBTC/waj7fsfKa25E27bcVHL9HOlrqpVchRd5jAQfGJMEIKi2oZVwQ32zzxAPD7U bpfR+jbrXlasDHxjGz1cf+eHbg1KMSkg7tuSUVWyoQmnhTEeBuzsGUCDEPTHZkYm8+l3 0J2RBdf9mehQhWbKnq5dRz8VEQSFUNWuJL7cYjirOQ2eYuRsLuSnjWkIEIvCZeS0DzZA 0K+887ciMnRxNoDhv58Cambo/91H+L4RcOx2FGje7fp5anwU4oWYWuPC15AqnvjiYeUA V0IqsFw4TCDYEG7BBdD7VXBCOUOyHCrBMR/WH0vDK1FnD+Ly6E+X4Zn1Gg3cIQ4w6AGP +JDw==
X-Gm-Message-State: ALoCoQlFiAWjkdtx00xhe9v6ZLaaTdYiT86JSfLXe9+Qvgxg+x4TLh+6b7gVoT1MoAlxhe5D2VtMq4SABXCZBoz6zIC0mGE4+A==
X-Received: by with SMTP id g107mr7572571qge.57.1446732935979; Thu, 05 Nov 2015 06:15:35 -0800 (PST)
Received: from ( []) by with ESMTPS id v12sm753259qka.13.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 06:15:35 -0800 (PST)
Received: from (brn1wnexcas02 []) by (8.13.8/8.13.8) with ESMTP id tA5EFZR5021973 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2015 09:15:35 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Thu, 5 Nov 2015 09:15:35 -0500
From: "Gould, James" <>
To: Rik Ribbers <>
Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-launchphase
Thread-Index: AQHRFzw+gcZCc6Iynkacb92U56WUiJ6Nv5KAgAAEaoCAAAo7AA==
Date: Thu, 05 Nov 2015 14:15:35 +0000
Message-ID: <>
References: <> <C80127C588F8F2409E2B535AF968B768BA20273B@kambx1.SIDN.local> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_6C2ADE70802344E38AF482ECBA3884A3verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-launchphase
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2015 14:15:41 -0000

That sounds like a reasonable plan.





James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Nov 5, 2015, at 8:38 AM, Rik Ribbers <<>> wrote:


Thx for digging this up. This is not a big deal for me but I think this could be clarified in the draft. It might help those people who pick up the document right now and start implementing it.

My proposal is: Let the document move on and if for another reason a new version is needed consider adding the few words for clarification.


On 05 Nov 2015, at 22:23, Gould, James <<>> wrote:


For some reason I didn’t see Rik’s latest posting ( ).

I replied to the original launchphase + domain check thread with the following ( ):

We also support the standard check form for all launch phases.  The launchphase draft extends the domain mapping to define new forms of checks targeted for the launch phases, but there is no intent to disallow the use of the standard availability check defined in the domain mapping.

Considering that this is an extension, it is additive to what it extends.  There is nothing in the draft that is meant to change the behavior of the vanilla availability check as defined in RFC 5731.  I don’t see the need to add clarifying text on what happens when the extension is not used, since the extension only defines what happens when the extension is used.  If the WG agrees that the proposed clarifying text is necessary it can be added.

Feedback is welcome.





James Gould
Distinguished Engineer<x-msg://4/>

12061 Bluemont Way
Reston, VA 20190<>

On Nov 4, 2015, at 3:06 PM, James Galvin <<>> wrote:

This issue raised by Rik Ribbers has not been addressed by the working group.  Would the authors, and any one from the working group please comment?  Rik's suggestion seems reasonable to me but I would like to see confirmation from the authors.

With this suggestion address this document is ready to move forward. However, it is dependent on draft-ietf-eppext-tmch-func-spec/, so I'd like to hold it in the working group and submit these two documents together.

In addition to the change suggested above, we need a document shepherd to move this forward.  Would anyone like to volunteer?


On 7/21/15 10:28 AM, Rik Ribbers wrote:

I finished the review. There is one issue that I raised earlier that (imho) needs some more clarification in the document.


We have interpreted section 2.3 different then the other implementers with respect to the normal or vanilla (as Alexander suggested) domain check.

Having fully re-read the draft I am not sure if this issue should be addressed here or in the lozano functional specification
( However the last is expired and not getting any attention. In this draft there are several requirements concerning Domain Registration, there are no requirements concerning Domain Availability. So if nothing is specified the vanilla domain check can be used.

However section 2.3 suggest one MUST provide a launchphase...... so what to do....

My suggestion is to add a few wording (slightly different then my previous proposal):

** old **
The <launch:phase> element MUST be included by the client to define the target launch phase of the command.

** new **
The <launch:phase> element MUST be included by the client to define the target launch phase of the command when using this EPP extension.


-----Original Message-----
From: EppExt [] On Behalf Of Antoin Verschuren
Sent: maandag 20 juli 2015 22:02
Subject: [eppext] Working Group Last call for draft-ietf-eppext-launchphase


This is the starting of the WGLC on the Launch Phase Mapping for the Extensible Provisioning Protocol (EPP).
There was extensive discussion on the mailing list, an we believe the outcome is incorporated in the document and is ready for WGLC.
The current version of this document can be found here:

We'll have a 1,5 week period for comments, closing on Friday, 31 July 2015.

During last call the chairs are looking for a document shepherd for this document.
If you're interested, please contact the chairs. The document authors can not be the shepherd.


- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

EppExt mailing list<>

EppExt mailing list<>