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

Rik Ribbers <rik.ribbers@sidn.nl> Thu, 05 November 2015 13:39 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 7257C1B2C28 for <eppext@ietfa.amsl.com>; Thu, 5 Nov 2015 05:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.085
X-Spam-Level:
X-Spam-Status: No, score=0.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 yF4UJ2qH8CVG for <eppext@ietfa.amsl.com>; Thu, 5 Nov 2015 05:38:58 -0800 (PST)
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 482961B2C26 for <eppext@ietf.org>; Thu, 5 Nov 2015 05:38:57 -0800 (PST)
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-mailer:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=b9Jddj5PH9kdStogm9J0xpw+JbuJekwlKwPdVwnaj3s=; b=ya3mSaS+4MwOStwNrubsDyPtulLZ8zttmdauN2AWQGmpyHKgFoie3qp8RpiL9kyKN5s9KXew66yqD9HwEhZY/wAOvDInlHxYtwqTHRLKspp99FKXFESH7pIbb1TKF819/n7kS3vmF0lKJaETgVNmsk89tY6VSHQmncujMipK65igjctHLrc7I6ogaZ6083e+u457Hl5xFOWeQFuQbGfDNS6z/OQfYvuxWWH7PKNJ/vp3RhdquJ+kCk1yQzNlfNLQe8CEf4BjqgAT9g3imyFv8VEknqXZpum+hcJmGHYl7nAmnUdpXL9ye9uYAgeHGrhMRNTl3QKk4rauWhb+9O5QpQ==
Received: from ka-mbx03.SIDN.local ([192.168.2.179]) by arn2-kamx.sidn.nl with ESMTP id tA5Dctkg014021-tA5Dctki014021 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 5 Nov 2015 14:38:55 +0100
Received: from ka-mbx02.SIDN.local (192.168.2.178) by ka-mbx03.SIDN.local (192.168.2.179) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 5 Nov 2015 14:39:05 +0100
Received: from ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549]) by ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549%13]) with mapi id 15.00.1076.000; Thu, 5 Nov 2015 14:38:57 +0100
From: Rik Ribbers <rik.ribbers@sidn.nl>
To: "Gould, James" <JGould@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] Working Group Last call for draft-ietf-eppext-launchphase
Thread-Index: AQHRF80jHe9kVV2nNEO/iV2d8gUN9J6NXj6A
Date: Thu, 05 Nov 2015 13:38:57 +0000
Message-ID: <F3E180F1-4DCA-4449-9629-CAEAA44C38B7@sidn.nl>
References: <B785119F-67E7-4B34-9995-6A6F5806DF10@antoin.nl> <C80127C588F8F2409E2B535AF968B768BA20273B@kambx1.SIDN.local> <563A6547.40308@elistx.com> <3C657106-B3AB-40E3-B145-47B1208A481D@verisign.com>
In-Reply-To: <3C657106-B3AB-40E3-B145-47B1208A481D@verisign.com>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3096.5)
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.4.205]
Content-Type: multipart/signed; boundary="Apple-Mail=_497147C1-22BD-45EF-9CF7-29D8A7F279EB"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/DzvwO3pRqKAERVTRfTQTJrDpiNw>
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 13:39:01 -0000

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> wrote:
> 
> Hi,
> 
> For some reason I didn’t see Rik’s latest posting ( http://mailarchive.ietf.org/arch/msg/eppext/UvQWpcfS3aDkO3ccksT9X0N6EbI <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 <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 <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/ <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 <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 <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 <xmpp:antoinverschuren@gmail.com>
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> EppExt mailing list
>>> 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
>