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

"Gould, James" <JGould@verisign.com> Thu, 05 November 2015 14:15 UTC

Return-Path: <JGould@verisign.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 8FD531B2D41 for <eppext@ietfa.amsl.com>; Thu, 5 Nov 2015 06:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xyu8iyY5DdP3 for <eppext@ietfa.amsl.com>; Thu, 5 Nov 2015 06:15:37 -0800 (PST)
Received: from mail-oi0-f100.google.com (mail-oi0-f100.google.com [209.85.218.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E8B1B2D3C for <eppext@ietf.org>; Thu, 5 Nov 2015 06:15:37 -0800 (PST)
Received: by oiww189 with SMTP id w189so1090138oiw.2 for <eppext@ietf.org>; Thu, 05 Nov 2015 06:15:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.140.94.244 with SMTP id g107mr7572571qge.57.1446732935979; Thu, 05 Nov 2015 06:15:35 -0800 (PST)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id v12sm753259qka.13.2015.11.05.06.15.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Nov 2015 06:15:35 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (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 BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 5 Nov 2015 09:15:35 -0500
From: "Gould, James" <JGould@verisign.com>
To: Rik Ribbers <rik.ribbers@sidn.nl>
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: <6C2ADE70-8023-44E3-8AF4-82ECBA3884A3@verisign.com>
References: <B785119F-67E7-4B34-9995-6A6F5806DF10@antoin.nl> <C80127C588F8F2409E2B535AF968B768BA20273B@kambx1.SIDN.local> <563A6547.40308@elistx.com> <3C657106-B3AB-40E3-B145-47B1208A481D@verisign.com> <F3E180F1-4DCA-4449-9629-CAEAA44C38B7@sidn.nl>
In-Reply-To: <F3E180F1-4DCA-4449-9629-CAEAA44C38B7@sidn.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_6C2ADE70802344E38AF482ECBA3884A3verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ljwQhD1qjWA7Hb3qZD3tNiyxBNw>
Cc: "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] Working Group Last call for draft-ietf-eppext-launchphase
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: Thu, 05 Nov 2015 14:15:41 -0000

That sounds like a reasonable plan.

Thanks,


—


JG


[cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com]

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Nov 5, 2015, at 8:38 AM, Rik Ribbers <rik.ribbers@sidn.nl<mailto:rik.ribbers@sidn.nl>> wrote:

Jim,

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.

Gr,
Rik

On 05 Nov 2015, at 22:23, Gould, James <JGould@verisign.com<mailto:JGould@verisign.com>> wrote:

Hi,

For some reason I didn’t see Rik’s latest posting ( http://mailarchive.ietf.org/arch/msg/eppext/UvQWpcfS3aDkO3ccksT9X0N6EbI ).

I replied to the original launchphase + domain check thread with the following ( http://mailarchive.ietf.org/arch/msg/eppext/uFAkm8HsumOmN6SOMOFNSJg3s5o ):

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.

Thanks,

—

JG


<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
jgould@Verisign.com<x-msg://4/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Nov 4, 2015, at 3:06 PM, James Galvin <galvin@elistx.com<mailto:galvin@elistx.com>> 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?

Jim






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

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

See http://www.ietf.org/mail-archive/web/eppext/current/msg00585.html

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
(https://datatracker.ietf.org/doc/draft-lozano-tmch-func-spec/). 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.

Gr,
Rik


-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Antoin Verschuren
Sent: maandag 20 juli 2015 22:02
To: eppext@ietf.org<mailto:eppext@ietf.org>
Subject: [eppext] Working Group Last call for draft-ietf-eppext-launchphase

Greetings,

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:

  https://www.ietf.org/id/draft-ietf-eppext-launchphase-05.txt

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.

thanks,

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:antoinverschuren@gmail.com




_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org<mailto:EppExt@ietf.org>
https://www.ietf.org/mailman/listinfo/eppext