From nobody Thu Jan 1 15:13:04 2015 Return-Path: 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 19D9D1A1B0C for ; Thu, 1 Jan 2015 15:13:03 -0800 (PST) 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] 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 Jpexym8mdc0l; Thu, 1 Jan 2015 15:13:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 063041A802A; Thu, 1 Jan 2015 15:13:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150101231300.23069.76137.idtracker@ietfa.amsl.com> Date: Thu, 01 Jan 2015 15:13:00 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/ZCe0DNKMHWsyFL_UjjyC1IM1H4w Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 23:13:03 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Thu Jan 1 15:13:07 2015 Return-Path: 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 4D7571A1AF1; Thu, 1 Jan 2015 15:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 YwFzUqJ2FhGm; Thu, 1 Jan 2015 15:13:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DD81A802F; Thu, 1 Jan 2015 15:13:00 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150101231300.23069.39137.idtracker@ietfa.amsl.com> Date: Thu, 01 Jan 2015 15:13:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/R2JWzZtoBJSzoiwfLQEZufCCS4s Cc: eppext chair , eppext mailing list , RFC Editor Subject: [eppext] Document Action: 'Extension Registry for the Extensible Provisioning Protocol' to Informational RFC (draft-ietf-eppext-reg-10.txt) X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 23:13:06 -0000 The IESG has approved the following document: - 'Extension Registry for the Extensible Provisioning Protocol' (draft-ietf-eppext-reg-10.txt) as Informational RFC This document is the product of the Extensible Provisioning Protocol Extensions Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ Technical Summary The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP and it specifies a format for an IANA registry to record those extensions. Working Group Summary One issue that was discussed at length by the working group is whether or not "Specification Required" was a sufficient IANA policy for this registry. Of concern was the question of whether or not extensions to EPP should be reviewed for the purpose of harmonizing extensions that may be similar. After considerable debate it was the consensus of the working group that there was unlikely to be sufficient motivation in the industry to harmonize extensions as compared to publishing a specification describing the extension. The WG put forward this document as Standards Track. However, there is no strong feeling in the WG that this is required, so it is left to the discretion of the IESG to decide whether Informational is more appropriate. Document Quality The Document Shepherd did a thorough editorial and technical review of the document, and resolved any issues brought up during WGLC. A subsequent AD Review resulted in additional clarifications. The Document Shepherd does not have any concerns about the depth or breath of the reviews. Personnel Jim Galvin (co-chair of the working group) is the Document Shepherd. Pete Resnick is the responsible Area Director. RFC Editor Note A simple change to address Brian's comment: OLD A reference to the specification of this extension NEW A publicly available reference to the specification of this extension From nobody Fri Jan 2 10:56:50 2015 Return-Path: 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 C18EC1A0049 for ; Fri, 2 Jan 2015 10:56:49 -0800 (PST) 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] 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 kJsMfqlI0h3K; Fri, 2 Jan 2015 10:56:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC49B1A1C03; Fri, 2 Jan 2015 10:56:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150102185647.4472.49275.idtracker@ietfa.amsl.com> Date: Fri, 02 Jan 2015 10:56:47 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/4fSF0emLF5MGoXiNjsQP9TT2bpk Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2015 18:56:50 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Mon Jan 5 00:06:49 2015 Return-Path: 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 993001A1F20 for ; Mon, 5 Jan 2015 00:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 7bZ-iHB_cg7S; Mon, 5 Jan 2015 00:06:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA531A1BF9; Mon, 5 Jan 2015 00:06:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105080639.23357.38409.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 00:06:39 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/zSvFsWNLb4cBlX6p2F8srxlfPzE Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 08:06:45 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Mon Jan 5 13:58:39 2015 Return-Path: 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 050EE1A8F33; Mon, 5 Jan 2015 13:58:36 -0800 (PST) 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] 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 ydY03moH3oix; Mon, 5 Jan 2015 13:58:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B041A8BBD; Mon, 5 Jan 2015 13:58:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105215834.10539.85478.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 13:58:34 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/ykCmSTipobYCBE2TlsDxXuB_iF0 Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-idnmap-02.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:58:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP) Authors : Francisco Obispo Luis Enrique Munoz Filename : draft-ietf-eppext-idnmap-02.txt Pages : 10 Date : 2015-01-05 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional features required to implement registrations of domain names in characters sets other than ASCII. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-idnmap/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-idnmap-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-idnmap-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 15:06:15 2015 Return-Path: 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 01C2F1A01A5 for ; Mon, 5 Jan 2015 15:06:00 -0800 (PST) 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] 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 5gpdxjhP67r5; Mon, 5 Jan 2015 15:05:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 878121A9074; Mon, 5 Jan 2015 15:05:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105230556.14546.2456.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 15:05:56 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/PGNgU7WOI0gz8W7mVzgpKOIAjAg Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 23:06:00 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Mon Jan 5 15:18:33 2015 Return-Path: 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 3BDE11A0204 for ; Mon, 5 Jan 2015 15:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 r2eZR9bJxYwG for ; Mon, 5 Jan 2015 15:18:24 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6606A1A0181 for ; Mon, 5 Jan 2015 15:18:23 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKVKsbvmRG7l3ysj+ex92Up8ZwZnFPQR1I@postini.com; Mon, 05 Jan 2015 15:18:23 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t05NILrk025077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Jan 2015 18:18:22 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 5 Jan 2015 18:18:21 -0500 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQKT3krDH7sE6wI0yQ8a5hZx2LtA== Date: Mon, 5 Jan 2015 23:18:20 +0000 Message-ID: <6B3201F3-4F0B-4689-BF14-5E545EB1DE9D@verisign.com> 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_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/d4Vt2YQ14fHhThj6ZzOcMzEwtnI Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Mon, 05 Jan 2015 23:18:30 -0000 --_004_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_ Content-Type: multipart/alternative; boundary="_000_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_" --_000_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, =93...releases for Allocation or registration such reserved domain name= at any time following the start date of the Claims Period, such domain MUS= T be subject to the Claims Services (as described in Section 3) for a perio= d of ninety (90) calendar days following the date Registry Operator release= s such domain name for registration=85=94. This means that support for the= Claims Check Form needs to be revised to indicate whether or not the Claim= s Create Form is needed for the domain name and the use of the Claims Creat= e Form should be supported in phases other than =93claims=94. There are no= XML schema changes required to support this. Please review and provide fe= edback to the proposed revised language in the draft below to include in th= e next version of the draft that will also include the Implementation Statu= s section discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thanks, =97 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 =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <09A6CD2FBA996849B13DC0EE277B8C42@verisign.com> Content-Transfer-Encoding: quoted-printable All,

There was an issue raised privately in supporting claims as a Claims S= ervice post the Claims Phase.   According to section 2.4.3 of the RPM = Requirements, =93...releases for Allocation or registration such reserved d= omain name at any time following the start date of the Claims Period, such domain MUST be subject to the Claims Servi= ces (as described in Section 3) for a period of ninety (90) calendar days f= ollowing the date Registry Operator releases such domain name for registrat= ion=85=94.  This means that support for the Claims Check Form needs to be revised to indicate whether or not t= he Claims Create Form is needed for the domain name and the use of the Clai= ms Create Form should be supported in phases other than =93claims=94.  = ;There are no XML schema changes required to support this.  Please review and provide feedback to the proposed = revised language in the draft below to include in the next version of the d= raft that will also include the Implementation Status section discussed at = the IETF-91 EPPEXT meeting. 

Change 3.1.1 "Cla= ims Check Form" as follows:

   =
The Claims Check Form defines a new command called the Claims Check
   Command that is used to determine whether or not there are any
   matching trademarks, in the specified launch phase, for each domain
   name passed in the command, that requires the use of the "Claims=
 Create Form" 
=
   on a Domain Create Command.

   =
Instead of returning whether the domain name is available, the Claims
   Check Command will return whether or not at least one matching
   trademark exists for the domain name, that requires the use of the&nb=
sp;
=
   "Claims Create Form" on a Domain Create Command.  

   =
<launch:name>  Contains the fully qualified name of the queried
           domain name.  This element MUST contain an "exists" at=
tribute
           whose value indicates if a matching trademark exists for the
           domain name that requires the use of the "Claims Create =
Form" on a Domain Create Command.  
   =
        A value of "1" (or "true") means that a
           matching trademark does exist and that the "Claims Creat=
e Form" is required on 
   =
        a Domain Create Command.  A
           value of "0" (or "false") means that a match=
ing trademark
           does not exist or that the "Claims Create Form" is =
NOT required on a Domain Create Command.


Change 3.3.2 "Cla= ims Create Form" as follows:

<=
;launch:phase>  SHOULD contain the value of "claims" to=
 indicate the
       claims launch phase.  A value other than "claims" MAY b=
e used to 
=
pass the claims notice for domain names outside of the claims phase.  <=
/pre>

Based on the above revised language the following may be done:

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 


Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_-- --_004_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Mon, 05 Jan 2015 23:18:20 GMT"; modification-date="Mon, 05 Jan 2015 23:18:20 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_6B3201F34F0B4689BF145E545EB1DE9Dverisigncom_-- From nobody Tue Jan 6 12:06:33 2015 Return-Path: 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 F1C621A1B7B for ; Tue, 6 Jan 2015 12:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 qkKwmRxJMIIq; Tue, 6 Jan 2015 12:06:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E61A1B6B; Tue, 6 Jan 2015 12:06:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106200629.23622.23213.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 12:06:29 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/V5gH0pXv7du0rfag4o781SV1OJY Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:06:31 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Tue Jan 6 14:05:51 2015 Return-Path: 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 52B511A8747 for ; Tue, 6 Jan 2015 14:05:49 -0800 (PST) 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] 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 BIBqtXmfex4j; Tue, 6 Jan 2015 14:05:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEB41A872B; Tue, 6 Jan 2015 14:05:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150106220547.6511.83692.idtracker@ietfa.amsl.com> Date: Tue, 06 Jan 2015 14:05:47 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/jlptGf5Mt3rtf8PY1ZvfIyWyQNA Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 22:05:49 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Wed Jan 7 11:06:13 2015 Return-Path: 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 8FA581A03A1 for ; Wed, 7 Jan 2015 11:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 rtAAkDv1lJoL; Wed, 7 Jan 2015 11:06:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C62B1A0338; Wed, 7 Jan 2015 11:06:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: eppext-chairs@tools.ietf.org, draft-ietf-eppext-reg@tools.ietf.org, eppext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107190604.10890.78130.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 11:06:04 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/9qbxDKRIpQ8NaXcreDJynB62A14 Subject: [eppext] ID Tracker State Update Notice: X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 19:06:06 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-eppext-reg/ From nobody Thu Jan 8 05:28:42 2015 Return-Path: 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 80D191A3BA1; Thu, 8 Jan 2015 05:28:39 -0800 (PST) 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] 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 M1Y-by_qyo99; Thu, 8 Jan 2015 05:28:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C538C1A00C6; Thu, 8 Jan 2015 05:28:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150108132837.481.7158.idtracker@ietfa.amsl.com> Date: Thu, 08 Jan 2015 05:28:37 -0800 Archived-At: Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-keyrelay-01.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 13:28:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Relay Extension for the Extensible Provisioning Protocol Authors : Marc Groeneweg Antoin Verschuren Filename : draft-ietf-eppext-keyrelay-01.txt Pages : 15 Date : 2015-01-08 Abstract: This document describes a generic Extensible Provisioning Protocol (EPP) extension for the purpose of relaying data between registrars. Furthermore, this document describes a specific implementation for relaying DNSSEC key material between DNS operators (by means of their respective registrars), to facilitate the change of DNS operator, while keeping the DNSSEC chain of trust intact. This I-D introduces a new generic command and an element . For the specific implementation of relaying DNSSEC key material it introduces an extension of the with a element. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-keyrelay-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-keyrelay-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 8 05:41:51 2015 Return-Path: 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 95C301A3BA7 for ; Thu, 8 Jan 2015 05:41:49 -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 xxL6daYZbrB0 for ; Thu, 8 Jan 2015 05:41:47 -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 70ABB1A1B63 for ; Thu, 8 Jan 2015 05:41:47 -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:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=60A+M6VaeS5hgrLuugQ7mh8+PI9r4wiMkd4jwj5Ubn0=; b=RhYRt2D3buL6mEL3C1YtRYzG+pQQ1dUbJ+/luTnw8bQGaq4EjPfWWkc1ZAjXph8UZ3vtVVeTMapXRmSuzk0aqksG9r/1HqtFBlf2nJLhw6oiYO6SWCHHUvyEmwDUmf3gROjcaQUVgaduLVGkm6sJzxNaHOEHK1xbAPqkRXGbcgQ= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t08DfjYf031352-t08DfjYi031352 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 8 Jan 2015 14:41:45 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Thu, 8 Jan 2015 14:41:41 +0100 From: Rik Ribbers To: "eppext@ietf.org" Thread-Topic: New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMw== Date: Thu, 8 Jan 2015 13:41:41 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.156] Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B927CDA8kambx2SIDNlocal_" MIME-Version: 1.0 Archived-At: Subject: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 13:41:50 -0000 --_000_C80127C588F8F2409E2B535AF968B768B927CDA8kambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers --_000_C80127C588F8F2409E2B535AF968B768B927CDA8kambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

As you (may) have noticed we su= bmitted a new version of the keyrelay draft. In this draft we tried to solv= e all the open issues, remarks and feedback we received.<= /p>

 

The major  changes are:

 

  1.  Introducing the= <relay> command, and thus seperating the data and<= /p>

     &= nbsp; the command.

 

   2.  Updated t= he Introduction, describing the general use of relay vs

     &= nbsp; the intended use-case of relaying DNSSEC key data.<= /p>

 

   3.  Restructu= ring the document to make it more inline with existing

     &= nbsp; EPP extensions.

 

In the end it has become a majo= r rewrite and as always feedback is welcome.

 

Kind regards,=

Rik Ribbers

--_000_C80127C588F8F2409E2B535AF968B768B927CDA8kambx2SIDNlocal_-- From nobody Thu Jan 8 08:16:17 2015 Return-Path: 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 168881A87DB for ; Thu, 8 Jan 2015 08:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DcKPUBsTM0zY for ; Thu, 8 Jan 2015 08:16:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFA81A7D83 for ; Thu, 8 Jan 2015 08:16:04 -0800 (PST) Received: from BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) by BLUPR02MB033.namprd02.prod.outlook.com (10.242.191.13) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 16:15:39 +0000 Received: from BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) by BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) with mapi id 15.01.0049.002; Thu, 8 Jan 2015 16:15:39 +0000 From: Jody Kolker To: "Gould, James" , "eppext@ietf.org" Thread-Topic: draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQKT3krDH7sE6wI0yQ8a5hZx2LtJy2aJsA Date: Thu, 8 Jan 2015 16:15:38 +0000 Message-ID: References: <6B3201F3-4F0B-4689-BF14-5E545EB1DE9D@verisign.com> In-Reply-To: <6B3201F3-4F0B-4689-BF14-5E545EB1DE9D@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.202.160.76] authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkolker@godaddy.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR02MB033; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB033; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(85714005)(164054003)(40134004)(38284003)(68736005)(101416001)(551944002)(15975445007)(102836002)(19625215002)(66066001)(86362001)(54206007)(62966003)(77156002)(16601075003)(92566001)(2950100001)(20776003)(17760045003)(16236675004)(19300405004)(74316001)(18206015028)(64706001)(21056001)(230783001)(4396001)(106356001)(40100003)(122556002)(33656002)(87936001)(99396003)(99936001)(50986999)(54606007)(76176999)(31966008)(54356999)(19580395003)(120916001)(19580405001)(2900100001)(2501002)(76576001)(46102003)(19627595001)(19617315012)(19609705001)(99286002)(105586002)(107886001)(97736003)(2656002)(107046002)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB033; H:BLUPR02MB034.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts) Content-Type: multipart/related; boundary="_004_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 16:15:38.8073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB033 Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 16:16:16 -0000 --_004_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_ Content-Type: multipart/alternative; boundary="_000_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_" --_000_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jim. >From a registrar perspective, this will solve the issue of domains that are= released after the initial 90 day claims period but still require a claim = to be presented to the customer. Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Monday, January 05, 2015 3:18 PM To: eppext@ietf.org Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Servi= ce" post the Claims Phase All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, "...releases for Allocation or registration such reserved domain name a= t any time following the start date of the Claims Period, such domain MUST = be subject to the Claims Services (as described in Section 3) for a period = of ninety (90) calendar days following the date Registry Operator releases = such domain name for registration...". This means that support for the Cla= ims Check Form needs to be revised to indicate whether or not the Claims Cr= eate Form is needed for the domain name and the use of the Claims Create Fo= rm should be supported in phases other than "claims". There are no XML sch= ema changes required to support this. Please review and provide feedback t= o the proposed revised language in the draft below to include in the next v= ersion of the draft that will also include the Implementation Status sectio= n discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 1. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thanks, - JG [cid:image001.png@01D02B1B.47DE3280] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jim.

 

From a registrar perspective, this wi= ll solve the issue of domains that are released after the initial 90 day cl= aims period but still require a claim to be presented to the customer.

 

Thanks,

Jody Kolker

319-294-3933 (office)

319-329-9805 (mobile) Please con= tact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.

 

This email message and any attachment= s hereto is intended for use only by the addressee(s) named herein and may = contain confidential information. If you have received this email in error, please immediately notify the sender and per= manently delete the original and any copy of this message and its attachmen= ts.

 

From: EppExt [mailto:eppext-bounces@= ietf.org] On Behalf Of Gould, James
Sent: Monday, January 05, 2015 3:18 PM
To: eppext@ietf.org
Subject: [eppext] draft-ietf-eppext-launchphase Support for a "= Claims Service" post the Claims Phase

 

All,

 

There was an issue raised privately in supporting cl= aims as a Claims Service post the Claims Phase.   According to section= 2.4.3 of the RPM Requirements, “...releases for Allocation or regist= ration such reserved domain name at any time following the start date of the Claims Period, such domain MUST be subject= to the Claims Services (as described in Section 3) for a period of ninety = (90) calendar days following the date Registry Operator releases such domai= n name for registration…”.  This means that support for the Claims Check Form needs to be revised to indica= te whether or not the Claims Create Form is needed for the domain name and = the use of the Claims Create Form should be supported in phases other than = “claims”.  There are no XML schema changes required to support this.  Please review and provide feedback= to the proposed revised language in the draft below to include in the next= version of the draft that will also include the Implementation Status sect= ion discussed at the IETF-91 EPPEXT meeting. 

 

Change 3.1.1 "Claims Check Form" as follow= s:

 

   The Claims Check Form define=
s a new command called the Claims Check
   Command that is used to dete=
rmine whether or not there are any
   matching trademarks, in the =
specified launch phase, for each domain
   name passed in the command, that requires the use of the "Claims Create Form" 
   on a Domain Create Comman=
d.

 

   Instead of returning whether=
 the domain name is available, the Claims
   Check Command will return wh=
ether or not at least one matching
   trademark exists for the dom=
ain name, that requires the use of the 
   "Claims Create Form&=
quot; on a Domain Create Command. 

 

   <launch:name>  Co=
ntains the fully qualified name of the queried
       =
;    domain name.  This element MUST contain an "e=
xists" attribute
       =
;    whose value indicates if a matching trademark exists fo=
r the
       =
;    domain name that requires the use of the "Claim=
s Create Form" on a Domain Create Command.  
       =
;    A value of "1" (or "true") means th=
at a
       =
;    matching trademark does exist and that the "Cla=
ims Create Form" is required on 
       =
;    a Domain Create Command.  A

       =
;    value of "0" (or "false") means tha=
t a matching trademark


       =
;    does not exist or that the "Claims Create Form&=
quot; is NOT required on a Domain Create Command.

 

 

Change 3.3.2 "Claims Create Form" as follo= ws:

 

<launch:phase>  SHOULD =
contain the value of "claims" to indicate the
       clai=
ms launch phase.  A value other than "claims" MAY be used=
 to 
pass the claims notice for domain name=
s outside of the claims phase. 

 

 

Based on the above revised language the following ma= y be done:

 

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse
  1. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse 

 

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    1. else 
      1. claims notice is NOT required
  1. During post claims phase with a create command 
    2. <= /ol>
      1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
        1. claims notice is required 
      1. else 
        1. claims notice is NOT required 

 

 

Thanks,

 

—

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com<= /a>

 

“This message (including any attachmen= ts) is intended only for the use of the individual or entity to which it is= addressed, and may contain information that is non-public, proprietary, pr= ivileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”
--_000_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_-- --_004_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Thu, 08 Jan 2015 16:15:38 GMT"; modification-date="Thu, 08 Jan 2015 16:15:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_BLUPR02MB0343DE4687D44D237D89988BF470BLUPR02MB034namprd_-- From nobody Thu Jan 8 09:12:12 2015 Return-Path: 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 F2D331A005C for ; Thu, 8 Jan 2015 09:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 bHyDWe7q3Qvv for ; Thu, 8 Jan 2015 09:12:08 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA0F01A87E0 for ; Thu, 8 Jan 2015 09:12:05 -0800 (PST) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t08H5TiD024277; Thu, 8 Jan 2015 12:11:59 -0500 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 1rswbg84qq-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 08 Jan 2015 12:11:52 -0500 Received: from stntexmb12.cis.neustar.com ([169.254.2.192]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Thu, 8 Jan 2015 12:11:50 -0500 From: "Tran, Trung" To: Jody Kolker , "Gould, James" , "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/A== Date: Thu, 8 Jan 2015 17:11:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.33.200.242] Content-Type: multipart/mixed; boundary="_004_D0D41AB946E54trungtranneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7674 signatures=670599 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=3.01686287063063e-10 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.998296994268722 urlsuspect_oldscore=0.998296994268722 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.998296994268722 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501080161 Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 17:12:11 -0000 --_004_D0D41AB946E54trungtranneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D0D41AB946E54trungtranneustarbiz_" --_000_D0D41AB946E54trungtranneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? Trung From: Jody Kolker > Date: Thursday, January 8, 2015 at 11:15 AM To: "Gould, James" >, "eppe= xt@ietf.org" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Thanks Jim. >From a registrar perspective, this will solve the issue of domains that are= released after the initial 90 day claims period but still require a claim = to be presented to the customer. Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Monday, January 05, 2015 3:18 PM To: eppext@ietf.org Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Servi= ce" post the Claims Phase All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, =93...releases for Allocation or registration such reserved domain name= at any time following the start date of the Claims Period, such domain MUS= T be subject to the Claims Services (as described in Section 3) for a perio= d of ninety (90) calendar days following the date Registry Operator release= s such domain name for registration=85=94. This means that support for the= Claims Check Form needs to be revised to indicate whether or not the Claim= s Create Form is needed for the domain name and the use of the Claims Creat= e Form should be supported in phases other than =93claims=94. There are no= XML schema changes required to support this. Please review and provide fe= edback to the proposed revised language in the draft below to include in th= e next version of the draft that will also include the Implementation Statu= s section discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 1. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thanks, =97 JG [cid:image001.png@01D02B1B.47DE3280] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_D0D41AB946E54trungtranneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <48AE312A2CCF524E9139E507FB525214@neustar.biz> Content-Transfer-Encoding: quoted-printable
Thanks Jim for bringing this to the eppext.  This will definitely= help the post claims phase.

With the wording changes, is there still a way to determine if there= =92s a trademark against the name regardless on whether or not the claims a= ck is needed in the create domain?  

Trung
From: Jody Kolker <jkolker@godaddy.com>
Date: Thursday, January 8, 2015 at = 11:15 AM
To: "Gould, James" <JGould@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Thanks Jim.

 

From a registrar perspective, this = will solve the issue of domains that are released after the initial 90 day = claims period but still require a claim to be presented to the customer.

 

Thanks,

Jody Kolker

319-294-3933 (office)

319-329-9805 (mobile) Please c= ontact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.

 

This email message and any attachme= nts hereto is intended for use only by the addressee(s) named herein and ma= y contain confidential information. If you have received this email in error, please immediately notify the se= nder and permanently delete the original and any copy of this message and i= ts attachments.

 

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: Monday, January 05, 2015 3:18 PM
To: eppext@ietf.org
Subject: [eppext] draft-ietf-eppext-launchphase Support for a "= Claims Service" post the Claims Phase

 

All,

 

There was an issue raised privately in supporting cl= aims as a Claims Service post the Claims Phase.   According to section= 2.4.3 of the RPM Requirements, =93...releases for Allocation or registrati= on such reserved domain name at any time following the start date of the Claims Period, such domain MUST be subject= to the Claims Services (as described in Section 3) for a period of ninety = (90) calendar days following the date Registry Operator releases such domai= n name for registration=85=94.  This means that support for the Claims Check Form needs to be revised to indica= te whether or not the Claims Create Form is needed for the domain name and = the use of the Claims Create Form should be supported in phases other than = =93claims=94.  There are no XML schema changes required to support this.  Please review and provide feedback= to the proposed revised language in the draft below to include in the next= version of the draft that will also include the Implementation Status sect= ion discussed at the IETF-91 EPPEXT meeting. 

 

Change 3.1.1 "Claims Check Form" as follows:

 

   The Claims Check Form define=
s a new command called the Claims Check
   Command that is used to dete=
rmine whether or not there are any
   matching trademarks, in the =
specified launch phase, for each domain
   name passed in the command, that requires the use of the "Claims Create Form" 
   on a Domain Create Comman=
d.

 

   Instead of returning whether=
 the domain name is available, the Claims
   Check Command will return wh=
ether or not at least one matching
   trademark exists for the dom=
ain name, that requires the use of the 
   "Claims Create Form&=
quot; on a Domain Create Command. 

 

   <launch:name>  Co=
ntains the fully qualified name of the queried
       =
;    domain name.  This element MUST contain an "e=
xists" attribute
       =
;    whose value indicates if a matching trademark exists fo=
r the
       =
;    domain name that requires the use of the "Claim=
s Create Form" on a Domain Create Command.  
       =
;    A value of "1" (or "true") means th=
at a
       =
;    matching trademark does exist and that the "Cla=
ims Create Form" is required on 
       =
;    a Domain Create Command.  A

       =
;    value of "0" (or "false") means tha=
t a matching trademark


       =
;    does not exist or that the "Claims Create Form&=
quot; is NOT required on a Domain Create Command.

 

 

Change 3.3.2 "Claims Create Form" as follows:<= /o:p>

 

<launch:phase>  SHOULD =
contain the value of "claims" to indicate the
       clai=
ms launch phase.  A value other than "claims" MAY be used=
 to 
pass the claims notice for domain name=
s outside of the claims phase. 

 

 

Based on the above revised language the following ma= y be done:

 

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse
  1. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse 

 

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    1. else 
      1. claims notice is NOT required
  1. During post claims phase with a create command 
    2. <= /ol>
      1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
        1. claims notice is required 
      1. else 
        1. claims notice is NOT required 

 

 

Thanks,

 

=97<= /o:p>

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

 

=93This message (including any attachments) = is intended only for the use of the individual or entity to which it is add= ressed, and may contain information that is non-public, proprietary, privil= eged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_D0D41AB946E54trungtranneustarbiz_-- --_004_D0D41AB946E54trungtranneustarbiz_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=4109; creation-date="Thu, 08 Jan 2015 17:11:49 GMT"; modification-date="Thu, 08 Jan 2015 17:11:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_D0D41AB946E54trungtranneustarbiz_-- From nobody Thu Jan 8 09:41:51 2015 Return-Path: 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 3EBAF1A8AEB for ; Thu, 8 Jan 2015 09:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HjOHiGSKwd16 for ; Thu, 8 Jan 2015 09:41:47 -0800 (PST) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBE91A7D83 for ; Thu, 8 Jan 2015 09:41:46 -0800 (PST) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id D2FE6604DDE; Thu, 8 Jan 2015 17:41:45 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id AD68F60332E; Thu, 8 Jan 2015 17:41:45 +0000 (UTC) Received: from dynamic-200.sna1.uniregistry.net (wsip-98-189-40-200.oc.oc.cox.net [98.189.40.200]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id BF0C2604DA7; Thu, 8 Jan 2015 17:41:44 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_694390E5-E57F-4007-B9E4-BC8B9C623692" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Francisco Obispo In-Reply-To: Date: Thu, 8 Jan 2015 09:41:43 -0800 Message-Id: References: To: "Tran, Trung" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Jody Kolker , "eppext@ietf.org" , "Gould, James" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 17:41:49 -0000 --Apple-Mail=_694390E5-E57F-4007-B9E4-BC8B9C623692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 =20 > On Jan 8, 2015, at 9:11 AM, Tran, Trung = wrote: >=20 > Thanks Jim for bringing this to the eppext. This will definitely help = the post claims phase. >=20 > With the wording changes, is there still a way to determine if there=92s= a trademark against the name regardless on whether or not the claims = ack is needed in the create domain? =20 --Apple-Mail=_694390E5-E57F-4007-B9E4-BC8B9C623692 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_87E50D1A-FCD0-4138-8097-F44269CEB0E7" --Apple-Mail=_87E50D1A-FCD0-4138-8097-F44269CEB0E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Francisco Obispo
CTO - Registry = Operations



2161 San Joaquin Hills = Rd.
Newport Beach, CA, = 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

 

On Jan = 8, 2015, at 9:11 AM, Tran, Trung <Trung.Tran@neustar.biz> wrote:

Thanks Jim for bringing this to the eppext.  This will = definitely help the post claims phase.

With = the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack = is needed in the create domain?  

= --Apple-Mail=_87E50D1A-FCD0-4138-8097-F44269CEB0E7 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mail Attachment.png" Content-Type: image/png; name="Mail Attachment.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAAJsAAABfCAIAAABweiJ5AAAYSWlDQ1BJQ0MgUHJvZmlsZQAAWAmt WWdUFM3S7tkIy7LknHOSnEFyzjkjsOScMyaCSFARBBQBFVQQVDARREwIIooIKmAAJBhIKqggCMjX i+F9zz33/vv2nJl5prq65qmq7p7pWgC4iOTo6HAUPQARkfGx9ib6/K5u7vz4UUAETAAPZAAn2S8u Ws/W1hL8z9/yEEAojc+kKbb+p9p/b2DwD4jzAwCxhc2+/nF+ERBfAwBD8ouOjQcA2wnlQknx0RQ8 DTFzLCQI8ToFB21hHGQPmH1/YeEtHUd7AwBwagBQEcnk2CAASIZQzp/oFwTtkPxhG2Okf0gk7JYM sbZfMBnKOFuhzraIiCgKfguxuO+/7AT9C5PJvn9tkslBf/EvX2BP+GDDkLjocHLK1s3/5ykiPAHG a+snAM/E4FhTe3hlhnGrCIuyoGAixJcifa1tIGaEuD0EevQb9wUnmDpBTNEf94szgLEErBB/8ycb WkDMDQCKkBDmpPcbi5JjIdrSR+mHxJs5/sbOsVH2v+2jQiPDrSnjA9pB7QwOMPuDiwLijBygHHJA hQaGGJtBDHOFOpca7OgCMeSJak0McbaGmARxZ1yYA4UDxc7T1GADinxLJzbBnsJZGMqnA2ONKT5C HTQxIg6iLftoQT/y1rPYoVwpPtjRFMphX7Slf4ChEcTwuWjXgEin33zQwdHx+hQ7FP3U6PCt8Q15 oosCwk0ockGIz8QlOvzpez8+1pEih3FDD4WSzSnjFXJGz0bH21JiQuGzAiyBATAE/CABHr4gCoSC kL75lnl496vFGJBBLAgCAUD6t+RPD5etlkh4dgCp4COIhDpxf/vpb7UGgEQo3/gr/dVXGgRutSZu 9QgD7+ETIjCcGG2MJsYSnnXhoYBRw6j/6cdP94cnzghniDPFGeMk/kiAH2QdDo9YEPJfZBawLQB6 FwvPkX98+Mce9j12ADuJHcSOY18CZ/B2y8pvT71DMmL/MPhr2QqMQ2u/ohIAIxYJZv7oYEQha2WM PkYL8ofcMawYTiCNUYKe6GF0oG/KUPonehTWCX+5/RPLP3H/o0dhzf8vH3/LSZIk5d8sfP94BTP5 JxL/aeWflhDgD7Us/lMTnYO+iu5G30X3oNvRLYAffRvdiu5F36Tg35yNt6IT9Pdp9lsRDYM+hPzR kTsvNyO3/ufur69kKKEwoOQAjv/4gOR4OP6AQVR0SmxIUHA8vx5chQP4zSL9ZLbxK8jJKwJAWdMp OgB8td9aqxHWJ//IAuC6uh3OD+r+f2ShRwCo7wKALe8fmagHABzbALj81C8hNvGXPQzlggUEQAdn BgfgBUJAHPqkAFSAJtAFRsAc2ABH4Aa8YNSDQQRknQR2gnSQDfLBYVACjoOT4DQ4By6CK6AFtIO7 4D54BPrBIHgNx8Y7MAcWwDJYQxAEj9AiTAgHwoeIIFKIAqKGaCNGiCVij7ghPkgQEokkIDuRTCQf KUKOI1VIHXIZuY7cRXqQAeQlMoHMIF+QHyg0iohiRvGgRFGyKDWUHsoC5YjagQpCxaBSUVmoQ6hj qGrUBVQz6i7qEWoQNY6aQy2hAZoGzYoWQEuj1dAGaBu0OzoQHYvejc5Dl6Kr0Q3oNpjrZ+hx9Dx6 FYPDMGH4MdJwfJpinDB+mBjMbswBzHHMOUwzphPzDDOBWcD8xNJiubFSWA2sGdYVG4RNwmZjS7E1 2CZsF5w777DLOByOFSeGU4Vz0w0XikvDHcBV4hpxd3ADuCncEh6P58BL4bXwNngyPh6fjS/DX8Df xj/Fv8OvUNFQ8VEpUBlTuVNFUmVQlVLVU92iekr1gWqNmp5ahFqD2obanzqFuoD6DHUb9RPqd9Rr BAaCGEGL4EgIJaQTjhEaCF2EEcJXGhoaQRp1GjuaEJq9NMdoLtE8oJmgWSUyEiWJBkRPYgLxELGW eIf4kviVlpZWlFaX1p02nvYQbR3tPdox2hUSE0mGZEbyJ+0hlZOaSU9Jn+io6UTo9Oi86FLpSumu 0j2hm6enphelN6An0++mL6e/Tj9Mv8TAxCDPYMMQwXCAoZ6hh2GaEc8oymjE6M+YxXia8R7jFBOa SYjJgMmPKZPpDFMX0ztmHLMYsxlzKHM+80XmPuYFFkYWJRZnlmSWcpabLOOsaFZRVjPWcNYC1ius Q6w/2HjY9NgC2HLZGtiesn1n52LXZQ9gz2NvZB9k/8HBz2HEEcZRyNHCMcqJ4ZTktONM4jzB2cU5 z8XMpcnlx5XHdYXrFTeKW5LbnjuN+zR3L/cSDy+PCU80TxnPPZ55XlZeXd5Q3mLeW7wzfEx82nwh fMV8t/lm+Vn49fjD+Y/xd/IvCHALmAokCFQJ9AmsCYoJOglmCDYKjgoRhNSEAoWKhTqEFoT5hK2E dwqfF34lQi2iJhIsclSkW+S7qJioi+h+0RbRaTF2MTOxVLHzYiPitOI64jHi1eLPJXASahJhEpUS /ZIoSWXJYMlyySdSKCkVqRCpSqmBbdht6tsit1VvG5YmSutJJ0qfl56QYZWxlMmQaZH5JCss6y5b KNst+1NOWS5c7ozca3lGeXP5DPk2+S8Kkgp+CuUKzxVpFY0V9yi2Ki4qSSkFKJ1QeqHMpGylvF+5 Q3lDRVUlVqVBZUZVWNVHtUJ1WI1ZzVbtgNoDday6vvoe9Xb1VQ0VjXiNKxqfNaU1wzTrNae3i20P 2H5m+5SWoBZZq0prXJtf20f7lPa4joAOWadaZ1JXSNdft0b3g56EXqjeBb1P+nL6sfpN+t8NNAx2 GdwxRBuaGOYZ9hkxGjkZHTcaMxY0DjI+b7xgomySZnLHFGtqYVpoOmzGY+ZnVme2YK5qvsu804Jo 4WBx3GLSUtIy1rLNCmVlbnXEasRaxDrSusUG2JjZHLEZtRWzjbG9YYezs7Urt3tvL2+/077bgcnB 26HeYdlR37HA8bWTuFOCU4cznbOnc53zdxdDlyKXcVdZ112uj9w43ULcWt3x7s7uNe5LHkYeJR7v PJU9sz2HdojtSN7R48XpFe5105vOm+x91Qfr4+JT77NOtiFXk5d8zXwrfBf8DPyO+s356/oX+88E aAUUBXwI1AosCpwO0go6EjQTrBNcGjwfYhByPGQx1DT0ZOj3MJuw2rDNcJfwxgiqCJ+I65GMkWGR nVG8UclRA9FS0dnR4zEaMSUxC7EWsTVxSNyOuNZ4Zvjx3JsgnrAvYSJRO7E8cSXJOelqMkNyZHJv imRKbsqHVOPUs2mYNL+0jp0CO9N3TuzS21W1G9ntu7tjj9CerD3v9prsPZdOSA9Lf5whl1GU8S3T JbMtiydrb9bUPpN957NJ2bHZw/s195/MweSE5PTlKuaW5f7M8897mC+XX5q/fsDvwMOD8gePHdw8 FHior0Cl4MRh3OHIw0OFOoXnihiKUoumjlgdaS7mL84r/lbiXdJTqlR68ijhaMLR8WOWx1rLhMsO l60fDz4+WK5f3ljBXZFb8b3Sv/LpCd0TDSd5Tuaf/HEq5NSLKpOq5mrR6tLTuNOJp9+fcT7TfVbt bF0NZ01+zUZtZO34OftznXWqdXX13PUF51HnE87PXPC80H/R8GJrg3RDVSNrY/4lcCnh0uxln8tD VyyudFxVu9pwTeRaRRNTU14z0pzSvNAS3DLe6tY6cN38ekebZlvTDZkbte0C7eU3WW4W3CLcyrq1 eTv19tKd6Dvzd4PuTnV4d7y+53rveaddZ1+XRdeD+8b373Xrdd9+oPWgvUej5/pDtYctj1QeNfcq 9zY9Vn7c1KfS1/xE9Ulrv3p/28D2gVtPdZ7efWb47P5zs+ePBq0HB4achl4Mew6Pv/B/Mf0y/OXi q8RXa6/3jmBH8kbpR0vHuMeq30i8aRxXGb85YTjRO+kw+XrKb2rubdzb9XdZ72nfl37g+1A3rTDd PmM80z/rMftuLnpubT77I8PHik/in6591v3cu+C68G4xdnHzy4GvHF9rvyl961iyXRpbjlhe+563 wrFyblVttfuHy48Pa0nr+PVjGxIbbT8tfo5sRmxuRpNjyVvfAmh4RgUGAvClFgBaNwCY+gEgkH7t ubY04CcyAnUgdkaMUHpoNQw7loCjwstRuVFnEm4TcbRkUgs9gSGc8SGzMksFG2AP4+jjUuE+zDPH p8tfIDAgRBBWF3ETDROLEPeU0JfkkVyUur+tTDpMRkuWVvaNXKP8XgU7RQHFj0rXlfep2Klyq75T a1BP1tDTJGg+216h5a+9TfuLTovuTj19faL+G4NbhvVGlcaFJrtNyWY65uzmixa9lg1WldZVNu22 U/ZYBw5HTid6Z7TzusuaG3Cn9iB50u7A7FjymvTu97lDvupb41fmnxeQEhgU5BisH6IUKhkmEM4R QReJjvwWNRndH3Mj9kzcofg9CdmJTcmYlIDUOzvBLtHdGnvM9nqkJ2QcyizJStuntG8qu2C/bY5I Lk0eyEcdYDgofki7wPqwS6F7kfsR12LnEsdSu6PWxyzKTI7rl2tXqFcqnpA+KXlKrsqiOvP0+Fmz mgu1c3UM9SLn5S9oXjRssGp0ueR9OfhK9NWka7ubMpr3teS05l8vaCu5UdFec/Para7bw3fG7w51 NN4L7GTvfNBVej+pO/DBjh6Xh3aPLHpNHpv2OT6J6T818PIZzXPZQYMhs2GjF2ovRV6RXq2+nh55 MXp37PSbzPGgCadJ6ymrtzbvbN6bf1CfZpsen8mbVZodnzs3n/rR9BPVp7rPJp+nFk4vJn/x+mrz zWopdLljZf+Plg3Dzc3f+ZdHY9AzmHHsFG6BCk2tQgimqSCOkyTpkujvM3IwpTA/Z1Vgy2Af5VTm yubu5+Xkc+UvFGgXHBFaEl4WmRV9LHZaPFZCW5JK8rnUyW2h0srSP2Xuyx6Sc5Hnk/+g0KCYqKSl jCh3qeSp2qgxqQ2pl2l4aPJojsBR4KnNoT2sc1TXQ09Ub01/0OCy4QGjAOPtJgwm703bzUrMEy0C LH2tgq2jbCJsfe1s7DUdJB25nEjOKOdllw+uQ2733Bs8yj3zdqR6hXi7+hiSZX3Z/RC/Wf/BgM7A pqCa4NKQrNCoMLdw3QixSFo4Eiaix2K+xQnEeyeUJd5NepE8lTKfurqTZhfvbvE9/Htxe9+kN2UU ZMZmee1zynbdH5KTmVuZdzG/6UDzwWuHLhdcPFxXeLbo1JHy4pKSgtLcoxnHUsqijgeVh1Tsrbx9 UuLUuWqx00Vnnp1drSWd46wTqpeE40D1onaDYaPVJbfL4Veyr56+dqtpoHmsZbr1axv6Blu71E3N W7q3Ve8I3EXdnezovtfUWdtVfv9w974HqT2xD+Mf5fa297E+2dU/+pTzmc5zx8HAob3DZ188efnt NeOI9KjlWPSbo+M3Jp5Ojk1Nvp17j4XZT58ZmGOYl/uo/En0M93nlYX3i8NfHn69/q1qac+y83ex 78sr7aupPzTXiOuGGzO/8y+DzKEq0V4YCSweu4ibwc9STVIv0hCIIrR6JHe6dPoLDAOMm8wiLEas oWz72E9yXOPs4nrAfZ/nBm8VXzK/Pv8PgTOCFoJzQjnCYsIdIl4iq6LFYnJiD8WDJPAStZKmkh+k sreJb+uS9pMBMpWy22VfyCXAr5tGBUuFacVMJV6lVmV75XmVfap8qi3wq2VafY8Gq8Z5TT3Np9v9 tn/SStPGa5frKOkM6abq8eq16tvovzQINtg0rDayNaY2vmey01TJdNas2tzTgt1iyLLEysGazrrH JtNW0/abXaN9mIOYw1vHKqcdzhzOz10KXE1dN92a3MM9hD1GPUt3WO9Y9ir2FvG+5qPn84qc7Cvo +wKuI8EBJoGqQerBZiHk0IgwcrhOBH3ESOTZqIho5ej1mHuxeXG28SzxrxNOJvoniSa9Tz6RYpQy khqexpz2bOeNXbd2d+65t/d6el1GaWZmVtQ+j2yj/ZI52JznuWV57vnC+WsHxg8+PnS94NTh3YUe RRpHOI+sFg+VXCk9evTgsaKyquNXy+9XvKicPbF2iraKv1rxtOkZz7NRNbtrc88dqNtbTz6veoF0 4cvFjw2rl4iXea8oXLW9ltZ0rXmlVf16dFvZjUvtrTdv3Oq5vXTXpON6p0PXUndpj+LD570H+3z6 zZ7qPdcfCn9JGpmb7Jtd+rZKyf+v2hvlnYBTAeBIOtyhZgPgpANAYScAooNw30kAwJYWAEd1gBIN BChiL0A0Jv6+PxCABjhAAxhg/YYPiAE5oAHrLjbAHdZC4uDusgCcAA3gFngCJsA3uHPkRuQRE8Qb SUIKkQvIA+Q9CocSR1mi4lCVcJ+3Cfd1iejr6J8YE8wRzCRWEZuDfYPTwJXh1uAO6yGVKlUtNRd1 IYGGkEtDoDlM5CTW0irRtpO0SG10anQ36E3pXzPEM9IzXmQyZBpgdmQeYLFhecrqzbrCVsauxT7G sYuTi7ONy4ubmrudJ5FXifcr3xX+WAFlgXXBbqFS4WCR7aIk0XGxq+I5Er6SelKi20jb1qQ/ybyV HZRrkk9TkFcYU8xRUlb6rNyqUqSaouavbqkhp8m2naQlo12uK6V3UL/H4LMRlTGLCYcpt5mwuZKF tWWM1THrTpsvdkL2Lg6HHLudMS6GrtluvR6snr476r3e+uDIDL443yW/d/4jAbNBdMEWISWhH8K3 RxRHfoo2j6mPI8bHJLxKMk5uTZVOq9nFv7t8L2t6YSYhK33f0v7QnLm8/AMRh5oKGY5wFn8srTvm fZy1vL/y4EmTU0vVBWeYz+bULJ8Lq/ty/vBFo0aGS4tX3l+bbp5r/dA21b54m+2uwT2vLp9uhx6d R7KPJZ6oDEQ+WxnGvKIeOfmGaeLWO9L0zjm9j42f176ofDNeJnw/uPJwdfrHu7WX69c2Dv/03ZTb Wj8o+cfD+h4jrDkIAEmgCLSAKawz+MAKQxrIBWWgDlyHdYRRsIBgEU5Ebiv7KUgxcgnpQz6i6FCK KHdUJuoK6h2aD+2NPoOex6hgsjCDWAlsOnYE5r4cD/DB+EEqI6pWalnqeoIE4QKNEs1toi1xijaZ RE0qoROguwT3r68ZkhhZGVuYnJk+Mu9iIbAcY5VmfcgWxc7GfocjhJOZ8w5XFLcw9whPGa8rHzvf S/5KAX9BOSEg9Fz4vEiWqKeYEtzLzUr0Sl6Fb7EC6UyZnbLxcn7yugpEhT7FPCULZTblRZWXqt1q zerVGgc0U7cnauVqt+p811PU9zfIN6wxaja+YXLD9KZZj/mEJcpK0trZZp9ti928g7Cjt1Ol85ir oFuoe7MnfoeL13HvLp8BcodvnV+Of0iAfaBpkFtwRsidMNpw34j2KM7o1JjROP34ukS6pOjkR6kC aYk7+3cr7zmTzpVRnEXYl5Y9n0POncxPPShXgDo8WnS5OLFU6eiXssvlCZUaJ36cqqlWOF155kON WG3wuUv1bOcrLmo1fLxUdkX9al8TuXmttbrNrh3crLtteWex42Sn732NBwIPMY8eP058guvPe0p8 Vj3oPWz1Mvx17eiHcb5J27fp72/NsM0d/iS68Phr8fKBVbM1hfUTG29/Lv7OPwZQw5ouO8y+FKw1 GQBbWGGKALvgzK8C18ADMAbnPRERRXSRHUgaUo7cRCZQ1DDrZFQJqh/Ngg5A38RwY/ZiZrFu2Mc4 A9xNWE+5S2VJNUodR6AjXKJxJqKJLbQxJHnSCl0XfRlDAqMbkxmzOYsdqzmbKrsEhzKnN1cKdzyP L68jnzW/lYCVoKWQlbC9iLdonNhB8XqJB5Iz22ilVWUCZY/LDSlwKvorNSqvqdqqPdbI3e6mjdU5 rLuub2GQCTPYYtxucsu0z2zNwsKy2VrG5oKdjH2zo4HTkEuEG8H9gqezF4MPja+3v0fA2yDN4PyQ 92H24b2RVlFPYzxip+PTEnmTxlLup93ZVbnHae+PjKos52y+/Qu5N/MPHAwsMCnkKHpUHFiyfDSz jOF4dYVK5eOTgVVIdcUZtbODtQl1XPUPLuxpMLkke8X42p7m6taCNrd2tpvDt8vvut3Dd569r9R9 o8fo4XBvcp9sP3pg4dn04MBw4UuxV5Wvf44ajeW9eTRBN+k0dertzHv5D2HTp2YezM7OYz9yf5L7 bLjgskj+4v/V9pvgt6Wlg8vcy/Xf1b8f/7664rLSvMq6GrvavLr2Q/dH1o+eNdKaw9rRtf51qnXd 9eT1y+szGwIbbhtFGw83Nn7K//T/efTno58/N+U3AzaPbfZS8h8XqKhAeXsAhKgPy49jm5tfRQHA FwGwUbi5uVa9ublxGm42RgC4E/7r/xyKMuV/oooFCnrUujJAuf7793+Hw8XBvpCpSAAAAZxpVFh0 WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8i IHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2Jl LmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTU1PC9leGlm OlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjk1PC9leGlm OlBpeGVsWURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4K PC94OnhtcG1ldGE+CgOpdOAAABtsSURBVHgB7V0JWFNXFn7ZSCAkYd9BZBGQRVBQERGtO6K4KxWx rVO7fO2001o72GlnprZVq9NlbK17XWrHqqOouLTivtcNUBQUEGVT2SGEkHX+x4MQkxABg1rmvc8v 3nfvuefee849633vwVCr1QR9dSMKMLvRWuilkBSgOdrd9gHNUZqj3Y0C3W09tIx2N46yu9uCnvV6 6uRSqVLOYDD0J4KwwozJFpmZ6zcZr5GplLWyBhJGH2tTpCLi8DisZlbSHDVOzA633q65ny+u1NBX u79CpXTgCQY7+ujzRRtMv1wrk5x+mA9+6u8TpZpgE+oB9p6O5iKqI4OOR/Up+CQ1oKeRAB+8NMCW x40HhEaxkjg1u4Tm6OPI+Udrp7WuiTl28v6tm7UPDGpduVLpbiGKdQsyZA+NTaNEUn2oKAuSSDA1 otgMD9llq9TDXQPc+DZUFc1RY6TsRBubweQwmWYMln5fcITFQHChyxV9SJ0a6FQOCwi1lWsziJJQ c5hqhhZOWuvqUO8Pf0vLqIlZWCdvaFC0Gb1AG1ubWXR0SEQvNTKJkV5CjjmXjl6MEOhJmpZn/vZp 4VVrjgG2VSka59h7/jgoUVtJtmeszKrCMWf+U8di8PXy8FWEylup3jRwWpSDD4WK1rrtIWkHYArE ZWVSMZNhQPmpCJWIze0lcuoAuiZQZC1u1T0gi2q9HB9DxVQRXiIHEac5cUFztKPkfd7hDWyl533K z/f8DtxNz64sJNhmSArozlSpcBDYzfIZ0FGtWyAu35X3O0H6yboXxmCpVRN69vMSOlJtNEd1afSE 9yfv5yzNv0Rw+YQeQwm5dLKzz4veA1oTPO0brLShNvnWWRk4qs9UtcpGrQpz9NZwlNa67SPqHweK llET80quVskJFRn0610qhpqtZpgxDSQf9GAfqUBiSEqg9yOV1A2ZXFARXCZTk9mlOWqATJ2uAs3/ dGzt5punCHNLA1pX1hDs1js9bgHI36Eh0u7njEpdTmYB9VNRaiWhUu0f806sRwiFk+Zoh2j7GGAw apx7iKsZnzDjItTQgVYp5O5WTiRjOnj14FsnB49o4qheX7WaqVJ7Cmw1KGk7qiFFNynQMmpiRqbe vXqt4h6TjF50MauUcheBfZJvpJ6g6ULq3OeLK7bnnkclQ8/XVatVMMuTvCJ8hA5UL5qjOtR70tu/ ZhzIunyA4FsZiEcb6wmvvrN9Bmq8mHYOll5VlHzgGzJ00feqVLCjSpeZn2s4SmvddlK1vWB36pAF rGMwDYmKWingmPuJnDoqo8j+Z9c+bJqBga5MlcpX5CBsOQCgOdpeVrUTTqVWy8n0qwHSqwk1G4LW cc8I+luhVrV9sKrGoaxmPENbqZ1zp8EMUWDGkVU7bx4neEJ9X5eQSazcgirikw3y2xCy5rrDJTdH 713SttZV7Rv3XpxHHwqa5qgRSnamyZzNIdg8gmMgekHgaI/Wjl8sJpPg8MjoxYAdVRFqZdOjEc14 aa3bcQI/3z1oGTUxf/bcvZJZfo+F6EXvUioVbgK7l8joRWP19IAMVeDs5T+551UQUj0bjAQhS62e 4h3hS5+9GCKdCeoSLvy34fxuQmBjIHqRiole/ZN8IlkdYyhxtqxg4fZ/kna05dGT1okqFYheHF7+ huZoK01MW/pX8Ijf7DzMSbOnm2KQKuQhVi4GDjkfN4M+1i5Tx7zOIphIyOvAKtVqjkrV19ZDU0/b UQ0pTFZAnNEW28BkXZ60b9i2OurX03a0fRRtN9Qn6fsXnfmZ4FkaYB2Z31Hti/1LnFtwu/GRgPFH V+/NPknwBAYiIoUC5zy34hfSWrdDJO0AsDXXgnhYQEYv+idfQCOp/SLjUKxrUPvzDOkV9/amHyLq Kgg2IiK9C099uvrZt7zGhGZa6+rR6MkqHjTUHivNVjOYLD2/FNSWqxRCDne8e3M2oD1D3ZNUnSzJ YbM5BjW5XKlwNBeOcAnQoKK1roYUpimAvmoG405lMctQkgFxS75Snn4/b27gcBeL5vcDjQycWphx rjRHaDAD1dQNT3v3t++pjYHmqDY1TFPeczfjl4MrCT7MnqELzoyi8ZNbpy+Nervfo8zQhsZz9Cuy 0uYfXEGIK4m2Mk0yGWFpNcoj2FerJ611tYhhomJmVVGfXYsIpYxgtpHzg78rqSXsPFKiZsW35GO1 B6+Xy5Kv7Fpx5QDpGpvxDIS2gCaR1I3oHX14+JvafWmOalPDZOWcmtIHUjEHxg8Safhi4FUWDoPp JbTT8ZLQo1YmvVtfKeDwuCyOYXYSBN5KUygVwdauOi/S0FrXML2fsJbLMov57XsCSSKkGggEqAYv BoEzMrnMQEyCjHyzZ9tWXya08UthY3+Mmq2DmuaoDkFMc+tpafu6z4BV+/9NmJmR2TsTX2qisZGw d3/TP0YfMc1RfZqYpmZ5/ylVjXXXqh84wKfVf2Oi04MwEAKpHogrPwmNjdBK/mnw0XZUQ4ouKay5 ferS/TyhhZBpGqYyVCp5jVz2btCIQJGzwRnTMmqQLCar9BM4vnZ4DVGSizDjSZHCuVXIiUbJ8EHT 3SzaxEbL6JPS+bH9M6tL+xz8isi9TPDMCYNPlD0WBQAg4vJGdH8jJvH7gQlgblsXzdG2KGPK+ofS uu+zjx0vLyxXyFx4fAQtBvzbNgbEQbdYIauUSfvyrSd7hEz27NcGYHM1zVHj9DFl6+/l+ZPObS8p zMJBJxnVQF4N5H61RkRso5ARMilOct4LGfFZvwnmTAOPRmh1IIs0R3UI0rW3yONvuX32g2uHiZJb hLSezPuAr4g+8Y/SpNCuOHRrejKBrBTZD/UOXxgydqRr73bOjOZoOwllSjA8eHCiNDul6Pqukuzi qlJCUkPaSBX5IBHJYK45HmqJceg5yaX3BI+QngL7Do1Nc7RD5DI9MKS2QlZf09hAffFTyOaKuBb2 PIGQTDZ15qI52hmqPc99TJ6gep4X+38xN5qj3Y3NNEdpjnY3CnS39dAySnO0u1Ggu62HllGao92N At1tPbSM0hw1KQWKi4quXrkilUpNitUEyJRKZWZGRn5+vglwPV0Uzc8wlJaUrF2zBpRls9kymfzF xFkhIc1fJdOZT1FR0drVa5RyOZPNAuTspNmBQfjjCJ259qakfJL8UUVFRdSQ6K/+/a2Li0tnsHRB n5qamuQPFqTu22duYbEg+a+vzJ2r/ypuFwxrIpR4SRhXRnq6s529pRnXRiDkMlk7tm+n6vV/L168 aC+0EnB5gOQx2Cm7dunDtKemsrJyYL9wkQXfw9kFIy75fHF7ej0dmE3rN1hwzNwcnbDGXj288vPy OzFuVVUVNFBJSUlxcbFEIukEhs51aZZRFotlZW0NATUzM+Nyufhta8OwWWwrG+vGxkYOhwNITtuQ bWGg6uUyWV1dnYWFBY/Hw+hVlRXG4Z9mK5iBp0AwNwwqkUqk0qa/WdbBGXz15bIdO3YIBYJGWeOy r78eOXJkBxF0EvyZeUZ29vYJsxOxeUtKS3p6eU1LmNnJFXRBt/GTJob2DSsuKamurp4ydSqm14lB YE3uFhQUFhbeu3u3QWLsL0F0ArmRLs/sWUC8gf7R3/4WHh6el5c3evRobx8fI7N8yk1eXl47du/e vy/V1s42fuJEqJBOTAC6B1Jubm4OGwxl1gkMnetiMo7W1Yllssamr4CoRVZWoALe37iZlXX7di60 lo21dUhoqKNj87fUqbk2NDQMiYkZOmyYQqGQy+VQ46iH1GJH45OG+IahpUBA0eJG1o38vLzomCEi 0SNv6N26dev2rVticT0o5+3jHdC7t3EXpvDevevXr9fW1AqFwpDQPq6urhgRggjPFs+EMJhMkVDE ZDFxayWySpqTBEsG+0KpXw19xWLxjawsWEfMWWBp6enl5evrC4NFAWAt4ro6TANuJjUZ/NZUV6MX UAkEAlg04K+tqSHNJEGgI7Wo6qqq8+fPu7q4BoUEl5eXs1kslUrFYrOtrAw8yIkmwFMjAo2NrW3r wkm8avX1a9cCfHu5Ozl7e/SAi7QnJYWq1/+9euWqr2dPuDMU5P7UVArmg/fnB/sH9O/bL3pg5L27 936/cGHm1Gm9enoBm4ONrYu9Q9/g4DWrVqnwlbWW658ffxLo6x8ZHhHeJ/TkyZNU9Xcrvgvs5YfK kIDeR46kQXHNe2Wup4u7l7sH+NfSVZ2WljZz+owAH19gdrK1wygYa2r8xF8PHtLAaBfgoMx/913M EPCOVrYutvahgUFfLlkKB23unDl9/HtjDqOGvQBPHr1yb9+OiRocERaGOWB0mUxGoQKTVv/ww9Co wT3d3J3s7B1tbF3tHPx9fMaPjV2/di1IDLCc7Oxhg6PRN8jPH3P26eEJQvUL6RM1YAB+Tx4/QeEf CpjQsGB//7ffeBP4161dNyiiv6UFf8kXXyjkiskT4kODguE5As+5M2ep0bV/N/24EWuJ6j8gyM/v 3bf+DAZrWk0mo+UPH9zJz+dbWmL7f/ftt3tT9paWFJvzLbgcLpvNwse3S4pKFvzlfT7fEqERtbnK y8sgeSJrkbxRLqmvpyqrqypRCTdNrVTt37MP0SouaDA7u9Z3uL5a/q8vlyyBXEOnQVCUcgVCqfr6 +uNHj2FnfLgw+b358yls1O+d/DuvzJlz6fffgRao1Fw1esELXfrZFzevZeXm3S4qKQakWFwHZYEC SHy34A5EHyzs4elJveMA4Uv+8MN1P6zhC/gwGY2IoVVqGZMhL5OfLz934vjxXTt2bvp5K0S8oKCg tpZUA5A/EBrSU1ZWBpwyqUwiIZfZhL8AjiFw5uXmLnjv/S2bNwOYgzf9WXA9WYHBQQdSU+FqwBin pOweOCiSWgj1i1lt37btzp07GAID9R+EP2VAPXZGtpuMo/CRzXnm0CrAvmnjRowqsrbi8/kgtFhS j3qBSKhUqjZuWD9x8iRKj8GxpiwNGwxpsVXQvYgC0RFU27ljB5Qw1JRU0gA81Hp+WLny04//jn3A 43IVMkVoWKiLi1tZRfmNa9cwNHp99vdP7e0dZs9JouCh6z5OTr588aJzU7wLOuIBLZFQCLS11bV7 9qZYW1tDa0HV83ikzUMvIMFewb5HgVT7TZW7d+36cc06Owc7MAmtY+PGYZPdv3//euY1KHPwBhoS yykreyiXy+SNMsgNNQHgRCv2UKO8UamCom3Gj0psLyieyxcvYSCoYhAK6wXA9Bkztm39GTO3sbE5 cuQINoS9fevzYwg1r2VmOjg4wGyF9e07dmwsNRD1azKOUugwe0wdn6mbOWtWQsJMEBGzWf39yiOH j2Br83jcosIiKFIYPO1JGCyDcGCks7PzyFGjQsJC+RZ8pCBycnIQFVgKLTEQaP350iXj4sZZWVnD Sp07ew6cg9pE8PXNsuXDhg93cyPNJAT38OHDtnZ2KGNH9wsPf/X11wICAiQNDYcPHtq8eXNNZZW5 Jd/gHKhKZtPLZYf2H8DGQw3GXb1+XfSQIVQrvNld23ds/PHHhR//DZzGZlq8bBkYuGd3CkwPakCQ xDlzQkKCG6SNQU3ZGJKrLZdM2gh2Rg+Jjo6JAf96BwaiJTAwaFBU1P69+xAo3rtTcOzI0ekzZ7T0 IFL37MW+xH4Cy8eOi9UxtCblKBNPKKowzF8WfDB/wQfUDHr5+fn4+kwYOw5ajnI6AKCZXFsFMAxC GTlk8BeLF1OLpCC3bNoErwHsgffxj0WLZiUmUvWWlpYjR40E+WYnJEDKoZEO7N8/77V5aE1LOwya khJZW9u3b9+NWzbbOzR/LjosLCxy8OA35s2rq61tayZkfZNKw6ahtCi+vAm1qYF3d3d/5/33psyY TuW8bG1tE2eT73TeuJ518sQJSCFGHz1m9AvDh2u6aApo4vEtFn3y8YuzZgG5ph4fV504efLBAwew rUFSaOCp06eB8QCorKg4evQoVoo52NnYTZw0WdOLKhiOR419uK5VY+ugwi0DJg2aBx6/dpuDg6OP ry+eXyQhyMvwoJou+FgXVBAU1+ykJG121tdLLl74naSRTAbp7xferwjRXsuFokcPDx8fH5AJwnT2 1CkgxO7JuXETxAJC3L7x1lsadlLDDYwc2KNHD+ObDGQFMBxjLAE7o6FR+urLr8SPi/vr/A9+2rw5 Iz0DJsbNzY2iOIUWv5gGlkrdQj1q6rUL2LXItibNmaPNTgpg2PAX/Pz8AAB6njt3Fg4XVX/ixAk4 buAoxHRwTHRA79avpFAAzfuCnHTTvKlazVSo20d/we5WrlKrbQVo+syZzgKwy8hgprVTK7iREuag brI6GpgHpSWwW1g8pBBm708vvUS5eM0AeHqZyawX12O1mBUy1eCitEGK4ARdsKNhL6EwNNioAqYK MKPrxYvYJEcTEhNTdu+GhgAerAga9fSpUxgR7ol/QMCMhARYbuN4dIbGLfYuqIK5YaPotCKkiR0/ /svFi6F+yu6X/fbrr5SpOrAvFRPGAkGESdOm6PTCbTNHsWbNFkOH6urmWEe/g1QigZtHAeOXa2Yg dtZlM/lmlbbt0MdquAaE025AOg32iYFvBTGZkIAb128qVQrt7QVgGDnsHjIVVVIibWjA3oNfT36h T6VGPYv1GPWgPZxOOaJ/xMo1qxf9/R+w5VgOkqXw9oAR5Lp4/sKpkycz069+vnQp6Ul15AIqXAZ7 xI0fv2H1WplcZsYzO7j/wNvvvAObffr0abiNWCAOSKKjm225dvdmjsJRhoFFPhO7TKVQwtFPTErS htOU0VRfJ7a2tYGrBmlwcnbSNHV1AZEPVG5NbQ2Ghi569c3XzNhsiKn2uNQWUEAi7WzJbcpi8S0s 8ElwrhkPwvrw4UPof214CAe40hZNtSFRHjN2bHhEBFyt0ydOgK/wwiCy6Av/BTts3eq1AwdFweDp 9Or0LdyoyCGkfwR5zbp+PT09PePq1Yel923t7cS1dePGx+nkW6iBWjhqZ+fbyzc7Oxv8t7Dkp+5L hWUe+sILOrPJy8vfuGEjz4L08uGI+gX4uXt46MB03a2jk7Orm1txYRGHY4ZNmjg7qW+/vsaHg8JE QHnp0iX8cV5QYevmLfAhtbsg4IOvgfBJu9JIGR4meIZ/UJWw4ulX03H6hGAUognjfTQtTZ+joBX2 lhGcbTYxiClTp8HHbnIsFFs2bS4pLESMCKvv4OQ44VFnRYOkVQuNiR0HLYcdx+XxYF3eefvtnzZv KS8rx+4j9XBVFVwvpFeKigshH+gPS/bCyJEGt4kGu2kLCEtiYmKwHg6bLRHXf7boUxxk6gyB6B6X phJOY1R0NBalVKsQECOm/GThwuKiYvgyyMOBE6+9Og+ulYUluSLjF0R84YIPoV0pMAi3l7f35KlT cLILImBWkPUaBLstFyX3YCc0CrKALdUd+39IzBD4PohTLS0Fe3fvvnzxMswqfCJ4zvABDeJq3Tvj 4yds27oVnrGTkxO6VZRXIMWz8rvvPDw8MFeYJWQ3MDk4AphlVUWlVy/fl195xSDSrqucOevFn7du hTmBe3Lm5KmkhBfnvj4vODgE53+Y4flz59euWuXm7r5t5w4YOWoa4+Li1vzww63sHBs7Wyjt1StX QQNhUQjmsSLIKKLAx0wYX6lRqxE4fbV8+Y4d2+MnTRo9egzSOrBTkO+ft/yEuAgMBst79HhEY6EX TD5cGOQIGxqkFRXlMxMSXJqSyY8ZsaUZQ8TGxWVmZFL7A195BQuwivjJk1pAdP9v5SgkDwH7S7Nn 52TnIKjCLUQW2YDcnFtwUzEtWE3gQiXMLXbl0uXLnqbKpSYOrfvZksWvvvwyyIe9deHCBWhUZE8w PdQgSYsCHH3kCBd9/jnVxc7e7h+fLZo7ew6YBwIJrURIekB1Y1EIkJBwkDU2wiLqEkbrHjixh75Z /jWyHEgHbVy/YfvWbc6uzjiQgAsJiadiCeyMGTNbzwS9vb0RZQENKImThvfffReWwtPTc/LUqR3y +sdPmLBh7TpoTcofBhKkyQZHR2tN8JFiq9ZFNYK/rb/8MiE+HjYS60dMDXGE1cSFvQZcIBkUXUT/ /lt/2YZUjjYmRE5YHshaU1WNb2FpN6FMtkL1kK010OFUa0O9pFLcVFtdLcd3Ypsu7OVKcS0gq2qq YauoSu3fsbGx6zdtQhBZUVaO3C+wgT138vJJt05NRgJQU35+/tpdMNX1WzYFBgZCmLAErA5KGCsa N3HCytWrnZydqXBL42IBJ5ZJzqGqCkRQKpTY4skff9TT24uiiVQmxSHg5UuX8HgDrBJohe21dPny PqGhmnEhRohqoDnILmoywwVPPe233wAAqWjGX0OeyWi6GCwgaEF+SiLGeRR5Ybi4+HjK8BmEb5VR qhkHQ5u2/nQkLe3XQ79mZV0ve/AAIR2a8KwCVtXL33/osKHwqvUxRkZGQjNAiKGidfQY5gFjhi4c eJxmXChMaqyIiIja2hokcaFJkO2jKoOCgxKmz4CD1tBA7miqUud39JgxIX36IFt9/Pjxwrt3MUMM IbAU9vTuGRkVNWXaFGdnF50uYOrAyEiczNy4fr2mrlYgEA4YOGDU6NEQo/IHDyl3F7+40FEoEk2c OAlRmkIm7x0UhFAdk//TvFdj48bt27P3zJkz+bm5yAmr1EqIr4OjY3j/iBcTE7FjtAf16NFjzYb1 Xy//V2ZmRpPt5yBjNWL0aAo/kjASaUMT/kDsLe2O+mUEu0iBYZ9hv7o4OYP++jCaGmPvj0Ioy8vK sH8RL3F5XPDpafpBmikaKSiUSjzGg3MbEAVsgAfQFnBpaalm02jDwNNJnJkARkKLQML+uydFY4C1 wXTKiIIgwgqFEmRxdHDkG00L4xkGcX09zhVgpLADdFC15/a/O3e+Ne8NJMahYBLnJH27YgV2cJsd IVjd/oIZCw8NW7Z0KTao9mIzMjJGxAzF2SpOfIXmFh8lJ2u3PtsyJLJJlnBYmzsseggmiUNZHO4e STtifGLGZLTNXfCHaoAEv/na69jm0Jw4cgkLD3d2doLWuVdQcOzY0apK0suDdReIBLtT9+lozme4 UBjgP7/1FjyDgjt3oGBghuA3RA6O2rV3j3FB17Wjz3ANXTR0UVExcrA44MNzi0j0ZGVlUQNBccHq 4yp/WM7jm8OFfn7YiRniCOLU8ROQVGxETBJuGnwQHPIYZyc6PsYmdxGVnyZaROL/2blj8rSpbDMO PAsqi0I5yUhTgGTRQ4ds3roVh8xPc1aPHQsWobyqEuno+rp6mE8HB/tvVqwYMWLEYzt2f62rIcGV y5fxkFReXi7iK5giBKaePXsGBwcPGDiwk1k6DeouKMCN37l9O04nhVZW/v5+eL6unQ+Z/h9xtAvI /jyi7P5a93mkelfOieZoV1L3WeCmOfosqN6VY/4PV2iSp+CpbccAAAAASUVORK5CYII= --Apple-Mail=_87E50D1A-FCD0-4138-8097-F44269CEB0E7-- --Apple-Mail=_694390E5-E57F-4007-B9E4-BC8B9C623692-- From nobody Thu Jan 8 09:44:31 2015 Return-Path: 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 A2FFC1A8AF9 for ; Thu, 8 Jan 2015 09:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 XHM63DDg84b3 for ; Thu, 8 Jan 2015 09:44:26 -0800 (PST) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1ED1A8AEB for ; Thu, 8 Jan 2015 09:44:26 -0800 (PST) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id BD41960397E; Thu, 8 Jan 2015 17:44:25 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id B1478604F47; Thu, 8 Jan 2015 17:44:25 +0000 (UTC) Received: from dynamic-200.sna1.uniregistry.net (wsip-98-189-40-200.oc.oc.cox.net [98.189.40.200]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id 9F70660397E; Thu, 8 Jan 2015 17:44:24 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_68FC055A-4737-4BFA-90EF-0DE9885E9BD9" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Francisco Obispo In-Reply-To: Date: Thu, 8 Jan 2015 09:44:23 -0800 Message-Id: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> References: To: "Gould, James" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Jody Kolker , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 17:44:29 -0000 --Apple-Mail=_68FC055A-4737-4BFA-90EF-0DE9885E9BD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi James, The only component that is still open is what to call that extended = claims phase. Perhaps it=92s useful to suggest a name for that special = phase (extended-claims?) to avoid having 100 different phase names. I believe the clarification is very useful. Thanks Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 =20 > On Jan 8, 2015, at 9:11 AM, Tran, Trung = wrote: >=20 > Thanks Jim for bringing this to the eppext. This will definitely help = the post claims phase. >=20 > With the wording changes, is there still a way to determine if there=92s= a trademark against the name regardless on whether or not the claims = ack is needed in the create domain? =20 >=20 > Trung > From: Jody Kolker > Date: Thursday, January 8, 2015 at 11:15 AM > To: "Gould, James" , "eppext@ietf.org" = > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a = "Claims Service" post the Claims Phase >=20 >> Thanks Jim. >> =20 >> =46rom a registrar perspective, this will solve the issue of domains = that are released after the initial 90 day claims period but still = require a claim to be presented to the customer. >> =20 >> Thanks, >> Jody Kolker >> 319-294-3933 (office) >> 319-329-9805 (mobile) Please contact my direct supervisor Charles = Beadnall (cbeadnall@godaddy.com) with any feedback. >> =20 >> This email message and any attachments hereto is intended for use = only by the addressee(s) named herein and may contain confidential = information. If you have received this email in error, please = immediately notify the sender and permanently delete the original and = any copy of this message and its attachments. >> =20 >> From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, = James >> Sent: Monday, January 05, 2015 3:18 PM >> To: eppext@ietf.org >> Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims = Service" post the Claims Phase >> =20 >> All,=20 >> =20 >> There was an issue raised privately in supporting claims as a Claims = Service post the Claims Phase. According to section 2.4.3 of the RPM = Requirements, =93...releases for Allocation or registration such = reserved domain name at any time following the start date of the Claims = Period, such domain MUST be subject to the Claims Services (as described = in Section 3) for a period of ninety (90) calendar days following the = date Registry Operator releases such domain name for registration=85=94. = This means that support for the Claims Check Form needs to be revised = to indicate whether or not the Claims Create Form is needed for the = domain name and the use of the Claims Create Form should be supported in = phases other than =93claims=94. There are no XML schema changes = required to support this. Please review and provide feedback to the = proposed revised language in the draft below to include in the next = version of the draft that will also include the Implementation Status = section discussed at the IETF-91 EPPEXT meeting.=20 >> =20 >> Change 3.1.1 "Claims Check Form" as follows: >> =20 >> The Claims Check Form defines a new command called the Claims = Check >> Command that is used to determine whether or not there are any >> matching trademarks, in the specified launch phase, for each = domain >> name passed in the command, that requires the use of the "Claims = Create Form"=20 >> on a Domain Create Command. >> =20 >> Instead of returning whether the domain name is available, the = Claims >> Check Command will return whether or not at least one matching >> trademark exists for the domain name, that requires the use of the=20= >> "Claims Create Form" on a Domain Create Command. =20 >> =20 >> Contains the fully qualified name of the queried >> domain name. This element MUST contain an "exists" = attribute >> whose value indicates if a matching trademark exists for = the >> domain name that requires the use of the "Claims Create = Form" on a Domain Create Command. =20 >> A value of "1" (or "true") means that a >> matching trademark does exist and that the "Claims Create = Form" is required on=20 >> a Domain Create Command. A >> value of "0" (or "false") means that a matching trademark >> does not exist or that the "Claims Create Form" is NOT = required on a Domain Create Command. >> =20 >> =20 >> Change 3.3.2 "Claims Create Form" as follows: >> =20 >> SHOULD contain the value of "claims" to indicate the >> claims launch phase. A value other than "claims" MAY be used = to=20 >> pass the claims notice for domain names outside of the claims phase. =20= >> =20 >> =20 >> Based on the above revised language the following may be done: >> =20 >> =95 During claims phase with a claims check command=20 >> =95 If domain has matching trademark =20 >> =95 return exists=3Dtrue=20 >> =95 else =20 >> =95 return exists=3Dfalse >> =95 During post claims phase with a claims check command=20 >> =95 If domain was released post claims phase start and = is within 90 days of release and has matching trademark >> =95 return exists=3Dtrue=20 >> =95 else =20 >> =95 return exists=3Dfalse=20 >> =20 >> =95 During claims phase with a create command =20 >> =95 If domain has matching trademark =20 >> =95 claims notice is required=20 >> =95 else =20 >> =95 claims notice is NOT required >> =95 During post claims phase with a create command =20 >> =95 If domain was released post claims phase start and = is within 90 days of release and has matching trademark return=20 >> =95 claims notice is required=20 >> =95 else =20 >> =95 claims notice is NOT required=20 >> =20 >> =20 >> Thanks, >> =20 >> =97 >> =20 >> JG >>=20 >>=20 >> >>=20 >> James Gould >> Distinguished Engineer >> jgould@Verisign.com >>=20 >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >>=20 >> VerisignInc.com >> =20 >> =93This message (including any attachments) is intended only for the = use of the individual or entity to which it is addressed, and may = contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be = constituted as attorney work product. If you are not the intended = recipient, you are hereby notified that any use, dissemination, = distribution, or copying of this communication is strictly prohibited. = If you have received this message in error, notify sender immediately = and delete this message immediately.=94 >>=20 > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --Apple-Mail=_68FC055A-4737-4BFA-90EF-0DE9885E9BD9 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_4F7E4E68-80AD-44CD-8006-F32101559E0E" --Apple-Mail=_4F7E4E68-80AD-44CD-8006-F32101559E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi James,

The only component that is still open = is what to call that extended claims phase. Perhaps it=92s useful to = suggest a name for that special phase (extended-claims?) to avoid having = 100 different phase names.

I believe the clarification is very useful.

Thanks



Francisco Obispo
CTO - Registry = Operations



2161 San Joaquin Hills = Rd.
Newport Beach, CA, = 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

 

On Jan = 8, 2015, at 9:11 AM, Tran, Trung <Trung.Tran@neustar.biz> wrote:

Thanks Jim for bringing this to the eppext.  This will = definitely help the post claims phase.

With = the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack = is needed in the create domain?  

Trung
From: Jody Kolker <jkolker@godaddy.com>
Date: Thursday, = January 8, 2015 at 11:15 AM
To: "Gould, James" = <JGould@verisign.com>, "eppext@ietf.org" = <eppext@ietf.org>
Subject: Re: [eppext] = draft-ietf-eppext-launchphase Support for a "Claims Service" post the = Claims Phase

Thanks Jim.
 
=46rom a = registrar perspective, this will solve the issue of domains that are = released after the initial 90 day claims period but still require a = claim to be presented to the customer.
 
Thanks,
Jody Kolker
319-294-3933 = (office)
319-329-9805 (mobile) Please contact my direct = supervisor Charles Beadnall (cbeadnall@godaddy.com) with any = feedback.
 
This email message and any = attachments hereto is intended for use only by the addressee(s) named = herein and may contain confidential information. If you have = received this email in error, please immediately notify the sender and = permanently delete the original and any copy of this message = and its attachments.
 
From: EppExt [mailto:eppext-bounces@ietf.org] On = Behalf Of Gould, James
Sent: Monday, January 05, = 2015 3:18 PM
To: eppext@ietf.org
Subject: [eppext] draft-ietf-eppext-launchphase Support = for a "Claims Service" post the Claims Phase
 
All, 
 
There was an = issue raised privately in supporting claims as a Claims Service post the = Claims Phase.   According to section 2.4.3 of the = RPM Requirements, =93...releases for Allocation or registration = such reserved domain name at any time following the start date of the = Claims Period, such domain MUST be subject to the Claims Services = (as described in Section 3) for a period of ninety (90) calendar days = following the date Registry Operator releases such domain name for = registration=85=94.  This means that support for the Claims Check = Form needs to be revised to indicate whether or not the Claims = Create Form is needed for the domain name and the use of the Claims = Create Form should be supported in phases other than =93claims=94. =  There are no XML schema changes required to support this. =  Please review and provide feedback to the proposed revised = language in the draft below to include in the next version of the draft = that will also include the Implementation Status section discussed = at the IETF-91 EPPEXT meeting. 
 
Change 3.1.1 "Claims Check Form" as follows:
 
   The Claims Check Form = defines a new command called the Claims Check
  =  Command that is used to determine whether or not there are any
   matching trademarks, in the specified launch = phase, for each domain
   name passed in the = command, that requires the use of the "Claims Create Form" 
   on a Domain Create Command.
 
   Instead of returning = whether the domain name is available, the Claims
  =  Check Command will return whether or not at least one matching
   trademark exists for the domain name, that = requires the use of the 
   "Claims Create = Form" on a Domain Create Command.  
 
   <launch:name>  Contains the fully = qualified name of the queried
        =    domain name.  This element MUST contain an "exists" = attribute
           whose = value indicates if a matching trademark exists for the
           domain = name that requires the use of the "Claims Create Form" on a Domain = Create Command.  
          =  A value of "1" (or "true") means that a
  =          matching trademark does exist and = that the "Claims Create Form" is required on 
  =          a Domain Create Command.  A
           value of "0" (or = "false") means that a matching trademark
    =        does not exist or that the "Claims = Create Form" is NOT required on a Domain Create Command.
 
 
Change 3.3.2 = "Claims Create Form" as follows:
 
<launch:phase>  SHOULD contain the value of = "claims" to indicate the
       claims = launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims = phase.  
 
 
Based on the above revised language the following may be = done:
 
=95 = During claims phase with a claims check command 
=95 If domain has = matching trademark  
= =95 return exists=3Dtrue 
= =95 else  
= =95 return exists=3Dfalse
=95 = During post claims phase with a claims check command 
=95 If domain was = released post claims phase start and is within 90 days of release and = has matching trademark
= =95 return exists=3Dtrue 
= =95 else  
= =95 return exists=3Dfalse 
 
=95 During claims phase with a = create command  
=95= If domain has matching trademark  
= =95 claims notice is required 
=95 else  
=95 claims notice = is NOT required
=95 = During post claims phase with a create command  
=95 If domain was = released post claims phase start and is within 90 days of release and = has matching trademark return 
= =95 claims notice is required 
=95 else  
=95 claims notice = is NOT required 
 
 
Thanks,
 
=97
 
JG


<image001.png>

James Gould
Distinguished = Engineer
jgould@Verisign.com

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

VerisignInc.com
 
=93This = message (including any attachments) is intended only for the use of the = individual or entity to which it is addressed, and may contain = information that is non-public, proprietary, privileged, confidential = and exempt from disclosure under applicable law or may be constituted as = attorney work product. If you are not the intended recipient, you = are hereby notified that any use, dissemination, distribution, or = copying of this communication is strictly prohibited. If you have = received this message in error, notify sender immediately and = delete this message immediately.=94

<image001.png>_____= __________________________________________
EppExt mailing = list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

= --Apple-Mail=_4F7E4E68-80AD-44CD-8006-F32101559E0E Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mail Attachment.png" Content-Type: image/png; name="Mail Attachment.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAAJsAAABfCAIAAABweiJ5AAAYSWlDQ1BJQ0MgUHJvZmlsZQAAWAmt WWdUFM3S7tkIy7LknHOSnEFyzjkjsOScMyaCSFARBBQBFVQQVDARREwIIooIKmAAJBhIKqggCMjX i+F9zz33/vv2nJl5prq65qmq7p7pWgC4iOTo6HAUPQARkfGx9ib6/K5u7vz4UUAETAAPZAAn2S8u Ws/W1hL8z9/yEEAojc+kKbb+p9p/b2DwD4jzAwCxhc2+/nF+ERBfAwBD8ouOjQcA2wnlQknx0RQ8 DTFzLCQI8ToFB21hHGQPmH1/YeEtHUd7AwBwagBQEcnk2CAASIZQzp/oFwTtkPxhG2Okf0gk7JYM sbZfMBnKOFuhzraIiCgKfguxuO+/7AT9C5PJvn9tkslBf/EvX2BP+GDDkLjocHLK1s3/5ykiPAHG a+snAM/E4FhTe3hlhnGrCIuyoGAixJcifa1tIGaEuD0EevQb9wUnmDpBTNEf94szgLEErBB/8ycb WkDMDQCKkBDmpPcbi5JjIdrSR+mHxJs5/sbOsVH2v+2jQiPDrSnjA9pB7QwOMPuDiwLijBygHHJA hQaGGJtBDHOFOpca7OgCMeSJak0McbaGmARxZ1yYA4UDxc7T1GADinxLJzbBnsJZGMqnA2ONKT5C HTQxIg6iLftoQT/y1rPYoVwpPtjRFMphX7Slf4ChEcTwuWjXgEin33zQwdHx+hQ7FP3U6PCt8Q15 oosCwk0ockGIz8QlOvzpez8+1pEih3FDD4WSzSnjFXJGz0bH21JiQuGzAiyBATAE/CABHr4gCoSC kL75lnl496vFGJBBLAgCAUD6t+RPD5etlkh4dgCp4COIhDpxf/vpb7UGgEQo3/gr/dVXGgRutSZu 9QgD7+ETIjCcGG2MJsYSnnXhoYBRw6j/6cdP94cnzghniDPFGeMk/kiAH2QdDo9YEPJfZBawLQB6 FwvPkX98+Mce9j12ADuJHcSOY18CZ/B2y8pvT71DMmL/MPhr2QqMQ2u/ohIAIxYJZv7oYEQha2WM PkYL8ofcMawYTiCNUYKe6GF0oG/KUPonehTWCX+5/RPLP3H/o0dhzf8vH3/LSZIk5d8sfP94BTP5 JxL/aeWflhDgD7Us/lMTnYO+iu5G30X3oNvRLYAffRvdiu5F36Tg35yNt6IT9Pdp9lsRDYM+hPzR kTsvNyO3/ufur69kKKEwoOQAjv/4gOR4OP6AQVR0SmxIUHA8vx5chQP4zSL9ZLbxK8jJKwJAWdMp OgB8td9aqxHWJ//IAuC6uh3OD+r+f2ShRwCo7wKALe8fmagHABzbALj81C8hNvGXPQzlggUEQAdn BgfgBUJAHPqkAFSAJtAFRsAc2ABH4Aa8YNSDQQRknQR2gnSQDfLBYVACjoOT4DQ4By6CK6AFtIO7 4D54BPrBIHgNx8Y7MAcWwDJYQxAEj9AiTAgHwoeIIFKIAqKGaCNGiCVij7ghPkgQEokkIDuRTCQf KUKOI1VIHXIZuY7cRXqQAeQlMoHMIF+QHyg0iohiRvGgRFGyKDWUHsoC5YjagQpCxaBSUVmoQ6hj qGrUBVQz6i7qEWoQNY6aQy2hAZoGzYoWQEuj1dAGaBu0OzoQHYvejc5Dl6Kr0Q3oNpjrZ+hx9Dx6 FYPDMGH4MdJwfJpinDB+mBjMbswBzHHMOUwzphPzDDOBWcD8xNJiubFSWA2sGdYVG4RNwmZjS7E1 2CZsF5w777DLOByOFSeGU4Vz0w0XikvDHcBV4hpxd3ADuCncEh6P58BL4bXwNngyPh6fjS/DX8Df xj/Fv8OvUNFQ8VEpUBlTuVNFUmVQlVLVU92iekr1gWqNmp5ahFqD2obanzqFuoD6DHUb9RPqd9Rr BAaCGEGL4EgIJaQTjhEaCF2EEcJXGhoaQRp1GjuaEJq9NMdoLtE8oJmgWSUyEiWJBkRPYgLxELGW eIf4kviVlpZWlFaX1p02nvYQbR3tPdox2hUSE0mGZEbyJ+0hlZOaSU9Jn+io6UTo9Oi86FLpSumu 0j2hm6enphelN6An0++mL6e/Tj9Mv8TAxCDPYMMQwXCAoZ6hh2GaEc8oymjE6M+YxXia8R7jFBOa SYjJgMmPKZPpDFMX0ztmHLMYsxlzKHM+80XmPuYFFkYWJRZnlmSWcpabLOOsaFZRVjPWcNYC1ius Q6w/2HjY9NgC2HLZGtiesn1n52LXZQ9gz2NvZB9k/8HBz2HEEcZRyNHCMcqJ4ZTktONM4jzB2cU5 z8XMpcnlx5XHdYXrFTeKW5LbnjuN+zR3L/cSDy+PCU80TxnPPZ55XlZeXd5Q3mLeW7wzfEx82nwh fMV8t/lm+Vn49fjD+Y/xd/IvCHALmAokCFQJ9AmsCYoJOglmCDYKjgoRhNSEAoWKhTqEFoT5hK2E dwqfF34lQi2iJhIsclSkW+S7qJioi+h+0RbRaTF2MTOxVLHzYiPitOI64jHi1eLPJXASahJhEpUS /ZIoSWXJYMlyySdSKCkVqRCpSqmBbdht6tsit1VvG5YmSutJJ0qfl56QYZWxlMmQaZH5JCss6y5b KNst+1NOWS5c7ozca3lGeXP5DPk2+S8Kkgp+CuUKzxVpFY0V9yi2Ki4qSSkFKJ1QeqHMpGylvF+5 Q3lDRVUlVqVBZUZVWNVHtUJ1WI1ZzVbtgNoDday6vvoe9Xb1VQ0VjXiNKxqfNaU1wzTrNae3i20P 2H5m+5SWoBZZq0prXJtf20f7lPa4joAOWadaZ1JXSNdft0b3g56EXqjeBb1P+nL6sfpN+t8NNAx2 GdwxRBuaGOYZ9hkxGjkZHTcaMxY0DjI+b7xgomySZnLHFGtqYVpoOmzGY+ZnVme2YK5qvsu804Jo 4WBx3GLSUtIy1rLNCmVlbnXEasRaxDrSusUG2JjZHLEZtRWzjbG9YYezs7Urt3tvL2+/077bgcnB 26HeYdlR37HA8bWTuFOCU4cznbOnc53zdxdDlyKXcVdZ112uj9w43ULcWt3x7s7uNe5LHkYeJR7v PJU9sz2HdojtSN7R48XpFe5105vOm+x91Qfr4+JT77NOtiFXk5d8zXwrfBf8DPyO+s356/oX+88E aAUUBXwI1AosCpwO0go6EjQTrBNcGjwfYhByPGQx1DT0ZOj3MJuw2rDNcJfwxgiqCJ+I65GMkWGR nVG8UclRA9FS0dnR4zEaMSUxC7EWsTVxSNyOuNZ4Zvjx3JsgnrAvYSJRO7E8cSXJOelqMkNyZHJv imRKbsqHVOPUs2mYNL+0jp0CO9N3TuzS21W1G9ntu7tjj9CerD3v9prsPZdOSA9Lf5whl1GU8S3T JbMtiydrb9bUPpN957NJ2bHZw/s195/MweSE5PTlKuaW5f7M8897mC+XX5q/fsDvwMOD8gePHdw8 FHior0Cl4MRh3OHIw0OFOoXnihiKUoumjlgdaS7mL84r/lbiXdJTqlR68ijhaMLR8WOWx1rLhMsO l60fDz4+WK5f3ljBXZFb8b3Sv/LpCd0TDSd5Tuaf/HEq5NSLKpOq5mrR6tLTuNOJp9+fcT7TfVbt bF0NZ01+zUZtZO34OftznXWqdXX13PUF51HnE87PXPC80H/R8GJrg3RDVSNrY/4lcCnh0uxln8tD VyyudFxVu9pwTeRaRRNTU14z0pzSvNAS3DLe6tY6cN38ekebZlvTDZkbte0C7eU3WW4W3CLcyrq1 eTv19tKd6Dvzd4PuTnV4d7y+53rveaddZ1+XRdeD+8b373Xrdd9+oPWgvUej5/pDtYctj1QeNfcq 9zY9Vn7c1KfS1/xE9Ulrv3p/28D2gVtPdZ7efWb47P5zs+ePBq0HB4achl4Mew6Pv/B/Mf0y/OXi q8RXa6/3jmBH8kbpR0vHuMeq30i8aRxXGb85YTjRO+kw+XrKb2rubdzb9XdZ72nfl37g+1A3rTDd PmM80z/rMftuLnpubT77I8PHik/in6591v3cu+C68G4xdnHzy4GvHF9rvyl961iyXRpbjlhe+563 wrFyblVttfuHy48Pa0nr+PVjGxIbbT8tfo5sRmxuRpNjyVvfAmh4RgUGAvClFgBaNwCY+gEgkH7t ubY04CcyAnUgdkaMUHpoNQw7loCjwstRuVFnEm4TcbRkUgs9gSGc8SGzMksFG2AP4+jjUuE+zDPH p8tfIDAgRBBWF3ETDROLEPeU0JfkkVyUur+tTDpMRkuWVvaNXKP8XgU7RQHFj0rXlfep2Klyq75T a1BP1tDTJGg+216h5a+9TfuLTovuTj19faL+G4NbhvVGlcaFJrtNyWY65uzmixa9lg1WldZVNu22 U/ZYBw5HTid6Z7TzusuaG3Cn9iB50u7A7FjymvTu97lDvupb41fmnxeQEhgU5BisH6IUKhkmEM4R QReJjvwWNRndH3Mj9kzcofg9CdmJTcmYlIDUOzvBLtHdGnvM9nqkJ2QcyizJStuntG8qu2C/bY5I Lk0eyEcdYDgofki7wPqwS6F7kfsR12LnEsdSu6PWxyzKTI7rl2tXqFcqnpA+KXlKrsqiOvP0+Fmz mgu1c3UM9SLn5S9oXjRssGp0ueR9OfhK9NWka7ubMpr3teS05l8vaCu5UdFec/Para7bw3fG7w51 NN4L7GTvfNBVej+pO/DBjh6Xh3aPLHpNHpv2OT6J6T818PIZzXPZQYMhs2GjF2ovRV6RXq2+nh55 MXp37PSbzPGgCadJ6ymrtzbvbN6bf1CfZpsen8mbVZodnzs3n/rR9BPVp7rPJp+nFk4vJn/x+mrz zWopdLljZf+Plg3Dzc3f+ZdHY9AzmHHsFG6BCk2tQgimqSCOkyTpkujvM3IwpTA/Z1Vgy2Af5VTm yubu5+Xkc+UvFGgXHBFaEl4WmRV9LHZaPFZCW5JK8rnUyW2h0srSP2Xuyx6Sc5Hnk/+g0KCYqKSl jCh3qeSp2qgxqQ2pl2l4aPJojsBR4KnNoT2sc1TXQ09Ub01/0OCy4QGjAOPtJgwm703bzUrMEy0C LH2tgq2jbCJsfe1s7DUdJB25nEjOKOdllw+uQ2733Bs8yj3zdqR6hXi7+hiSZX3Z/RC/Wf/BgM7A pqCa4NKQrNCoMLdw3QixSFo4Eiaix2K+xQnEeyeUJd5NepE8lTKfurqTZhfvbvE9/Htxe9+kN2UU ZMZmee1zynbdH5KTmVuZdzG/6UDzwWuHLhdcPFxXeLbo1JHy4pKSgtLcoxnHUsqijgeVh1Tsrbx9 UuLUuWqx00Vnnp1drSWd46wTqpeE40D1onaDYaPVJbfL4Veyr56+dqtpoHmsZbr1axv6Blu71E3N W7q3Ve8I3EXdnezovtfUWdtVfv9w974HqT2xD+Mf5fa297E+2dU/+pTzmc5zx8HAob3DZ188efnt NeOI9KjlWPSbo+M3Jp5Ojk1Nvp17j4XZT58ZmGOYl/uo/En0M93nlYX3i8NfHn69/q1qac+y83ex 78sr7aupPzTXiOuGGzO/8y+DzKEq0V4YCSweu4ibwc9STVIv0hCIIrR6JHe6dPoLDAOMm8wiLEas oWz72E9yXOPs4nrAfZ/nBm8VXzK/Pv8PgTOCFoJzQjnCYsIdIl4iq6LFYnJiD8WDJPAStZKmkh+k sreJb+uS9pMBMpWy22VfyCXAr5tGBUuFacVMJV6lVmV75XmVfap8qi3wq2VafY8Gq8Z5TT3Np9v9 tn/SStPGa5frKOkM6abq8eq16tvovzQINtg0rDayNaY2vmey01TJdNas2tzTgt1iyLLEysGazrrH JtNW0/abXaN9mIOYw1vHKqcdzhzOz10KXE1dN92a3MM9hD1GPUt3WO9Y9ir2FvG+5qPn84qc7Cvo +wKuI8EBJoGqQerBZiHk0IgwcrhOBH3ESOTZqIho5ej1mHuxeXG28SzxrxNOJvoniSa9Tz6RYpQy khqexpz2bOeNXbd2d+65t/d6el1GaWZmVtQ+j2yj/ZI52JznuWV57vnC+WsHxg8+PnS94NTh3YUe RRpHOI+sFg+VXCk9evTgsaKyquNXy+9XvKicPbF2iraKv1rxtOkZz7NRNbtrc88dqNtbTz6veoF0 4cvFjw2rl4iXea8oXLW9ltZ0rXmlVf16dFvZjUvtrTdv3Oq5vXTXpON6p0PXUndpj+LD570H+3z6 zZ7qPdcfCn9JGpmb7Jtd+rZKyf+v2hvlnYBTAeBIOtyhZgPgpANAYScAooNw30kAwJYWAEd1gBIN BChiL0A0Jv6+PxCABjhAAxhg/YYPiAE5oAHrLjbAHdZC4uDusgCcAA3gFngCJsA3uHPkRuQRE8Qb SUIKkQvIA+Q9CocSR1mi4lCVcJ+3Cfd1iejr6J8YE8wRzCRWEZuDfYPTwJXh1uAO6yGVKlUtNRd1 IYGGkEtDoDlM5CTW0irRtpO0SG10anQ36E3pXzPEM9IzXmQyZBpgdmQeYLFhecrqzbrCVsauxT7G sYuTi7ONy4ubmrudJ5FXifcr3xX+WAFlgXXBbqFS4WCR7aIk0XGxq+I5Er6SelKi20jb1qQ/ybyV HZRrkk9TkFcYU8xRUlb6rNyqUqSaouavbqkhp8m2naQlo12uK6V3UL/H4LMRlTGLCYcpt5mwuZKF tWWM1THrTpsvdkL2Lg6HHLudMS6GrtluvR6snr476r3e+uDIDL443yW/d/4jAbNBdMEWISWhH8K3 RxRHfoo2j6mPI8bHJLxKMk5uTZVOq9nFv7t8L2t6YSYhK33f0v7QnLm8/AMRh5oKGY5wFn8srTvm fZy1vL/y4EmTU0vVBWeYz+bULJ8Lq/ty/vBFo0aGS4tX3l+bbp5r/dA21b54m+2uwT2vLp9uhx6d R7KPJZ6oDEQ+WxnGvKIeOfmGaeLWO9L0zjm9j42f176ofDNeJnw/uPJwdfrHu7WX69c2Dv/03ZTb Wj8o+cfD+h4jrDkIAEmgCLSAKawz+MAKQxrIBWWgDlyHdYRRsIBgEU5Ebiv7KUgxcgnpQz6i6FCK KHdUJuoK6h2aD+2NPoOex6hgsjCDWAlsOnYE5r4cD/DB+EEqI6pWalnqeoIE4QKNEs1toi1xijaZ RE0qoROguwT3r68ZkhhZGVuYnJk+Mu9iIbAcY5VmfcgWxc7GfocjhJOZ8w5XFLcw9whPGa8rHzvf S/5KAX9BOSEg9Fz4vEiWqKeYEtzLzUr0Sl6Fb7EC6UyZnbLxcn7yugpEhT7FPCULZTblRZWXqt1q zerVGgc0U7cnauVqt+p811PU9zfIN6wxaja+YXLD9KZZj/mEJcpK0trZZp9ti928g7Cjt1Ol85ir oFuoe7MnfoeL13HvLp8BcodvnV+Of0iAfaBpkFtwRsidMNpw34j2KM7o1JjROP34ukS6pOjkR6kC aYk7+3cr7zmTzpVRnEXYl5Y9n0POncxPPShXgDo8WnS5OLFU6eiXssvlCZUaJ36cqqlWOF155kON WG3wuUv1bOcrLmo1fLxUdkX9al8TuXmttbrNrh3crLtteWex42Sn732NBwIPMY8eP058guvPe0p8 Vj3oPWz1Mvx17eiHcb5J27fp72/NsM0d/iS68Phr8fKBVbM1hfUTG29/Lv7OPwZQw5ouO8y+FKw1 GQBbWGGKALvgzK8C18ADMAbnPRERRXSRHUgaUo7cRCZQ1DDrZFQJqh/Ngg5A38RwY/ZiZrFu2Mc4 A9xNWE+5S2VJNUodR6AjXKJxJqKJLbQxJHnSCl0XfRlDAqMbkxmzOYsdqzmbKrsEhzKnN1cKdzyP L68jnzW/lYCVoKWQlbC9iLdonNhB8XqJB5Iz22ilVWUCZY/LDSlwKvorNSqvqdqqPdbI3e6mjdU5 rLuub2GQCTPYYtxucsu0z2zNwsKy2VrG5oKdjH2zo4HTkEuEG8H9gqezF4MPja+3v0fA2yDN4PyQ 92H24b2RVlFPYzxip+PTEnmTxlLup93ZVbnHae+PjKos52y+/Qu5N/MPHAwsMCnkKHpUHFiyfDSz jOF4dYVK5eOTgVVIdcUZtbODtQl1XPUPLuxpMLkke8X42p7m6taCNrd2tpvDt8vvut3Dd569r9R9 o8fo4XBvcp9sP3pg4dn04MBw4UuxV5Wvf44ajeW9eTRBN+k0dertzHv5D2HTp2YezM7OYz9yf5L7 bLjgskj+4v/V9pvgt6Wlg8vcy/Xf1b8f/7664rLSvMq6GrvavLr2Q/dH1o+eNdKaw9rRtf51qnXd 9eT1y+szGwIbbhtFGw83Nn7K//T/efTno58/N+U3AzaPbfZS8h8XqKhAeXsAhKgPy49jm5tfRQHA FwGwUbi5uVa9ublxGm42RgC4E/7r/xyKMuV/oooFCnrUujJAuf7793+Hw8XBvpCpSAAAAZxpVFh0 WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8i IHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2Jl LmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTU1PC9leGlm OlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjk1PC9leGlm OlBpeGVsWURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4K PC94OnhtcG1ldGE+CgOpdOAAABtsSURBVHgB7V0JWFNXFn7ZSCAkYd9BZBGQRVBQERGtO6K4KxWx rVO7fO2001o72GlnprZVq9NlbK17XWrHqqOouLTivtcNUBQUEGVT2SGEkHX+x4MQkxABg1rmvc8v 3nfvuefee849633vwVCr1QR9dSMKMLvRWuilkBSgOdrd9gHNUZqj3Y0C3W09tIx2N46yu9uCnvV6 6uRSqVLOYDD0J4KwwozJFpmZ6zcZr5GplLWyBhJGH2tTpCLi8DisZlbSHDVOzA633q65ny+u1NBX u79CpXTgCQY7+ujzRRtMv1wrk5x+mA9+6u8TpZpgE+oB9p6O5iKqI4OOR/Up+CQ1oKeRAB+8NMCW x40HhEaxkjg1u4Tm6OPI+Udrp7WuiTl28v6tm7UPDGpduVLpbiGKdQsyZA+NTaNEUn2oKAuSSDA1 otgMD9llq9TDXQPc+DZUFc1RY6TsRBubweQwmWYMln5fcITFQHChyxV9SJ0a6FQOCwi1lWsziJJQ c5hqhhZOWuvqUO8Pf0vLqIlZWCdvaFC0Gb1AG1ubWXR0SEQvNTKJkV5CjjmXjl6MEOhJmpZn/vZp 4VVrjgG2VSka59h7/jgoUVtJtmeszKrCMWf+U8di8PXy8FWEylup3jRwWpSDD4WK1rrtIWkHYArE ZWVSMZNhQPmpCJWIze0lcuoAuiZQZC1u1T0gi2q9HB9DxVQRXiIHEac5cUFztKPkfd7hDWyl533K z/f8DtxNz64sJNhmSArozlSpcBDYzfIZ0FGtWyAu35X3O0H6yboXxmCpVRN69vMSOlJtNEd1afSE 9yfv5yzNv0Rw+YQeQwm5dLKzz4veA1oTPO0brLShNvnWWRk4qs9UtcpGrQpz9NZwlNa67SPqHweK llET80quVskJFRn0610qhpqtZpgxDSQf9GAfqUBiSEqg9yOV1A2ZXFARXCZTk9mlOWqATJ2uAs3/ dGzt5punCHNLA1pX1hDs1js9bgHI36Eh0u7njEpdTmYB9VNRaiWhUu0f806sRwiFk+Zoh2j7GGAw apx7iKsZnzDjItTQgVYp5O5WTiRjOnj14FsnB49o4qheX7WaqVJ7Cmw1KGk7qiFFNynQMmpiRqbe vXqt4h6TjF50MauUcheBfZJvpJ6g6ULq3OeLK7bnnkclQ8/XVatVMMuTvCJ8hA5UL5qjOtR70tu/ ZhzIunyA4FsZiEcb6wmvvrN9Bmq8mHYOll5VlHzgGzJ00feqVLCjSpeZn2s4SmvddlK1vWB36pAF rGMwDYmKWingmPuJnDoqo8j+Z9c+bJqBga5MlcpX5CBsOQCgOdpeVrUTTqVWy8n0qwHSqwk1G4LW cc8I+luhVrV9sKrGoaxmPENbqZ1zp8EMUWDGkVU7bx4neEJ9X5eQSazcgirikw3y2xCy5rrDJTdH 713SttZV7Rv3XpxHHwqa5qgRSnamyZzNIdg8gmMgekHgaI/Wjl8sJpPg8MjoxYAdVRFqZdOjEc14 aa3bcQI/3z1oGTUxf/bcvZJZfo+F6EXvUioVbgK7l8joRWP19IAMVeDs5T+551UQUj0bjAQhS62e 4h3hS5+9GCKdCeoSLvy34fxuQmBjIHqRiole/ZN8IlkdYyhxtqxg4fZ/kna05dGT1okqFYheHF7+ huZoK01MW/pX8Ijf7DzMSbOnm2KQKuQhVi4GDjkfN4M+1i5Tx7zOIphIyOvAKtVqjkrV19ZDU0/b UQ0pTFZAnNEW28BkXZ60b9i2OurX03a0fRRtN9Qn6fsXnfmZ4FkaYB2Z31Hti/1LnFtwu/GRgPFH V+/NPknwBAYiIoUC5zy34hfSWrdDJO0AsDXXgnhYQEYv+idfQCOp/SLjUKxrUPvzDOkV9/amHyLq Kgg2IiK9C099uvrZt7zGhGZa6+rR6MkqHjTUHivNVjOYLD2/FNSWqxRCDne8e3M2oD1D3ZNUnSzJ YbM5BjW5XKlwNBeOcAnQoKK1roYUpimAvmoG405lMctQkgFxS75Snn4/b27gcBeL5vcDjQycWphx rjRHaDAD1dQNT3v3t++pjYHmqDY1TFPeczfjl4MrCT7MnqELzoyi8ZNbpy+Nervfo8zQhsZz9Cuy 0uYfXEGIK4m2Mk0yGWFpNcoj2FerJ611tYhhomJmVVGfXYsIpYxgtpHzg78rqSXsPFKiZsW35GO1 B6+Xy5Kv7Fpx5QDpGpvxDIS2gCaR1I3oHX14+JvafWmOalPDZOWcmtIHUjEHxg8Safhi4FUWDoPp JbTT8ZLQo1YmvVtfKeDwuCyOYXYSBN5KUygVwdauOi/S0FrXML2fsJbLMov57XsCSSKkGggEqAYv BoEzMrnMQEyCjHyzZ9tWXya08UthY3+Mmq2DmuaoDkFMc+tpafu6z4BV+/9NmJmR2TsTX2qisZGw d3/TP0YfMc1RfZqYpmZ5/ylVjXXXqh84wKfVf2Oi04MwEAKpHogrPwmNjdBK/mnw0XZUQ4ouKay5 ferS/TyhhZBpGqYyVCp5jVz2btCIQJGzwRnTMmqQLCar9BM4vnZ4DVGSizDjSZHCuVXIiUbJ8EHT 3SzaxEbL6JPS+bH9M6tL+xz8isi9TPDMCYNPlD0WBQAg4vJGdH8jJvH7gQlgblsXzdG2KGPK+ofS uu+zjx0vLyxXyFx4fAQtBvzbNgbEQbdYIauUSfvyrSd7hEz27NcGYHM1zVHj9DFl6+/l+ZPObS8p zMJBJxnVQF4N5H61RkRso5ARMilOct4LGfFZvwnmTAOPRmh1IIs0R3UI0rW3yONvuX32g2uHiZJb hLSezPuAr4g+8Y/SpNCuOHRrejKBrBTZD/UOXxgydqRr73bOjOZoOwllSjA8eHCiNDul6Pqukuzi qlJCUkPaSBX5IBHJYK45HmqJceg5yaX3BI+QngL7Do1Nc7RD5DI9MKS2QlZf09hAffFTyOaKuBb2 PIGQTDZ15qI52hmqPc99TJ6gep4X+38xN5qj3Y3NNEdpjnY3CnS39dAySnO0u1Ggu62HllGao92N At1tPbSM0hw1KQWKi4quXrkilUpNitUEyJRKZWZGRn5+vglwPV0Uzc8wlJaUrF2zBpRls9kymfzF xFkhIc1fJdOZT1FR0drVa5RyOZPNAuTspNmBQfjjCJ259qakfJL8UUVFRdSQ6K/+/a2Li0tnsHRB n5qamuQPFqTu22duYbEg+a+vzJ2r/ypuFwxrIpR4SRhXRnq6s529pRnXRiDkMlk7tm+n6vV/L168 aC+0EnB5gOQx2Cm7dunDtKemsrJyYL9wkQXfw9kFIy75fHF7ej0dmE3rN1hwzNwcnbDGXj288vPy OzFuVVUVNFBJSUlxcbFEIukEhs51aZZRFotlZW0NATUzM+Nyufhta8OwWWwrG+vGxkYOhwNITtuQ bWGg6uUyWV1dnYWFBY/Hw+hVlRXG4Z9mK5iBp0AwNwwqkUqk0qa/WdbBGXz15bIdO3YIBYJGWeOy r78eOXJkBxF0EvyZeUZ29vYJsxOxeUtKS3p6eU1LmNnJFXRBt/GTJob2DSsuKamurp4ydSqm14lB YE3uFhQUFhbeu3u3QWLsL0F0ArmRLs/sWUC8gf7R3/4WHh6el5c3evRobx8fI7N8yk1eXl47du/e vy/V1s42fuJEqJBOTAC6B1Jubm4OGwxl1gkMnetiMo7W1Yllssamr4CoRVZWoALe37iZlXX7di60 lo21dUhoqKNj87fUqbk2NDQMiYkZOmyYQqGQy+VQ46iH1GJH45OG+IahpUBA0eJG1o38vLzomCEi 0SNv6N26dev2rVticT0o5+3jHdC7t3EXpvDevevXr9fW1AqFwpDQPq6urhgRggjPFs+EMJhMkVDE ZDFxayWySpqTBEsG+0KpXw19xWLxjawsWEfMWWBp6enl5evrC4NFAWAt4ro6TANuJjUZ/NZUV6MX UAkEAlg04K+tqSHNJEGgI7Wo6qqq8+fPu7q4BoUEl5eXs1kslUrFYrOtrAw8yIkmwFMjAo2NrW3r wkm8avX1a9cCfHu5Ozl7e/SAi7QnJYWq1/+9euWqr2dPuDMU5P7UVArmg/fnB/sH9O/bL3pg5L27 936/cGHm1Gm9enoBm4ONrYu9Q9/g4DWrVqnwlbWW658ffxLo6x8ZHhHeJ/TkyZNU9Xcrvgvs5YfK kIDeR46kQXHNe2Wup4u7l7sH+NfSVZ2WljZz+owAH19gdrK1wygYa2r8xF8PHtLAaBfgoMx/913M EPCOVrYutvahgUFfLlkKB23unDl9/HtjDqOGvQBPHr1yb9+OiRocERaGOWB0mUxGoQKTVv/ww9Co wT3d3J3s7B1tbF3tHPx9fMaPjV2/di1IDLCc7Oxhg6PRN8jPH3P26eEJQvUL6RM1YAB+Tx4/QeEf CpjQsGB//7ffeBP4161dNyiiv6UFf8kXXyjkiskT4kODguE5As+5M2ep0bV/N/24EWuJ6j8gyM/v 3bf+DAZrWk0mo+UPH9zJz+dbWmL7f/ftt3tT9paWFJvzLbgcLpvNwse3S4pKFvzlfT7fEqERtbnK y8sgeSJrkbxRLqmvpyqrqypRCTdNrVTt37MP0SouaDA7u9Z3uL5a/q8vlyyBXEOnQVCUcgVCqfr6 +uNHj2FnfLgw+b358yls1O+d/DuvzJlz6fffgRao1Fw1esELXfrZFzevZeXm3S4qKQakWFwHZYEC SHy34A5EHyzs4elJveMA4Uv+8MN1P6zhC/gwGY2IoVVqGZMhL5OfLz934vjxXTt2bvp5K0S8oKCg tpZUA5A/EBrSU1ZWBpwyqUwiIZfZhL8AjiFw5uXmLnjv/S2bNwOYgzf9WXA9WYHBQQdSU+FqwBin pOweOCiSWgj1i1lt37btzp07GAID9R+EP2VAPXZGtpuMo/CRzXnm0CrAvmnjRowqsrbi8/kgtFhS j3qBSKhUqjZuWD9x8iRKj8GxpiwNGwxpsVXQvYgC0RFU27ljB5Qw1JRU0gA81Hp+WLny04//jn3A 43IVMkVoWKiLi1tZRfmNa9cwNHp99vdP7e0dZs9JouCh6z5OTr588aJzU7wLOuIBLZFQCLS11bV7 9qZYW1tDa0HV83ikzUMvIMFewb5HgVT7TZW7d+36cc06Owc7MAmtY+PGYZPdv3//euY1KHPwBhoS yykreyiXy+SNMsgNNQHgRCv2UKO8UamCom3Gj0psLyieyxcvYSCoYhAK6wXA9Bkztm39GTO3sbE5 cuQINoS9fevzYwg1r2VmOjg4wGyF9e07dmwsNRD1azKOUugwe0wdn6mbOWtWQsJMEBGzWf39yiOH j2Br83jcosIiKFIYPO1JGCyDcGCks7PzyFGjQsJC+RZ8pCBycnIQFVgKLTEQaP350iXj4sZZWVnD Sp07ew6cg9pE8PXNsuXDhg93cyPNJAT38OHDtnZ2KGNH9wsPf/X11wICAiQNDYcPHtq8eXNNZZW5 Jd/gHKhKZtPLZYf2H8DGQw3GXb1+XfSQIVQrvNld23ds/PHHhR//DZzGZlq8bBkYuGd3CkwPakCQ xDlzQkKCG6SNQU3ZGJKrLZdM2gh2Rg+Jjo6JAf96BwaiJTAwaFBU1P69+xAo3rtTcOzI0ekzZ7T0 IFL37MW+xH4Cy8eOi9UxtCblKBNPKKowzF8WfDB/wQfUDHr5+fn4+kwYOw5ajnI6AKCZXFsFMAxC GTlk8BeLF1OLpCC3bNoErwHsgffxj0WLZiUmUvWWlpYjR40E+WYnJEDKoZEO7N8/77V5aE1LOwya khJZW9u3b9+NWzbbOzR/LjosLCxy8OA35s2rq61tayZkfZNKw6ahtCi+vAm1qYF3d3d/5/33psyY TuW8bG1tE2eT73TeuJ518sQJSCFGHz1m9AvDh2u6aApo4vEtFn3y8YuzZgG5ph4fV504efLBAwew rUFSaOCp06eB8QCorKg4evQoVoo52NnYTZw0WdOLKhiOR419uK5VY+ugwi0DJg2aBx6/dpuDg6OP ry+eXyQhyMvwoJou+FgXVBAU1+ykJG121tdLLl74naSRTAbp7xferwjRXsuFokcPDx8fH5AJwnT2 1CkgxO7JuXETxAJC3L7x1lsadlLDDYwc2KNHD+ObDGQFMBxjLAE7o6FR+urLr8SPi/vr/A9+2rw5 Iz0DJsbNzY2iOIUWv5gGlkrdQj1q6rUL2LXItibNmaPNTgpg2PAX/Pz8AAB6njt3Fg4XVX/ixAk4 buAoxHRwTHRA79avpFAAzfuCnHTTvKlazVSo20d/we5WrlKrbQVo+syZzgKwy8hgprVTK7iREuag brI6GpgHpSWwW1g8pBBm708vvUS5eM0AeHqZyawX12O1mBUy1eCitEGK4ARdsKNhL6EwNNioAqYK MKPrxYvYJEcTEhNTdu+GhgAerAga9fSpUxgR7ol/QMCMhARYbuN4dIbGLfYuqIK5YaPotCKkiR0/ /svFi6F+yu6X/fbrr5SpOrAvFRPGAkGESdOm6PTCbTNHsWbNFkOH6urmWEe/g1QigZtHAeOXa2Yg dtZlM/lmlbbt0MdquAaE025AOg32iYFvBTGZkIAb128qVQrt7QVgGDnsHjIVVVIibWjA3oNfT36h T6VGPYv1GPWgPZxOOaJ/xMo1qxf9/R+w5VgOkqXw9oAR5Lp4/sKpkycz069+vnQp6Ul15AIqXAZ7 xI0fv2H1WplcZsYzO7j/wNvvvAObffr0abiNWCAOSKKjm225dvdmjsJRhoFFPhO7TKVQwtFPTErS htOU0VRfJ7a2tYGrBmlwcnbSNHV1AZEPVG5NbQ2Ghi569c3XzNhsiKn2uNQWUEAi7WzJbcpi8S0s 8ElwrhkPwvrw4UPof214CAe40hZNtSFRHjN2bHhEBFyt0ydOgK/wwiCy6Av/BTts3eq1AwdFweDp 9Or0LdyoyCGkfwR5zbp+PT09PePq1Yel923t7cS1dePGx+nkW6iBWjhqZ+fbyzc7Oxv8t7Dkp+5L hWUe+sILOrPJy8vfuGEjz4L08uGI+gX4uXt46MB03a2jk7Orm1txYRGHY4ZNmjg7qW+/vsaHg8JE QHnp0iX8cV5QYevmLfAhtbsg4IOvgfBJu9JIGR4meIZ/UJWw4ulX03H6hGAUognjfTQtTZ+joBX2 lhGcbTYxiClTp8HHbnIsFFs2bS4pLESMCKvv4OQ44VFnRYOkVQuNiR0HLYcdx+XxYF3eefvtnzZv KS8rx+4j9XBVFVwvpFeKigshH+gPS/bCyJEGt4kGu2kLCEtiYmKwHg6bLRHXf7boUxxk6gyB6B6X phJOY1R0NBalVKsQECOm/GThwuKiYvgyyMOBE6+9Og+ulYUluSLjF0R84YIPoV0pMAi3l7f35KlT cLILImBWkPUaBLstFyX3YCc0CrKALdUd+39IzBD4PohTLS0Fe3fvvnzxMswqfCJ4zvABDeJq3Tvj 4yds27oVnrGTkxO6VZRXIMWz8rvvPDw8MFeYJWQ3MDk4AphlVUWlVy/fl195xSDSrqucOevFn7du hTmBe3Lm5KmkhBfnvj4vODgE53+Y4flz59euWuXm7r5t5w4YOWoa4+Li1vzww63sHBs7Wyjt1StX QQNhUQjmsSLIKKLAx0wYX6lRqxE4fbV8+Y4d2+MnTRo9egzSOrBTkO+ft/yEuAgMBst79HhEY6EX TD5cGOQIGxqkFRXlMxMSXJqSyY8ZsaUZQ8TGxWVmZFL7A195BQuwivjJk1pAdP9v5SgkDwH7S7Nn 52TnIKjCLUQW2YDcnFtwUzEtWE3gQiXMLXbl0uXLnqbKpSYOrfvZksWvvvwyyIe9deHCBWhUZE8w PdQgSYsCHH3kCBd9/jnVxc7e7h+fLZo7ew6YBwIJrURIekB1Y1EIkJBwkDU2wiLqEkbrHjixh75Z /jWyHEgHbVy/YfvWbc6uzjiQgAsJiadiCeyMGTNbzwS9vb0RZQENKImThvfffReWwtPTc/LUqR3y +sdPmLBh7TpoTcofBhKkyQZHR2tN8JFiq9ZFNYK/rb/8MiE+HjYS60dMDXGE1cSFvQZcIBkUXUT/ /lt/2YZUjjYmRE5YHshaU1WNb2FpN6FMtkL1kK010OFUa0O9pFLcVFtdLcd3Ypsu7OVKcS0gq2qq YauoSu3fsbGx6zdtQhBZUVaO3C+wgT138vJJt05NRgJQU35+/tpdMNX1WzYFBgZCmLAErA5KGCsa N3HCytWrnZydqXBL42IBJ5ZJzqGqCkRQKpTY4skff9TT24uiiVQmxSHg5UuX8HgDrBJohe21dPny PqGhmnEhRohqoDnILmoywwVPPe233wAAqWjGX0OeyWi6GCwgaEF+SiLGeRR5Ybi4+HjK8BmEb5VR qhkHQ5u2/nQkLe3XQ79mZV0ve/AAIR2a8KwCVtXL33/osKHwqvUxRkZGQjNAiKGidfQY5gFjhi4c eJxmXChMaqyIiIja2hokcaFJkO2jKoOCgxKmz4CD1tBA7miqUud39JgxIX36IFt9/Pjxwrt3MUMM IbAU9vTuGRkVNWXaFGdnF50uYOrAyEiczNy4fr2mrlYgEA4YOGDU6NEQo/IHDyl3F7+40FEoEk2c OAlRmkIm7x0UhFAdk//TvFdj48bt27P3zJkz+bm5yAmr1EqIr4OjY3j/iBcTE7FjtAf16NFjzYb1 Xy//V2ZmRpPt5yBjNWL0aAo/kjASaUMT/kDsLe2O+mUEu0iBYZ9hv7o4OYP++jCaGmPvj0Ioy8vK sH8RL3F5XPDpafpBmikaKSiUSjzGg3MbEAVsgAfQFnBpaalm02jDwNNJnJkARkKLQML+uydFY4C1 wXTKiIIgwgqFEmRxdHDkG00L4xkGcX09zhVgpLADdFC15/a/O3e+Ne8NJMahYBLnJH27YgV2cJsd IVjd/oIZCw8NW7Z0KTao9mIzMjJGxAzF2SpOfIXmFh8lJ2u3PtsyJLJJlnBYmzsseggmiUNZHO4e STtifGLGZLTNXfCHaoAEv/na69jm0Jw4cgkLD3d2doLWuVdQcOzY0apK0suDdReIBLtT9+lozme4 UBjgP7/1FjyDgjt3oGBghuA3RA6O2rV3j3FB17Wjz3ANXTR0UVExcrA44MNzi0j0ZGVlUQNBccHq 4yp/WM7jm8OFfn7YiRniCOLU8ROQVGxETBJuGnwQHPIYZyc6PsYmdxGVnyZaROL/2blj8rSpbDMO PAsqi0I5yUhTgGTRQ4ds3roVh8xPc1aPHQsWobyqEuno+rp6mE8HB/tvVqwYMWLEYzt2f62rIcGV y5fxkFReXi7iK5giBKaePXsGBwcPGDiwk1k6DeouKMCN37l9O04nhVZW/v5+eL6unQ+Z/h9xtAvI /jyi7P5a93mkelfOieZoV1L3WeCmOfosqN6VY/4PV2iSp+CpbccAAAAASUVORK5CYII= --Apple-Mail=_4F7E4E68-80AD-44CD-8006-F32101559E0E-- --Apple-Mail=_68FC055A-4737-4BFA-90EF-0DE9885E9BD9-- From nobody Thu Jan 8 11:15:59 2015 Return-Path: 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 BF8811A8FD7 for ; Thu, 8 Jan 2015 11:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 YhJ1a8pyWLKE for ; Thu, 8 Jan 2015 11:15:54 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FC21A8FD5 for ; Thu, 8 Jan 2015 11:15:52 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVK7XaJN/K5RfkEJ2jkplMP/oi+T/jbir@postini.com; Thu, 08 Jan 2015 11:15:53 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t08JFp4F017948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 14:15:51 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 8 Jan 2015 14:15:51 -0500 From: "Gould, James" To: "Tran, Trung" Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy27AwA Date: Thu, 8 Jan 2015 19:15:50 +0000 Message-ID: <767798B5-1F73-4164-A490-54ABC79C5FBE@verisign.com> References: In-Reply-To: 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_767798B51F734164A49054ABC79C5FBEverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Jody Kolker , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 19:15:58 -0000 --_004_767798B51F734164A49054ABC79C5FBEverisigncom_ Content-Type: multipart/alternative; boundary="_000_767798B51F734164A49054ABC79C5FBEverisigncom_" --_000_767798B51F734164A49054ABC79C5FBEverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Trung, If the desire is to determine whether there is a trademark against the name= , the client could pass =93claims=94 even though =93claims=94 may be a past= phase, assuming that the server supports it. Do you know why a client wou= ld want to know this if a claims notice is not required for the active phas= e? Thanks, =97 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 On Jan 8, 2015, at 12:11 PM, Tran, Trung > wrote: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? Trung From: Jody Kolker > Date: Thursday, January 8, 2015 at 11:15 AM To: "Gould, James" >, "eppe= xt@ietf.org" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Thanks Jim. >From a registrar perspective, this will solve the issue of domains that are= released after the initial 90 day claims period but still require a claim = to be presented to the customer. Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Monday, January 05, 2015 3:18 PM To: eppext@ietf.org Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Servi= ce" post the Claims Phase All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, =93...releases for Allocation or registration such reserved domain name= at any time following the start date of the Claims Period, such domain MUS= T be subject to the Claims Services (as described in Section 3) for a perio= d of ninety (90) calendar days following the date Registry Operator release= s such domain name for registration=85=94. This means that support for the= Claims Check Form needs to be revised to indicate whether or not the Claim= s Create Form is needed for the domain name and the use of the Claims Creat= e Form should be supported in phases other than =93claims=94. There are no= XML schema changes required to support this. Please review and provide fe= edback to the proposed revised language in the draft below to include in th= e next version of the draft that will also include the Implementation Statu= s section discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 1. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_767798B51F734164A49054ABC79C5FBEverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Trung,

If the desire is to determine whether there is a trademark against the= name, the client could pass =93claims=94 even though =93claims=94 may be a= past phase, assuming that the server supports it.  Do you know why a = client would want to know this if a claims notice is not required for the active phase?  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 8, 2015, at 12:11 PM, Tran, Trung <Trung.Tran@neustar.biz> wrote:

Thanks Jim for bringing this to the eppext.  This will definitely= help the post claims phase.

With the wording changes, is there still a way to determine if there= =92s a trademark against the name regardless on whether or not the claims a= ck is needed in the create domain?  

Trung
From: Jody Kolker <jkolker@godaddy.com= >
Date: Thursday, January 8, 2015 at 11:15 AM
To: "Gould, James" <JGould@v= erisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Suppor= t for a "Claims Service" post the Claims Phase

Thanks Jim.
 
From a registrar perspective, this will solve the issue of= domains that are released after the initial 90 day claims period but still= require a claim to be presented to the customer.
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct superv= isor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended = for use only by the addressee(s) named herein and may contain confidential = information. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.<= /o:p>
 
From:=  EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, Jam= es
Sent: Monday, Janu= ary 05, 2015 3:18 PM
To: e= ppext@ietf.org
Subject: [eppext] = draft-ietf-eppext-launchphase Support for a "Claims Service" post= the Claims Phase
 
All,
 
There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase.   According to section 2.4.3 of the RPM Requi= rements, =93...releases for Allocation or registration such reserved domain= name at any time following the start date of the Claims Period, such domain MUST be subject to the Claims Services (= as described in Section 3) for a period of ninety (90) calendar days follow= ing the date Registry Operator releases such domain name for registration= =85=94.  This means that support for the Claims Check Form needs to be revised to indicate whether or not the Claim= s Create Form is needed for the domain name and the use of the Claims Creat= e Form should be supported in phases other than =93claims=94.  There a= re no XML schema changes required to support this.  Please review and provide feedback to the proposed revised lan= guage in the draft below to include in the next version of the draft that w= ill also include the Implementation Status section discussed at the IETF-91= EPPEXT meeting. 
 
Change 3.= 1.1 "Claims Check Form" as follows:
&nbs= p;
   The Claims Check Form defines =
a new command called the Claims Check
   Command that is used to determ=
ine whether or not there are any
   matching trademarks, in the sp=
ecified launch phase, for each domain
   name passed in the command,=
 that requires the use of the "Claims Create Form" =

   on a Domain Create Command<=
/b>.
&nbs= p;
   Instead of returning whether t=
he domain name is available, the Claims
   Check Command will return whet=
her or not at least one matching
   trademark exists for the domai=
n name, that requires the use of the 
   "Claims Create Form&qu=
ot; on a Domain Create Command. 
&nbs= p;
   <launch:name>  Cont=
ains the fully qualified name of the queried
       &=
nbsp;   domain name.  This element MUST contain an "exi=
sts" attribute
       &=
nbsp;   whose value indicates if a matching trademark exists for =
the
       &=
nbsp;   domain name that requires the use of the "Claims =
Create Form" on a Domain Create Command.  
       &=
nbsp;   A value of "1" (or "true") means that=
 a
       &=
nbsp;   matching trademark does exist and that the "Claim=
s Create Form" is required on 
       &=
nbsp;   a Domain Create Command.  A
       &=
nbsp;   value of "0" (or "false") means that =
a matching trademark
       &=
nbsp;   does not exist or that the "Claims Create Form&qu=
ot; is NOT required on a Domain Create Command.
&nbs= p;
&nbs= p;
Change 3.= 3.2 "Claims Create Form" as follows:
&nbs= p;
<launch:phase>  SHOULD co=
ntain the value of "claims" to indicate the
       claims=
 launch phase.  A value other than "claims" MAY be used t=
o 
pass the claims notice for domain names =
outside of the claims phase. 
&nbs= p;
 
Based on the above revised language the following may be done:
 
  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse
  1. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    1. else 
      1. claims notice is NOT required
  1. During post claims phase with a create command 
      1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
        1. claims notice is required 
      1. else 
        1. claims notice is NOT required 
 
 
Thanks,
 
=97=
&nbs= p;

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Ver= isignInc.com
 
=93This message (including any attachments) is= intended only for the use of the individual or entity to which it is addre= ssed, and may contain information that is non-public, proprietary, privileg= ed, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
<image001.png>

--_000_767798B51F734164A49054ABC79C5FBEverisigncom_-- --_004_767798B51F734164A49054ABC79C5FBEverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 08 Jan 2015 19:15:50 GMT"; modification-date="Thu, 08 Jan 2015 19:15:50 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_767798B51F734164A49054ABC79C5FBEverisigncom_-- From nobody Thu Jan 8 11:35:28 2015 Return-Path: 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 0A5B61A9081 for ; Thu, 8 Jan 2015 11:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 2-ASdgcDGRPe for ; Thu, 8 Jan 2015 11:35:23 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6600D1A9087 for ; Thu, 8 Jan 2015 11:35:20 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKVK7b97lXfdAd5+sujcAEpjgmtgBSpM86@postini.com; Thu, 08 Jan 2015 11:35:23 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t08JZIsM007226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 14:35:18 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 8 Jan 2015 14:35:17 -0500 From: "Gould, James" To: Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YA= Date: Thu, 8 Jan 2015 19:35:17 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> 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_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Jody Kolker , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 19:35:27 -0000 --_004_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_ Content-Type: multipart/alternative; boundary="_000_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_" --_000_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Francisco, What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Thanks, =97 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 On Jan 8, 2015, at 12:44 PM, Francisco Obispo > wrote: Hi James, The only component that is still open is what to call that extended claims = phase. Perhaps it=92s useful to suggest a name for that special phase (exte= nded-claims?) to avoid having 100 different phase names. I believe the clarification is very useful. Thanks Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 On Jan 8, 2015, at 9:11 AM, Tran, Trung > wrote: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? Trung From: Jody Kolker > Date: Thursday, January 8, 2015 at 11:15 AM To: "Gould, James" >, "eppe= xt@ietf.org" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Thanks Jim. >From a registrar perspective, this will solve the issue of domains that are= released after the initial 90 day claims period but still require a claim = to be presented to the customer. Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: Monday, January 05, 2015 3:18 PM To: eppext@ietf.org Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Servi= ce" post the Claims Phase All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, =93...releases for Allocation or registration such reserved domain name= at any time following the start date of the Claims Period, such domain MUS= T be subject to the Claims Services (as described in Section 3) for a perio= d of ninety (90) calendar days following the date Registry Operator release= s such domain name for registration=85=94. This means that support for the= Claims Check Form needs to be revised to indicate whether or not the Claim= s Create Form is needed for the domain name and the use of the Claims Creat= e Form should be supported in phases other than =93claims=94. There are no= XML schema changes required to support this. Please review and provide fe= edback to the proposed revised language in the draft below to include in th= e next version of the draft that will also include the Implementation Statu= s section discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: =95 During claims phase with a claims check command =95 If domain has matching trademark =95 return exists=3Dtrue =95 else =95 return exists=3Dfalse =95 During post claims phase with a claims check command =95 If domain was released post claims phase start and is within 90 days of= release and has matching trademark =95 return exists=3Dtrue =95 else =95 return exists=3Dfalse =95 During claims phase with a create command =95 If domain has matching trademark =95 claims notice is required =95 else =95 claims notice is NOT required =95 During post claims phase with a create command =95 If domain was released post claims phase start and is within 90 days of= release and has matching trademark return =95 claims notice is required =95 else =95 claims notice is NOT required Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Francisco,

What do you mean by the extended claims phase?  Is there a past m= ail list thread on this or is this a new issue?  Please clarify.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 8, 2015, at 12:44 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:

Hi James,

The only component that is still open is what to call that = extended claims phase. Perhaps it=92s useful to suggest a name for that spe= cial phase (extended-claims?) to avoid having 100 different phase names.

I believe the clarification is very useful.

Thanks



Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, = CA, 92660
off. +1.345.749.6284=
fax. +1.345.746.6263=

 

On Jan 8, 2015, at 9:11 AM, Tran, Trun= g <Trung.Tran@neust= ar.biz> wrote:

Thanks Jim for bringing this to the eppext.  This will definitely help= the post claims phase.

With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain?  

Trung
From: Jody Kolker <jkolker@godaddy.com>
Date: Thursday, January 8, 2015 at 11:15 AM
To: "Gould, James" <JGould@verisign.com>, "epp= ext@ietf.org" <eppext@ietf.o= rg>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a &quo= t;Claims Service" post the Claims Phase

Thanks Jim.
 
>From a registrar perspective, this will solve the issue of domains that are= released after the initial 90 day claims period but still require a claim = to be presented to the customer.
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with a= ny feedback.
 
This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. = ;If you have received this email in error, please immediately notify the se= nder and permanently delete the original and any copy of this message and its attachments.
 
From: EppExt [mailto:eppext= -bounces@ietf.org] On Behalf Of Gould, James
Sent: Monday, January 05, 2015 3:18 PM
To: eppext@ietf.org
Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Cl= aims Service" post the Claims Phase
 
All, 
 
There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase.   According to section 2.4.3 of the RPM = Requirements, =93...releases for Allocation or registration such reserved d= omain name at any time following the start date of the Claims Period, such domain MUST be subject to the Claims Servi= ces (as described in Section 3) for a period of ninety (90) calendar days f= ollowing the date Registry Operator releases such domain name for regi= stration=85=94.  This means that support for the Claims Check Form needs to be revised to indicate whether or not the = Claims Create Form is needed for the domain name and the use of the Claims = Create Form should be supported in phases other than =93claims=94. &nb= sp;There are no XML schema changes required to support this.  Please review and provide feedback to the proposed revise= d language in the draft below to include in the next version of the draft t= hat will also include the Implementation Status section discussed at t= he IETF-91 EPPEXT meeting. 
 
Change 3.1.1 "Claims Check Form" as follows:
 
   The Claims Check Form defines a new command called the Claims = Check
   Command that is used to determine whether or not there are any=
   matching trademarks, in the specified launch phase, for each d= omain
   name passed in the command, that requires the use of the "= ;Claims Create Form" 
   on a Domain Create Command.
 
   Instead of returning whether the domain name is available, the= Claims
   Check Command will return whether or not at least one matching=
   trademark exists for the domain name, that requires the use of= the 
   "Claims Create Form" on a Domain Create Command. &nb= sp;
 
   <launch:name>  Contains the fully qualified name of= the queried
           domain name.  This element MU= ST contain an "exists" attribute
           whose value indicates if a matchin= g trademark exists for the
           domain name that requires the= use of the "Claims Create Form" on a Domain Create Command. &nbs= p;
           A value of "1" (or "= ;true") means that a
           matching trademark does exist = ;and that the "Claims Create Form" is required on 
           a Domain Create Command.  A            value of "0" (or "f= alse") means that a matching trademark
           does not exist or that the &q= uot;Claims Create Form" is NOT required on a Domain Create Command.  
 
Change 3.3.2 "Claims Create Form" as follows:
 
<launch:phase>  SHOULD contain the value of "claims&qu= ot; to indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Based on the above revised language the following may be done:
 
=95 During claims phase with a claims check command 
=95 If domain has matching trademark  
=95 return exists=3Dtrue 
=95 else  
=95 return exists=3Dfalse
=95 During post claims phase with a claims check command 
=95 If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark
=95 return exists=3Dtrue 
=95 else  
=95 return exists=3Dfalse 
 
=95 During claims phase with a create command  
=95 If domain has matching trademark  
=95 claims notice is required 
=95 else  
=95 claims notice is NOT required
=95 During post claims phase with a create command  
=95 If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return 
=95 claims notice is required 
=95 else  
=95 claims notice is NOT required 
 
 
Thanks,
 
=97
 
JG


<image001.png>=

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
=93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work product. If you are not the in= tended recipient, you are hereby notified that any use, dissemination, dist= ribution, or copying of this communication is strictly prohibited. If you h= ave received this message in error, notify sender immediately and delete this message immediately.=94

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


--_000_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_-- --_004_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 08 Jan 2015 19:35:16 GMT"; modification-date="Thu, 08 Jan 2015 19:35:16 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_B392E84286BF4F1E96FCED2EA7E19F6Dverisigncom_-- From nobody Thu Jan 8 12:08:42 2015 Return-Path: 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 7A0C11A01AE for ; Thu, 8 Jan 2015 12:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9Dufq4tOFarO for ; Thu, 8 Jan 2015 12:08:22 -0800 (PST) Received: from zimbra1.uniregistry.com (zimbra1.uniregistry.com [162.221.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id AF04F1ACD5F for ; Thu, 8 Jan 2015 12:08:21 -0800 (PST) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id 2A8EE6022BA; Thu, 8 Jan 2015 20:08:19 +0000 (UTC) Received: from zimbra1.uniregistry.com (localhost [127.0.0.1]) by zimbra1.uniregistry.com (Postfix) with ESMTP id 17DA56066BA; Thu, 8 Jan 2015 20:08:19 +0000 (UTC) Received: from dynamic-200.sna1.uniregistry.net (wsip-98-189-40-200.oc.oc.cox.net [98.189.40.200]) by zimbra1.uniregistry.com (Postfix) with ESMTPSA id 1595C6022BA; Thu, 8 Jan 2015 20:08:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_14155B11-69FA-4368-99BB-8DA32D015B18" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Francisco Obispo In-Reply-To: Date: Thu, 8 Jan 2015 12:08:16 -0800 Message-Id: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> To: "Gould, James" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Jody Kolker , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 20:08:26 -0000 --Apple-Mail=_14155B11-69FA-4368-99BB-8DA32D015B18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >>> SHOULD contain the value of "claims" to indicate the >>> claims launch phase. A value other than "claims" MAY be used = to=20 >>> pass the claims notice for domain names outside of the claims phase. = =20 Once a TLD has ended the mandatory 90 day period of =93claims=94 a = registry might decide to call it something else.=20 We are not supporting extended claims, but we had to support an extended = sunrise for the names on the ICANN names-collision block list (30 day = period instead of a 60 day end-date sunrise), and we initially thought = about having a phase called =93sunrise=94 with a sub-phase called = =93extended=94 but we thought it would be too complicated for RARs to = change their code, so we decided just to trigger it by calling the phase = =93sunsrise=94, but in reality, a registry can call it anything they = want in order to support it, because they are different things. Since there is no guidance on what the phases should be called, it seems = like we=92re going to end up with discrete phase names for anything that = is not: claims or sunrise. > On Jan 8, 2015, at 11:35 AM, Gould, James wrote: >=20 > What do you mean by the extended claims phase? Is there a past mail = list thread on this or is this a new issue? Please clarify. >=20 Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 =20 --Apple-Mail=_14155B11-69FA-4368-99BB-8DA32D015B18 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_AFAB3B13-9113-49C9-A99A-D4D8152B9C17" --Apple-Mail=_AFAB3B13-9113-49C9-A99A-D4D8152B9C17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
<launch:phase> =  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value = other than "claims" MAY be used to 
pass the claims = notice for domain names outside of the claims = phase.  


Once= a TLD has ended the mandatory 90 day period of =93claims=94 a registry = might decide to call it something else. 

We are not supporting extended claims, = but we had to support an extended sunrise for the names on the ICANN = names-collision block list (30 day period instead of a 60 day end-date = sunrise), and we initially thought about having a phase called =93sunrise=94= with a sub-phase called =93extended=94 but we thought it would be too = complicated for RARs to change their code, so we decided just to trigger = it by calling the phase =93sunsrise=94, but in reality, a registry can = call it anything they want in order to support it, because they are = different things.

Since there is no guidance on what the phases should be = called, it seems like we=92re going to end up with discrete phase names = for anything that is not: claims or sunrise.


On Jan 8, 2015, at 11:35 AM, Gould, James = <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there = a past mail list thread on this or is this a new issue?  Please = clarify.


Francisco Obispo
CTO - Registry = Operations



2161 San Joaquin Hills = Rd.
Newport Beach, CA, = 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

 

= --Apple-Mail=_AFAB3B13-9113-49C9-A99A-D4D8152B9C17 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mail Attachment.png" Content-Type: image/png; name="Mail Attachment.png" Content-Id: iVBORw0KGgoAAAANSUhEUgAAAJsAAABfCAIAAABweiJ5AAAYSWlDQ1BJQ0MgUHJvZmlsZQAAWAmt WWdUFM3S7tkIy7LknHOSnEFyzjkjsOScMyaCSFARBBQBFVQQVDARREwIIooIKmAAJBhIKqggCMjX i+F9zz33/vv2nJl5prq65qmq7p7pWgC4iOTo6HAUPQARkfGx9ib6/K5u7vz4UUAETAAPZAAn2S8u Ws/W1hL8z9/yEEAojc+kKbb+p9p/b2DwD4jzAwCxhc2+/nF+ERBfAwBD8ouOjQcA2wnlQknx0RQ8 DTFzLCQI8ToFB21hHGQPmH1/YeEtHUd7AwBwagBQEcnk2CAASIZQzp/oFwTtkPxhG2Okf0gk7JYM sbZfMBnKOFuhzraIiCgKfguxuO+/7AT9C5PJvn9tkslBf/EvX2BP+GDDkLjocHLK1s3/5ykiPAHG a+snAM/E4FhTe3hlhnGrCIuyoGAixJcifa1tIGaEuD0EevQb9wUnmDpBTNEf94szgLEErBB/8ycb WkDMDQCKkBDmpPcbi5JjIdrSR+mHxJs5/sbOsVH2v+2jQiPDrSnjA9pB7QwOMPuDiwLijBygHHJA hQaGGJtBDHOFOpca7OgCMeSJak0McbaGmARxZ1yYA4UDxc7T1GADinxLJzbBnsJZGMqnA2ONKT5C HTQxIg6iLftoQT/y1rPYoVwpPtjRFMphX7Slf4ChEcTwuWjXgEin33zQwdHx+hQ7FP3U6PCt8Q15 oosCwk0ockGIz8QlOvzpez8+1pEih3FDD4WSzSnjFXJGz0bH21JiQuGzAiyBATAE/CABHr4gCoSC kL75lnl496vFGJBBLAgCAUD6t+RPD5etlkh4dgCp4COIhDpxf/vpb7UGgEQo3/gr/dVXGgRutSZu 9QgD7+ETIjCcGG2MJsYSnnXhoYBRw6j/6cdP94cnzghniDPFGeMk/kiAH2QdDo9YEPJfZBawLQB6 FwvPkX98+Mce9j12ADuJHcSOY18CZ/B2y8pvT71DMmL/MPhr2QqMQ2u/ohIAIxYJZv7oYEQha2WM PkYL8ofcMawYTiCNUYKe6GF0oG/KUPonehTWCX+5/RPLP3H/o0dhzf8vH3/LSZIk5d8sfP94BTP5 JxL/aeWflhDgD7Us/lMTnYO+iu5G30X3oNvRLYAffRvdiu5F36Tg35yNt6IT9Pdp9lsRDYM+hPzR kTsvNyO3/ufur69kKKEwoOQAjv/4gOR4OP6AQVR0SmxIUHA8vx5chQP4zSL9ZLbxK8jJKwJAWdMp OgB8td9aqxHWJ//IAuC6uh3OD+r+f2ShRwCo7wKALe8fmagHABzbALj81C8hNvGXPQzlggUEQAdn BgfgBUJAHPqkAFSAJtAFRsAc2ABH4Aa8YNSDQQRknQR2gnSQDfLBYVACjoOT4DQ4By6CK6AFtIO7 4D54BPrBIHgNx8Y7MAcWwDJYQxAEj9AiTAgHwoeIIFKIAqKGaCNGiCVij7ghPkgQEokkIDuRTCQf KUKOI1VIHXIZuY7cRXqQAeQlMoHMIF+QHyg0iohiRvGgRFGyKDWUHsoC5YjagQpCxaBSUVmoQ6hj qGrUBVQz6i7qEWoQNY6aQy2hAZoGzYoWQEuj1dAGaBu0OzoQHYvejc5Dl6Kr0Q3oNpjrZ+hx9Dx6 FYPDMGH4MdJwfJpinDB+mBjMbswBzHHMOUwzphPzDDOBWcD8xNJiubFSWA2sGdYVG4RNwmZjS7E1 2CZsF5w777DLOByOFSeGU4Vz0w0XikvDHcBV4hpxd3ADuCncEh6P58BL4bXwNngyPh6fjS/DX8Df xj/Fv8OvUNFQ8VEpUBlTuVNFUmVQlVLVU92iekr1gWqNmp5ahFqD2obanzqFuoD6DHUb9RPqd9Rr BAaCGEGL4EgIJaQTjhEaCF2EEcJXGhoaQRp1GjuaEJq9NMdoLtE8oJmgWSUyEiWJBkRPYgLxELGW eIf4kviVlpZWlFaX1p02nvYQbR3tPdox2hUSE0mGZEbyJ+0hlZOaSU9Jn+io6UTo9Oi86FLpSumu 0j2hm6enphelN6An0++mL6e/Tj9Mv8TAxCDPYMMQwXCAoZ6hh2GaEc8oymjE6M+YxXia8R7jFBOa SYjJgMmPKZPpDFMX0ztmHLMYsxlzKHM+80XmPuYFFkYWJRZnlmSWcpabLOOsaFZRVjPWcNYC1ius Q6w/2HjY9NgC2HLZGtiesn1n52LXZQ9gz2NvZB9k/8HBz2HEEcZRyNHCMcqJ4ZTktONM4jzB2cU5 z8XMpcnlx5XHdYXrFTeKW5LbnjuN+zR3L/cSDy+PCU80TxnPPZ55XlZeXd5Q3mLeW7wzfEx82nwh fMV8t/lm+Vn49fjD+Y/xd/IvCHALmAokCFQJ9AmsCYoJOglmCDYKjgoRhNSEAoWKhTqEFoT5hK2E dwqfF34lQi2iJhIsclSkW+S7qJioi+h+0RbRaTF2MTOxVLHzYiPitOI64jHi1eLPJXASahJhEpUS /ZIoSWXJYMlyySdSKCkVqRCpSqmBbdht6tsit1VvG5YmSutJJ0qfl56QYZWxlMmQaZH5JCss6y5b KNst+1NOWS5c7ozca3lGeXP5DPk2+S8Kkgp+CuUKzxVpFY0V9yi2Ki4qSSkFKJ1QeqHMpGylvF+5 Q3lDRVUlVqVBZUZVWNVHtUJ1WI1ZzVbtgNoDday6vvoe9Xb1VQ0VjXiNKxqfNaU1wzTrNae3i20P 2H5m+5SWoBZZq0prXJtf20f7lPa4joAOWadaZ1JXSNdft0b3g56EXqjeBb1P+nL6sfpN+t8NNAx2 GdwxRBuaGOYZ9hkxGjkZHTcaMxY0DjI+b7xgomySZnLHFGtqYVpoOmzGY+ZnVme2YK5qvsu804Jo 4WBx3GLSUtIy1rLNCmVlbnXEasRaxDrSusUG2JjZHLEZtRWzjbG9YYezs7Urt3tvL2+/077bgcnB 26HeYdlR37HA8bWTuFOCU4cznbOnc53zdxdDlyKXcVdZ112uj9w43ULcWt3x7s7uNe5LHkYeJR7v PJU9sz2HdojtSN7R48XpFe5105vOm+x91Qfr4+JT77NOtiFXk5d8zXwrfBf8DPyO+s356/oX+88E aAUUBXwI1AosCpwO0go6EjQTrBNcGjwfYhByPGQx1DT0ZOj3MJuw2rDNcJfwxgiqCJ+I65GMkWGR nVG8UclRA9FS0dnR4zEaMSUxC7EWsTVxSNyOuNZ4Zvjx3JsgnrAvYSJRO7E8cSXJOelqMkNyZHJv imRKbsqHVOPUs2mYNL+0jp0CO9N3TuzS21W1G9ntu7tjj9CerD3v9prsPZdOSA9Lf5whl1GU8S3T JbMtiydrb9bUPpN957NJ2bHZw/s195/MweSE5PTlKuaW5f7M8897mC+XX5q/fsDvwMOD8gePHdw8 FHior0Cl4MRh3OHIw0OFOoXnihiKUoumjlgdaS7mL84r/lbiXdJTqlR68ijhaMLR8WOWx1rLhMsO l60fDz4+WK5f3ljBXZFb8b3Sv/LpCd0TDSd5Tuaf/HEq5NSLKpOq5mrR6tLTuNOJp9+fcT7TfVbt bF0NZ01+zUZtZO34OftznXWqdXX13PUF51HnE87PXPC80H/R8GJrg3RDVSNrY/4lcCnh0uxln8tD VyyudFxVu9pwTeRaRRNTU14z0pzSvNAS3DLe6tY6cN38ekebZlvTDZkbte0C7eU3WW4W3CLcyrq1 eTv19tKd6Dvzd4PuTnV4d7y+53rveaddZ1+XRdeD+8b373Xrdd9+oPWgvUej5/pDtYctj1QeNfcq 9zY9Vn7c1KfS1/xE9Ulrv3p/28D2gVtPdZ7efWb47P5zs+ePBq0HB4achl4Mew6Pv/B/Mf0y/OXi q8RXa6/3jmBH8kbpR0vHuMeq30i8aRxXGb85YTjRO+kw+XrKb2rubdzb9XdZ72nfl37g+1A3rTDd PmM80z/rMftuLnpubT77I8PHik/in6591v3cu+C68G4xdnHzy4GvHF9rvyl961iyXRpbjlhe+563 wrFyblVttfuHy48Pa0nr+PVjGxIbbT8tfo5sRmxuRpNjyVvfAmh4RgUGAvClFgBaNwCY+gEgkH7t ubY04CcyAnUgdkaMUHpoNQw7loCjwstRuVFnEm4TcbRkUgs9gSGc8SGzMksFG2AP4+jjUuE+zDPH p8tfIDAgRBBWF3ETDROLEPeU0JfkkVyUur+tTDpMRkuWVvaNXKP8XgU7RQHFj0rXlfep2Klyq75T a1BP1tDTJGg+216h5a+9TfuLTovuTj19faL+G4NbhvVGlcaFJrtNyWY65uzmixa9lg1WldZVNu22 U/ZYBw5HTid6Z7TzusuaG3Cn9iB50u7A7FjymvTu97lDvupb41fmnxeQEhgU5BisH6IUKhkmEM4R QReJjvwWNRndH3Mj9kzcofg9CdmJTcmYlIDUOzvBLtHdGnvM9nqkJ2QcyizJStuntG8qu2C/bY5I Lk0eyEcdYDgofki7wPqwS6F7kfsR12LnEsdSu6PWxyzKTI7rl2tXqFcqnpA+KXlKrsqiOvP0+Fmz mgu1c3UM9SLn5S9oXjRssGp0ueR9OfhK9NWka7ubMpr3teS05l8vaCu5UdFec/Para7bw3fG7w51 NN4L7GTvfNBVej+pO/DBjh6Xh3aPLHpNHpv2OT6J6T818PIZzXPZQYMhs2GjF2ovRV6RXq2+nh55 MXp37PSbzPGgCadJ6ymrtzbvbN6bf1CfZpsen8mbVZodnzs3n/rR9BPVp7rPJp+nFk4vJn/x+mrz zWopdLljZf+Plg3Dzc3f+ZdHY9AzmHHsFG6BCk2tQgimqSCOkyTpkujvM3IwpTA/Z1Vgy2Af5VTm yubu5+Xkc+UvFGgXHBFaEl4WmRV9LHZaPFZCW5JK8rnUyW2h0srSP2Xuyx6Sc5Hnk/+g0KCYqKSl jCh3qeSp2qgxqQ2pl2l4aPJojsBR4KnNoT2sc1TXQ09Ub01/0OCy4QGjAOPtJgwm703bzUrMEy0C LH2tgq2jbCJsfe1s7DUdJB25nEjOKOdllw+uQ2733Bs8yj3zdqR6hXi7+hiSZX3Z/RC/Wf/BgM7A pqCa4NKQrNCoMLdw3QixSFo4Eiaix2K+xQnEeyeUJd5NepE8lTKfurqTZhfvbvE9/Htxe9+kN2UU ZMZmee1zynbdH5KTmVuZdzG/6UDzwWuHLhdcPFxXeLbo1JHy4pKSgtLcoxnHUsqijgeVh1Tsrbx9 UuLUuWqx00Vnnp1drSWd46wTqpeE40D1onaDYaPVJbfL4Veyr56+dqtpoHmsZbr1axv6Blu71E3N W7q3Ve8I3EXdnezovtfUWdtVfv9w974HqT2xD+Mf5fa297E+2dU/+pTzmc5zx8HAob3DZ188efnt NeOI9KjlWPSbo+M3Jp5Ojk1Nvp17j4XZT58ZmGOYl/uo/En0M93nlYX3i8NfHn69/q1qac+y83ex 78sr7aupPzTXiOuGGzO/8y+DzKEq0V4YCSweu4ibwc9STVIv0hCIIrR6JHe6dPoLDAOMm8wiLEas oWz72E9yXOPs4nrAfZ/nBm8VXzK/Pv8PgTOCFoJzQjnCYsIdIl4iq6LFYnJiD8WDJPAStZKmkh+k sreJb+uS9pMBMpWy22VfyCXAr5tGBUuFacVMJV6lVmV75XmVfap8qi3wq2VafY8Gq8Z5TT3Np9v9 tn/SStPGa5frKOkM6abq8eq16tvovzQINtg0rDayNaY2vmey01TJdNas2tzTgt1iyLLEysGazrrH JtNW0/abXaN9mIOYw1vHKqcdzhzOz10KXE1dN92a3MM9hD1GPUt3WO9Y9ir2FvG+5qPn84qc7Cvo +wKuI8EBJoGqQerBZiHk0IgwcrhOBH3ESOTZqIho5ej1mHuxeXG28SzxrxNOJvoniSa9Tz6RYpQy khqexpz2bOeNXbd2d+65t/d6el1GaWZmVtQ+j2yj/ZI52JznuWV57vnC+WsHxg8+PnS94NTh3YUe RRpHOI+sFg+VXCk9evTgsaKyquNXy+9XvKicPbF2iraKv1rxtOkZz7NRNbtrc88dqNtbTz6veoF0 4cvFjw2rl4iXea8oXLW9ltZ0rXmlVf16dFvZjUvtrTdv3Oq5vXTXpON6p0PXUndpj+LD570H+3z6 zZ7qPdcfCn9JGpmb7Jtd+rZKyf+v2hvlnYBTAeBIOtyhZgPgpANAYScAooNw30kAwJYWAEd1gBIN BChiL0A0Jv6+PxCABjhAAxhg/YYPiAE5oAHrLjbAHdZC4uDusgCcAA3gFngCJsA3uHPkRuQRE8Qb SUIKkQvIA+Q9CocSR1mi4lCVcJ+3Cfd1iejr6J8YE8wRzCRWEZuDfYPTwJXh1uAO6yGVKlUtNRd1 IYGGkEtDoDlM5CTW0irRtpO0SG10anQ36E3pXzPEM9IzXmQyZBpgdmQeYLFhecrqzbrCVsauxT7G sYuTi7ONy4ubmrudJ5FXifcr3xX+WAFlgXXBbqFS4WCR7aIk0XGxq+I5Er6SelKi20jb1qQ/ybyV HZRrkk9TkFcYU8xRUlb6rNyqUqSaouavbqkhp8m2naQlo12uK6V3UL/H4LMRlTGLCYcpt5mwuZKF tWWM1THrTpsvdkL2Lg6HHLudMS6GrtluvR6snr476r3e+uDIDL443yW/d/4jAbNBdMEWISWhH8K3 RxRHfoo2j6mPI8bHJLxKMk5uTZVOq9nFv7t8L2t6YSYhK33f0v7QnLm8/AMRh5oKGY5wFn8srTvm fZy1vL/y4EmTU0vVBWeYz+bULJ8Lq/ty/vBFo0aGS4tX3l+bbp5r/dA21b54m+2uwT2vLp9uhx6d R7KPJZ6oDEQ+WxnGvKIeOfmGaeLWO9L0zjm9j42f176ofDNeJnw/uPJwdfrHu7WX69c2Dv/03ZTb Wj8o+cfD+h4jrDkIAEmgCLSAKawz+MAKQxrIBWWgDlyHdYRRsIBgEU5Ebiv7KUgxcgnpQz6i6FCK KHdUJuoK6h2aD+2NPoOex6hgsjCDWAlsOnYE5r4cD/DB+EEqI6pWalnqeoIE4QKNEs1toi1xijaZ RE0qoROguwT3r68ZkhhZGVuYnJk+Mu9iIbAcY5VmfcgWxc7GfocjhJOZ8w5XFLcw9whPGa8rHzvf S/5KAX9BOSEg9Fz4vEiWqKeYEtzLzUr0Sl6Fb7EC6UyZnbLxcn7yugpEhT7FPCULZTblRZWXqt1q zerVGgc0U7cnauVqt+p811PU9zfIN6wxaja+YXLD9KZZj/mEJcpK0trZZp9ti928g7Cjt1Ol85ir oFuoe7MnfoeL13HvLp8BcodvnV+Of0iAfaBpkFtwRsidMNpw34j2KM7o1JjROP34ukS6pOjkR6kC aYk7+3cr7zmTzpVRnEXYl5Y9n0POncxPPShXgDo8WnS5OLFU6eiXssvlCZUaJ36cqqlWOF155kON WG3wuUv1bOcrLmo1fLxUdkX9al8TuXmttbrNrh3crLtteWex42Sn732NBwIPMY8eP058guvPe0p8 Vj3oPWz1Mvx17eiHcb5J27fp72/NsM0d/iS68Phr8fKBVbM1hfUTG29/Lv7OPwZQw5ouO8y+FKw1 GQBbWGGKALvgzK8C18ADMAbnPRERRXSRHUgaUo7cRCZQ1DDrZFQJqh/Ngg5A38RwY/ZiZrFu2Mc4 A9xNWE+5S2VJNUodR6AjXKJxJqKJLbQxJHnSCl0XfRlDAqMbkxmzOYsdqzmbKrsEhzKnN1cKdzyP L68jnzW/lYCVoKWQlbC9iLdonNhB8XqJB5Iz22ilVWUCZY/LDSlwKvorNSqvqdqqPdbI3e6mjdU5 rLuub2GQCTPYYtxucsu0z2zNwsKy2VrG5oKdjH2zo4HTkEuEG8H9gqezF4MPja+3v0fA2yDN4PyQ 92H24b2RVlFPYzxip+PTEnmTxlLup93ZVbnHae+PjKos52y+/Qu5N/MPHAwsMCnkKHpUHFiyfDSz jOF4dYVK5eOTgVVIdcUZtbODtQl1XPUPLuxpMLkke8X42p7m6taCNrd2tpvDt8vvut3Dd569r9R9 o8fo4XBvcp9sP3pg4dn04MBw4UuxV5Wvf44ajeW9eTRBN+k0dertzHv5D2HTp2YezM7OYz9yf5L7 bLjgskj+4v/V9pvgt6Wlg8vcy/Xf1b8f/7664rLSvMq6GrvavLr2Q/dH1o+eNdKaw9rRtf51qnXd 9eT1y+szGwIbbhtFGw83Nn7K//T/efTno58/N+U3AzaPbfZS8h8XqKhAeXsAhKgPy49jm5tfRQHA FwGwUbi5uVa9ublxGm42RgC4E/7r/xyKMuV/oooFCnrUujJAuf7793+Hw8XBvpCpSAAAAZxpVFh0 WE1MOmNvbS5hZG9iZS54bXAAAAAAADx4OnhtcG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8i IHg6eG1wdGs9IlhNUCBDb3JlIDUuNC4wIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZXhpZj0iaHR0cDovL25zLmFkb2Jl LmNvbS9leGlmLzEuMC8iPgogICAgICAgICA8ZXhpZjpQaXhlbFhEaW1lbnNpb24+MTU1PC9leGlm OlBpeGVsWERpbWVuc2lvbj4KICAgICAgICAgPGV4aWY6UGl4ZWxZRGltZW5zaW9uPjk1PC9leGlm OlBpeGVsWURpbWVuc2lvbj4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgIDwvcmRmOlJERj4K PC94OnhtcG1ldGE+CgOpdOAAABtsSURBVHgB7V0JWFNXFn7ZSCAkYd9BZBGQRVBQERGtO6K4KxWx rVO7fO2001o72GlnprZVq9NlbK17XWrHqqOouLTivtcNUBQUEGVT2SGEkHX+x4MQkxABg1rmvc8v 3nfvuefee849633vwVCr1QR9dSMKMLvRWuilkBSgOdrd9gHNUZqj3Y0C3W09tIx2N46yu9uCnvV6 6uRSqVLOYDD0J4KwwozJFpmZ6zcZr5GplLWyBhJGH2tTpCLi8DisZlbSHDVOzA633q65ny+u1NBX u79CpXTgCQY7+ujzRRtMv1wrk5x+mA9+6u8TpZpgE+oB9p6O5iKqI4OOR/Up+CQ1oKeRAB+8NMCW x40HhEaxkjg1u4Tm6OPI+Udrp7WuiTl28v6tm7UPDGpduVLpbiGKdQsyZA+NTaNEUn2oKAuSSDA1 otgMD9llq9TDXQPc+DZUFc1RY6TsRBubweQwmWYMln5fcITFQHChyxV9SJ0a6FQOCwi1lWsziJJQ c5hqhhZOWuvqUO8Pf0vLqIlZWCdvaFC0Gb1AG1ubWXR0SEQvNTKJkV5CjjmXjl6MEOhJmpZn/vZp 4VVrjgG2VSka59h7/jgoUVtJtmeszKrCMWf+U8di8PXy8FWEylup3jRwWpSDD4WK1rrtIWkHYArE ZWVSMZNhQPmpCJWIze0lcuoAuiZQZC1u1T0gi2q9HB9DxVQRXiIHEac5cUFztKPkfd7hDWyl533K z/f8DtxNz64sJNhmSArozlSpcBDYzfIZ0FGtWyAu35X3O0H6yboXxmCpVRN69vMSOlJtNEd1afSE 9yfv5yzNv0Rw+YQeQwm5dLKzz4veA1oTPO0brLShNvnWWRk4qs9UtcpGrQpz9NZwlNa67SPqHweK llET80quVskJFRn0610qhpqtZpgxDSQf9GAfqUBiSEqg9yOV1A2ZXFARXCZTk9mlOWqATJ2uAs3/ dGzt5punCHNLA1pX1hDs1js9bgHI36Eh0u7njEpdTmYB9VNRaiWhUu0f806sRwiFk+Zoh2j7GGAw apx7iKsZnzDjItTQgVYp5O5WTiRjOnj14FsnB49o4qheX7WaqVJ7Cmw1KGk7qiFFNynQMmpiRqbe vXqt4h6TjF50MauUcheBfZJvpJ6g6ULq3OeLK7bnnkclQ8/XVatVMMuTvCJ8hA5UL5qjOtR70tu/ ZhzIunyA4FsZiEcb6wmvvrN9Bmq8mHYOll5VlHzgGzJ00feqVLCjSpeZn2s4SmvddlK1vWB36pAF rGMwDYmKWingmPuJnDoqo8j+Z9c+bJqBga5MlcpX5CBsOQCgOdpeVrUTTqVWy8n0qwHSqwk1G4LW cc8I+luhVrV9sKrGoaxmPENbqZ1zp8EMUWDGkVU7bx4neEJ9X5eQSazcgirikw3y2xCy5rrDJTdH 713SttZV7Rv3XpxHHwqa5qgRSnamyZzNIdg8gmMgekHgaI/Wjl8sJpPg8MjoxYAdVRFqZdOjEc14 aa3bcQI/3z1oGTUxf/bcvZJZfo+F6EXvUioVbgK7l8joRWP19IAMVeDs5T+551UQUj0bjAQhS62e 4h3hS5+9GCKdCeoSLvy34fxuQmBjIHqRiole/ZN8IlkdYyhxtqxg4fZ/kna05dGT1okqFYheHF7+ huZoK01MW/pX8Ijf7DzMSbOnm2KQKuQhVi4GDjkfN4M+1i5Tx7zOIphIyOvAKtVqjkrV19ZDU0/b UQ0pTFZAnNEW28BkXZ60b9i2OurX03a0fRRtN9Qn6fsXnfmZ4FkaYB2Z31Hti/1LnFtwu/GRgPFH V+/NPknwBAYiIoUC5zy34hfSWrdDJO0AsDXXgnhYQEYv+idfQCOp/SLjUKxrUPvzDOkV9/amHyLq Kgg2IiK9C099uvrZt7zGhGZa6+rR6MkqHjTUHivNVjOYLD2/FNSWqxRCDne8e3M2oD1D3ZNUnSzJ YbM5BjW5XKlwNBeOcAnQoKK1roYUpimAvmoG405lMctQkgFxS75Snn4/b27gcBeL5vcDjQycWphx rjRHaDAD1dQNT3v3t++pjYHmqDY1TFPeczfjl4MrCT7MnqELzoyi8ZNbpy+Nervfo8zQhsZz9Cuy 0uYfXEGIK4m2Mk0yGWFpNcoj2FerJ611tYhhomJmVVGfXYsIpYxgtpHzg78rqSXsPFKiZsW35GO1 B6+Xy5Kv7Fpx5QDpGpvxDIS2gCaR1I3oHX14+JvafWmOalPDZOWcmtIHUjEHxg8Safhi4FUWDoPp JbTT8ZLQo1YmvVtfKeDwuCyOYXYSBN5KUygVwdauOi/S0FrXML2fsJbLMov57XsCSSKkGggEqAYv BoEzMrnMQEyCjHyzZ9tWXya08UthY3+Mmq2DmuaoDkFMc+tpafu6z4BV+/9NmJmR2TsTX2qisZGw d3/TP0YfMc1RfZqYpmZ5/ylVjXXXqh84wKfVf2Oi04MwEAKpHogrPwmNjdBK/mnw0XZUQ4ouKay5 ferS/TyhhZBpGqYyVCp5jVz2btCIQJGzwRnTMmqQLCar9BM4vnZ4DVGSizDjSZHCuVXIiUbJ8EHT 3SzaxEbL6JPS+bH9M6tL+xz8isi9TPDMCYNPlD0WBQAg4vJGdH8jJvH7gQlgblsXzdG2KGPK+ofS uu+zjx0vLyxXyFx4fAQtBvzbNgbEQbdYIauUSfvyrSd7hEz27NcGYHM1zVHj9DFl6+/l+ZPObS8p zMJBJxnVQF4N5H61RkRso5ARMilOct4LGfFZvwnmTAOPRmh1IIs0R3UI0rW3yONvuX32g2uHiZJb hLSezPuAr4g+8Y/SpNCuOHRrejKBrBTZD/UOXxgydqRr73bOjOZoOwllSjA8eHCiNDul6Pqukuzi qlJCUkPaSBX5IBHJYK45HmqJceg5yaX3BI+QngL7Do1Nc7RD5DI9MKS2QlZf09hAffFTyOaKuBb2 PIGQTDZ15qI52hmqPc99TJ6gep4X+38xN5qj3Y3NNEdpjnY3CnS39dAySnO0u1Ggu62HllGao92N At1tPbSM0hw1KQWKi4quXrkilUpNitUEyJRKZWZGRn5+vglwPV0Uzc8wlJaUrF2zBpRls9kymfzF xFkhIc1fJdOZT1FR0drVa5RyOZPNAuTspNmBQfjjCJ259qakfJL8UUVFRdSQ6K/+/a2Li0tnsHRB n5qamuQPFqTu22duYbEg+a+vzJ2r/ypuFwxrIpR4SRhXRnq6s529pRnXRiDkMlk7tm+n6vV/L168 aC+0EnB5gOQx2Cm7dunDtKemsrJyYL9wkQXfw9kFIy75fHF7ej0dmE3rN1hwzNwcnbDGXj288vPy OzFuVVUVNFBJSUlxcbFEIukEhs51aZZRFotlZW0NATUzM+Nyufhta8OwWWwrG+vGxkYOhwNITtuQ bWGg6uUyWV1dnYWFBY/Hw+hVlRXG4Z9mK5iBp0AwNwwqkUqk0qa/WdbBGXz15bIdO3YIBYJGWeOy r78eOXJkBxF0EvyZeUZ29vYJsxOxeUtKS3p6eU1LmNnJFXRBt/GTJob2DSsuKamurp4ydSqm14lB YE3uFhQUFhbeu3u3QWLsL0F0ArmRLs/sWUC8gf7R3/4WHh6el5c3evRobx8fI7N8yk1eXl47du/e vy/V1s42fuJEqJBOTAC6B1Jubm4OGwxl1gkMnetiMo7W1Yllssamr4CoRVZWoALe37iZlXX7di60 lo21dUhoqKNj87fUqbk2NDQMiYkZOmyYQqGQy+VQ46iH1GJH45OG+IahpUBA0eJG1o38vLzomCEi 0SNv6N26dev2rVticT0o5+3jHdC7t3EXpvDevevXr9fW1AqFwpDQPq6urhgRggjPFs+EMJhMkVDE ZDFxayWySpqTBEsG+0KpXw19xWLxjawsWEfMWWBp6enl5evrC4NFAWAt4ro6TANuJjUZ/NZUV6MX UAkEAlg04K+tqSHNJEGgI7Wo6qqq8+fPu7q4BoUEl5eXs1kslUrFYrOtrAw8yIkmwFMjAo2NrW3r wkm8avX1a9cCfHu5Ozl7e/SAi7QnJYWq1/+9euWqr2dPuDMU5P7UVArmg/fnB/sH9O/bL3pg5L27 936/cGHm1Gm9enoBm4ONrYu9Q9/g4DWrVqnwlbWW658ffxLo6x8ZHhHeJ/TkyZNU9Xcrvgvs5YfK kIDeR46kQXHNe2Wup4u7l7sH+NfSVZ2WljZz+owAH19gdrK1wygYa2r8xF8PHtLAaBfgoMx/913M EPCOVrYutvahgUFfLlkKB23unDl9/HtjDqOGvQBPHr1yb9+OiRocERaGOWB0mUxGoQKTVv/ww9Co wT3d3J3s7B1tbF3tHPx9fMaPjV2/di1IDLCc7Oxhg6PRN8jPH3P26eEJQvUL6RM1YAB+Tx4/QeEf CpjQsGB//7ffeBP4161dNyiiv6UFf8kXXyjkiskT4kODguE5As+5M2ep0bV/N/24EWuJ6j8gyM/v 3bf+DAZrWk0mo+UPH9zJz+dbWmL7f/ftt3tT9paWFJvzLbgcLpvNwse3S4pKFvzlfT7fEqERtbnK y8sgeSJrkbxRLqmvpyqrqypRCTdNrVTt37MP0SouaDA7u9Z3uL5a/q8vlyyBXEOnQVCUcgVCqfr6 +uNHj2FnfLgw+b358yls1O+d/DuvzJlz6fffgRao1Fw1esELXfrZFzevZeXm3S4qKQakWFwHZYEC SHy34A5EHyzs4elJveMA4Uv+8MN1P6zhC/gwGY2IoVVqGZMhL5OfLz934vjxXTt2bvp5K0S8oKCg tpZUA5A/EBrSU1ZWBpwyqUwiIZfZhL8AjiFw5uXmLnjv/S2bNwOYgzf9WXA9WYHBQQdSU+FqwBin pOweOCiSWgj1i1lt37btzp07GAID9R+EP2VAPXZGtpuMo/CRzXnm0CrAvmnjRowqsrbi8/kgtFhS j3qBSKhUqjZuWD9x8iRKj8GxpiwNGwxpsVXQvYgC0RFU27ljB5Qw1JRU0gA81Hp+WLny04//jn3A 43IVMkVoWKiLi1tZRfmNa9cwNHp99vdP7e0dZs9JouCh6z5OTr588aJzU7wLOuIBLZFQCLS11bV7 9qZYW1tDa0HV83ikzUMvIMFewb5HgVT7TZW7d+36cc06Owc7MAmtY+PGYZPdv3//euY1KHPwBhoS yykreyiXy+SNMsgNNQHgRCv2UKO8UamCom3Gj0psLyieyxcvYSCoYhAK6wXA9Bkztm39GTO3sbE5 cuQINoS9fevzYwg1r2VmOjg4wGyF9e07dmwsNRD1azKOUugwe0wdn6mbOWtWQsJMEBGzWf39yiOH j2Br83jcosIiKFIYPO1JGCyDcGCks7PzyFGjQsJC+RZ8pCBycnIQFVgKLTEQaP350iXj4sZZWVnD Sp07ew6cg9pE8PXNsuXDhg93cyPNJAT38OHDtnZ2KGNH9wsPf/X11wICAiQNDYcPHtq8eXNNZZW5 Jd/gHKhKZtPLZYf2H8DGQw3GXb1+XfSQIVQrvNld23ds/PHHhR//DZzGZlq8bBkYuGd3CkwPakCQ xDlzQkKCG6SNQU3ZGJKrLZdM2gh2Rg+Jjo6JAf96BwaiJTAwaFBU1P69+xAo3rtTcOzI0ekzZ7T0 IFL37MW+xH4Cy8eOi9UxtCblKBNPKKowzF8WfDB/wQfUDHr5+fn4+kwYOw5ajnI6AKCZXFsFMAxC GTlk8BeLF1OLpCC3bNoErwHsgffxj0WLZiUmUvWWlpYjR40E+WYnJEDKoZEO7N8/77V5aE1LOwya khJZW9u3b9+NWzbbOzR/LjosLCxy8OA35s2rq61tayZkfZNKw6ahtCi+vAm1qYF3d3d/5/33psyY TuW8bG1tE2eT73TeuJ518sQJSCFGHz1m9AvDh2u6aApo4vEtFn3y8YuzZgG5ph4fV504efLBAwew rUFSaOCp06eB8QCorKg4evQoVoo52NnYTZw0WdOLKhiOR419uK5VY+ugwi0DJg2aBx6/dpuDg6OP ry+eXyQhyMvwoJou+FgXVBAU1+ykJG121tdLLl74naSRTAbp7xferwjRXsuFokcPDx8fH5AJwnT2 1CkgxO7JuXETxAJC3L7x1lsadlLDDYwc2KNHD+ObDGQFMBxjLAE7o6FR+urLr8SPi/vr/A9+2rw5 Iz0DJsbNzY2iOIUWv5gGlkrdQj1q6rUL2LXItibNmaPNTgpg2PAX/Pz8AAB6njt3Fg4XVX/ixAk4 buAoxHRwTHRA79avpFAAzfuCnHTTvKlazVSo20d/we5WrlKrbQVo+syZzgKwy8hgprVTK7iREuag brI6GpgHpSWwW1g8pBBm708vvUS5eM0AeHqZyawX12O1mBUy1eCitEGK4ARdsKNhL6EwNNioAqYK MKPrxYvYJEcTEhNTdu+GhgAerAga9fSpUxgR7ol/QMCMhARYbuN4dIbGLfYuqIK5YaPotCKkiR0/ /svFi6F+yu6X/fbrr5SpOrAvFRPGAkGESdOm6PTCbTNHsWbNFkOH6urmWEe/g1QigZtHAeOXa2Yg dtZlM/lmlbbt0MdquAaE025AOg32iYFvBTGZkIAb128qVQrt7QVgGDnsHjIVVVIibWjA3oNfT36h T6VGPYv1GPWgPZxOOaJ/xMo1qxf9/R+w5VgOkqXw9oAR5Lp4/sKpkycz069+vnQp6Ul15AIqXAZ7 xI0fv2H1WplcZsYzO7j/wNvvvAObffr0abiNWCAOSKKjm225dvdmjsJRhoFFPhO7TKVQwtFPTErS htOU0VRfJ7a2tYGrBmlwcnbSNHV1AZEPVG5NbQ2Ghi569c3XzNhsiKn2uNQWUEAi7WzJbcpi8S0s 8ElwrhkPwvrw4UPof214CAe40hZNtSFRHjN2bHhEBFyt0ydOgK/wwiCy6Av/BTts3eq1AwdFweDp 9Or0LdyoyCGkfwR5zbp+PT09PePq1Yel923t7cS1dePGx+nkW6iBWjhqZ+fbyzc7Oxv8t7Dkp+5L hWUe+sILOrPJy8vfuGEjz4L08uGI+gX4uXt46MB03a2jk7Orm1txYRGHY4ZNmjg7qW+/vsaHg8JE QHnp0iX8cV5QYevmLfAhtbsg4IOvgfBJu9JIGR4meIZ/UJWw4ulX03H6hGAUognjfTQtTZ+joBX2 lhGcbTYxiClTp8HHbnIsFFs2bS4pLESMCKvv4OQ44VFnRYOkVQuNiR0HLYcdx+XxYF3eefvtnzZv KS8rx+4j9XBVFVwvpFeKigshH+gPS/bCyJEGt4kGu2kLCEtiYmKwHg6bLRHXf7boUxxk6gyB6B6X phJOY1R0NBalVKsQECOm/GThwuKiYvgyyMOBE6+9Og+ulYUluSLjF0R84YIPoV0pMAi3l7f35KlT cLILImBWkPUaBLstFyX3YCc0CrKALdUd+39IzBD4PohTLS0Fe3fvvnzxMswqfCJ4zvABDeJq3Tvj 4yds27oVnrGTkxO6VZRXIMWz8rvvPDw8MFeYJWQ3MDk4AphlVUWlVy/fl195xSDSrqucOevFn7du hTmBe3Lm5KmkhBfnvj4vODgE53+Y4flz59euWuXm7r5t5w4YOWoa4+Li1vzww63sHBs7Wyjt1StX QQNhUQjmsSLIKKLAx0wYX6lRqxE4fbV8+Y4d2+MnTRo9egzSOrBTkO+ft/yEuAgMBst79HhEY6EX TD5cGOQIGxqkFRXlMxMSXJqSyY8ZsaUZQ8TGxWVmZFL7A195BQuwivjJk1pAdP9v5SgkDwH7S7Nn 52TnIKjCLUQW2YDcnFtwUzEtWE3gQiXMLXbl0uXLnqbKpSYOrfvZksWvvvwyyIe9deHCBWhUZE8w PdQgSYsCHH3kCBd9/jnVxc7e7h+fLZo7ew6YBwIJrURIekB1Y1EIkJBwkDU2wiLqEkbrHjixh75Z /jWyHEgHbVy/YfvWbc6uzjiQgAsJiadiCeyMGTNbzwS9vb0RZQENKImThvfffReWwtPTc/LUqR3y +sdPmLBh7TpoTcofBhKkyQZHR2tN8JFiq9ZFNYK/rb/8MiE+HjYS60dMDXGE1cSFvQZcIBkUXUT/ /lt/2YZUjjYmRE5YHshaU1WNb2FpN6FMtkL1kK010OFUa0O9pFLcVFtdLcd3Ypsu7OVKcS0gq2qq YauoSu3fsbGx6zdtQhBZUVaO3C+wgT138vJJt05NRgJQU35+/tpdMNX1WzYFBgZCmLAErA5KGCsa N3HCytWrnZydqXBL42IBJ5ZJzqGqCkRQKpTY4skff9TT24uiiVQmxSHg5UuX8HgDrBJohe21dPny PqGhmnEhRohqoDnILmoywwVPPe233wAAqWjGX0OeyWi6GCwgaEF+SiLGeRR5Ybi4+HjK8BmEb5VR qhkHQ5u2/nQkLe3XQ79mZV0ve/AAIR2a8KwCVtXL33/osKHwqvUxRkZGQjNAiKGidfQY5gFjhi4c eJxmXChMaqyIiIja2hokcaFJkO2jKoOCgxKmz4CD1tBA7miqUud39JgxIX36IFt9/Pjxwrt3MUMM IbAU9vTuGRkVNWXaFGdnF50uYOrAyEiczNy4fr2mrlYgEA4YOGDU6NEQo/IHDyl3F7+40FEoEk2c OAlRmkIm7x0UhFAdk//TvFdj48bt27P3zJkz+bm5yAmr1EqIr4OjY3j/iBcTE7FjtAf16NFjzYb1 Xy//V2ZmRpPt5yBjNWL0aAo/kjASaUMT/kDsLe2O+mUEu0iBYZ9hv7o4OYP++jCaGmPvj0Ioy8vK sH8RL3F5XPDpafpBmikaKSiUSjzGg3MbEAVsgAfQFnBpaalm02jDwNNJnJkARkKLQML+uydFY4C1 wXTKiIIgwgqFEmRxdHDkG00L4xkGcX09zhVgpLADdFC15/a/O3e+Ne8NJMahYBLnJH27YgV2cJsd IVjd/oIZCw8NW7Z0KTao9mIzMjJGxAzF2SpOfIXmFh8lJ2u3PtsyJLJJlnBYmzsseggmiUNZHO4e STtifGLGZLTNXfCHaoAEv/na69jm0Jw4cgkLD3d2doLWuVdQcOzY0apK0suDdReIBLtT9+lozme4 UBjgP7/1FjyDgjt3oGBghuA3RA6O2rV3j3FB17Wjz3ANXTR0UVExcrA44MNzi0j0ZGVlUQNBccHq 4yp/WM7jm8OFfn7YiRniCOLU8ROQVGxETBJuGnwQHPIYZyc6PsYmdxGVnyZaROL/2blj8rSpbDMO PAsqi0I5yUhTgGTRQ4ds3roVh8xPc1aPHQsWobyqEuno+rp6mE8HB/tvVqwYMWLEYzt2f62rIcGV y5fxkFReXi7iK5giBKaePXsGBwcPGDiwk1k6DeouKMCN37l9O04nhVZW/v5+eL6unQ+Z/h9xtAvI /jyi7P5a93mkelfOieZoV1L3WeCmOfosqN6VY/4PV2iSp+CpbccAAAAASUVORK5CYII= --Apple-Mail=_AFAB3B13-9113-49C9-A99A-D4D8152B9C17-- --Apple-Mail=_14155B11-69FA-4368-99BB-8DA32D015B18-- From nobody Thu Jan 8 12:24:23 2015 Return-Path: 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 F309F1A1A76 for ; Thu, 8 Jan 2015 12:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 RXDW8190ZFSy for ; Thu, 8 Jan 2015 12:24:03 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957C61A1A30 for ; Thu, 8 Jan 2015 12:24:00 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKVK7nXoY1w5VD2kC9KKl6Equk3S0X8WNQ@postini.com; Thu, 08 Jan 2015 12:24:02 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t08KNvqM025876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Jan 2015 15:23:58 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 8 Jan 2015 15:23:57 -0500 From: "Gould, James" To: Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEA Date: Thu, 8 Jan 2015 20:23:56 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: 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_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Jody Kolker , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 20:24:07 -0000 --_004_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_ Content-Type: multipart/alternative; boundary="_000_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_" --_000_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 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 On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 --_000_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7DAE0715476B3C4C81FA7EAB0D954CF1@verisign.com> Content-Transfer-Encoding: quoted-printable Francisco,

I would have gone with the sub-phase approach as well, since if the be= havior between the two claims phases are consistent (e.g. requirement for c= laims check and claims notice) I=92m not sure the value in defining a new t= op-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:

<launch:phase>  SHOULD contain the value of "claims" t= o indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;


Once a TLD has ended the mandatory 90 day period of =93clai= ms=94 a registry might decide to call it something else. 

We are not supporting extended claims, but we had to suppor= t an extended sunrise for the names on the ICANN names-collision block list= (30 day period instead of a 60 day end-date sunrise), and we initially tho= ught about having a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too comp= licated for RARs to change their code, so we decided just to trigger it by = calling the phase =93sunsrise=94, but in reality, a registry can call it an= ything they want in order to support it, because they are different things.

Since there is no guidance on what the phases should be cal= led, it seems like we=92re going to end up with discrete phase names for an= ything that is not: claims or sunrise.


On Jan 8, 2015, at 11:35 AM, Gould, Ja= mes <JGould@verisign.c= om> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.


Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, = CA, 92660
off. +1.345.749.6284=
fax. +1.345.746.6263=

 


--_000_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_-- --_004_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 08 Jan 2015 20:23:56 GMT"; modification-date="Thu, 08 Jan 2015 20:23:56 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CF36E71127BD47A6938EB9B1804DFD0Everisigncom_-- From nobody Thu Jan 8 13:51:18 2015 Return-Path: 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 98D641A005D for ; Thu, 8 Jan 2015 13:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 LNR1D4cVEGmj for ; Thu, 8 Jan 2015 13:51:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92AD51A01A9 for ; Thu, 8 Jan 2015 13:51:05 -0800 (PST) Received: from BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) by BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 21:50:41 +0000 Received: from BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) by BLUPR02MB034.namprd02.prod.outlook.com ([169.254.12.109]) with mapi id 15.01.0049.002; Thu, 8 Jan 2015 21:50:41 +0000 From: Jody Kolker To: "Gould, James" , Francisco Obispo Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy2fq2AgAAe/ICAAAk3AIAABGEAgAATFuA= Date: Thu, 8 Jan 2015 21:50:39 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.202.160.233] authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkolker@godaddy.com; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR02MB034; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:BLUPR02MB034; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(31014004)(164054003)(377454003)(199003)(38284003)(24454002)(19580405001)(19580395003)(19300405004)(101416001)(31966008)(74316001)(20776003)(92566001)(230783001)(16236675004)(17760045003)(99936001)(54606007)(76176999)(50986999)(66066001)(54356999)(4396001)(93886004)(64706001)(97736003)(19609705001)(54206007)(87936001)(2656002)(19617315012)(21056001)(122556002)(62966003)(107046002)(33656002)(16601075003)(105586002)(77156002)(19625215002)(40100003)(99286002)(106356001)(68736005)(106116001)(120916001)(86362001)(2900100001)(99396003)(46102003)(76576001)(18206015028)(2950100001)(15975445007)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB034; H:BLUPR02MB034.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: godaddy.com does not designate permitted sender hosts) Content-Type: multipart/related; boundary="_004_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 21:50:39.9740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR02MB034 Archived-At: Cc: "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 08 Jan 2015 21:51:14 -0000 --_004_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_ Content-Type: multipart/alternative; boundary="_000_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_" --_000_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there's a tr= ademark against the name regardless on whether or not the claims ack is nee= ded in the create domain? This could be accomplished by leaving the "claims" implementation as it is = currently and introducing a sub-phase for claims named "extended". When th= e sup-phase of "extended" is passed the results from Jim's earlier email wo= uld be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of "extended" * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of "extended" * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of "extended" * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of "e= xtended" * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I'm not sure if determining i= f a domain has a claim when all claims periods have expired is needed. Thi= s implementation also would require additional work by all registrars to su= pport if adopted, while the implementation from Jim's first post would requ= ire only updates by the registries which would be better for widespread ado= ption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I'm not sure the value in defining a new top-leve= l phase name. Is there a material behavior change between the two phases a= nd is the concept of an extended claims phase a generic use case? We have = stuck with the standard set of "sunrise", "claims", and "open" phases. Hav= e others utilized the use of sub-phases or have created custom top-level ph= ase names to meet their needs? If so, can you share your scheme? It would= be good to know if there are any common patterns. Thanks, - JG [cid:image001.png@01D02B47.ACAB1530] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of "claims" a registry mig= ht decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called "sunrise" with a sub-phase called "extended" but we though= t it would be too complicated for RARs to change their code, so we decided = just to trigger it by calling the phase "sunsrise", but in reality, a regis= try can call it anything they want in order to support it, because they are= different things. Since there is no guidance on what the phases should be called, it seems li= ke we're going to end up with discrete phase names for anything that is not= : claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 --_000_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From Francisco:

 

Thanks Jim for bringing this to the eppext.  T= his will definitely help the post claims phase.

 

With the wording changes, is there still a way to d= etermine if there’s a trademark against the name regardless on whethe= r or not the claims ack is needed in the create domain?  

 

This could be accomplished by leaving= the “claims” implementation as it is currently and introducing= a sub-phase for claims named “extended”.  When the sup-ph= ase of “extended” is passed the results from Jim’s earlier e= mail would be below.

 

  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of &#= 8220;extended”
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 

 =

  1. During claims phase with a create command or post claims phase without= a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f “extended”
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

This would still allow a registrar to= determine if a claim currently exists on a domain when a claim period does= not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domai= n has a claim when all claims periods have expired is needed.  This im= plementation also would require additional work by all registrars to suppor= t if adopted, while the implementation from Jim’s first post would require only updates by the registries which = would be better for widespread adoption.

 

Thoughts?

 

Thanks,

Jody Kolker

319-294-3933 (office)

319-329-9805 (mobile) Please con= tact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.

 

This email message and any attachment= s hereto is intended for use only by the addressee(s) named herein and may = contain confidential information. If you have received this email in error, please immediately notify the sender and per= manently delete the original and any copy of this message and its attachmen= ts.

 

From: Gould, James [mailto:JGould@ve= risign.com]
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a &q= uot;Claims Service" post the Claims Phase

 

Francisco,

 

I would have gone with the sub-phase approach as wel= l, since if the behavior between the two claims phases are consistent (e.g.= requirement for claims check and claims notice) I’m not sure the val= ue in defining a new top-level phase name.  Is there a material behavior change between the two phases and is th= e concept of an extended claims phase a generic use case?  We have stu= ck with the standard set of “sunrise”, “claims”, an= d “open” phases.  Have others utilized the use of sub-phas= es or have created custom top-level phase names to meet their needs?  If so, can= you share your scheme?  It would be good to know if there are any com= mon patterns.  

 

Thanks,

 

—

 

JG


3D"cid:image00=

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

 

On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wro= te:



<launch:phase>  SHOULD contain the value of "claims&q= uot; to indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;

 

 

Once a TLD has ended the mandatory 90 day period of = “claims” a registry might decide to call it something else.&nbs= p;

 

We are not supporting extended claims, but we had to= support an extended sunrise for the names on the ICANN names-collision blo= ck list (30 day period instead of a 60 day end-date sunrise), and we initia= lly thought about having a phase called “sunrise” with a sub-phase called “extended” but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase “sunsrise”, but= in reality, a registry can call it anything they want in order to support it, because they are different things.

 

Since there is no guidance on what the phases should= be called, it seems like we’re going to end up with discrete phase n= ames for anything that is not: claims or sunrise.

 

 

On Jan 8, 2015, at 11= :35 AM, Gould, James <JGould@veri= sign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 

Francisco Obispo
CTO - Registry Operations
=
<Mail Attachment.png>



2161 San Joaquin Hills Rd.

Newport Beach, CA, 92660

off. +1.345.749.6284

fax. +1.345.746.6263

 

 

 

 

--_000_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_-- --_004_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Thu, 08 Jan 2015 21:50:39 GMT"; modification-date="Thu, 08 Jan 2015 21:50:39 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_BLUPR02MB034B2D11DA287B2DB2A4B59BF470BLUPR02MB034namprd_-- From nobody Fri Jan 9 06:29:26 2015 Return-Path: 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 34B7A1A89FC for ; Fri, 9 Jan 2015 06:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dPe0ttKy6G7s for ; Fri, 9 Jan 2015 06:29:22 -0800 (PST) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D33CC1A8972 for ; Fri, 9 Jan 2015 06:29:17 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKVK/lvTPIha4bsdHx3FVSoIRTD+gyxcIu@postini.com; Fri, 09 Jan 2015 06:29:21 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t09ETGC0018040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 09:29:16 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 9 Jan 2015 09:29:16 -0500 From: "Gould, James" To: Rik Ribbers Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEA Date: Fri, 9 Jan 2015 14:29:15 +0000 Message-ID: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> References: In-Reply-To: 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_0ED7237BF4E845D7971F1625350DB0FCverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 09 Jan 2015 14:29:25 -0000 --_004_0ED7237BF4E845D7971F1625350DB0FCverisigncom_ Content-Type: multipart/alternative; boundary="_000_0ED7237BF4E845D7971F1625350DB0FCverisigncom_" --_000_0ED7237BF4E845D7971F1625350DB0FCverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rik, Below is my feedback to the updated draft: 1. As noted in past mailing list comments and in person discussions, I d= on=92t agree with the mixing of a protocol extension for the command and an= object mapping for the poll response. I have provided examples of impleme= nting this draft using either an object mapping or a command response exten= sion of domain. In it=92s current form, I=92m assuming that the EPP greeti= ng and login would include the urn:ietf:params:xml:ns:relay-1.0 URI in both= a and an element. I highly recommend that you reconside= r this. 2. You are making keyrelay more generic by creating a new extension poin= t of the data to relay, with the key data being one concrete type. I still= believe that creating a Key Relay Object Mapping would have been the best = route to go, since the creation of a Key Relay object would add it into the= poll queue for consumption by the losing registrar. The only command supp= orted by the mapping is create along with the poll info response. The crea= te is creating a transient object. If other types of data need to be =93re= layed=94, a similar approach could be taken without having to add an additi= onal layer of extensibility. A new EPP object mapping would be defined for= the new type. The key relay along with any other relay objects will be pr= operly exposed in the EPP greeting and login elements. 3. Nit in 3.1.1, =93An OPTIONAL (client transaction identifier)= element that MAY be used to uniquely identify the command to the registrar= =94, should reference client instead of registrar. 4. What is the expected response to the command? I=92m assuming= that it=92s as EPP response as defined in section 2.6 of RFC 5730 where th= e value is set with the value associated with the comma= nd if supplied by the client. Regards, =97 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 On Jan 8, 2015, at 8:41 AM, Rik Ribbers > wrote: All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_0ED7237BF4E845D7971F1625350DB0FCverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Rik,

Below is my feedback to the updated draft:

  1. As noted in past mailing list comments and in person discussions, I don= =92t agree with the mixing of a protocol extension for the command and an o= bject mapping for the poll response.  I have provided examples of impl= ementing this draft using either an object mapping or a command response extension of domain.  In it=92s current= form, I=92m assuming that the EPP greeting and login would include the urn= :ietf:params:xml:ns:relay-1.0 URI in both a <objURI> and an <extUR= I> element.  I highly recommend that you reconsider this.    
  2. You are making keyrelay more generic by creati= ng a new extension point of the data to relay, with the key data being one = concrete type.  I still believe that creating a Key Relay Object Mappi= ng would have been the best route to go, since the creation of a Key Relay object would add it into the poll queue for consumption by the= losing registrar.  The only command supported by the mapping is creat= e along with the poll info response.  The create is creating a transie= nt object.  If other types of data need to be =93relayed=94, a similar approach could be taken without having to add = an additional layer of extensibility.  A new EPP object mapping would = be defined for the new type.  The key relay along with any other relay= objects will be properly exposed in the EPP greeting and login <objURI> elements.  
  3. Nit in 3.1.1, =93An OPTI= ONAL <clTRID> (client transaction identifier) element that MAY be use= d to uniquely identify the command to the registrar=94, should reference cl= ient instead of registrar. 
  4. What is the expected response to t= he <relay> command?  I=92m assuming that it=92s as EPP response = as defined in section 2.6 of RFC 5730 where the <clTRID> value is set= with the <r:clTRID> value associated with the command if supplied by= the client.

Regards,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 8, 2015, at 8:41 AM, Rik Ribbers <rik.ribbers@sidn.nl> wrote:

All,
 
As you (may) have noticed we submitted a new version o= f the keyrelay draft. In this draft we tried to solve all the open issues, = remarks and feedback we received.
 
The major  changes are:
 
  1.  Introducing the <relay> command,= and thus seperating the data and
       the command.=
 
   2.  Updated the Introduction, descri= bing the general use of relay vs
       the intended use-= case of relaying DNSSEC key data.
 
   3.  Restructuring the document to ma= ke it more inline with existing
       EPP extensions.
 
In the end it has become a major rewrite and as always= feedback is welcome.
 
Kind regards,
Rik Ribbers
_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/ep= pext

--_000_0ED7237BF4E845D7971F1625350DB0FCverisigncom_-- --_004_0ED7237BF4E845D7971F1625350DB0FCverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 09 Jan 2015 14:29:15 GMT"; modification-date="Fri, 09 Jan 2015 14:29:15 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_0ED7237BF4E845D7971F1625350DB0FCverisigncom_-- From nobody Fri Jan 9 08:28:13 2015 Return-Path: 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 8BE161A700D for ; Fri, 9 Jan 2015 08:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 e0Lsn_Rf9-mO for ; Fri, 9 Jan 2015 08:28:04 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B821A6F87 for ; Fri, 9 Jan 2015 08:27:42 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKVLABfNy5NZHW7TvRzuxhiz+ApcFk02CJ@postini.com; Fri, 09 Jan 2015 08:27:45 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t09GRdeR019869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Jan 2015 11:27:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 9 Jan 2015 11:27:39 -0500 From: "Gould, James" To: Jody Kolker Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAA== Date: Fri, 9 Jan 2015 16:27:38 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: 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_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Francisco Obispo , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Fri, 09 Jan 2015 16:28:08 -0000 --_004_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_ Content-Type: multipart/alternative; boundary="_000_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_" --_000_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 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 On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 --_000_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From F= rancisco:
 =
Thanks= Jim for bringing this to the eppext.  This will definitely help the p= ost claims phase.
 =
With t= he wording changes, is there still a way to determine if there=92s a tradem= ark against the name regardless on whether or not the claims ack is needed = in the create domain?  
 
This could be accomplished by leaving the =93claims=94 imp= lementation as it is currently and introducing a sub-phase for claims named= =93extended=94.  When the sup-phase of =93extended=94 is passed the results from Jim=92s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim= currently exists on a domain when a claim period does not exist for the TL= D (the current implementation).  From a registrar perspective, I=92m not sure if determining if a domain has a c= laim when all claims periods have expired is needed.  This implementat= ion also would require additional work by all registrars to support if adop= ted, while the implementation from Jim=92s first post would require only updates by the registries which would be bet= ter for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct superv= isor Charles Beadnall (cbeadnall@= godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended = for use only by the addressee(s) named herein and may contain confidential = information. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.<= /o:p>
 
From:=  Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppext@ietf.o= rg; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobis= po@uniregistry.com> wrote:


<launch:phase>  = ;SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@veris= ign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newpo= rt Beach, CA, 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

--_000_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_-- --_004_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 09 Jan 2015 16:27:38 GMT"; modification-date="Fri, 09 Jan 2015 16:27:38 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C3F2FBCAC8004CC2BD49D36D028B5522verisigncom_-- From nobody Mon Jan 12 19:04:12 2015 Return-Path: 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 546F41A89EF for ; Mon, 12 Jan 2015 19:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 blqWXgRApsN7 for ; Mon, 12 Jan 2015 19:04:05 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84BA11A886C for ; Mon, 12 Jan 2015 19:04:05 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.14.7/8.14.7) with SMTP id t0D30H6j016705; Mon, 12 Jan 2015 22:04:02 -0500 Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1rvn4grg5a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Jan 2015 22:04:01 -0500 Received: from stntexmb12.cis.neustar.com ([169.254.2.192]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 12 Jan 2015 22:04:01 -0500 From: "Tran, Trung" To: "Gould, James" , Jody Kolker Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgA Date: Tue, 13 Jan 2015 03:04:01 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.168.128.76] Content-Type: multipart/mixed; boundary="_004_D0D9F3EF49253trungtranneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5600 definitions=7679 signatures=670600 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=8.21569173803383e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.993311949948012 urlsuspect_oldscore=0.993311949948012 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.993311949948012 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501130029 Archived-At: Cc: Francisco Obispo , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 03:04:09 -0000 --_004_D0D9F3EF49253trungtranneustarbiz_ Content-Type: multipart/alternative; boundary="_000_D0D9F3EF49253trungtranneustarbiz_" --_000_D0D9F3EF49253trungtranneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 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 On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 --_000_D0D9F3EF49253trungtranneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <930FB34273F5244A9A697EEEA193F4C5@neustar.biz> Content-Transfer-Encoding: quoted-printable
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <= trung.tran@neustar.biz> Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From F= rancisco:
 =
Thanks= Jim for bringing this to the eppext.  This will definitely help the p= ost claims phase.
 =
With t= he wording changes, is there still a way to determine if there=92s a tradem= ark against the name regardless on whether or not the claims ack is needed = in the create domain?  
 
This could be accomplished by leaving the =93claims=94 imp= lementation as it is currently and introducing a sub-phase for claims named= =93extended=94.  When the sup-phase of =93extended=94 is passed the results from Jim=92s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim= currently exists on a domain when a claim period does not exist for the TL= D (the current implementation).  From a registrar perspective, I=92m not sure if determining if a domain has a c= laim when all claims periods have expired is needed.  This implementat= ion also would require additional work by all registrars to support if adop= ted, while the implementation from Jim=92s first post would require only updates by the registries which would be bet= ter for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct superv= isor Charles Beadnall (cbeadnall@= godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended = for use only by the addressee(s) named herein and may contain confidential = information. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.<= /o:p>
 
From:=  Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppext@ietf.o= rg; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<= span style=3D"font-size: 9pt; font-family: Verdana, sans-serif;">
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobis= po@uniregistry.com> wrote:


<launch:phase>  = ;SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@veris= ign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newpo= rt Beach, CA, 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

 --_000_D0D9F3EF49253trungtranneustarbiz_-- --_004_D0D9F3EF49253trungtranneustarbiz_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: attachment; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 03:04:00 GMT"; modification-date="Tue, 13 Jan 2015 03:04:00 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_D0D9F3EF49253trungtranneustarbiz_-- From nobody Tue Jan 13 00:19:08 2015 Return-Path: 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 B10951A8A43 for ; Tue, 13 Jan 2015 00:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 i92GbLMc5rx3 for ; Tue, 13 Jan 2015 00:19:00 -0800 (PST) Received: from smtp67.ord1c.emailsrvr.com (smtp67.ord1c.emailsrvr.com [108.166.43.67]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037281A8A41 for ; Tue, 13 Jan 2015 00:18:59 -0800 (PST) Received: from smtp9.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 51A74380221 for ; Tue, 13 Jan 2015 03:18:59 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4E06D3800F9 for ; Tue, 13 Jan 2015 03:18:59 -0500 (EST) X-Virus-Scanned: OK Received: by smtp9.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 3E46438023D for ; Tue, 13 Jan 2015 03:18:58 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E66C0.dip0.t-ipconnect.de [87.142.102.192]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 13 Jan 2015 08:18:59 GMT Message-ID: <54B4D4F1.6070405@comlaude.com> Date: Tue, 13 Jan 2015 09:18:57 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: eppext@ietf.org References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030200090008040505090204" Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 08:19:04 -0000 This is a multi-part message in MIME format. --------------030200090008040505090204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc. The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when /not/ to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael *Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: > This works for me, Jim. Though it’s not often, we have cases where > change in ownership of a domain might not occur if there’s trademark > against the name. So a potential registrant might not want to buy an > existing registered name if there’s trademark against it in the TMCH. > > Thanks, > Trung > From: , James > > Date: Friday, January 9, 2015 at 11:27 AM > To: Jody Kolker > > Cc: Francisco Obispo >, "eppext@ietf.org > " >, > "Tran, Trung" > > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a > "Claims Service" post the Claims Phase > > Jody, > > I believe that passing the active phase is more straight forward > as opposed to defining a special sub-phase like “extended" to > drive the behavior. Having the claims check return “exists=true” > only when a claims notice is required on the create based on the > active phase should be able to handle the use case of releasing > domains post the claims phase and also applies to the claims > phase. All names that have matching trademarks during the claims > phase will require a claims notice on create, so the behavior is > consistent. > > I’m still not sure why a client would want to know whether there > is a matching trademark when a claims notice is not required on > the create. Does anyone see a need for this? Since the “claims” > phase would always return “exists=true” for domains that have > matching trademarks, a client could pass the “claims” phase when > the active phase is not the “claims” phase to obtain this > information. Of course servers would need to support referencing > a past “claims” phase to support this use case. The change in the > text should support the logic that I previously posted before, > which I extend to support addressing the optional matching > trademark past the claims phase use case. Is this use case really > needed? > > 1. During claims phase with a claims check command > 1. If domain has matching trademark > 1. return exists=true > 2. else > 1. return exists=false > 2. During post claims phase with a claims check command > 1. If domain was released post claims phase start and is > within 90 days of release and has matching trademark > 1. return exists=true > 2. else > 1. return exists=false > 3. *During post claims phase with a claims phase check and > passing “claims” as the phase (optional matching trademark > past the claims phase use case)* > 1. *If domains has matching trademark * > 1. *return exists=true* > 2. *else* > 1. *return exists=false* > > > 1. During claims phase with a create command > 1. If domain has matching trademark > 1. claims notice is required > 2. else > 1. claims notice is NOT required > 2. During post claims phase with a create command > 1. If domain was released post claims phase start and is > within 90 days of release and has matching trademark return > 1. claims notice is required > 2. else > 1. claims notice is NOT required > > > Thoughts? > > — > > > JG > > > > > *James Gould > *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > > On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: > >> From Francisco: >> Thanks Jim for bringing this to the eppext. This will definitely >> help the post claims phase. >> With the wording changes, is there still a way to determine if >> there’s a trademark against the name regardless on whether or not >> the claims ack is needed in the create domain? >> This could be accomplished by leaving the “claims” implementation >> as it is currently and introducing a sub-phase for claims named >> “extended”. When the sup-phase of “extended” is passed the >> results from Jim’s earlier email would be below. >> >> 1. During claims phase with a claims check command or post >> claims phase without a sub-phase of “extended” >> 1. If domain has matching trademark >> 1. return exists=true >> 2. else >> 1. return exists=false >> 2. During post claims phase with a claims check command with a >> sub-phase of “extended” >> 1. If domain was released post claims phase start and is >> within 90 days of release and has matching trademark >> 1. return exists=true >> 2. else >> 1. return exists=false >> >> 1. During claims phase with a create command or post claims >> phase without a sub-phase of “extended” >> 1. If domain has matching trademark >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> 2. During post claims phase with a create command with a >> sub-phase of “extended” >> 1. If domain was released post claims phase start and is >> within 90 days of release and has matching trademark return >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> >> This would still allow a registrar to determine if a claim >> currently exists on a domain when a claim period does not exist >> for the TLD (the current implementation). From a registrar >> perspective, I’m not sure if determining if a domain has a claim >> when all claims periods have expired is needed. This >> implementation also would require additional work by all >> registrars to support if adopted, while the implementation from >> Jim’s first post would require only updates by the registries >> which would be better for widespread adoption. >> Thoughts? >> Thanks, >> Jody Kolker >> 319-294-3933 (office) >> 319-329-9805 (mobile) Please contact my direct supervisor Charles >> Beadnall (cbeadnall@godaddy.com ) >> with any feedback. >> This email message and any attachments hereto is intended for use >> only by the addressee(s) named herein and may contain >> confidential information. If you have received this email in >> error, please immediately notify the sender and permanently >> delete the original and any copy of this message and its attachments. >> *From:*Gould, James [mailto:JGould@verisign.com] >> *Sent:*Thursday, January 08, 2015 12:24 PM >> *To:*Francisco Obispo >> *Cc:*Jody Kolker;eppext@ietf.org ; Tran, >> Trung >> *Subject:*Re: [eppext] draft-ietf-eppext-launchphase Support for >> a "Claims Service" post the Claims Phase >> Francisco, >> I would have gone with the sub-phase approach as well, since if >> the behavior between the two claims phases are consistent (e.g. >> requirement for claims check and claims notice) I’m not sure the >> value in defining a new top-level phase name. Is there a >> material behavior change between the two phases and is the >> concept of an extended claims phase a generic use case? We have >> stuck with the standard set of “sunrise”, “claims”, and “open” >> phases. Have others utilized the use of sub-phases or have >> created custom top-level phase names to meet their needs? If so, >> can you share your scheme? It would be good to know if there are >> any common patterns. >> Thanks, >> — >> >> JG >> >> >> >> >> *James Gould >> *Distinguished Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com >> >> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >> > wrote: >> >> >> SHOULD contain the value of >> "claims" to indicate the >> claims launch phase. A value other than >> "claims" MAY be used to >> pass the claims notice for domain names outside >> of the claims phase. >> >> Once a TLD has ended the mandatory 90 day period of “claims” >> a registry might decide to call it something else. >> We are not supporting extended claims, but we had to support >> an extended sunrise for the names on the ICANN >> names-collision block list (30 day period instead of a 60 day >> end-date sunrise), and we initially thought about having a >> phase called “sunrise” with a sub-phase called “extended” but >> we thought it would be too complicated for RARs to change >> their code, so we decided just to trigger it by calling the >> phase “sunsrise”, but in reality, a registry can call it >> anything they want in order to support it, because they are >> different things. >> Since there is no guidance on what the phases should be >> called, it seems like we’re going to end up with discrete >> phase names for anything that is not: claims or sunrise. >> >> On Jan 8, 2015, at 11:35 AM, Gould, James >> > wrote: >> >> What do you mean by the extended claims phase? Is there >> a past mail list thread on this or is this a new issue? >> Please clarify. >> >> *Francisco Obispo* >> CTO - Registry Operations >> >> >> >> >> 2161 San Joaquin Hills Rd. >> Newport Beach, CA, 92660 >> off. +1.345.749.6284 >> fax. +1.345.746.6263 >> > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --------------030200090008040505090204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.  

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

—


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.
 
With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
 
  1. During claims phase with a create command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
 
From: Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.  
 
Thanks,
 
—
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase.  
 
 
Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263

 

_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext
--------------030200090008040505090204-- From nobody Tue Jan 13 02:09:18 2015 Return-Path: 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 E83AE1ACE55 for ; Tue, 13 Jan 2015 02:09:15 -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 Q_z2ubTW8NTN for ; Tue, 13 Jan 2015 02:09:12 -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 A0C841ACE54 for ; Tue, 13 Jan 2015 02:09:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:cc: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=o5TNMbOveZ8yOQ+OzOdRPWAscRv0oRCBfj7f1Fz1Ebs=; b=JoZ1YdR1iLutdXVWeCIdBbfvEuRFnTXR3oxC/iTRqnsqgvtaf4WIKvn+eBBBV2PV0FP9jgeBiihUxTqtRWYreBGVBanDmN3N7MBPotN+JITQe4WsFihZxxRXfyDIBjg9iqvJfRlwCwt05+2Yn/HTgjfrS6yQTb6mE0LIWoFywPw= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0DA9933005176-t0DA9935005176 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Tue, 13 Jan 2015 11:09:09 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 11:09:04 +0100 From: Rik Ribbers To: "'Gould, James'" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qA= Date: Tue, 13 Jan 2015 10:09:04 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> In-Reply-To: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.154] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 10:09:16 -0000 --_004_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, Thank you for the feedback. My feedback on issue 1 and 2: I get a feeling we are running in circles. All arguments have been mentione= d in previous posts on this mailinglist. So what it boils down to is what t= he rest of the WG thinks of this. So I politely , but urgently ask the oth= er members on this list to respond to the question: Should we reconsider ex= tending EPP with a new command and use the object or protocol extension Jam= es proposes (see http://www.ietf.org/mail-archive/web/eppext/current/msg002= 41.html) If there are no responses the authors and the WG cannot make progr= ess on this document. For issue 3 and 4: We will incorporate the changes in the next version of t= he draft. Gr, Rik From: Gould, James [mailto:JGould@verisign.com] Sent: vrijdag 9 januari 2015 15:29 To: Rik Ribbers Cc: eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Rik, Below is my feedback to the updated draft: 1. As noted in past mailing list comments and in person discussions, I d= on't agree with the mixing of a protocol extension for the command and an o= bject mapping for the poll response. I have provided examples of implement= ing this draft using either an object mapping or a command response extensi= on of domain. In it's current form, I'm assuming that the EPP greeting and= login would include the urn:ietf:params:xml:ns:relay-1.0 URI in both a and an element. I highly recommend that you reconsider this= . 2. You are making keyrelay more generic by creating a new extension poin= t of the data to relay, with the key data being one concrete type. I still= believe that creating a Key Relay Object Mapping would have been the best = route to go, since the creation of a Key Relay object would add it into the= poll queue for consumption by the losing registrar. The only command supp= orted by the mapping is create along with the poll info response. The crea= te is creating a transient object. If other types of data need to be "rela= yed", a similar approach could be taken without having to add an additional= layer of extensibility. A new EPP object mapping would be defined for the= new type. The key relay along with any other relay objects will be proper= ly exposed in the EPP greeting and login elements. 3. Nit in 3.1.1, "An OPTIONAL (client transaction identifier) e= lement that MAY be used to uniquely identify the command to the registrar",= should reference client instead of registrar. 4. What is the expected response to the command? I'm assuming t= hat it's as EPP response as defined in section 2.6 of RFC 5730 where the value is set with the value associated with the command i= f supplied by the client. Regards, - JG [cid:image001.png@01D02F1F.F0E0A450] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 8:41 AM, Rik Ribbers > wrote: All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 = ;

Thank you = for the feedback.

 = ;

My feedbac= k on issue 1 and 2:

 = ;

I get a fe= eling we are running in circles. All arguments have been mentioned in previ= ous posts on this mailinglist. So what it boils down to is what the rest of the WG thinks of this. So I politely , but  urgently= ask the other members on this list to respond to the question: Should we r= econsider extending EPP with a new command and use the object or protocol e= xtension James proposes (see http://www.ietf.org/mail-archive/web/eppext/current/msg00241.html) I= f there are no responses the authors and the WG cannot make progress on thi= s document.

 = ;

For issue = 3 and 4: We will incorporate the changes in the next version of the draft.<= o:p>

 = ;

Gr,

Rik  =

 = ;

 = ;

 = ;

From: Gould, James [mailto:JGould@verisign.com]
Sent: vrijdag 9 januari 2015 15:29
To: Rik Ribbers
Cc: eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Rik,

 

Below is my feedback to the updated draft:

 

  1. As noted in past mailing list comments and in person discussions, I donR= 17;t agree with the mixing of a protocol extension for the command and an o= bject mapping for the poll response.  I have provided examples of impl= ementing this draft using either an object mapping or a command response extension of domain.  In it’s cur= rent form, I’m assuming that the EPP greeting and login would include= the urn:ietf:params:xml:ns:relay-1.0 URI in both a <objURI> and an &= lt;extURI> element.  I highly recommend that you reconsider this.    
  2. You are making keyrelay more generic by creating a new extension point of t= he data to relay, with the key data being one concrete type.  I still = believe that creating a Key Relay Object Mapping would have been the best r= oute to go, since the creation of a Key Relay object would add it into the poll queue for consumption by the losin= g registrar.  The only command supported by the mapping is create alon= g with the poll info response.  The create is creating a transient obj= ect.  If other types of data need to be “relayed”, a similar approach could be taken without having to add an additional laye= r of extensibility.  A new EPP object mapping would be defined for the= new type.  The key relay along with any other relay objects will be p= roperly exposed in the EPP greeting and login <objURI> elements.  
  3. Nit in 3.1.1, “An OPTIONAL <clTRID> (client transaction identif= ier) element that MAY be used to uniquely identify the command to the regis= trar”, should reference client instead of registrar. =
  4. What is the expected response to the <relay> command?  I’m= assuming that it’s as EPP response as defined in section 2.6 of RFC = 5730 where the <clTRID> value is set with the <r:clTRID> value = associated with the command if supplied by the client.

 

Regards,

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 8, 2015, at 8:41 AM, Rik Ribbers <rik.ribbers@sidn.nl> wrote:



All,

 

As you (may) have notice= d we submitted a new version of the keyrelay draft. In this draft we tried = to solve all the open issues, remarks and feedback we received.

 

The major  changes = are:

 

  1.  Introduc= ing the <relay> command, and thus seperating the data and

    =    the command.

 

   2.  Up= dated the Introduction, describing the general use of relay vs

    =    the intended use-case of relaying DNSSEC key data.

 

   3.  Re= structuring the document to make it more inline with existing

    =    EPP extensions.

 

In the end it has become= a major rewrite and as always feedback is welcome.

 

Kind regards,

Rik Ribbers

________________________________________= _______
EppExt mailing list
EppExt@ietf= .org
https://www.ietf.org/mailman/listinfo/eppext

 

--_000_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Tue, 13 Jan 2015 09:59:02 GMT"; modification-date="Tue, 13 Jan 2015 09:59:02 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B9280B52kambx2SIDNlocal_-- From nobody Tue Jan 13 04:14:33 2015 Return-Path: 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 7916D1A8AA1 for ; Tue, 13 Jan 2015 04:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.184 X-Spam-Level: *** X-Spam-Status: No, score=3.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 k2lLFrjKX8-I for ; Tue, 13 Jan 2015 04:14:26 -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 F0F811A1B75 for ; Tue, 13 Jan 2015 04:14:25 -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-originating-ip:content-type:mime-version; bh=XaY6c2+KR7cx7FpHd68P4KZHnRUtaaK6WaOm1OguSWM=; b=F/SRh5kla4vkGvATcMzGy63WpN/r8W5sSRtFdzWBvgyQcWhj25hOzMB6LGvkbo6z9KTKjBG/asHm2uUJxRsSbXvnLV1GCZDIl1q7kKwxZtmtk4dLJzdDn+swh09FwbLS0Y+fRoDUymfR/T806AExNoWbYf2ORWUH6XqdawGMyAo= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0DCEOFm015233-t0DCEOFo015233 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Tue, 13 Jan 2015 13:14:24 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 13:14:22 +0100 From: Rik Ribbers To: "'Gould, James'" , "eppext@ietf.org" Thread-Topic: draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQKT3krDH7sE6wI0yQ8a5hZx2LtJy+AlJA Date: Tue, 13 Jan 2015 12:14:22 +0000 Message-ID: References: <6B3201F3-4F0B-4689-BF14-5E545EB1DE9D@verisign.com> In-Reply-To: <6B3201F3-4F0B-4689-BF14-5E545EB1DE9D@verisign.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.154] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 12:14:30 -0000 --_004_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable James, I'm not an expert on the sunrise and claims requirements, but the wording s= eems correct according the RPM requirements. Gr, Rik From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James Sent: dinsdag 6 januari 2015 0:18 To: eppext@ietf.org Subject: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Servi= ce" post the Claims Phase All, There was an issue raised privately in supporting claims as a Claims Servic= e post the Claims Phase. According to section 2.4.3 of the RPM Requiremen= ts, "...releases for Allocation or registration such reserved domain name a= t any time following the start date of the Claims Period, such domain MUST = be subject to the Claims Services (as described in Section 3) for a period = of ninety (90) calendar days following the date Registry Operator releases = such domain name for registration...". This means that support for the Cla= ims Check Form needs to be revised to indicate whether or not the Claims Cr= eate Form is needed for the domain name and the use of the Claims Create Fo= rm should be supported in phases other than "claims". There are no XML sch= ema changes required to support this. Please review and provide feedback t= o the proposed revised language in the draft below to include in the next v= ersion of the draft that will also include the Implementation Status sectio= n discussed at the IETF-91 EPPEXT meeting. Change 3.1.1 "Claims Check Form" as follows: The Claims Check Form defines a new command called the Claims Check Command that is used to determine whether or not there are any matching trademarks, in the specified launch phase, for each domain name passed in the command, that requires the use of the "Claims Create = Form" on a Domain Create Command. Instead of returning whether the domain name is available, the Claims Check Command will return whether or not at least one matching trademark exists for the domain name, that requires the use of the "Claims Create Form" on a Domain Create Command. Contains the fully qualified name of the queried domain name. This element MUST contain an "exists" attribute whose value indicates if a matching trademark exists for the domain name that requires the use of the "Claims Create Form" on= a Domain Create Command. A value of "1" (or "true") means that a matching trademark does exist and that the "Claims Create Form" = is required on a Domain Create Command. A value of "0" (or "false") means that a matching trademark does not exist or that the "Claims Create Form" is NOT required = on a Domain Create Command. Change 3.3.2 "Claims Create Form" as follows: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Based on the above revised language the following may be done: 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 1. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thanks, - JG [cid:image001.png@01D02F32.D8EBB2A0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com "This message (including any attachments) is intended only for the use of t= he individual or entity to which it is addressed, and may contain informati= on that is non-public, proprietary, privileged, confidential and exempt fro= m disclosure under applicable law or may be constituted as attorney work pr= oduct. If you are not the intended recipient, you are hereby notified that = any use, dissemination, distribution, or copying of this communication is s= trictly prohibited. If you have received this message in error, notify send= er immediately and delete this message immediately." --_000_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Tue, 13 Jan 2015 12:14:22 GMT"; modification-date="Tue, 13 Jan 2015 12:14:22 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B9280D2Ckambx2SIDNlocal_-- From nobody Tue Jan 13 05:22:47 2015 Return-Path: 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 E4CEE1A8ADA for ; Tue, 13 Jan 2015 05:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 4Jmnhnyo_oRV for ; Tue, 13 Jan 2015 05:22:37 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0971A8AD0 for ; Tue, 13 Jan 2015 05:22:34 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKVLUcGRUtpxydRrjfszlCqQhW6Byy71Kc@postini.com; Tue, 13 Jan 2015 05:22:37 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0DDMWG4031300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:22:33 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 08:22:32 -0500 From: "Gould, James" To: Rik Ribbers Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gA== Date: Tue, 13 Jan 2015 13:22:31 +0000 Message-ID: <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> In-Reply-To: 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_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 13:22:42 -0000 --_004_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_ Content-Type: multipart/alternative; boundary="_000_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_" --_000_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I agree with Rik that more from the WG must weigh in on this. I believe Ri= k and I understood fully each others perspective, but we simply don=92t agr= ee. Please take some time to review the two different approaches and reply= to the list with your opinion. To be clear, my preferred approach is to use an object extension for both t= he command and the poll message response as in: Command looks like: example.org 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P1M13D 123456 Poll message looks like: Command completed successfully; ack to dequeue 1999-04-04T22:01:00.0Z Key Relay message. example.org 1999-04-04T22:01:00.0Z 256 3 8 cmlraXN0aGViZXN0 JnSdBAZSxxzJ P24D ClientX ClientY BCD-23456 65432-WXY The latest version of draft-ietf-eppext-keyrelay incorporates a general r:r= elayData element with a new extension point for concrete data to relay as i= n k:keyRelayData. If an object extension was used, new relay data would be= represented using another object extension, which will be present in the g= reeting and login list of objURI=92s. For example, if I wanted to relay a = Hello World message, I would create a Hello World object extension with the= URI urn:ietf:params:xml:ns:helloworld-1.0, that follows the relay protocol= pattern of defining the create command and the info response for the poll = message. Command looks like: Hello World from Jim 123456 Poll message looks like: Command completed successfully; ack to dequeue 1999-04-04T22:01:00.0Z Hello World Relay message. Hello World from Jim BCD-23456 65432-WXY If both the keyrelay and helloworld extensions were supported, the svcMenu = element of the login and greeting may look like: 1.0 en fr urn:ietf:params:xml:ns:obj1 urn:ietf:params:xml:ns:obj2 urn:ietf:params:xml:ns:obj3 ... urn:ietf:params:xml:ns:keyrelay-1.0 urn:ietf:params:xml:ns:helloworld-1.0 ... http://custom/obj1ext-1.0 <= /svcMenu> In doing so, the server will be able to know whether or not the client supp= orts the specific relay message type. There is a general question of what = the server should do in the event that the client cannot process a specific= poll message. Comparing the greeting and login services can easily identi= fy relay object support issues. In the end, there is no need to utilize a protocol extension to create a tr= ansient poll message object and mix a protocol extension for the command an= d an object extension for the response. Please provide your feedback. Thanks, =97 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 On Jan 13, 2015, at 5:09 AM, Rik Ribbers > wrote: James, Thank you for the feedback. My feedback on issue 1 and 2: I get a feeling we are running in circles. All arguments have been mentione= d in previous posts on this mailinglist. So what it boils down to is what t= he rest of the WG thinks of this. So I politely , but urgently ask the oth= er members on this list to respond to the question: Should we reconsider ex= tending EPP with a new command and use the object or protocol extension Jam= es proposes (see http://www.ietf.org/mail-archive/web/eppext/current/msg002= 41.html) If there are no responses the authors and the WG cannot make progr= ess on this document. For issue 3 and 4: We will incorporate the changes in the next version of t= he draft. Gr, Rik From: Gould, James [mailto:JGould@verisign.com] Sent: vrijdag 9 januari 2015 15:29 To: Rik Ribbers Cc: eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Rik, Below is my feedback to the updated draft: 1. As noted in past mailing list comments and in person discussions, I d= on=92t agree with the mixing of a protocol extension for the command and an= object mapping for the poll response. I have provided examples of impleme= nting this draft using either an object mapping or a command response exten= sion of domain. In it=92s current form, I=92m assuming that the EPP greeti= ng and login would include the urn:ietf:params:xml:ns:relay-1.0 URI in both= a and an element. I highly recommend that you reconside= r this. 2. You are making keyrelay more generic by creating a new extension poin= t of the data to relay, with the key data being one concrete type. I still= believe that creating a Key Relay Object Mapping would have been the best = route to go, since the creation of a Key Relay object would add it into the= poll queue for consumption by the losing registrar. The only command supp= orted by the mapping is create along with the poll info response. The crea= te is creating a transient object. If other types of data need to be =93re= layed=94, a similar approach could be taken without having to add an additi= onal layer of extensibility. A new EPP object mapping would be defined for= the new type. The key relay along with any other relay objects will be pr= operly exposed in the EPP greeting and login elements. 3. Nit in 3.1.1, =93An OPTIONAL (client transaction identifier)= element that MAY be used to uniquely identify the command to the registrar= =94, should reference client instead of registrar. 4. What is the expected response to the command? I=92m assuming= that it=92s as EPP response as defined in section 2.6 of RFC 5730 where th= e value is set with the value associated with the comma= nd if supplied by the client. Regards, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 8:41 AM, Rik Ribbers > wrote: All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <81262FB7390DBA48B8378D3B0F89AE89@verisign.com> Content-Transfer-Encoding: quoted-printable All,

I agree with Rik that more from the WG must weigh in on this.  I = believe Rik and I understood fully each others perspective, but we simply d= on=92t agree.  Please take some time to review the two different appro= aches and reply to the list with your opinion.  

To be clear, my preferred approach is to use an object extension for b= oth the command and the poll message response as in:

Command looks like:

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"
  xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0"= ;>
 <command>
   <create>
     <keyrelay:create>
       <keyrelay:name>example.org</keyrelay:name>
       <keyrelay:keyData>
          <secDNS:flags>256</secDNS:= flags>
          <secDNS:protocol>3</secDNS= :protocol>
          <secDNS:alg>8</secDNS:alg&= gt;
          <secDNS:pubKey>cmlraXN0aGViZX= N0</secDNS:pubKey>
       </keyrelay:keyData>
       <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</d= omain:pw>
       </keyrelay:authInfo>
       <keyrelay:expiry>
          <keyrelay:relative>P1M13D<= /keyrelay:relative>
       </keyrelay:expiry>
     </keyrelay:create>
   </create>
   <clTRID>123456</clTRID>
 </command>
</epp>

Poll message looks like:

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"
  xmlns:keyrelay=3D"urn:ietf:params:xml:ns:keyrelay-1.0"= ;>
  <response>
    <result code=3D"1301">
       <msg>Command completed successfully; = ack to dequeue</msg>
    </result>
    <msgQ count=3D"5" id=3D"12345">= ;
       <qDate>1999-04-04T22:01:00.0Z</qDa= te>
       <msg>Key Relay message.</msg>
    </msgQ>
    <resData>
      <keyrelay:infData>
        <keyrelay:name paResult=3D"true&qu= ot;>example.org
        </keyrelay:name>
        <keyrelay:paDate>1999-04-04T22:01:00= .0Z
        </keyrelay:paDate>
        <keyrelay:keyData>
          <secDNS:flags>256</secDNS:= flags>
          <secDNS:protocol>3</secDNS= :protocol>
          <secDNS:alg>8</secDNS:alg&= gt;
          <secDNS:pubKey>cmlraXN0aGViZX= N0</secDNS:pubKey>
        </keyrelay:keyData>
        <keyrelay:authInfo>
          <domain:pw>JnSdBAZSxxzJ</d= omain:pw>
        </keyrelay:authInfo>
        <keyrelay:expiry>
          <keyrelay:relative>P24D</k= eyrelay:relative>
        </keyrelay:expiry>
        <keyrelay:reID>ClientX</keyrelay:= reID>
        <keyrelay:acID>ClientY</keyrelay:= acID>
      </keyrelay:infData>
    </resData>
    <trID>
       <clTRID>BCD-23456</clTRID>
       <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>


The latest version of draft-ietf-eppext-keyrelay incorporates a g= eneral r:relayData element with a new extension point for concrete data to = relay as in k:keyRelayData.  If an object extension was used, new rela= y data would be represented using another object extension, which will be present in the greeting and login list of = objURI=92s.  For example, if I wanted to relay a Hello World message, = I would create a Hello World object extension with the URI urn:ietf:params:= xml:ns:helloworld-1.0, that follows the relay protocol pattern of defining the create command and the info respons= e for the poll message.  

Command looks like:

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"
  xmlns:helloworld=3D"urn:ietf:params:xml:ns:helloworld-1.0&= quot;>
 <command>
   <create>
     <helloworld:create>
       <helloworld:value>Hello World from Ji= m</keyrelay:name>
     </helloworld:create>
   </create>
   <clTRID>123456</clTRID>
 </command>
</epp>

Poll message looks like:

<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0"
  xmlns:helloworld=3D"urn:ietf:params:xml:ns:helloworld-1.0&= quot;>
  <response>
    <result code=3D"1301">
       <msg>Command completed successfully; = ack to dequeue</msg>
    </result>
    <msgQ count=3D"5" id=3D"12345">= ;
       <qDate>1999-04-04T22:01:00.0Z</qDa= te>
       <msg>Hello World Relay message.</m= sg>
    </msgQ>
    <resData>
      <helloworld:infData>
       <helloworld:value>Hello World from Ji= m</keyrelay:name>
      </keyrelay:infData>
    </resData>
    <trID>
       <clTRID>BCD-23456</clTRID>
       <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>


If both the keyrelay and helloworld extensions were supported, the svc= Menu element of the login and greeting may look like:

       <svcMenu>
         <version>1.0</version>
         <lang>en</lang>
         <lang>fr</lang>
         <objURI>urn:ietf:params:xml:ns:obj1</objURI>
         <objURI>urn:ietf:params:xml:ns:obj2</objURI>
         <objURI>urn:ietf:params:xml:ns:obj3</objURI>
         ...

         <objURI>urn:ietf:params:xml:ns:keyr=
elay-1.0</objURI>

         <objURI><=
span style=3D"font-family: Verdana; white-space: normal;">urn:ietf:params:x=
ml:ns:helloworld-1.0</objURI>

         ...
         =
<svcExtension>
           <extURI>http://custom/obj1ext-1.0</extURI>
         </svcExtension>
       </svcMenu>

In doing so, the server will be able to know whether or not the client= supports the specific relay message type.  There is a general questio= n of what the server should do in the event that the client cannot process = a specific poll message.  Comparing the greeting and login services can easily identify relay object support issue= s.  

In the end, there is no need to utilize a protocol extension to create= a transient poll message object and mix a protocol extension for the comma= nd and an object extension for the response.  

Please provide your feedback.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 13, 2015, at 5:09 AM, Rik Ribbers <rik.ribbers@sidn.nl> wrote:

James,
 
Thank you for the feedback.
 
My feedback on issue 1 and 2:
 
I get a feeling we are running in circles. = All arguments have been mentioned in previous posts on this mailinglist. So= what it boils down to is what the rest of the WG thinks of this. So I politely , but  urgently ask the other= members on this list to respond to the question: Should we reconsider exte= nding EPP with a new command and use the object or protocol extension James= proposes (see http://www.ietf.org/mail-ar= chive/web/eppext/current/msg00241.html) If there are no responses the authors and the WG cannot make progress on t= his document.
 
For issue 3 and 4: We will incorporate the = changes in the next version of the draft.
 
Gr,
Rik  
 
 
 
From: = Gould, James [mailto:JGould@verisign.com] 
Sent: vrijdag 9 ja= nuari 2015 15:29
To: Rik Ribbers Cc: e= ppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Rik,
 
Below is my feedback to the updated draft:
 
  1. As noted in past mailing list comments and in person discussions, I don=92t= agree with the mixing of a protocol extension for the command and an objec= t mapping for the poll response.  I have provided examples of implemen= ting this draft using either an object mapping or a command response extension of domain.  In it=92s current= form, I=92m assuming that the EPP greeting and login would include the urn= :ietf:params:xml:ns:relay-1.0 URI in both a <objURI> and an <extUR= I> element.  I highly recommend that you reconsider this.    
  2. Nit in 3.1.1, =93An OPTIONAL <clTRID> (client transaction identifier)= element that MAY be used to uniquely identify the command to the registrar= =94, should reference client instead of registrar. 
    3. What is the expected response to the <relay> command?  I=92m ass= uming that it=92s as EPP response as defined in section 2.6 of RFC 5730 whe= re the <clTRID> value is set with the <r:clTRID> value associat= ed with the command if supplied by the client.
 
Regards,
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com=
 
On Jan 8, 2015, at 8:41 AM, Rik Ribbers <rik.ribbers@si= dn.nl> wrote:


All,
 
As you (may) have noticed we submitted a new version of the keyrelay= draft. In this draft we tried to solve all the open issues, remarks and fe= edback we received.
 
The major  changes are:
 
  1.  Introducing the <relay> command, and thus sepe= rating the data and
       the command.<= /div>
 
   2.  Updated the Introduction, describing the gener= al use of relay vs
       the intended use-case of relayi= ng DNSSEC key data.
 
   3.  Restructuring the document to make it more inl= ine with existing
       EPP extensions.
 
In the end it has become a major rewrite and as always feedback is w= elcome.
 
Kind regards,
Rik Ribbers
_________= ______________________________________
EppExt mailing list
EppExt@ietf.org
https://w= ww.ietf.org/mailman/listinfo/eppext

--_000_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_-- --_004_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 13:22:31 GMT"; modification-date="Tue, 13 Jan 2015 13:22:31 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_472EF0011A034C50A7DB3D6B766B3BA8verisigncom_-- From nobody Tue Jan 13 05:34:35 2015 Return-Path: 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 E4B191A8ADA for ; Tue, 13 Jan 2015 05:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 W2FcCAgTSyFz for ; Tue, 13 Jan 2015 05:34:29 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CFC01A8ADD for ; Tue, 13 Jan 2015 05:34:25 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKVLUe4Pkpob+5Orj2j1L4iov/NSKNStXj@postini.com; Tue, 13 Jan 2015 05:34:28 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0DDYNDM032619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:34:23 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 08:34:23 -0500 From: "Gould, James" To: "Tran, Trung" Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgAEEEYA= Date: Tue, 13 Jan 2015 13:34:22 +0000 Message-ID: <7D5A771D-7B44-4868-B996-00305D07FE77@verisign.com> References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> In-Reply-To: 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_7D5A771D7B444868B99600305D07FE77verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Jody Kolker , Francisco Obispo , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 13:34:34 -0000 --_004_7D5A771D7B444868B99600305D07FE77verisigncom_ Content-Type: multipart/alternative; boundary="_000_7D5A771D7B444868B99600305D07FE77verisigncom_" --_000_7D5A771D7B444868B99600305D07FE77verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Trung, Got it, so it=92s really for resale or recreate use cases post the initial = create. I believe that supporting the claims check with =93claims=94 as th= e phase post the =93claims=94 phase would address this use case, since all = domains that have trademarks in the =93claims=94 phase will return exists= =3D=931=94 as desired. The question is whether the draft should provide te= xt to cover this use case and I=92m assuming that this behavior is a MAY, m= eaning servers MAY support this behavior. Do the registrars on the list se= e a need for this behavior and feel that using the claims check with =93cla= ims=94 as the phase post the =93claims=94 phase is acceptable and how stron= g of a need is this (MAY or SHOULD). Thanks, =97 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 On Jan 12, 2015, at 10:04 PM, Tran, Trung > wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 --_000_7D5A771D7B444868B99600305D07FE77verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Trung,

Got it, so it=92s really for resale or recreate use cases post the ini= tial create.  I believe that supporting the claims check with =93claim= s=94 as the phase post the =93claims=94 phase would address this use case, = since all domains that have trademarks in the =93claims=94 phase will return exists=3D=931=94 as desired.  The question is wheth= er the draft should provide text to cover this use case and I=92m assuming = that this behavior is a MAY, meaning servers MAY support this behavior. &nb= sp;Do the registrars on the list see a need for this behavior and feel that using the claims check with =93claims=94 as the pha= se post the =93claims=94 phase is acceptable and how strong of a need is th= is (MAY or SHOULD).  

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 12, 2015, at 10:04 PM, Tran, Trung <Trung.Tran@neustar.biz> wrote:

This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <= trung.tran@neustar.biz> Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

= =97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From F= rancisco:
 =
Thanks= Jim for bringing this to the eppext.  This will definitely help the p= ost claims phase.
 =
With t= he wording changes, is there still a way to determine if there=92s a tradem= ark against the name regardless on whether or not the claims ack is needed = in the create domain?  
 
This could be accomplished by leaving the =93claims=94 imp= lementation as it is currently and introducing a sub-phase for claims named= =93extended=94.  When the sup-phase of =93extended=94 is passed the results from Jim=92s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim= currently exists on a domain when a claim period does not exist for the TL= D (the current implementation).  From a registrar perspective, I=92m not sure if determining if a domain has a c= laim when all claims periods have expired is needed.  This implementat= ion also would require additional work by all registrars to support if adop= ted, while the implementation from Jim=92s first post would require only updates by the registries which would be bet= ter for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct superv= isor Charles Beadnall (cbeadnall@= godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended = for use only by the addressee(s) named herein and may contain confidential = information. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.<= /o:p>
 
From:=  Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppext@ietf.o= rg; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<= span style=3D"font-size: 9pt; font-family: Verdana, sans-serif;">
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobis= po@uniregistry.com> wrote:


<launch:phase>  = ;SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@veris= ign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newpo= rt Beach, CA, 92660
off. = +1.345.749.6284
fax. = +1.345.746.6263

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

--_000_7D5A771D7B444868B99600305D07FE77verisigncom_-- --_004_7D5A771D7B444868B99600305D07FE77verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 13:34:22 GMT"; modification-date="Tue, 13 Jan 2015 13:34:22 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_7D5A771D7B444868B99600305D07FE77verisigncom_-- From nobody Tue Jan 13 05:44:54 2015 Return-Path: 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 B1EBD1A8AE6 for ; Tue, 13 Jan 2015 05:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 i1ouRBRB2y6O for ; Tue, 13 Jan 2015 05:44:47 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29221A8AD8 for ; Tue, 13 Jan 2015 05:44:45 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKVLUhTej31ld8//7HtdBuXSspqnaPV0bc@postini.com; Tue, 13 Jan 2015 05:44:46 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0DDiibN028594 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 08:44:44 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 08:44:43 -0500 From: "Gould, James" To: Michael Holloway Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgA== Date: Tue, 13 Jan 2015 13:44:43 +0000 Message-ID: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> In-Reply-To: <54B4D4F1.6070405@comlaude.com> 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_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 13:44:53 -0000 --_004_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_ Content-Type: multipart/alternative; boundary="_000_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_" --_000_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, The split out of the responsibility of the registries and the CNIS / TMDB w= as worked out a couple of years ago, where there was a desire to not make t= he CNIS the critical path for the majority of the registrations. The agree= ment was for the registries to provide the claims check service and enforce= the claims notice on create based on a feed of trademark labels from the T= MDB to the registries. The proposal is to support the claims service post the =93claims=94 phase b= y passing the active phase to the server and the server will return whether= or not the claims notice is required based on a combination of a matching = trademark and whether the domain name already went through 90 days of the c= laims service. From a client perspective it means utilizing the claims che= ck in a similar fashion during and post the claims phase. The use case bro= ught up by Trung was more of an exception to the rule, in the client wantin= g to know whether there is a matching trademark for a domain name independe= nt of the requirement for passing the claims notice. In that case, the pro= posal is to pass =93claims=94 as the phase independent of the active phase = to get a true or false answer to whether a trademark matches the domain nam= e. Do the proposals work for you? Thanks, =97 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 On Jan 13, 2015, at 3:18 AM, Michael Holloway > wrote: Hi all Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= . The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not t= o submit claims data in a domain_create if the domain has a claim. As it is= , various registries are extending the claims periods past 90 days, so its = contradictory to have extended claims and post claims defined the same way = in the query but without a defined (or facilitated) way to differentiate th= e requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 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 On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Michael,

The split out of the responsibility of the registries and the CNIS / T= MDB was worked out a couple of years ago, where there was a desire to not m= ake the CNIS the critical path for the majority of the registrations.  = ;The agreement was for the registries to provide the claims check service and enforce the claims notice on creat= e based on a feed of trademark labels from the TMDB to the registries. &nbs= p;

The proposal is to support the claims service post the =93claims=94 ph= ase by passing the active phase to the server and the server will return wh= ether or not the claims notice is required based on a combination of a matc= hing trademark and whether the domain name already went through 90 days of the claims service.  From a clie= nt perspective it means utilizing the claims check in a similar fashion dur= ing and post the claims phase.  The use case brought up by Trung was m= ore of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name in= dependent of the requirement for passing the claims notice.  In that c= ase, the proposal is to pass =93claims=94 as the phase independent of the a= ctive phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:
Hi all

Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= .

The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a cla= im. As it is, various registries are extending the claims periods past 90 d= ays, so its contradictory to have extended claims and post claims defined t= he same way in the query but without a defined (or facilitated) way to differentiate the requirement for a doma= in_create.

I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB.=

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign= .com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>= ;
Cc: Francisco Obispo <fobispo@uniregist= ry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

= =97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com=

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:
From Francisco:
 
Thanks Jim for bringing t= his to the eppext.  This will definitely help the post claims phase.
 
With the wording changes,= is there still a way to determine if there=92s a trademark against the nam= e regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving th= e =93claims=94 implementation as it is currently and introducing a sub-phas= e for claims named =93extended=94.  When the sup-phase of =93extended= =94 is passed the results from Jim=92s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to de= termine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar= perspective, I=92m not sure if determining if a domain has a claim when al= l claims periods have expired is needed.  This implementation also wou= ld require additional work by all registrars to support if adopted, while the implementation from Jim=92s first post wo= uld require only updates by the registries which would be better for widesp= read adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please cont= act my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments= hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in e= rror, please immediately notify the sender and permanently delete the origi= nal and any copy of this message and its attachments.
 
From:<= /span> Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97<= /div>
 =

JG<= /p>

 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com&g= t; wrote:


<launch:p= hase>  SHOULD contain the value of "claims" to indicate t= he
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@ver= isign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Francisco Obispo
CTO = - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 926= 60
off. +1.345.749.6284=
fax. +1.345.746.6263= 



_______________________________________________
EppExt mailing list
EppEx=
t@ietf.org
https://www.ietf.org/mailman/listinfo/eppext
_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinfo/eppext

--_000_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_-- --_004_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 13:44:43 GMT"; modification-date="Tue, 13 Jan 2015 13:44:43 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_EF1D8AA2F3404782BE72BB271203C1D1verisigncom_-- From nobody Tue Jan 13 05:58:36 2015 Return-Path: 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 C0C621A8A6C for ; Tue, 13 Jan 2015 05:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 hSc4Oonz7S6b for ; Tue, 13 Jan 2015 05:58:32 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E0F1A8AE2 for ; Tue, 13 Jan 2015 05:58:32 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVLUkhw/CX5Ji4fk++CiwndD3dY8Gva6R@postini.com; Tue, 13 Jan 2015 05:58:32 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0DDwU17030178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 13 Jan 2015 08:58:30 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 08:58:30 -0500 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: draft-ietf-eppext-launchphase Implementation Status Input Thread-Index: AQHQLzkCPABomTw47kGPYf7V8fjY6Q== Date: Tue, 13 Jan 2015 13:58:29 +0000 Message-ID: <921AEA32-BA4C-461A-96FA-07D5EFC99B61@verisign.com> 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_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] draft-ietf-eppext-launchphase Implementation Status Input X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 13:58:34 -0000 --_004_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_ Content-Type: multipart/alternative; boundary="_000_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_" --_000_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92m requesting input from the community to include in the draft-ietf-eppe= xt-launchphase Implementation Status Section discussed at the IETF-91 EPPEX= T meeting. In following RFC 6982, please provide the following publicly or= privately. An empty field (e.g. URL) may be left out: Organization: [Organization Name] Name: [Implementation Name] Description: [Description of implementation] Level of maturity: [Where is the implementation deployed?] Coverage: [Elements of draft-ietf-eppext-launchphase Implemented] Licensing: [Implementation Licensing] Contact: [Implementation Contact E-mail] URL: [URL describing the implementation or where the implementation is made= available] Below is an example of the Implementation Status section for the Verisign E= PP SDK: Organization: Verisign Inc. Name: Verisign EPP SDK Description: The Verisign EPP SDK includes both a full client implementatio= n and a full server stub implementation of draft-ietf-eppext-launchphase. Level of maturity: Production Coverage: All aspects of the protocol are implemented. Licensing: GNU Lesser General Public License Contact: jgould@verisign.com URL: http://www.verisigninc.com/en_US/channel-resources/domain-registry-pro= ducts/epp-sdks Any and all feedback is welcome. Thanks, =97 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 =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <168988846516624F9428168010ED0DA5@verisign.com> Content-Transfer-Encoding: quoted-printable Hi,

I=92m requesting input from the community to include in the draft= -ietf-eppext-launchphase Implementation Status Section discussed at the IET= F-91 EPPEXT meeting.  In following RFC 6982, please provide the follow= ing publicly or privately.  An empty field (e.g. URL) may be left out:

Organization: [Organization Name]

Name: [Implementation Name]

Description: [Description of implementation]

Level of maturity: [Where is the implementation deployed?]

Coverage: [Elements of draft-ietf-eppext-launchphase Implemented]=

Licensing: [Implementation Licensing]

Contact: [Implementation Contact E-mail]

URL: [URL describing the implementation or where the implementation is= made available]


Below is an example of the Implementation Status section for the Veris= ign EPP SDK:

Organization: Verisign Inc.

Name: Verisign EPP SDK

Description: The Verisign EPP SDK includes both a full client implementatio= n and a full server stub implementation of draft-ietf-eppext-launchphase.

Level of maturity: Production

Coverage: All aspects of the protocol are implemented.

Licensing: GNU Lesser General Public License

Contact: jgould@verisign.com

URL: http://www.verisigninc.com/en_US/channel-resources/domain-registry-products= /epp-sdks


Any and all feedback is welcome. 

Thanks,


=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_-- --_004_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 13:58:29 GMT"; modification-date="Tue, 13 Jan 2015 13:58:29 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_921AEA32BA4C461A96FA07D5EFC99B61verisigncom_-- From nobody Tue Jan 13 07:09:17 2015 Return-Path: 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 315CB1A8F3F for ; Tue, 13 Jan 2015 07:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 tn672wH19N2K for ; Tue, 13 Jan 2015 07:08:50 -0800 (PST) Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com [108.166.43.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858391A8AE6 for ; Tue, 13 Jan 2015 07:08:21 -0800 (PST) Received: from smtp23.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DE5692805B6; Tue, 13 Jan 2015 10:08:20 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D7B62280601; Tue, 13 Jan 2015 10:08:20 -0500 (EST) X-Virus-Scanned: OK Received: by smtp23.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 479292805B6; Tue, 13 Jan 2015 10:08:19 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E66C0.dip0.t-ipconnect.de [87.142.102.192]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Tue, 13 Jan 2015 15:08:20 GMT Message-ID: <54B534E2.8050001@comlaude.com> Date: Tue, 13 Jan 2015 16:08:18 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Gould, James" References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070202070009010008090902" Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 15:09:01 -0000 This is a multi-part message in MIME format. --------------070202070009010008090902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from. Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in _underlined red_) 1) A registry _must_ operate a 90 days claims phase 2) A registry _must_ operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future) 3) A registry _may_ operate a continued claims phase past the 90 domains for all domains. [create with claims form] 4) [new]: A registry _may_ operate a post claims (matching trademark past the claims phase use case) [create without claims] If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate. I hope this makes sense; and apologies if I am missing something fundamental! Cheers, Michael 1. During claims phase with a claims check command 1. If domain has matching trademark 1. return exists=true 2. else 1. return exists=false 2. During post claims phase with a claims check command 1. If domain was released post claims phase start and is within 90 days of release and has matching trademark 1. return exists=true 2. else 1. return exists=false 3. *During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)* 1. *If domains has matching trademark * 1. *return exists=true *_## The claims exists but it is NOT required on domain_create_ 2. *else* 1. *return exists=false* 1. During claims phase with a create command 1. If domain has matching trademark 1. claims notice is required 2. else 1. claims notice is NOT required 2. During post claims phase with a create command 1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return ## How does the client know if 90 days has passed (extended / post claims) or not without external source? 1. claims notice is required 2. else 1. claims notice is NOT required * Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com On 01/13/2015 02:44 PM, Gould, James wrote: > Michael, > > The split out of the responsibility of the registries and the CNIS / > TMDB was worked out a couple of years ago, where there was a desire to > not make the CNIS the critical path for the majority of the > registrations. The agreement was for the registries to provide the > claims check service and enforce the claims notice on create based on > a feed of trademark labels from the TMDB to the registries. > > The proposal is to support the claims service post the “claims” phase > by passing the active phase to the server and the server will return > whether or not the claims notice is required based on a combination of > a matching trademark and whether the domain name already went through > 90 days of the claims service. From a client perspective it means > utilizing the claims check in a similar fashion during and post the > claims phase. The use case brought up by Trung was more of an > exception to the rule, in the client wanting to know whether there is > a matching trademark for a domain name independent of the requirement > for passing the claims notice. In that case, the proposal is to pass > “claims” as the phase independent of the active phase to get a true or > false answer to whether a trademark matches the domain name. > > Do the proposals work for you? > > Thanks, > > — > > > JG > > > > > *James Gould > *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 13, 2015, at 3:18 AM, Michael Holloway > > > wrote: > >> Hi all >> >> Just a thought; would it not be more appropriate to facilitate this >> on the TMDB by adding a lookup based on label. This could return a >> simple true/false value, or all the info returned on a CNIS lookup >> exception notice_id etc. >> >> The problem with having and post claims service on the EPP server >> without changing the phase name is that the EPP client then has to >> decide when /not/ to submit claims data in a domain_create if the >> domain has a claim. As it is, various registries are extending the >> claims periods past 90 days, so its contradictory to have extended >> claims and post claims defined the same way in the query but without >> a defined (or facilitated) way to differentiate the requirement for a >> domain_create. >> >> I would be more comfortable with defining a specific sub_phase for >> the purpose, or even better skipping the middle man and going >> straight to the TMDB. >> >> Cheers, >> Michael >> >> *Michael Holloway >> Senior Systems Administrator**| Com Laude* >> E: michael.holloway@comlaude.com >> >> >> On 01/13/2015 04:04 AM, Tran, Trung wrote: >>> This works for me, Jim. Though it’s not often, we have cases where >>> change in ownership of a domain might not occur if there’s trademark >>> against the name. So a potential registrant might not want to buy >>> an existing registered name if there’s trademark against it in the TMCH. >>> >>> Thanks, >>> Trung >>> From: , James > >>> Date: Friday, January 9, 2015 at 11:27 AM >>> To: Jody Kolker > >>> Cc: Francisco Obispo >> >, "eppext@ietf.org >>> " >> >, "Tran, Trung" >> > >>> Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a >>> "Claims Service" post the Claims Phase >>> >>> Jody, >>> >>> I believe that passing the active phase is more straight forward >>> as opposed to defining a special sub-phase like “extended" to >>> drive the behavior. Having the claims check return >>> “exists=true” only when a claims notice is required on the >>> create based on the active phase should be able to handle the >>> use case of releasing domains post the claims phase and also >>> applies to the claims phase. All names that have matching >>> trademarks during the claims phase will require a claims notice >>> on create, so the behavior is consistent. >>> >>> I’m still not sure why a client would want to know whether there >>> is a matching trademark when a claims notice is not required on >>> the create. Does anyone see a need for this? Since the >>> “claims” phase would always return “exists=true” for domains >>> that have matching trademarks, a client could pass the “claims” >>> phase when the active phase is not the “claims” phase to obtain >>> this information. Of course servers would need to support >>> referencing a past “claims” phase to support this use case. The >>> change in the text should support the logic that I previously >>> posted before, which I extend to support addressing the optional >>> matching trademark past the claims phase use case. Is this use >>> case really needed? >>> >>> 1. During claims phase with a claims check command >>> 1. If domain has matching trademark >>> 1. return exists=true >>> 2. else >>> 1. return exists=false >>> 2. During post claims phase with a claims check command >>> 1. If domain was released post claims phase start and is >>> within 90 days of release and has matching trademark >>> 1. return exists=true >>> 2. else >>> 1. return exists=false >>> 3. *During post claims phase with a claims phase check and >>> passing “claims” as the phase (optional matching trademark >>> past the claims phase use case)* >>> 1. *If domains has matching trademark * >>> 1. *return exists=true* >>> 2. *else* >>> 1. *return exists=false* >>> >>> >>> 1. During claims phase with a create command >>> 1. If domain has matching trademark >>> 1. claims notice is required >>> 2. else >>> 1. claims notice is NOT required >>> 2. During post claims phase with a create command >>> 1. If domain was released post claims phase start and is >>> within 90 days of release and has matching trademark return >>> 1. claims notice is required >>> 2. else >>> 1. claims notice is NOT required >>> >>> >>> Thoughts? >>> >>> — >>> >>> JG >>> >>> >>> >>> >>> *James Gould >>> *Distinguished Engineer >>> jgould@Verisign.com >>> >>> 703-948-3271 >>> 12061 Bluemont Way >>> Reston, VA 20190 >>> >>> VerisignInc.com >>> >>> >>> On Jan 8, 2015, at 4:50 PM, Jody Kolker >> > wrote: >>> >>>> From Francisco: >>>> Thanks Jim for bringing this to the eppext. This will >>>> definitely help the post claims phase. >>>> With the wording changes, is there still a way to determine if >>>> there’s a trademark against the name regardless on whether or >>>> not the claims ack is needed in the create domain? >>>> This could be accomplished by leaving the “claims” >>>> implementation as it is currently and introducing a sub-phase >>>> for claims named “extended”. When the sup-phase of “extended” >>>> is passed the results from Jim’s earlier email would be below. >>>> >>>> 1. During claims phase with a claims check command or post >>>> claims phase without a sub-phase of “extended” >>>> 1. If domain has matching trademark >>>> 1. return exists=true >>>> 2. else >>>> 1. return exists=false >>>> 2. During post claims phase with a claims check command with a >>>> sub-phase of “extended” >>>> 1. If domain was released post claims phase start and is >>>> within 90 days of release and has matching trademark >>>> 1. return exists=true >>>> 2. else >>>> 1. return exists=false >>>> >>>> 1. During claims phase with a create command or post claims >>>> phase without a sub-phase of “extended” >>>> 1. If domain has matching trademark >>>> 1. claims notice is required >>>> 2. else >>>> 1. claims notice is NOT required >>>> 2. During post claims phase with a create command with a >>>> sub-phase of “extended” >>>> 1. If domain was released post claims phase start and is >>>> within 90 days of release and has matching trademark >>>> return >>>> 1. claims notice is required >>>> 2. else >>>> 1. claims notice is NOT required >>>> >>>> This would still allow a registrar to determine if a claim >>>> currently exists on a domain when a claim period does not exist >>>> for the TLD (the current implementation). From a registrar >>>> perspective, I’m not sure if determining if a domain has a >>>> claim when all claims periods have expired is needed. This >>>> implementation also would require additional work by all >>>> registrars to support if adopted, while the implementation from >>>> Jim’s first post would require only updates by the registries >>>> which would be better for widespread adoption. >>>> Thoughts? >>>> Thanks, >>>> Jody Kolker >>>> 319-294-3933 (office) >>>> 319-329-9805 (mobile) Please contact my direct supervisor >>>> Charles Beadnall (cbeadnall@godaddy.com >>>> ) with any feedback. >>>> This email message and any attachments hereto is intended for >>>> use only by the addressee(s) named herein and may contain >>>> confidential information. If you have received this email in >>>> error, please immediately notify the sender and permanently >>>> delete the original and any copy of this message and its >>>> attachments. >>>> *From:*Gould, James [mailto:JGould@verisign.com] >>>> *Sent:*Thursday, January 08, 2015 12:24 PM >>>> *To:*Francisco Obispo >>>> *Cc:*Jody Kolker;eppext@ietf.org ; >>>> Tran, Trung >>>> *Subject:*Re: [eppext] draft-ietf-eppext-launchphase Support >>>> for a "Claims Service" post the Claims Phase >>>> Francisco, >>>> I would have gone with the sub-phase approach as well, since if >>>> the behavior between the two claims phases are consistent (e.g. >>>> requirement for claims check and claims notice) I’m not sure >>>> the value in defining a new top-level phase name. Is there a >>>> material behavior change between the two phases and is the >>>> concept of an extended claims phase a generic use case? We >>>> have stuck with the standard set of “sunrise”, “claims”, and >>>> “open” phases. Have others utilized the use of sub-phases or >>>> have created custom top-level phase names to meet their needs? >>>> If so, can you share your scheme? It would be good to know if >>>> there are any common patterns. >>>> Thanks, >>>> — >>>> >>>> JG >>>> >>>> >>>> >>>> >>>> *James Gould >>>> *Distinguished Engineer >>>> jgould@Verisign.com >>>> >>>> 703-948-3271 >>>> 12061 Bluemont Way >>>> Reston, VA 20190 >>>> >>>> VerisignInc.com >>>> >>>> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >>>> > wrote: >>>> >>>> >>>> SHOULD contain the value of >>>> "claims" to indicate the >>>> claims launch phase. A value other than >>>> "claims" MAY be used to >>>> pass the claims notice for domain names outside >>>> of the claims phase. >>>> >>>> Once a TLD has ended the mandatory 90 day period of >>>> “claims” a registry might decide to call it something else. >>>> We are not supporting extended claims, but we had to >>>> support an extended sunrise for the names on the ICANN >>>> names-collision block list (30 day period instead of a 60 >>>> day end-date sunrise), and we initially thought about >>>> having a phase called “sunrise” with a sub-phase called >>>> “extended” but we thought it would be too complicated for >>>> RARs to change their code, so we decided just to trigger it >>>> by calling the phase “sunsrise”, but in reality, a registry >>>> can call it anything they want in order to support it, >>>> because they are different things. >>>> Since there is no guidance on what the phases should be >>>> called, it seems like we’re going to end up with discrete >>>> phase names for anything that is not: claims or sunrise. >>>> >>>> On Jan 8, 2015, at 11:35 AM, Gould, James >>>> > wrote: >>>> >>>> What do you mean by the extended claims phase? Is >>>> there a past mail list thread on this or is this a new >>>> issue? Please clarify. >>>> >>>> *Francisco Obispo* >>>> CTO - Registry Operations >>>> >>>> >>>> >>>> >>>> 2161 San Joaquin Hills Rd. >>>> Newport Beach, CA, 92660 >>>> off. +1.345.749.6284 >>>> fax. +1.345.746.6263 >>>> >>> >>> >>> >>> _______________________________________________ >>> EppExt mailing list >>> EppExt@ietf.org >>> https://www.ietf.org/mailman/listinfo/eppext >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext > --------------070202070009010008090902 Content-Type: multipart/related; boundary="------------050304050903020008070903" --------------050304050903020008070903 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi

Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from.

Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domains for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create without claims]

If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate.

I hope this makes sense; and apologies if I am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true ## The claims exists but it is NOT required on domain_create
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return ## How does the client know if 90 days has passed (extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / TMDB was worked out a couple of years ago, where there was a desire to not make the CNIS the critical path for the majority of the registrations.  The agreement was for the registries to provide the claims check service and enforce the claims notice on create based on a feed of trademark labels from the TMDB to the registries.  

The proposal is to support the claims service post the “claims” phase by passing the active phase to the server and the server will return whether or not the claims notice is required based on a combination of a matching trademark and whether the domain name already went through 90 days of the claims service.  From a client perspective it means utilizing the claims check in a similar fashion during and post the claims phase.  The use case brought up by Trung was more of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name independent of the requirement for passing the claims notice.  In that case, the proposal is to pass “claims” as the phase independent of the active phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

—


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.  

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

—

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.
 
With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
 
  1. During claims phase with a create command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
 
From: Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.  
 
Thanks,
 
—
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase.  
 
 
Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



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


--------------050304050903020008070903 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAtgAAABaCAIAAAANVraoAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAA3XFJREFUeNrsXQdgFNXWvnfKlvQQQkJJgKB0CwQQKwoB7CgY LCj2oD57C5Yf37OCPnslYOFZIVjAJ1KCCkonqChVCCUh1PS2ZWbuf26ZsrtJKKI+NWNcZmdu m9mZud+c853v4LVr17rYIsuyJEmoZfnbLISQRrdjjI+gYvO1CFsardV8RYMQ+MNhXcMWR0Vn 43wFPjVdNwwjctBwiZPQUVnV4VPXdaho9UJ4GYQUuDewZBDDWcvj8SQlJcGWGasWzf12vKbt iotNxZIM5bF5J2EJIyyOkzaKEaHDZhvZV/Y/NvioCPyHWafs2NkK/WNF+brOToYh/rfLs0+x brAydN3gu8ztrD+xhfAtdB3+Ibw8MT9ZGZ2ILvhozDLYMEfIfxnWIy1mINYTsksiu1mMrF2O 0SJx1Mi519zcsrQsLctfejHYs0M38MaNG71er9vtVhSlBYi0wJFfg0V+QzhiGKSx3mUsJjML SVhdQIOARDSoaBjY0Q6f+eFS5+thWARqQRUD4AjU4hs5HEG0EQDrGNGKsA0+oTB8JrVKioqO gjLPzH523oon2sSg2Ng0Nu0C5JBMwIERP0SMnVsIm50xFpO9BReIOSvTVtiEbZhzOUcPFLsY Yqo2zCk/rAxhZcxmMYcLtKLAECakYHjFAkMWTOE4wzAhkQXqONCxgQuxwA0KQznEwkmNYRGz NRtImaDEwpctWKRlaVn+wnMPu8l1A2kGLioqioqKAiCiqmoLEPnrgYyDQorf2TTSDBxp/vJj 86VBQrsGHAB1JFkOwyLi2E3TCPxB48QEFgazizQ6JKtZWIKaxtEGnzYp+iCGLMkS5nMn4YgE CnjcruQ2KVBmXemuV794ZPW6D45pE+3xttER9EvgwJjVw4IjAnNwQGStQ7M6wpYhBKMQu4VB bHBAWFXNsOd+ZMIXw1GGoQcb38AmzZ71LazA8IcTr7AVw4IXdCRYs4GIw5RCbOONo6Jp1yEO MOEELtwQRFCkIcfCXuYv7gBkLUvL0rL85eYnYREJ6njHjh3R0dEejweAiMwe6C3LX9LaccSI 5LewjjSKRXj55rpjGMLpheFTMkyS1HNi4oNIRELhiKbpSMxsYhfM0pJEr3lmG6EWFNMpwwvQ iVxjYITN5xzFUBBjUE8NloVphNeCLQnxiTHxsXVB/8If57/+5eM1ZYXpqSmq6tUpyKJ4hVAc Itw2pnUEIxkaxcxlQ7GIQbjvJsQ4ISwiDhjBDpqbRmz3jWWr0FkZzF0zlsnEdKAQxwrviBlX sNPCwcGQzsrAQ0GPMK44u7PsKxH+HdtYYu+1zB5OLILCLStO60iLaaRlaVn+mhYR3aBPK03H xcXFHIhwmkjLyfmrApHfGYtYxpim6oaxOpx9YTFRNwdinHUACEj0zR3LJhZBoW4avmgOVOHs FzsG6fTUsImcYo2gTvkmhLty6CStS4RSP2Rm6rDgCKxER0WltE5FCtqwd/vXhTPfKpjQytXQ OrEdllWCJKRwawaFHQyIyMz0gIW/hiEVhiC4y4bN98IcwwCKQCSYGySwwwgRxtVwQBNMbK6J BTVM3wovDF0EEZFMl5CjF4sRgkLL8CGZ3YmWdSL4Nw6qSrhpxGaNINtwYq7bTij+oziIIy2m kZalZfkrWkR05poJ6vLdd98NEERRlBay6l9vaQoENAMsmqFrHN1a2FwaBcqk+YrWRIUckxbz nmBHpzbUYF9l1p11kdP53gFVnLDJhi+mM4XaKhguwZR+KsG8qROddYj4Xr74Av7qmmoF4fat U/sfe0p66vENJPmnogKi17pVr4RVbE6zbAImgrzKD4B+msdsYRUsji6EYUJMLqzJPBFnwVEF WwRfVkYyj0Z8GPQw+GnkB23BIdG3qIccrYgyZjPC6EI3ErOwhamsRrCjC2T9sSPGDtxp/5rY 8mIJ7xUWRya2tCwtS8vyVzKKsFeWFiDSAlCOfi2nHcIigR56s5appMmKFoQJ3UucITZ2EWsy xTKlm2LCaB+R7FfigEfOfjGryCmuhDlk2NQuUZ8LwHlmhpEYxJElalOsqautrq6O9UZ3bd/j +G7ntIltU1rpL933A0Y+lxqFaPSNiJZx2GO4kcG2iwh2Bg7BD8gBHSzUYLeDcNh5xRFlBGCR 7CmfflD3FIKx88AeG3w4W+ZIQkJm2I9dwAkgBHqwy4Q2JdkYRBSQaMwODACAHqafmJcJwxwY HdEl27L8Jaeu0CvjV7dGQl6ASFgXGLVceS1ApGX5/Y0i6GBhLEdg5DiUwTSJSJqoaHWGQ4sZ 3DSCqesER1ZnqAI5jC7cTELdK6bXRmJL2PBkdodgSvcQXifKWpWgLxrVK5m2FnoXyTK0dqCi 3O/3tU2M692xf/u2Z6iyp/jAzqraYlVCsuKmtAs2WMzNI5iRRJx2Hn5YzFIi2cYJ8Q+FRfC/ LupZZgyn7UFmBJTIMnRSl62OzPKOcyROi+lEkh1ghDRSBmMnErH/tWwZdjEH9kJhMcxmMds0 Yk8B2Il2EEYtU8NfGGSEOeHMiyAk1LtRXIIPD5c4iNb8kWGSrYjlVnR0cZhwpJHRtgCaFiDy t8ciTeGDg8KRI7OONM8OaQZVHBkcCUNOlnuF6DpiJFaZIQNnCxxV2LOa2QiXLUFN0G8Jr2g6 RnhMDUMSVGUDupO4uYVBGbijAoHg/v37ocAxbdue2iNLcWeU11VW1u7z+w6osovaAax+JJsH YfkvCLGmadsowY/T9Gs4nSAh6IGXwZbFxSwjO80qputJDrHNcBOJDQ6I5XaxfikU5jwKMbxY bhoSAnREU87urRYskIGwI8DI+oLCfTQtj/S/LAoJCaByGPKsSd0g4aYLEglADnaJWIjHMGGH 4QjiICQkxFxccId12YWEs9sH0nLhNgFEWpDH39o60lQk7UFNI4dYEUe4TpqviJsATc1X4ywN yeRq2FiE6XyQxnwuvD1VkgCFSyYRRLA9GPtVYxW5sSSMVgKbVFWlFamBhCmVyawWxgFGhrVI J1DG4/GUV5Rv3rzZX193ycALXrrli9P73O1xtWnwa75AFQU+OnsIagwB6YhwKMTZso4AFY5K 2HRMJOa9wcytQY0y9A+QDOEoCNPoG7rFYnVgXoCVIaFlZLZCrEbYp7DOmLUo30T8iUYks1ls 1xIbrSFhZJexn+SYKOYA7L3iUU8cA47ca80FxAI9LaaRv9qkRFB237PI5CUTL75ZYAJkhqfz XW98lzt8DNKNRHc0yVsyI+cxynZkiliwJSOprWnJOIQ4K4Jyh42BRsiUpeTNZeQt+FtO3mZ/ sAJf31xmD4Mc3nHAX6I3BkY748bHQg+kZWl8aQEif0frSCSqOIJaR4xjuAJH87Uk06vivLu5 vEfztTiqII6uqSJIMEhMnRKn6YUwYEFRBTV0yM5GsKmixpgf1jZHdYS8Ho/b7YaKCiWw0hKS Q1+Eu3s4HIFlR8munTt3uBG674L7Jt2yOTHpTCMYaAg2ED3IIAhFIVwJVRKBLoYp2UEjiQmN V6FbTPMBMeGCmPudK/wcyNhCDBQr4NDCISjB/spQRQjU4GDFBjRiBTkbsbogIegHISmkZQ5r zJK210aUlES0EHISXTkWkTByohl26MRpp2lZ/iIvx8Q0VFi2ishduiFkbbgclm4ARtn65MzM Dl3NvcQR1B75ZzlfDoYMiGMYzgYjYEdYJHrIyA2noSUsZr3lVxeL0nIK/ramkUhKKToEd0wz kbrNYJFIyCJETpvmlAjehkPfnd/XmmFw40dTtSQOWbhRgdswmGkEJnqFAQ0Lzdgjx1iRZUmW g4EAsWzBDFJomiZzuRGEzFaJdSrgH7fqCqJgUNNEyAs7TI0QLRCgbbLZEgYFkAVqb9q0KSEh ISMl5Z3bphds2PD4e0MSXLVuVwxWXEwxjdI5dcxiXmQkRDokRs1g1gwkpmo+C1NYYFCGCdWR Nx+rWEQeC5V5LthhNoAsZQ5izvnm6yOcImzG19LyxJJrl0zzOH/2S9hUZ2cnIqyMafVmmIz3 SDCXVcNC7pa2Yw5YQLqQkkzBxRkbJQ7NwaExR8mDliJ4BS3LnxeLWMYDQ1z8lvZw+NSOTCEK hDLTuiVGx9KNmiEKw4UphVCukKlMaGGFSV+8O+nzaRZQWP34uxkp7VtddyayUDO1GUosVh4J IhcmZvvIvuasZi0OlY1yWOM8aN0amFUS//Eum17eVM3QN/n3t1hEWpY/Eo4cLSPHQWs1ykBq 3joCtRRTqczeyPVSGSZo8rKWJIWZMYgjKw38HwRgwVRWpVAXEPe/yFQj1a1yspS5F9YBDAWC QYPJpnEqFTYjgXkXqqp6PR6VRdYQVleiQEAKMql40Tj79Hg8dXV1RUVFVZWVWT16fPNE6cmZ r+46UOqvPyB0zdgzkdC0NpQFa+qEGKZ+CGGmEWYPkOinhJBlnLB8K1KoCSTUdWIVoOvcgCE3 VkY2TSMhDiD7q9myw3zSaO9O0wj3ASmOAWCbL2KXVB3WkSZNI07ryGHyFFuW/1UgQkIQiSMR QMi6QWwtP91h2+BAhNlIhGlEJ+LPspTwvWKjgcKeLNYKtjnVrDtDKF5YjVtGDiHJZXCpcrs7 4oRNVhUjvBHyRwr2qUG04K5r38k+V/LrfyyQbwEif+37+sh9Lr8FiLEcHGGL0TyqYHAkzASC WWhMc3CERc24FEVyeGo4iAloms5cJ5FhuojRURUmM2wNmEfEaLoRCAZ0U8XVGXHDq3NGiCox FVVOkqUC78jv99MMfGY7LIIYHygr21VSogW03POvnP1YQ0Ly5bv3FdfX7hMOcY3ZghgaIeyx SxwcOmLqnlppZjhxBKEQ2CEx/4UkOUCDjTNs1ojUWBmOKuSQWgyaYBKBRWzWCHwqIXQTEoKE RLyuDVkYsCBO1KKwYsTmqwos4gAuFvskhDiCW1gjfzHbCGl6kjZCXDarH/tP7gVXw7cZtz1V /kYBzPETR91S/tL8zA5dtz6VT6YunXzl/QAOEj0xEy++mUxdxhkh5a8syD33qhBGqrWCbc2c nEEjVj/yDmeNrP6/t3NOH+GEMonuaGgcuqBtvrls8lW5iZ5oG2QIiwj9Cr3DXto7G8DkK1lJ wziv18n/Ov/6+7MuP6/HwGlXP4SCOjLI0Xr6H7TIQ2eNaLv/84F1iwa37vLH3jktQOTvjkWO rmnkoBXD6J9hppGDVowgxzMbwcHgiMLAAXKElnA4QpkcoSRWYepgcMRjag2LXextncqzBoNW ReSk5bKNbpfLzWTjLb8BjFvX9SCAGIZ+ZOYDgiWoaSW7S8r2HWgV5Xnzlrx//6OIuHvvLN0R 9FXIWMEGVz0zkCCuMrlTloqPc0e45Dy3jkjMvSKhUJlWk9uBTKqHkxRiEVqdZQQEkQgOIYWE cDJkq6REnIRWjntIWJlQwwx/4kQwTmzTCLERjIM4ghsxjTROHGkxjfzJ4YcjEKaxvZG7Ipmk usEdfZOvHp+R3B42FO0rgVl/9YS3KfIwl8To2Imjb6VbLClf873HvCXQ5GsfmHzNA5mduvM9 sAJtThx5C7d/ZLRqu/Wpj3MGXWS1mXPmRasnvEM5sxyLWEdkkAX3vQx7nSUX3PMyQJl1xVvp Pa4bo/sPoTtq/YjmojgKyyNnXtY/Jq0ZWHN8VPtHBieiTWvR5lVTs3q56w8+U8QaqhQ0WoBI y3KEWOTIglzQbx9Wc1hDZXMPbjS+1zDTxDTaE0z/KrNjOBvnIEYn3JCAw4wctDgDDW5VlQSe Y5MsmxgNoluowumm4S0oiuJ1u12qymZWU84VUxDj8/sBNwEw4smuiUGqaqt2Fe/019b1z+j8 zh1zrh3x4YGGmB0lW4nhw4ZM+ak8jkZE0/CwGuapYX8inR0x/TWIODw1PESF2x5oiTC/STih FYX7VojpTJEdLFcU6scJIbQKpdiwMjb6kU2QYcXUWKYRQR02sZGCbcDhNI04UFTjMTVO00gL IvmrAZTGQEq/B8ZMmvU2rIx+7v5W157J3SKJ0XGwpVXOYHxl/0mzpwFcAFCS99Wn+PJMfGlf nN1n6GM3QYHsAVmINApEUGbnHgAXKupqxr31JL6iH/yN//Bl2J97/tjM9G4AFyZecgugmYKf V7bKGQJ7u9w5AtYz2rSfmP0PpJvOIwaVMjv1gNYKflqBL2O9X9oX1gHWZHXv1yYmoVPrdm3i Wm3fU7K9tCTZG4800ji7tvG/xkEbwIWcfikrb83818DhHn8j94E7iD+75VJUmI+qGpAhdTyw 4PrufZqJD4JHzbntehY9+oTb/5u4cFrIqn8768ihSICETeqHoo7aaJVmLC7OjYdBm+WRKeL2 dNRidFTkiOBt1KCiyjJAFgAEnNuBzMx5hMt/OY5dEEQY50MBLMIyzhi6JnihSKK4gPlbZEmy 0vDaI5ckFyAVWeYWFIAKCsa6RMN1A5rGBV65WUjXUYM/ULp3T0xtdEpq6o1nXTao+wnTFk6e v/rVBLfWJildZ2nxTCMAzL8G4nxRNvfSwWvEVg7hrBhk8lp5/hdMHHxV7AglZK4o8eyxssAQ k1wnUt/YdFEGeWibGJtJaSLJquIUhpXhK/y9R6TPI0IohJl9xM8q8fAgQZ9FNjfVWhcxUebz GRNEbJV4Yquv2CosLSTWP82CrTuyyVeqRh4aVoYpkz3Ev+Yt/KSitppvnPTfaZyXmnvBNYnR MVAiZ+goYpNMHQDHvIqzevaHAlAxb+Gn/DKiLSD01GW3wq7CreuH9OxXtG/X0Cdv4ZiXrj91 y5bnPsvqPUAEu5l+pYraKljv27n7U5ffCmXHv/fS0MdupuBdluBv5aa1iFI0WFFFRtFqCCHm 4GfMXHM89qKI2tpfilZ8OCG145ibrhj90ddr6nYhh0H50eEjO9d+hQ5U0i5UNzpQ/OyAgfm/ ePa7/ZGdJOju16646vJ2W9Ha/7RyxewiDUcd47cAkb/0fX1EqKJRYHHQis30hQ5B3CzkEWMG pOBm1M+EyTP0RYlLvDdBjMWmowSrqsb8Ms4xa8yx4jx2q2tFUdhXFIT/dUNDmoQkluaNMBcM S0ADIMMgVogQZ+BS+iqhk3TQ0HSNqp8B/tBZ4I9uGJSMonBOLYUyVdXVtfX1bVsnd23b44HL XujfffDcFW8t3zCrY5I7Orod7YdquuoMZrBJWiI2ex8z0ESHx4+UqaabTyeBJMyYFBvBsInb 4FXNmBqW2Y9YsmmMkWJSetk5pt4hiRjIjhFipgxGsTXVV5lYJTHPoIiIgf8M1hkPA6I/FdWl xQjbET0MwRCeXVCkUxbzD/NN8eAFZAvkw+9McZgIKaJvdBIScISYUFInLXDkT/SyhELY68QM V0EkISrWscsEJRYGJY44FGb4rKirdprFJl/34I1nXcRtovw9hFgUV2YICTPF9u3YDb4X/LzS bhahgnUrnzCMvp26Z6Z3g/EshL081M3sqHDbhuyTsjI7di/av8sEOgQwCqCinCEj7zt/LHR9 /4XXFBZtyF9e8PScd+kBqjJSJGTRtuGa1o3mjEOhuE04PvmzwDzYjrFJLlyN6jRUubnL/pLC scOf29B3woI5dW4WZBSTdv+wJPTVfxFWkIfVURXP7kWPDxo67tv5bDC2IeS8jn3fu35I/LZP 0TerUaveyd7oXcH6o55xoQWItCx/vCWmKRDD3qaJhBvPNMJppGGuHPFuZFpHGq1FjR+KwkNv sAOOaCbzAyCCxTuBdV2n07siKRgmYKxRU4hucNUQuGNpGA41REi8P17LetJxzWKsS/CfHtRg t8ygShAmeABDUFKm3TEdEgng0c7SXVGVUent0i/qd+FxGWd8uviZZRsW7NyzKrVVa8UVDbOx ITgTnDdhmBqkHA4RMTcTgQcY4KDCqTp7UgljEjxnNJbeRQ93u4fEJIppXNQyUCgeEQYMM7YR mVgGmc9tYiUvtDuQZMc7nsTMILpZDJrVhT1bhmIaMthe7nxxxnISmZbk3ykYk20/uMyNM44Z qsVB8+daYP6GWy8hOlZEx1h5lwyU4I2BG6SitoaXhLuSCEjOeOuaZv3YcO/Sr8jmEN1/3lXX nn7+tv2l+csWQGsVNdV582bueWshEfE4rBGne5fhIXrjC4OpbWuB7ZV1NTzhNonwjHDKWkVd FRIFxO6b3nxyzbYNWb1Pyj55KHw9If3Y49OOiY+KeejTN+ilz4DI9JzHRvYZBI+HBz5+/Zm5 799/zpVPXDwOCq/Zsemyyf/XJbn9Rzc/XlZdeUxq2qQ57w7p0a9f5x7TVxZcMfURCr1lSRwI G2fXhCR0YCtLICGjgIHWzrs7PWNs7vVj3v2mcE/J53dcgda9j+C55XZZ6A8F63MyKl9cnrQe VfAxJ+me16+6OjutFC19Ce2vJPUajq2Ol6JaXDMty5HbRSI9IEfgozlEu8hhO1yaGCQyzR5N mkaQ+d6M6es2cTwO+ItUUxQW2RQ305j+h4Aj7NnBmbQWtdU6UQYxGIlVpXG5dA6HDunDTlWV oA7PLMPFZM2gPMcxXLyEH45LUYkkBzEN6KXC81S2RAU8A71DS5jGisAESgVboXO/379xy8ak xMQuKSn3XvTE3GMv+nrV0z8UrZD8JdHeZEVxYWZdYDO54JnacEAKgxXCvWI6aJjNAxAJ8+AQ U6iU4QwBHri5AiMemsOT+ALIEY9hQ3hFKGxgnhHhxDHT4VFDCKesSPZrKueRCnkTHgMkfjXC X0RpASZkS0z3GEUh3MvEehEmE0NIiZCwJDScYiKMIsh05jgSGZIWo8ifZFlTvLmstmpQ1z4C f+i2Vkd2v8FwdxTtKxH3uMNwQrNh67rzq72XXVAXZ54JzfZ74MqKmipOIhnSe4BtN2UXmRH6 5Fm9bcNFfQed1SOzcNsGa2NWr/5wz8IY1mzbCJjg+A5dwsaf2albZX1N0d5diTFxYgwmGMpb +GlewSfoufsTo2LvvXDs3eddOfrkoQ99/DpF0wYa1e+s49pmdHvw0sSomJUT3l7404pHzrv2 nGfvLFi3cs7dz9879PJPCr+JdXmHv3FbvDdm/v0vn/3M7eV11Sseefsf7z5T4as1dVPMcR7f A9V8Da9bFPsDrpcVtHdv6/qP5l1zss+V5TkwH1XWs+2yDURUFe39fvJFF5/x0XQARiOPHfCf nGFRWz9GKzajqnoEL1FwTzdUJipxyG/7s47W0kJW/TsiEtvk8BtrqobhkoNwUUN11sOwiNFs RR4ZGzZUHt/bTEyNzMTaFcYk5U8NbsmAWpoZ9oLC5OElpCqK1wXQQpUlhQ+KET7gxUPzBwI8 /ifs7PGh0/hel0sWJFZDJNtD2Bfw6Rp7+WJGY7fbDSXLKys3b95cX119dq/+k67JP+fU3E5t zqprCNbXV0Fh6qrQHSRWHXHiqqkZTxibldlDuHQZMpVMrWgUHvHrkPSQbEYqiYjLJXKoTIji kIS3AnQVk9YaomKCnATYkOBe4qSshsTIsJAfR3AvsjiqZtyNqWpvM1hFRTu4RuTfawnu/RM9 oeBj/trl7eNbf37ns33ThVJqRqu20296vFfbzsUV+6ivhP2iDHmYPzy742I8UdZXutcOrMIH qitiVM9F/QbxiyBn6Kg3bvo/KNO5TTsLKxDxoBCRVws3rAbMcXvW6OvOGMEfQ7nnj338kpvh 3uRjmL92WfuE5Nn3PEe11BDKaNN+fu7LqTGtvlq/mtNWxBgQuuHMi/T3Vn6Z+1JibBwMqaK+ 5vvtm/ZXlW/fX2pacVHHxJSF61cBxCks2iBfPTDeE711b0nBTyvgDMxc+VXHVqlwSFv2FBdu 3bBt7y54Vyn4aWVFTXVDQ0OiN9bEUuZtrhnHxUH3fuRyI7f5p7pQEKNfVnl+yUf7dlGo7nLZ f7yMpJwWv3XCoAs/HnPtzBuPjVr7JiraRvkrqoI8HtpasKFnu5TmPEctFpGW5dCxSKSt4ggo I+gQNFV/jWkkzDbC53Kp2YqyaYRwGgW4QaWpipKp6R6EY6TWXez01HAVMmKKwDoRFaAJxeUi fir2wY0vEpEMZAR0HVpUQnGYpe5KNdMUJUgtMUFADAbmfFgZsIWm6Sr34zDfED/nxbt3Kwf2 d+nY6c7h/yg9/R+vzBz3S8nihsBeVVddqkcwT+mBE8GpwMw/YTCjiYRMkqfIU0OsJDwmIcPA gggqiYeZLbcqOWiqmukbs+iuYaYRTksxrAKE03V41JDQtIRVjTvBGZMHaivU1iJZDh9+NWk2 2ZQJ7TP3nP2dD55LuzoYrOIVTShX4kQvJSRW1FezwGLsZLAeuWmkKeEpbDsF7TfgZm4oZ041 4eA/yq5QZ6LIPw34Mklh//zvmwO69DrtmOO/e2iKoij8xqmrq/MTbfTLD4jTJYCIuFoP1FYF g8EXx9wNuKHPhKvoFcv8ntbhA6o4NeO4F6+8543rH4QGobCPLZzJxMvo4t0D8S5+KP7l+QUf 3T3s8heuuPP1a3PhORAIBODz33PeK9y+EV5i/vnZ1H5dep3a5bjSl+bAOGGQAAv2N1TT4BqG lIWRRsJTF88ae+q5Azr2KH1lLlcEgAEAoHn887eto9+2f9e1J5/bOaktrC+6/7ULX7y3c3K7 M7v3/WbjmpGZZ1bUVRs6t/rQXxdGQl85MIF2QnyrbPEg9fjObdDaIEUY1CgiiU9u6g2ySw6w hS01a8bgwDtS1c5/ZirI2IEK96JaHy0PAAUegBrj6WuBTglRlHV1tIFDCxD5m8KRo8IqRb+G /+HQPG3KOmIYRoRqALXxN5MmWpg0mPvDGcUhUEVTkTgYu+FJpKo6e5eydEGo6wRjVVVxqCnY nHeI1+OBT1/QT1EFjI0piOgsxEaRJBkeo4zCatmBuKfALUmAOQK6FvQHhP49+6QRNpoGu6zn LzytYPumrVuho/T09CfHTl64adv7c8ftPbCSWmIUVZJVmM1p2l/D0oI005ZbHmyLe0oxlYTt KZzl3WUCadbE6YyssaZZZ/JiyjmldBMsgl/MedhB5CGxntjbBt8B5Z6b+2K1v5byUVikD/wb 6429J+s2+CEnffFiVaAOy8yHZRJ12ACwYZ9jeiC2WrxNoqPg0Mr6awI9wkvAtydH3DS4W//u D46isQmUS4KJCWisIzssOJLVLZOmMgkLmMRo0tz3oPGc00dkduyW0bpdwbpVeYs/o6ZymT33 Iy83eLEeOmbiyJsL1q0c+u/bGTlAOprUP0ImjrgpM71b/qqFeYtn0fYbHUajwAUffrJ7izF6 FA6BS9ehbeV7Tnnyxtxzx+aeP9ba9853/530+X+K9u8SRg4Z0buSTq6032nLvjy3z2nDjh94 YmyPjJT2cDzx8fFYshHhCwXTXYo66bLbeGuLNq7JX7YgJ2tUZkaPzC49C3ds5BH8lJYu2Vmk J8yaUhtoGD0gK7NzD9jwY/Ev1L3y9ac8vhfGef7zd4+/4JqcwRdbgxw//VVKkmXyf84RXvjS fZNG32qVhAHkLfwkf+VCuE4+ufnJxVt+fGHhjLO6Z254cjrc9f+cNRVg0COfTZmf+4rf71+3 e9vt7z/bqXVbeBpwK5/X6/3XqDHJEo6Oju6TmFa9p6xO0vwqMVy0ryhDjo31I0lFLiwgCDyX OBBh1l9Lrs1O2YMc8rW7twtBNl6LqsHqzI9Db80UhcX+HW3fDC4uLoaD8Xg8LlO+qWX5+yyN 2jnwwZ4pzbhImq/VVHfNVOS1jNCrnnBLxsG6o+yzMG8UQnITMTUC6AAcoRG3mhM/UcIHC/3F pgfHBhYmotIMI+D3G2Z2GytwRmGa8Mh0LXHuiGiZbfRBLUeb1MCCKBPWpbqspH18DzySUlJS WrVqBRsnL/ww/6t7o+QqlycRuuCcVcSBlqW8ga30cQibzgmTQiEhe0rFhmFuF8YM7g7D5gNK 6JWElTEIdiQjwyxPn9B6bRvT7vM7voCtz85+buqitySPghkdD47kulOuuXf47bDrjAlnl9Ts xh4FHnAGCeladGo/Ic1IHLOYaesyMxMjFO+JWXzP2//36aufrPkK9r58ee7gHgO633shvPkR F32GEmLnfrcaIYd8n+RmXTFx1C2NXL2XZ06+8WFrgoEF5qF+D19VVLWXRkPIEVeawZq65JaC n1bQyE8PzBaNFTvixSALbn8+q2d/eC+f9OW7yKUwLIKbB1gVdTUUtcj44KjFeU6GjoHP/FVf FZWVMuCFf/3zSEyBukMW3WG9NLMGmGaoEA14Z84Xs7zzcELy4UW0KeEQG5JlN+O1bKxmS9mE 9GuNU8KNm8ScJZ3GMId+WmhKPNKU64of0Y09+uWdVkZZ6FFtkBpXE9tpa5m0bGvJz5WBGMUz 6dR6VPQjfTuwbCEWCuFPP0diLEdCQROXGIaZus8QQIQZRVCgdqk65NTPF9AYY2vR2QPCIF7Z FSO7qgL1fjc+1J+bC+cH9RaLSItp5PDoqOhoZ7+zAuqaqSWZuXAtI64IcjFz6jbuqVEUg/FP ne4ejdlUVKnx11DaoCzD1O4PBKzDoeG1xAgEDRlLsM+iwVoHQqNjJEn2eIJBkf0Os3AbbpvR mIIZp8fyGByRjc9M4QuHRoXOeHcwK1HfBYIBAPJRFZdkZumDt4UytqSnpY8bcvnlgy5/4qOH C5Y9kZYc73IlUD0Q3eBhP5ZMqkPag5FIbczHA13549TKPcfQmyOLHHHKhIjgHLuM5cphnhoi 0A5b58+14v3Fw08YNmXeFJgLMSOPYB2dkjFg54Hi9NZpxKcTzYBjYzYQxo7l2nKsM8IaoVFN yE7FR11fvBj1g4l4bPrdwAnumM6t2yeoUcivcZ0VWivIDGOyNe+YmZl5khGHGUB4bJw5zJx+ EwLwooYyA8wcqpnH9EqMiSv8ZV3OaRdyFFLww7Ki3cU554xOjI6bfM0DQyfdGjpjmc1amWOh qYBOwYoV9mMrYUTMss5rNbKYc8AUGSws+HF54Zb1VABUMTiFOKQdy/JhkMz2XQFgwaHlzZ9J UYvKwq4QccTNopBDsCZR3Zg48mZYLdz0c1HpTuRWOHs6pOJhO4aEUYT/2oyAGYoApLA5Hoen nXOeCtPJ4nD9SCFZbCzEYLp7bEebdYFbtcKqYEfCSION0+7XIbFnXXrElL6RUeO9izJhqia2 adCOzmWf32zdhjLbox+/oURUtxobG31ifMyJnVJQXCpCPrR7J5JVxMIDBfiIRCEIhWARJCLu 2FdTGZajEG4XoXtdneK0U1K7ytiIleUuqam9OndOjpaSlWBr7G8f645Kbtf7ibc2kcoW10zL chiQAh1pdAz6FcIhll0h5EXO5Io273NxMtuxmYxXbiaFL4AY5r41HIKqiKmKYQAcktSU1JpL VQ2WIU9gGiQb2NCQrgV1maIROQx1iegYl0tRlGCAohjJBDGEpfDVEHK7XBbp1Tq9PMqGwhFC fD6fIFww6oamw0PAr8iKS5F1dggKizouLin2uN0d2qdNuvLxHwZd968Pbt9e/EV6ahtZ8dJo WJjVxWuZkDEjPLKGsTOwPY8ZGItMNTLmSmI8V6+dvJc4xUWcXhtWhlMvnAJo5rzAn9xo6bol l5552cAuA1btKsQu2kOvtj1OOXbgh4umpw+6FI6Nv0iNO+3qU7qclJbU/ovvF3yw7JMdVaUw /pvPvLqytjreGzvm5FFPfP7Sok0rrzpl5AUnZkGzswsXvLP00wp/LfyChBrG0AlpXa8+6ULY NSozq2969ze/+YRPvRlJ7a4blj1q4LA1OzY8M+fdNSWb4MUdCtxw6oVDevTftm/XwvWrJs59 F8Y7btCIhKhYeLnPOWNEdv/Bhds3TprzbuHOTcK1gVDe4ll5C2ZS4l5Qz2jdbuuUL+nG/07P PvMcWCnaUzx0/PWUh1hbk5t9fdYJAzPiU4rq9gs7ASFZXftl9z2T+m5+XpnojrFftXUjq2vf 7P5DuFsnfzWzLkg49+wr4RQWrFuZ3W9wZqfu1M/yzWe5542lUlrbN+YtmlVUDsWk7MzBmeld M9O7Fe3bRbd/O0vEOrMfCdrMPm0YbClYvypn0EWJUbEF61fmLZ4tbCQY5Zx6QVaPfvREtW6X O/zK/MKviqr3ZaS2pZ6m9G7QIFQs2Lia2eRR7rAxVFGUjapgw2oYGL/yYQxwnvOWzE5MSMg5 4yIYIQyGgiGoeCiOoTCaCC/NRXEwCTEMOC0NFr8BO2LECbLZQmHl+QQvkXBUh5EjTUCo4QGZ geO8FsEhFhErYIu3HAJeHa1ZucOxiM1xoLSwpqyuSQj8sKBHaKTYTl9VlXxSvKEZRJZgGvdp iPhQw27kOkD5H4BCuEcG/jj+CM2h04itxXZcikA1xNWC6EkwuCACQjHt0NYlN/dFbgk1VKGK fah6O6qvRf4G5Af0s31nu4t31JSjqMNmPrUAkRY4cuRGDtQsj7WZTjngiLSOcM9FMyBGCg3T RRYdtVnGicSQvu5AP5jdXTqDC43qlPAYHJ4RhiqFMGwgMTUujWh6kKgyzdZrONVUzfG73G7Z MPyWkcMs4w8EoEUX22I4Ti//hDelKK/XHwwEg0Gq9SVhmb3VB/SgXwu6VZfCooJ5Xz6/f9v2 osSEViemZXx0/+w5qxc+9sFlCfKOpIR2WFUJC6LFkukGZglzBJWUy40QTtoQfg+DW0dMDVbr 7Zm/1+nigSSMBjZXwyzDpFGZTBkW6qj8gNft+Onnbb1P6X7Kqh0rkU5FaIf3ylpXvO7nop/R oEt5XPBLY54+tevAL9bM27F352nHDrjilFE3vXXvki0rx5x0MTS/c3/Jt+uXbS/dPv9eKv20 aMNy+Bx72sirThs55MkrK/U6SZaYmykkHSvWqTA+lPzi4bzvi9Z/9dPyPp17fnnPyz3uG1ER qL9/2JgEb+zCn1ZAgfvOvapverdLX30wM63rkJ4DYAIuLNpQsHZFZuceC+59qcvdF1do9fQZ SZ/pmBoMYMUl55w3mrpgaqvzF385+a5HYT1/0Tz65PUoMNPnous5Biqq3EPdLgaG+X7yVbnC FdJrgNONMvnaB3OyRlq7cs+7atzUJwEQcDdQxTlXcqly2AUIKTOjJ1/P6tG/34SxGe3SZ4x7 TDTViwOvtuNnvAqwJqv3gPHvvQhbJo6+lXuLeDvZA4agoJH33WxqwMAUQwBuoBVTO0y86o7C ovWZGT1m3D7RMZ6x3MUz8dJbYV0gjwFDhj5+88TR/+Bfc4ZfUvDD8ryvPllw14ucS4F69gcw J86eig+fPiIuUYdwHQpholhmPIJCZmhnaLeDIRZi5yARmmC4MSJPWAGCQgwzyMFQZvg+HACF QoiQyd6y4kR2HQo1xOGgiDb5w8RFPi/Vr4yPkwIEedw0pIXiD5lZkmQBQSJ5IWHPOicsIw6z HLEUjYlp2DMNKrofrfuWPlUCGgoEkN+PfH7i92taUDJcs/arPkk/AlzxVwMiFfU1APxbRtIM sePIjBxH3TRyZBVt4ZDQigKLSEIepFHTCKYelhBPDffvYJbdN7I7DhEUyvGQDCbFyv0G8I9B 5d0N2OJSVU5rNUyyCB8V1EIuF5QJasEQmAIAheXhU5lNxRI/4FYiKORWXKqsMBdPULh4aICA EdQD8OpDlViJaEozjAMVB+rr61OSUy/uP7RPxuqPlsz5aN6tybEoMa49llXGrDEFSvm7mMbN 3c6HrYO9yRPlIKJjLjfCLRxsDDa/QqjCG9wjI2zXFDMhwoOAqHQsEdJqeO7qOTnnjntz0Zt1 en1iVEz2gEvy5k8RL3gSunno9YBCRkzM3r63mD8DX8t5/sEL7jj3qUu5uuroiddB4w+Nvjve G9f/3uGVdTQKJr1N+4X/yr/6lIteXDgNzheM78eSjS9UVFxzxshPl859c+FM6u9AqHNKh1vf +Cf9Kst9MnouffLDwd36fbzmq8tffYAwOjHSjKLdxfdffG2i7KExom3a3/TGY3kLPgZwCvPx 6kkfZHXPzP/+Gx4oTB/BMKcqUqIrOmfoKAo+Fs+tgHdBfrPXVtG3f5jdVUGzy0hpjzav5iwH miYNocIt6/O/nZuRmpZzTja/+LJPHspRSN68mTCS7NOGZR7Ta/L1D0LLvJGi3SVQJTf7hsSY OEAhk/LfTIyNyzk7G4aHGoJFu3aOn/5KUWlxRUVF1vEn5V5yfe6F14yf9oJpVGe56dlS8P0y 6kU6ZzQADkAeeQs/obhKkfNXLYQyUBd6z/tiBjS4+t5n6KEtmZ83Z0bWiSfnZl8/8fLb8ubm cxQyftrz0F1GuzTa9XsvTrzyDm4WAvQG2IijkKEP35jZpUfRgdKKqkrkVW1fw8GfUMj2jgmF 3tAIJ2LiDNIccgiZVsMKk4jSBIezMSLbd9YSJg1HmZC9po2kOWxDwrs+lDiuxl72Pt+y+8o+ ndGenTTaxaXST/hTFPrZlC0kHPrgcEQSyR2xwt6svQYxrW6Y6pRwSn7AJ8e3+2IjA9+HTxb6 VUBk0vz34YJzbslM75Zz2oVHa+4s2Lg6f83X8Akzelb3fvyv+Sr9Jt6w4PbnOQI4MhxQuHMT fWOIWOC4qGXy0BZoAdqZfMV9/5sUkCNON4N+F4l3HnDLg3UbQRVmHRwh8U4MEX4hNa3ESud1 hiEkh6dGZyAAR4TVWH4U2eViyqiajpmEqiwSSQBcoM4fWcYRR8Ey7ALkoDACYAxAB+F4YpTV IPTIClhMVZH+RqIsERY1rAQpjAnSMUuyQYVYNSoMT92+LlWSdCaRUttQ21CyLSkhoVNS53su /MfZx/d7de7kHze8nRQjxcemGSJPHY2XEU8TiSmlY06vY3YYFk5i0kFs9TNkemF4fh9k5Yix hN4QixNmKQElE89wkTPFhBozv5uec964c04c/snqj4f2oI6VGd9+NOz4s/kPe07fs5esX1q8 dyc1LlGIJX24dOZ7t085rl13aOvbn5ZxWu0F/Yev3b5uROZQbpOCfnfsKx7U46SX5r5Fp3+Z 6uvzIVJJOYV2Dwuglk+XzaORzS6pMlArHgiaMaTXSaMGZNGDMUh5TVVidFyiOxrWqYXju3m0 HVWmYS9Q3hvLaBaE/onHMcruP4RbF2B6tmCH8PTTwQjfIhXOYng5q1sm15kY/cRdVIyLuSoA TFCTwwkDOUoY9+IjUD1v/szyD5YA5rCecuOn/rvgh2WwBbBIwZql8DUr8xRel+aLV6hCflbv AXBcFdWmV94XRJZyuS6uxnHPT6hooEc08dq76UmAujq8PZO8xbMS1SgORCblT80acBo/NMAZ gHWsNjM7dC3aUwIgJmfYJQBQ8r7MrwjUTfrsbQ5EADYVrF+Vkd6JF84ddR1syf92HkUhh/qS 5IQgEczTsCfYUdawIEe7PPnNug5fvttWRIZl4gPFFHzIFBCwFbhKA/QeB3gtuUzwAb94kGVr gDsFwIo7FJ9pSA8IkQIZWnCbcApTDWOtgXK1JEWQTjhu0hrgdQwxSSTBx0J6Q2zn78t2I8+R hFD9KiAC021237MyWrdzApGjdYGM++AZQCG5w8bAH703DpSOnjrB+tr8Mv6zN+DzyHAA3Kj8 KCrqa6CdiRfd9GtgzR++NCPm8dtph4SIHh5puhlkBss0ZRoRCfBIeCos0rSmqqglSSqXATPh iEh9x2JuIz01wjSiKBKLjqF5YpAB4ECnGIPQZCecrCrJkedZVVQZ02b9GpUKIaaEa1CntYlM Bd4lIYoQcvZUFTpQqRgr9dQIKw4VcKUs9aCLZf5lWWoAIOm79++rrKlpn5xyYqeTJlzeq3DT hdMWPFa0e03b+GhvVKqOoRBV7BAxviLXLZPV0JhPhYvFK8zFYif842IfPLpYnAlLWUQIsMqE S7US5vOhHjBT9YPDgtpA1bKNS8/ue87Hy2YM7T0M1mvqqyUTNMRHxVXXVdEkwHCS4EVKwbuq d8GujkntOQiiAI8mP0YndOrVMbmD842NWkcMInETvUSV8oXhC06ni072FXXVVb4aya0gjyy5 ud8eXdIv6/27nvl4xYI1Res7J3fIOn4gx2GMjlpdWV9NTSxumVq5TVCMnLGKBsk950pm3lhX uHU9cikAX6i54the/Kq1nhI03ZrVAjdv7CmmJhOXYr28wdROm/plHQUxboU6MvjiFIxSZI4h BNax4mt0Y8FDr1MMsbcEYERGm/Z23bBQCPYoY+Ezsl3GYNmIJAd70YGickffEHbjDJ1w48Sx d2afNnzi9ffkXnrjuMmP5S8vMBE3rVtUvpv6ay6/LavPyfAHZYY+cXNRzb5Dm20dNGE72WwE ImlZQpf9wdoS0i7N46J8VUpKBejpM1ytUHI/4k0xKjbI9VsktwcZfsPTDiVmIjWevnOV/Yyr 1ipeDw/ep1XcbVFyX+SKp6krytfhqh8Vj5vuBXSitMJp2ViNCZYskcrXyJ4oRlaXUMbFOty5 Owpk6JdFA8LKUq1tGdlK89cc/vJrXTOAQo6iCcSJQuB23frodOf0Dx0Nfekuep8cDIsAevj1 RwQDACAShrRalkNHP5H44KDCIY0mjmmG/+GkvjbuqWm6FmZluC3EGiXFChJP/CI1gsCYUhkF BQbMvizXHXtz0ADS6ESivhOZYyMLiolaLPRXk6jEu84YJzKzfwQ1TWZBKEqEaYQaL2TZzdBP UA/qmsESSlDeiKFrfgMr7OaXGN+W56n5Zce2hISEtHbt0gZclJrUaeGa/CU/f1i2b2tKYhtJ jSbEEBodWEzeIqutIdwrNLELRk4jrJkwT7yFYof7XmzhaV8s87bJ1rCsTXDcnyydPvnWd4Yd f3avtF6PvD+BzqeykFD7efvPvTv24nHHkkon2vP6DK+qr/5u3VLEXvuppUTC1Q3Va7etu+G5 26kxSpWZdCaFZrBOebb8pQ8Lhi2vwr/DOiBEGrNj/pqDe5+0bW/JFc/ew3Jz4HsvuKZvl572 nC1Rwwzsop82D8AmD2Z165eRTKf8vDn5tAWXDPNxTtZIOvv2Pqmoag93YQAKKfhxOYpxUzxU L3Kj5GbfMOnzaYmx8TlDLxEW3zVLs/qekn368Lz5M4uq9lrbqTXFdCja+ACz1KyKZA/m+JPo S9fbz+d/OxcgwowHnmtywmZDRTIOYS1gZ4gK/QqYRsCO+64t+GEZ9JXRNo1ulKXMbr0nffr2 uFf+Nfkfj8CAc7JG5S+Z72iH/nZwaEMfvSlRjVrw2BSomD0gi4qsKBH80Ei7gIVCjNAYV8OR lI4cQirav9kSROiTjRV3pLVFVSy9X0x7o90g3GEwjqGXaN3Kd5Sq1VGtE4zEgbjrDVgVM6mU PiKw9Utty5ue+GiAGkZiP3zsjdgVJ/Z2HBHYNk/bPNUT5yZyLOp1vz/o0qr2ePs+3LDsKXft CkXBKH0E6X5dxcw7YwN+OSaGpvZBREpM+WBrle46wkD0o88RmTT//azu/eAT7sAFtz9fuHMT rMNnZno32G6hlqa2cwSQv+br1eOnhhkhABBMvuK+0VMnQOG872bzTygJuwAuONEJbORWDd6+ 1ZEgfpvj5HV57wdFGzAq3h2UhCpWd3CY1jAim7JqhfX+PwIO0JGG6R5KxSP31IRpqvLpuemK TCgdhenHc0+NCFhtrBpXYuX+HVsXBGZ9gA6aJvQ/HFxUK5sd7U4nQcpXN0SwD8E6JXwE4W1U ZpG63OdiqcsbHDTAVsrpkqwoHm4L4d4OKtQmy5bNSQAsQmgkjqEEpWBAp32awvCGXwvKuu5S 4H2IwhrY7vF4qqurKyoq2rdNHdjlRPj7pNOAeSvf+GVXoVq3Iz6+LSIqEyPDLF4W23BDhNVw NVUm92EdN2OJSKY9QIioOxVUsRlbKwznxDrd1NSh4FVFyzYUr7vronur66rnr5ojeWXeHJbI lLl5b9/zzn0X35O/nBI7eqX1vHTgqDmFc2saqrmQGWcIf7Bk5lOXT7j94pzZK+ZhBXdsk35c p56vzHsbu1hUsEwtzjW+msp6SsnsBHefLFved0ky0y5zO0ptVUJ0XGan7hUNtZ1T027IGuX0 lWMh6hDCR3RevjmnX8hxRv5386hfxiXnLfoMgEhiTNyCx6fYz8AZU+jcr1CTAzx5Cn5akXXc SROvuxv+nO3lL56Xe1kOzNlbp861/dHfL6O2FmtYsiPqRApx6nNjzMSr7wREkn3G2c3e/MgW q3C6BUzjX9aJJ69+YXre/I8BP2WdMHDBM28XrFkGtQBgDX0kp3DHpgX/nAznFvZS7gucgeoq pIsBzHjweRjwpNnTZtwxEbYUblkPiETYXTQdGcrBtK9ICArhEMQp+GGQ5qQ1/saLoiEUnYi8 Mai2jvrqkgfK3a+y9uq+BingJ552uGsOVqOp127PVjW+jeyNdR9zTm3ZtkDZf9XkrvjYcdhF w7h8e7cqccmKN86dMby2bLt/z0xXtzN0ufWety70ynvVC16XOl3QsHhuTNfTcffrygpeISUF rmMykKHT6xzr/jZ9Z321EXmPUCn46OeagXl3/GdvcLJIwcbVQ1+6y5qDYe6HP07+aHS7E0Y0 igxgpgd0AgWgF0AkMM3TOH6GSJwtwM3P/6DkuA+e4R1Bg9Apf0GBujAGXhe2WNubYav0m3gD dA3tAOiBr9ACxxmw3RoGb8rJm+HF+GHSeLb/GU9NJDhopsrRSjeDDi3jjBSRbgaFwoUmnrQ4 Mo73oOlmJGaukBjmIPbTHgcNKtZuhIInG5lJNL5XkWnoDK/LybCAKgJMHZV7M/hep7FHUVUX S8hLQ0/ZFMMF5v2BgJ9KkGghvVg2IYzdbrdHdSsuRUQHspS9VICE5qkJGkREGwFqgZKle/Zu 3rxZ8/lG9h/x9Lgvz+x/e+vEngeqKn0NVfT1heuXAWQwiPPP5KAxjy/7Mx/9LGkdTxmDRLIY bOaLEZpMEuEaktR7wEqyc4vh/UlxSQt/ntuhdVr+tx9KClZVLDMKiaxIG/dsuOfNuy47/dIF j8xb8OCcR0dNWLJh6f+9/4jMfCsSI3xA4Y9WfDzx0+dvPf/GFc/NX/70vOn3ThnUc2BSbDzs 4tcKDKPKV/XyvHceufSuH5798oWrH+YjF9YRiVg4462v8rfvK1n69IwNL895/85nvvppucAf PERIFumETEF727iCWExKdv8h9AH13bwKfy2nphaWbB79Qm7RnhIHCpk66ZO32V5mzJCl0a89 WLB2heWyAajBr6eistKhE2501s37csboSfdQN4rl9bCFPjkowZaRY/x/nofWAMfknDs6/1sT ylgJ5Z0iXbJkf+XtCFkwlLf4M5rQBKHMY3plHT9w9DP3Uu4LPGn7Ug8LbT81raKhhvJbGakF vlJCycw3ofr4917kWAS2V1RVwjHS9RMHwiccI2/nYKKujlzPHHNQ4QqDsls0AwGwD9B4afoZ 0NiK9jf/czUYaVL8yC593rr8up1P331773JUU4kkuNi8xu4l9ZsK9n/5tOGvNcFIECWfwVHI gYWv7n/3ouov7zQaqL3Ndcz5DVVB0mogRyEHvp68b9rF1XNuN+orxN462Qg0wH0UlRiTmNFe 8boNf0Mg6MIn3FO7ebn/hylJx2ZILhYkDE85l7rdlQFPtyOfmH6NsmqXCZeGWSwW3P48bIQp GaZemJVhffIV98HMbZkHYNre+uj0prZzEwhAh2YYHlAXGud2F6sMByK8ZRgDrHPbA0Ci1eOn WpiG14WBASaAYk5PEHQd5tCBUUF5aBOqw/A41LCdpi/dBQPgmMM5VOgRABAcGnxCX1YL/2to +gg0VY9MUBX9Ok3VyGpSExYOG3yEpptx4pvmRxsUiedCjEYyQyooAk5ZbhSADwYTKbPcMXzF RYnrdBIMg1AcWOia5g8GdI3BAQZTuP2DipSoigVcnAvzwmCfFgz6/bqhi9y2ph/I63I7HVUw ogafLy42tlOnTvB17e7KZ6ePrq3a0qCVe1xeWXFTQ4bs0JHEOERhiVumePYahya8kAwhLPuM 7dC34pjYn4G1gJHsbb997w46ZoVCmjZR7Yt37zAUSfFSMNM2rv3OvTspfsEoxhXbPbVnh1Yd viycW+WrwSxWNi46juiIfnXJOk0DZMRI0aceMzDOG/fthmU7ykqRS5LcClElbouBH8Dw6b3b dD2hQ/dZK+Zz8kilrxZ7FaLIcI7T41K3lRRz7dqzeg6Mj477au3yyrrqTm06FO0tSYyLhwMq 99XBz0bLE5IRn1pUupNI1OwBgIOeCpgg/RpqCDIGq0TJmBwxBOjGjITUjOT21KPBCB9UMtXD VE0JI5b6tIz4FIAytACfnyn9hWmqGiSjVduM5HYUoPCNCos70AzhjoEy1LpgCI4IPfs6c4Ax hZJeAwo3/1xRV2M6wyQzI7xjshexx5hWhNkdvnJFVzjVsMUXzIhLTfREFxZtEK4fxoGtqKmi W6CYS+HjyerWr6K6kkqlqTIbPIbWsnr0K9y6nhJZZCnRG5vZqVtRaTF16EAtLzsPStNhFNZF Y+Fg3Vh735st1g7n06y8vKyqqiq5dVyCXNktXVVqN6DgPlReguBypfIhTC9EVeFc1leU62py 7IXTsBpVsfg1ZXd+zPDXcUJ3ra5qz7RRKRlRVJms251qx8FwhZfnXxN/+q1K2/56Q+3ud0a1 6eQCZG8ce5vaaSj8IuWf3hDlqVJPfhp7k3CwgkR12DfjtvgTz1bSz9rz1qjW7bC3VSsUDFK5 1SAgJB9So+vST39jvW/qyjWb6/cZh+KjOYrKqk4KheVJ4axvHu3CPRdWeSqq0/R2C5ocYtcH LdOoZSV/zdcwwsjem2oEIAWMNowKA71DC7B9xg2POrdDMUAt/AxQQaG+ZwE0gY0Hjff5/U0j h+tz+TXpZhoVMTsUTVX+uo5DjRw8TKMZ1RCu725EpJuBHZRd1cSiskwxARZWi03UAt35g0Fq xXCM0xL/4EgFKlJDCEaGpgvXCSEBKgtKXIpLCmWxCCqoLHtlL8AFH9zMLKwXcyVWogf9NPud aqabcYISgxhuWXZHRTX4/AE9wBPZwAHLTCoeWo/yeLCp0hYdFeX3+39ev751q1bHt02dduf8 95Yt+XT+VUHdR1CDJLskmlJXpOIVqesYNVUE7XK9M4FIQl9uMQsbsmUeCFM4FelukEQkFe+r 3+X2yjzwFZre79vlilPoz6bSuXlvwy5XtMwz8NYbdat2rlixbTkgGNVL511DwXWojk6g9Cs9 o3SLv/7LdQXMcoNkNyV/SMw8xO021Fjgkn7eu+mnXRuYNBtNBIy9MmairnAYxdV75CiZ46RF RYUUrcKIvcqO2r1ytFpFGuixemQuGQIVtlXuASRBUZjiwGqAUbzsxZ16Xky7Ap2ncVHd/qLq vZQXArvgGDnI4NiOBdcU1e6jyiLRbuEokUzLBEFFdfuKqvbQuhK2heH5/cIFwYjEqDxYiMYa Mk9zABsLtqyh83m0y/a/hNnGiQlQOONENQQ1lQ9eplHHRTV7USVrhA+MNws9RrnsI5UNuhGm DX6MfKNqFGz9ng4JYJmEK4z6gl/W0K9QRpGEev3B/TKma4bbQhA67rjjWiCIeDsKBuvrDsSX v4u2/4Cq96F1B5jGGmBclf7x3Ln8YaUo0W2SDHeqg9ykIpWSPwxftaoE1OgUZPiJf694srna EDmaOXGqVdnniklC8PDz7RVeVbUV1ksCK/6ptRqko6iG9bM9bY/19hhR+v4tsbG13uTO9Mfi ZGd6bagoUBO9ZfY9ya3uuf74FWVJzy7fPGfrujr3ocY4/SZkVY5IYJKGP6fHxLI0NLrdiR6a 2svb5NjiUMwMjZaBFjil46AlrQE3M5jIaBrnRoApcCw8imfiRTf9T8GRXyNidgRwxORgkkjI j5uXRmUzsR4BRygIaJrESjkZoXCEp3LVg0EeVtvUKF1MczRoppvhrdH4Wxqma9MerZPAwQrN VEfkADw3GBfVxFnU5yKzFHc8tNiyl1ggJsrthip+nw8JWTPZkHi6G11l2Xit9DQ2DqNy725V V3w+X0DXBE2TqTA3+Hxwnt0ulwXvYFxVbGmbmnrlyadeeXLRfe8/vm7DC7JS61JiWLQrs2zI gsfKgnp4oC/hUpSYC6EhidNSmVA7y2iLnHLvNhyhrgCZRg5KQvSEbpQozGIUVzqlwlfMOIgU iEgGNe6yLMYM/DBXF89cgyyRNKiFmXGFh+ggCqKoEwib0lZwuBQxyESnmWsoEJEYF4XFBzHH kmRIQsudylUbkngbZ041bIpeEpHukEXrGMwgJAmAxuZdClOENIblNJHN2F1OZQhLIMK9JKbx wxa2tT7pfCEjrjofknkkIicIciiKOi4IodXhlBONBCJiqEjYPKzQMDpy2db25tWd+VOsIVEQ Q2xqM0dLfKPVBXFow0uhOVyat4g4sUjL4nw7UtXySr9U4vIs/yqIPXBi4e6WPR6KRZza7eZF QkLZ99aaxGj09N7TG0yHnYeIkC62l+eXMhrMCh6iSV5vwL87P1hbHZ/SNWr4v8oWTZH2fxPX uxcJNLCYRcnGyvC7BQiqKUXbt52kyjP6dq0bdv6U9b7Xli8vClTq6kEEdn9DQTPAEzAfb310 eqSBIe+72ZHbncYGzhqJjI6BjZwr+isHxlkjh1geugNsAXDECVZgC1VWPlDKuSZO1BKGaXjI MUCf0VMnhMUB/Q7+l4P6TY4s3Qw6IpESC3CEZ7I9hJgaJSIZr6WpKjWhW2zBEc0hYiaS+rKA W9S0TQXudo1FuNimEcoPBZAhu1SlUdMIYiLuiqYFNM3AdtQJzQ/u97sZWdXpqDKVxti7fVSU DzAMoB/65JeJzLRGgkFD01R442nMkgRoKsrrhVHSiiSIabQPfaADYqttaHCrdOGcWZXJ1e/Z u3ff/v3HdOnyzJiH99U9fGfehcXF/02MS3C74xhAY7MUFlM7Gzo85jinlYMGKmEiROMtlQEs JOENO7ONILTybDoimpfO93R2l6ypk0nDGSJXDRUpYBMxFunoGE/DSVKk55gqRlJgxHEGk4oN 0ZinvyecApZj0CCmd4klz+NeJQaF2a9GbI8SwhYP0nY2IQ5MJJESmCEiMyONJIUn7xX+rGb9 2s1NybgJuh4+hHX2qx3mC8ihjo2EFWe+vEY3osagz2E+qkIiZazHaVnJit3bYLId0fMUz6Gx INftLUpP7BAbetds3rerK4tw3rSvuFubtMha1f66gGa0jo4NasEDDbVtYxOtXct3rt9ac8DQ jaEZfVNj4n5/H3rnTp0Ky87IPKGoftk0NTYJO1VTmxFuZ48eZGicHsW0lZkGshItEKyviiqI mLw47lV17K2hcbiy4m7Vyp2QhE56vH7H2oZ1M9te8rqUcoK2a4W+4V0XrjGViEzTCHVEkmBt nXFgpVtecaci33nNjWd+tmlR5ZbmD1P67c4gd4vw8BkLgsC03dR2p0Fl8hX3cUOCVYaresB0 HuYKOYKFk1tpIgmz5UYVzJzj4R4WazAwWo6ToCmnqhuP+HXiEqvlPypepnlmqBMfNMpjPZSK R9Cj1JiSqTPqtalakeG4NN1MsxWhI5UFwRqhfQFcCASDzVDxFVl2M7Onk69Kw1UCfir7QcLP HocjgDY8brdLlnXH+YHeoTufn1bkMTUWvuFhODTmRVGoY4UjG4JpKIws6Zgm3Q0ENMksaZXn cimqS43yuL0ur2FqgEjU3C7BodU3NOi6wam4khnIs2Xr1tLi4jbR6IO7Zj94/doA6bBzzw5D 9wMYMHQWi2vYDns4ZYQ5cbGIqwxJzstTgUn8hZ+tYMwTuDZOaJXtjfZ2bBJdKX+XC1LzZ6yj InZSYrGIxjUbF61ZCeZYGex4RIsRWp3aj25GYnWmK0YhpgpWmE21dsJXM6vxYWdz+zMuuDE8 gQ8BZBzWqSGhlNVQIHLPxy9vAwR9oLTvS0JRfn9EVIF1X5fUVTCTAMeeqC4YEDt0/10fv8pX b/7kZb5Sq4m9paxW4c4fH/7izas+efE/a+a+uOgzZ/s3TH++ndIqRfGc9vo9fEtlwGeO3R7t voZaa33cpy89Z+msHA0fet++fVbFj4jv0h9pPuzMpmu9TTWCRajGGPGVUbAa1Qp7WhsNVdTp HNeZjlzT9ModxE8165ToBOxN1usria6JvfDgqNsrwRsXvLIF6kmXsRpKKvvi4TYjngq6Ou1f 9B+S2Af1uq2hqt7u2tKAZyv+oF5RVlmrR+cu3v/t7o1hP+vvahFBjMU57oNnYKq2nDUweXOS aaPbnUaIBbc/D5N6lwmXWmVgLoeNv574yYNsh750l7Nl2NhMy3zA/SbeYGEXwEPcssIjZazt 3P7B8QeP3eVuJr7rD1RFO+KMM4dCAWnUNHIEwiHo0NLNhEEkEYJrGBJ3UTQBYlSmGmJ5Ovin xr7KuMmMGCrM30ylg8WpinueWiqIrkg2ccQyjfBjp9YIQANMVNW5C963dEnmyXiJQxheWDgJ ifJ6abKZYFA3dCZmAvMqDFur92uqonIXjxFBslExjomK8QdpphqDmYhkFtLsC/oDQWrLVVjW X8SwSE1DfVFRUUpSm3N69R7+r+9fnpM3bf79sdKeNq3T4ZFFkIEt4QyupcrTj0kiuJdLu3Ad FmwLXJvrWGidGYhYk7VEEQ6W7WsJWXl9DQfLhGXXIzzfKsEi655hpt9j7WBmuLE1tLmjwrB6 d7SGOYUWW1YeLORPTFkLK08a4Rl3MHJkZQ0xjRDLZUF4/g2zVIvU1lF6Ntl81dCnQWp00oNZ VF6lnvjeWD5/dclPu8vLLu47bE/l9iXbt+/3V5yUeuzS3dveHnnra0tnRSEprd0xneOjvvll 1bSfl8VL7vNPHHznwLOR7K7WGz79pZCmeVI8+yv33/nFW/CqMKb/8OJ9W9fvLt1PtOtPPNUt k69KthwTFT974/IdZSUd07pOHEyjMZJjYxNaJRDN0ykmqayi7J55b8Ptlt13yCtLPtKC7lqk Tcu+465Zr0oBbdDxZ6qkeva6n4qrdpX7MRqYdRR96F2P71+k3tW56m5i6DbQthx2jVYzgqRs HUruI3uiovvd6N8+09UuU07uCzv9+7bi+h24+heEBkkub3T/nEDRdFfbPnIbOgv7929DdcVK +3YoWIvaDMIdhu+ffldUvORq33fXW1e6qhYHXWXuUybU6QlerR5jJQQMsae35q93Rce/YZz2 77VLDPfBEx/+qqiZgzIkLDtBwcbVMM1zZ81Bt0fW5RLvzjKRvfAtzs/IYs6vsF64cxO03wwE iXTHcB2RsAHzMBxkRheH9cUDiTlq+aPwR6NX9m9aKzLqtXmbTbhll7s2mtNBIs7YWivYVW46 3YxomafejdBO5SaHZt7bNEPXDM35JsymY8wtDmFHba0Yuu6nvBFdMsODKRKSqB1fcbm43LsV g2PXMgzKfqVJfGnecKqXpusypsE7nMVKrOAgsy5m0vV6MOgLBDQW/sNdP4z4YQDwcatuTpvV uaiaJEV7ve07pMEBrS/dMWX+83O+e7FzshQX25FyehFP12daObCgU1AirI64NJaIqRHeDRFf Y+phYoc8FRbcCar8RoekI5F3D9MtwjfNUQDFK+ZGHYkUfNisyP0pErWBWTJXonFqhBYxT5gP FU6WZnJWzMmOUU9sTQr2ixjmO7kz9gcJ5gwbktmEgYmdAJoDHMlsmYRmim/WYBJWWMK/wbxu X9m/renmVx6LYXFUWVgQi9Rd++h7Flk15/2nnr3k/li3/MFPC1/46sO7Thp7+cAzLvrgX1G6 /MGYh//99eSr+o4t2DRHdacoMtlbVvr+9k039zl5y+6i9ITu1548aOS7T3xy1UPQzhkv333z ySPcCv5w3YqOHvTdgYrjUlJqg1LugLN+KTvwcuGcscedLhF1f6Dh3C7dpv+89vGzL8t87Z7C W56Fuqe+ese9p1wycvoT28d/vKpowf0Fc8/peUJ1faCuruyTax/dfWDz8Hf+ffupV9xw8pmX ffBYlOJ+5fz7vtj6TYIndeixPY6uk33L1qJ2ZYuiVkxE3ljk8QqmKld256YIpOuuVOmUZ7Hi rVj0mlrygbtNhjTwGTk2haF+QDBiit+df19U/XdRbbvQvXFtw/d+PD6q9tv4tLbElYJPfb5i 9X993z6UfMJA5awpVSvece2d7cm8KRh/csUHI9ukxdBXBo0lwON/DT5fVXlQJ5+nXHHNN4uC XpOU3ejFc1SiZhpFD5Ebm1JfPRRV1qbKRPbiFGK39oYVc37l4OagvYdVb2owkSE8Vl9/FAQJ Qw9hKOG3SzeDjorEuwkspKbxvmSKftpd8Om5mXQzrCJM5UaopirPP2dwTNF4d0ihgqBUUFXT NZE9mE150KFMDNiLGhNNkRXFA+8HTF+EB5pw0i51JwUCXMUkkjFDhUOYOwlGReEIpowQHq0b CAQNqs+h8C1OHENVM1wuzIwfPr8PDogqhVIFRqJrMEv7ZJmqmHB/EJSpqqlp2LolJal1z3Yd Hx3z/Jm9Br37zZTNW75MT010ueM4E4Rgc1ajrA5Gl2AUVh2ZMTU8xsaMoTHEaebEXCEJb5g2 BsnkVZqWCWE+EV+oOBmzfHCYgkWmX7Mit7gzgXnG2eF2F/gvLb7d6MyRvdv1SEvq8O2m5T8V b3h/xaeGzJICSbbBgzuSiBgVp/1iR/p3K+NoCD9CYV8SXDEjTzxrcLf+CVGxC9etnLl6YVH5 bgqaME70xt546oV94R4nqGDdyrzFs4QcahPEi9yhYyaOvBlKDv337Uz2QzqC3BzNTFkTR9wE D5z8VQvFSKSDvY9awOVwUctRPBbLQRP6zCn31aw/sCslWn5x0eePD772zZ+WntazW71Pb+Xx BCV42avVMak3At9s+Lo8IN1w/IAqX1Wtv768oa5jK/iBa3z+IGsmGKN4L+83CNa+2LIGnsxn dOow9oSTNuzadvn0Z18fcUdNQ/3e6gpZUr8vK4lSKSyivpug3/Ts4Iv7nB7oOb3f1AkPnTR0 8DEn3tr/7AM1NU98896qPcVfrP12UKfeBcU/nNer14GGQLeEqNqAb+P+Yh+pOIpAhD9YjumS UVhVldlrBPrlS4SjGj/VPBc2P5mSrKDq+iX/VI67ydX+BI4zgtVl5V+/Iu1ZGNujCya1DUv/ KfeGvX3E3pry8q9fw7vmxXbvTLAL9bq1vnR77eKJKV27yHq5/4epcQNyiH6FQaSKLx51K/VY TaQR4Cb+pu8PwQZZURenX3XjlwuaQyG/p2umZfkfcviGOlCO2FNzBM6aX5luBjWBKoQlg/tl IkwsAo40ZuSwNFXpbWPCEcIsCjJzdTTuqYF7ikqsU+OJbugGzbggkthRiwdV38ay+UoREt/L NVUVJciMHJaJiNolmLNIYQwOJxyhSqyS5JIkjQ3VFwwaTDiE+Uj0oAb3vg5YRKVOHolLuFqT p9CEBciiUUeQwYTniU40OugAwCiVjQcGDy34/f6dpbviqivT2qWP6H9xt/T+36z58IPFr+tV 29okJiuuWIwc9irCRdRhLJybauq9m5k4EeF8NTHTS9jKpWelGXU4RFjCPMyVWBmkIMI7w/mg oq7BMwfZPFps+YsI499d0nfkPcNvhy9frJm3Y29xeusO55847LwTho6f/vjOqt1YZeG73Mti JuYTuETE3/COsRnzYfbLPDEYi0zES3Pf6txa5HMZ0nPAk9m3XvZS7swfvk6MjZ93xwt9O3bn u7IHDMkZdFG/R8bSmF5VbuQR7FQu9wWpzAajzxw9IELffLJ69qca80Fd/EZN36pZ3TIzO3St qKuhqEXGB0ctR/1Y7KuLRBK2LjvxzMnffoyJMXHojWd167U/WP/gZ2+/M+LO7eXFREfndD8j RpUHpJ94cocBc7f/sGZv6Z2Z5/RJSesW1z4hOglJUdf0Gcz9q2P6DOINDuvc59LMQRO/nv7c N7OePvvaF6Oi52wpHHtCVr/U9KTYxB4VpT8Ubx/VrT+UvHfA+cIq04+q1qru+AcGntMv7bg6 hCYtzH/6vBskbLy5ZHbnhNSXL7n+wzUL7ps1dcqIO8rr9yoSubrP4JcWL/gtzNuZffusXNYw oKeGdixHRA05h/TKlaVAWe2ccQ2V9TKqdyfFYcXj1Urqv7u/Xu1kuJL0+iq9fItbrojv2ok9 G90erbR+yXi2t5VeX62Xb3VJ5QldO0vUC4zrl71Yt2trUlq8Kzqa4viS2dU7V2tqamDPOrdW GpfWNsybZsBLmqwUHnN19idz6z3GIaKQX+uaaVn+bK5YcrjeFnS0dcwO0VNDIiwZzVfk4iJG RHdSEzxc55TfiOCYJCmNpZsJsSgbmqYTM/CFz41EkYTBATlEz8RIWL5cLUj1U53qIDQrr8xY I+zu45AiJFUNxgF/ECBLMBjQzYpUG9WgGWooF4UR15mmGnGG5ABe8Ac43cTgCWCYJr3OgIrs VlTeFGAaGBVUaZOU3Dolmb41/jBvxfr53xROVeS6hJhkWY1ixA3dYAn6OF2TWiSwLFidVNne lIs3DSGwFjSzuRODQw9sEEEttIJWDNMPYvlxWFZg7m2xtjOyLDU8m7W4ygbBAzr2f/6ypz/8 Lv/1OVMqa6thGPD0TGvd4cO73qysrz530uWSW6bKJTBpIMlS7yS6+fTGVGmWKoexGBnOQyGa GYzDxEhYYlFy15Ax9w67auay+ZVVVdcPz06MiVuzdX3/h8a8Me7/bjxrJNSbMjc/I6XDkD4n w/r4916kaVa8qq1zar3r60bu0Csmjr4VgMLQR2+i0h18/rbIK5Y6i3OGDlFnjygWGtybc8oF ia7owi3rCzasoqJqqmyHd9q+fHEd52ZdMfGSWwp+Xjl04j8YeOIW/iY8TWGOGMKqZ//DPha3 IuTUwjpq0gpiqrlzvwzTTl37+Ad/Ch2Rqz94YtoVD/3OncLj4+eNP/XRPkUbv6Jpcl0uxINo ZMXKHGQE/fRmVVSJS51SU6ah++rgcQDnW/F4ZG+UeKyK4LfQvR6vGSVOjGCA0u5Ul/UqYfh9 WkMDNK5GRQufqK4zWbMgCgSM+qp1cUPO/G9huSsglGaax6BHS9CsZflzGUXQ75WGt3mfS/PW ERzqcEGW0nnTyXglU4ArDMZwkKFSBc/G+5MYRZQzQO2zwdLRUSH2Jjw1NARD5gHFmm7NAgTT WR9QBSGKGRdjHbLBTC9UA0CSgvDiAPUMkTgGSgBgUDh3hOMY/gpvghWXWwWQ44OpnSa00VjI pAzgQNOhFV2VXRSMME8Nz+LLFxiIx00lTAJ+f4CHIlOSh6zrRpB6aohKI2oUFcrRHDjanv17 D1SUdUrveN6Jw4ecOLxzm06L18/dtusbt1QdG5uEuWFBSGgQwWAVcETgMWt253OQbP12GOsS knU7rNMwvSCCaIwtAVdRxhAGFe67YQolpnsFW8QUw7h72O0/71z3zMf/pi+DbqqyBVV21ZQ+ +MG/3rtjypiBFx+f0fu1r6cVV+2myiESjnHHPnjOrYs3rpj9Q8EZXU+66uSLT0jr8cPO9dO+ /XTRL6sSouMmXHjrrMKCEX2GnNnjpNOfGlsZqGPUB/Tc/P+8tWBmRVmZETAqaiufuPqezikd JF/QRCEzbnrxERjxyhfzM4/plZM1atKsd4SDhllWsrr2y+57ZkbrdjDlJ7pjBJhl3Iisrn2z +w+hu9atyl/9VVFZKbSTe/aV3NGT3W9wZqfu1M/yzWe5543N6tm/cPvGvEWzisqhmJSdOTgz vSvVEdi3i27/dhYdrSFMTlRQ8bRhsKVg/aqcQRdR2cb1K/MWz7bUzHJOvSCrh5BezB1+ZX7h V0XV+xJjY3JOHwEd0Ta3baBtsvda7pjO6uHYzvsSM4oBx5UzbFRWrwFQAAZMaXOH4hhCf1a6 7++PQnbv3qMF9/SJ/hJ9/y0yJBZNTSw9Y3pb6uwOldw8xtzQDObDpgkiJVe05IriZ9sAwGcE AV9j1cOj9mU37I3mANTQDZN3jqX/Z+894Kuo0vfx6bfmpkFIB0LvJTTBghCwKwrB3imudcUC uopdYRfb2lbAtipKsWADBURkaQoBgSA1hBQ6Kffm1mn/9z1nZjKpFFl/7v/rfK54M3fOmTNn Zs55zlueR3TgwKbYjM68Q0Q1R9YgLLEaQAdGhlVFVxRWDAJ3UgFDfwKR/+s+mhN3nZwu9Tv7 d7bZ+A+9qYJNoQrq8qD8IjZrCk2NaYqMFUvxOMsqNIzDzKmRoRSqyglsEzk1aFhgJSQ7YzRj gjZRhWoWrA9HiNwMB0CFU2KwgDBTeFA+F8ooisPhEMgyhSc+F6ssFHQ4HaKmRdkYelxQKk+n oR5hJcwj8YlI0AhPTSPWGSknrACHhcNkykfXE7RSJqRposigSYVlRWgVqW3Xnt0ul7N9Trub 8+4a2Gv8p8v/tn7HVxX+/V7R4XDHkWQYk8AKGb8Ixxhry+q0BVywtXQjgJtI0hGLthUDttly YSzLso5DkuGPM1w8rG4wwZF7Q+NCCO8Bk5aQ0S2j64zPn0cHi8RyTuRR1ZCLXV+9d13J0bKL c8/r2aZbdU31c1+/wkoAmLjrB4y6btDl7y+ff+c51z9y+T1frF+yonBNvNv36T2vP/HJywsL lt405PKhHftv3Ltt+da1bAweAI0lQyrAsOpY8P7R42GteeswlMqbvWje8B4D6cUgO7vIMZKw YM0SACI5qZlsTNUdGqX/mjD4kjevn2y4QroNsBvW3rz54Ql5V1g/Tb7o+omznwVAMG307bCn 8oLrEj0++tOEsy/LzelKvwMa6Df1hpz07HkTnzKq6ob/5CSnTZn3GsCavO4DpnzwMuyZNvZO rCfop/XkDxjOyBrm9DlwAQ04BgAHFkzNnHb9PRuKUK9uyZTXEj0kvg1+GjoKkNCI6Xfmtu+6 5IFX6+9/7o7atExNX/LQa7k5XegB+f2HtZt0eaUSYkT2dEbA/B/etm7b1rnVMaFoFrNnB6MS SUW7MUyTdWeK3uMehnfVCbRh+fD610VR53vdbr5YCOH18FH16Ba9dIkICxzBpXe5g/FkmAcY JdVQpbz2SUdaF6brRMNxauFGlo/tXsKXLBDdXsZ0eJJCQu+aFfPGjh716QLZeRJX9ycQ+dM0 cqJGjt8IR04B/bBmvqXewDTSTDGM2bRZOKzTKUTCt1EKEwpHJFHExBNNMyTTSG1RBUNTBWoa aSxwRBBhSGBoLCpjKvRi6mwshnSrglCP9MxQokHNPJ5m6mqmaQTBUCymsJwkCg17lRZ0O52y IkSiUUyNoX4WYtAJR8Ki4KB4grp8LJsKjc/lPZ4oni1GwnSJJQaGo2g4hiDGIfJGvpHT6VRU bdOWLS1btOiakdF17PNfbx479/tHKiu2BoKVbskDmIVRKLJAXTqa7IsAjEVcYlo1GL3WJ8EY WTem3G/d4NNaIwfhaTUKcowtXMNgd2Ut7jKy0GO6pmFkBuAMwK08ABEH3ic0BxDy0FU71g7p OPCD7z++bthVry9+K6CGoJaLeub9+Ova4vK9c+/+11PzXnz5q7doC4vHTrrn/Jt/2LQKvm/a U3jjS/exBFgg6TtV48WJm31q7F20xQW7C2fMn9m3U3f6ZxW0QeSREl40vNs5KelFwaMUEU+7 AlHFht3b5q9cnJOaNeGCfPpE5p8xgqKQmd8uKDpQmn/mSAAxb9768PwfDQW7ogNlUGRy/rhE rw9QyPT5byXG+Sacn4/zfVguKi+ZMvfVov2llZWVeT0HTh5z6+RLb5ry3ku1cRuKZuGkDbsK J1wwFgAHIA9UsOORUHX+z8tQQabnQDj7zG/mQYXzprwAaKPoUNnMRfPhpFBnXo+Bk8+7Ln/I yEb2X3C9dYq8noMoChnxyPjcdl2QPru6Cp1T+imwm/251dlgxbJz16/dEwqYxf/SKwJoanRI DO8kqWLkg0MTycZL7MwKjnrFwyFedyqexA7111GZZ8ZaDgivfsTpiTHeNlxCm/oOaHc4eCwg pkpCg7KwRblNXHVAdHlJG4hJRiO59v6KC7nPP7h41LVff644TvTW/wlE/jc2Kmh8Ulo8p2Aa OWVUwZwYp2ojmbrNys1YPpd6nKpGNGoTsahWX2nEVVHLqWrSjXy6aUVB6c56Goe1Rg7CkGYV pLQlgDNgphb5xt8X9LkIAoaAKIpmmQbQBaPJsaiDFwjBuW7vOooqKMNHhDCoWl2kamokqnAs srua1plauRmMqOV5n9cbicTCsQirqYQZHurnFFWJKTGXw8WT6FeVRL/YqehdKOErBsMhqIWo AzMCi1EV0VBYFnin04Gk6BqGu3rc7kAgsHnz5tbZWRf1HHhRzyWvLHr7i5UPQj9wuiZxEo3V oM4TEj9CEiYYK32JJaTwLGOwgGimzcTwwrCmYcMKPuUsRT2yLrOOYQj7vEnYQcjcaeYtx5RV lFHcQ2jQWJK3ZOT6wPfsFpnVQf+HywCIXHlRnxEf/fRZz8wuPbO6THjjvkv7jkzw+BhVu+Hs 0UR6l6kOVsOe3pk4lS7/ZRVeCM+xEk1+MSAUPAlTP31Vl9Vbho7u277bomff+dt7z1uPN7LU i7Xm6KoAwCOEzXmd+lNDwthn7i06XEZdFQAmGCJmS1HCROLWmfndgoo5q1DA1szmmzJ7xtJN a3Dizx+3tGA1/JmXO5iWxXAKgaPqdEhY4K8ynsWIydGn6YzpNZz44tRKQrc17eZJmM0HZVUB oOTMHxcmim4KRKbPm53Tpg0FExP/+ThR78OXCzFH9wHG/pcfwxhY2378k9yZogMl9FyTR98C QGr+ym8RhZyObcevhVntOrslPhqNORwSXBPP1hltDhw8GApH27XOUnSV3AfEgvAmRmPoAnU5 RQEdEGrBzwVZ7Tq1TPJt376jdbsOLpEjTyBbXV0lii63pG/bvbdj+/b+mpDXGwdgHvPgUNWF raisTEpMjEYjgiDBIBAJhQGLO0R433V4RhRZYRAAszr7X7H8lJfvF9iK7qG31GWLIoEoJwiw VDB8IuZoaPyLdzzGCI5YRVl4788Y2EENG9WlnCfTACUlm2NH9nCS09V2gOBNljJyw/ED+KqV oo5RYmo4ULP9B46S96NFpArlHMyXOlxWGDu006o2VlbgFiQS/2UTDCK6T+r+fWOTP5HzLr1x 6Veqg/s9gAhVUWm4nfZZ8//yRqV5Jo+8tmGXzi9YblHE2jeanNw3q2O9t8M6nk7DjaIKOAbm 6fFDLmnXMsPaCQ1Yun095ZallU8489IEl7dREANPBRzTkETffrqHFr4Jxzw44hprVm4OjpBV fj25GZ34XOrJzdj7CqlBCD6we2qgnp/3bZ+x9KMm+eVgWCH4Q1YUq83wJ3ZLyU6+MYMK1EM5 8XhJwtQYAmJMZwUblWVWUZwOhx2u2fk/3A6HKgjhSESnGa1UeIUQw8MgitYRuuixW3dUVZQE TnBHYhFYMJHECBpuwkQiEeRpdTgwMdiMGrFOisJ4LrdCPDUq0U9hMRsY+lZDYniBd0suFaMv EO7AkFdWvv/gocPt2rS+64Jbrjn3lgffu33Pr2/44lMFRmJpvgln0LtjBCh8R80ak5GU6Odp VL6FarkYeb74D1frnallUCOlTTtY3eRetLjotdoysH9/VZk/7O/euvv8NfOJ7oWVo4Mptd2z us5ZMbesonxzceEl/c/7ePWCi3qOKDlS9tVPi649G+fyG4aPtZ5LKFp8uDTBG0dhJSewrMQy CEQMMxgNrn3pu/fUsFKwc+vXj84CLJKb080Y7tp3/X7nzwCpDOcF8YawcU474VnRwVJ0iEiC RcSck4rTw4ZdhVSwFx0ZdLPrrQg8xRAGyOI565glf3sDMcShMoAROSkZtWWtmcl8r/G1lQQ0 5lvH4BvHG6JltHKRz0nLpr9v2LkVD5b4ykgQAROJwMX92+vstze16GDZiEfHT7vxXjgYPpOv HD/imb8UBQ7/xviPqqMH1v5nTUnx3sNl+yPu1DN6pq1ctX7owAGvz3q3TfdeLd189779EuPc K5av3tIiXq4+VlRUFmDFM3p1PHo0cObIEZvXrlixamPXXt2qyopDnHfYSEENxP+6pWDhgjk6 50lMSclIbXH0wL5hF4wO11SUlB3ctq0oWHNs5y/rewwc0bV96qJVG2+85Jx33vvYm5yenpnh EUNffbG039kj+vRoq4ein3/7Q1Kyt1168k/rNgdZ12OPPRx3mrCXtRXtLc6RfmW+/VtNWXk4 hi+5m+PgLeCpIYRQFOIdhC+Yzm7ci9Du1YEv/+LLzMYwDl7yuiTBbfBH+H/+SN/1sTMxMVg0 0HfhS6zo4Fp0i5Z+SyQTmVhFaeUnExMyW9DwLVZ0xiW6DBJ3LPuxtnWmOyWNvNK8y+V1JsQj 2LUMM+ZHZvhg6Z5rUxYweWNuWvr1idhFhN8+QTb1Kw1u+n9LJ9rM1m/aOJirTlxx5o+5Aapo 5hbA1Ah4YmzusEaPt0wC9eIYAIXAMQBiclqkw0+UOhYKwp/0VlIm+5n/+WLeuCfhsHonrQj6 oXhTaj503Q91/n3JHDiGAhHL9XAicjOazdRryc00U9AfCQJgUijRlS2MgUZy8E0ozlC5GWrk oDVvLN35/LKPm7kXlDIYekkUhGgsptnCTXB0CIdR/YVo/9o9NfRXmPXjPB5Yw0XlKE0lpUk0 MgrXyA5R4niuoSUJGu91uhXJGYqGVVkhQTA8DkiqGoqEYAHnMOVmLABUHQnGOz2o7uv1AoIJ x2KwOmaJfi+hvVcjMb8HVpG8qBGPjyRJsH/H7iKv19O6deu3Jr5eUPLQXW/kOYI7432pHOc0 qEdZQu6lcgBHdF6v1cEz8mbM66TqMryVilur1mUm/ZKUXkMqjzEzhmtd0LphPsEjglH/d78s Pj/3gsUbF/9UvI6hpHGETGbSBXfDAR+vnMc72De/nf3BpLeHdBx4zZljXvtmNky+/ogffh3/ 0j2/7N1m6NhpGIqSnZTx2LX3Y0gvrHCJbC+cWyXnHtq+X6/0Tp/+/F1lZfXoweeZDpqtew+W tk3NGn3m+Z+sW9I2q/W4oZfD/gUrF7NE0xiKVwX9xpotf9y0L99LjIufMGKM4TEpWJ3Xd3D+ WefN/G5BUfUha39loNqyBxoRr/SpFXhDso50DKAQrPadF+evXJx/5nnzHnrBBnvqG/qIEG5d DWWa0sKZrwTLLN2yjv4y4YKx0794N9GXkD94BK5MVizOPwdTWCdcNHY6XIK5v7adpLZEX/yI xyckOr1LnpqVk5aVPyAPU4cEvX7Wz8ls3vgWN44f5688FlW5li0S5Wg4M7uT1xv39PROcXHe QE04zuvyV1Vcc+3V8PBKAl0GKAISyAhOh9Qu86rzL75cEjm/PxCXlCyQt/7y/BwlGtpTfLB1 u9ZaLCLxrOBwy3JyakZ2fBysrNRQ4DJ3XLymKm07dYvzOCbeeafgcPi8Xl2Te/UdkpqWxmI9 Sodeuboa9bjcwy4cAyOT0yGe9uFd4LmtpUKms7cc3ReuqZY8CcSma879uvml7hJOSspM6DvK k9oK1xmBEi68XzVUnhheYD0pXlcLnyLWEKEZB7yNGP9Of3X64vte7EtNIonxKlu9k9PDquld c2V2FRyjnIlJmPIeOsoFS1mKgWoDZnVGMzaZEY6U7L5am+c8/+prFn8ROx4WOQ2uGcq8Xm8n rJ5hBUmX0fDrHw2LUFrVP5QW7m/ZABDUuxbKSAtY4cq3HoPvFBNYUzUcDD8BTKzH2NZoHOvY 2VOhrwC12IEFvbkUqTBNpPieiORewyLNE8PTnNr6nhpCB0J1ehve6KT7L4RHdP2U2VrdwBGq mquS7JimjDHoqTHV7+ieD2+eOqxjX7Jch18E6yyUyx8QG5wInnYAMcipqioWHRtHeOKhKomw vzeMlYHGSBLGckSJpi5tEs2FicQiHIcDqyUZqNtSdaE2j8OlcHI4FkUtCYQV6KmBSwurKoAf hyCQfFftmWUfvrZ64Zuj772o80AoKArQFjEcDYcjUdrnaFfg+XA0GmXRhCNwnEqaBw0D1LJr 164EX0Lf7KxVz+14b9XSV+Zd7JWUJG8KK7h0aqFliTtGY6k+LqvZ6MJoqKnBoKKbKTI6tTbp ZkQIBR+8SRevGxrGjF6X90wj3cYLzGtLXhzU4YyXxr08e+msJYXfAXrISM4a02/MeT1H/uOz 58srSgUnv7b4p60lhQ+Nvg9qmfP9R5zALNq8ZMu+whnjn3p67vMlR8sBcFzc/7wV29ZUBvyG n4UzBGXIFegwub44dkqbFhmPj7rTunEAQb7ftPqt7+Y/fcOkvu27bX9jsfXT7MXzMMSERLkW lGxftnXd8O4Dn7tlEnzqmB5//HbyVRNgzt4zu7YsxnPs2VaLFXhb1glnI/fT9coaf6LXN+3G vwIiyT/7/Ga9sEwdNWALr5hhT3m9z1j/4tyZ330y/dO3J19xy7RbJk2zNXXmonlFB0onXzV+ 2q33wce2f35uB8MmBDXMe2AGNGnDbox4NYwlispoAvMbokQEEWd3X2Iy/VN0uOADX+IQMTCA QvDXhCRrLkP+wLojmsuFOxKTjBokUiEgj06dckghQ+MNXoR4kSIJ3k3az/FCnAfrTEo2yrKc mJaWZtYDLw/+H/5zmbQXDRSv9BM1CFF/JVd/sZGdna2kp29xpmhJw3JK50Z3fR8NKhh5pon1 7RA2i4i7/WAGPnQZ9v00p7+QTzHqdOYMZpM8alw8n3E2i2kyTHT/VodgiBlKyZnSFTMNU1c0 HJiX7/PK1iX4+l/NMFcbRpfCr/V1j3taphihIbYPzUGE0S/G8OW7tw4/PGPxqIcv/PyTiOO/ HyPSEGfk9z2XiujC0pmOzn+omRsaXDHjmz+mqea03AJK5zp+yCUjX5lEnSAAO6w5D4AIYIuJ c/7REEHWQwCAZuADEMRuurDub/OBI8dFFZbPpb7czPGMHFYpu9yMId3StPodjQatL+HLsujf MRlHGocjRKTOeiFpV+sG+znmvsIeAGrwLzUUUcQGMzqMUFB5LBo1eeeJ3IyMrB1UjKaeaYT+ 6XS5BFWORmVZk0VORMIQ5CBRQhGUqXGScFSGMsOasSNoLhIED5xOVcOhEA1TRf03OHsMI2Lh dC5RtEsQE8MCntkJg7sghSPhGLLIUxoQOJ0aDIcEjnc5nTSbho6zxyqPRcLBlilpNw7JG93v 6GMLnl++6vFEN5OY2JqwreuGeC5DbAwwnXO6Ef7B1F2NWzEfbK1pxMhBNJnHuFolGqu/60ST wPgfigaueyX/zpH3jssbN+lSY44sLC18dM7UuSvn8RLHObARi3757oFL7p3zw1x/JMC7RUAJ d7z7wDP5j86b8jYtUh3yV0f8Kwox4gENIcjKqlvRydCShQVLbhxyRYLHEF8FCHLX64/xLuGF b96Bh+C+y25NJLqsMBP/7Z0Z3xeuY90OVuRRlI/hrnr94Y9ve2Z4z0H0gA27CtHZwbJFx/aP mDp+3oPPUx8NnfIx2tQEuIRhjK3l5OBt1juem/LvF6fdcC/gmAlpWVBwwgXE02Qxl9g1dSmv FGerx9DxY2b++DmMBnk9Bua275Z3qHzsjAeQL3X0LZbDZco7Lyzd+tPSbT/D8nzymLr7t6zL 7dKD1rlh77alm9fm9RyU19sIfJm5eH6dW37yWyAQoMHX/yuDsN20jGRE4klMr3pMjkRq4uLi 6r2kcPl9evcKBNpt29bR13p069J52v4NMqsiQYAg2LJn64Me+lcsHBVlxWqHt8fFDHOxdUyo ZIu8c1F8ZnytepOlP6jp0Zow42kQC0j+laMyE4kaoUh6He8MSf5ToqGAEgk7krP3tRq8aNtu GGQZqbn8qf9usCodkWF0pm77P/LM/f/LLcnjA6jRb9q4vy+ZYyenb5ucBreDzprNs+wv27EB /qX+l1NWv2sU4jT69tofd103sjQbfXybohtRjicXzBvEo3WWiwYxPEmabXQ9yZiEYzTw0mgY aqBgYCtH1O+gJ6FLKW6z21RcmOeCm31IxWQZnhfpUFLXTQPvq8CJvANAjBCx5dTgMkORQ6oi CQ5k/yAE8LW9ymFgA0aper2AYQD94BLOpIGPkXrs3jHCeKZZy0F0RclyMBZFvzKadDlVVxUC RzAVRxCtNV8wEgmX7fN5vanp6c9d+9jOobc8NWd84e5vs5Lccd5UFcNb9NpsXo01gj3ZWiin WffdIlw1F+gc0bRTau96Ld0qg2J++J0zqeJVaKXIheSaaQsff+mr57ukd8tIzlqzfXXJ0VJA MKLE6U6ek/CuvbXy3W8KFu87UMLDHgfMENz+4IHr3pjYI61zt8yuxYdLN5ds88eC8AwMeuQi +JMj9gyq+gstqQrXPPHFq49//GLP1E4JTu/3m9awHLLXcR5JF7kXl73/wtfv9s7sxKh6wZ5C jHJ1i7BMZkVDt7cqFjzvH3e2jW/VNil92cY1uhnwwbqlDft3t7v70pyktJyW6ZgDzGOsBuOW 2KtzMSGFRdHF6d+8P/3L9/BPSYCni72mH1oanOLMHxbOXP55XrcBG3ZurQwGJv7raTzeKY54 5nYrOoTN74N968AAEazni3cZWSNuGiM0pDISHPH3O3N8qYlOz4a9vzIiN2Xeq1Pm/BPpQPaX FB0qxya5JeiNKZ++PuXjV5BfpHa/OH3R+9O//jfN04HzJrrictt0LiqHA8oQTrmE+paYk9ng 8YaJmcY8NYTsjJkfXnf8MUaCeq7P32ezAr8kCeA7EynfqASrON7BGGMGY5MOsLVbjbG+dFdq p0CwBi7W5XLVWz7Bvx6Pe+DAAccq2m90tU/PKmx7+Av96G54b9EzgulvlkUEqw0ULqv89mln QjKD0STVoi/eZKhm5OpDarDK0ao9jIPh/dsPf3hrShovuJy0H6NHig9+eJvL56YtdDlVlhOs Lj66/M3I5rkOXxLUxqmhuIQkI9jI+gAEiUZD/opYJCQk5+z0DXhtn/zdmuIaqZhxcv9118xx sQjMdtYy0YpUmF+wnArF0eU7DOJ2QRYaUwmrzKKj+wHE0PhKGnZAvQk01oGGfcEeOLKelwHO CPVbcWGA+mEFbz+FlVthnateKaQDqrvub7id+FngGDgRfCyLAlxyQ90+qNA6pmG3nBreohMk YBG7VQO+U/cKtKRRTNaUQaL517vRUieIRejlL9j4Az06N6vjmL7n5nXKrSc307DPR/cZ2juz g53GgibrPrLwTatjrahqKzKGGkhmrfkawNZeUlvbFuljep8zNndYM4swgRdg0pZNVEHUZ3DE 1OirSAMDbdsCctNpa+Nd3nPb9x43+OIE0uGIRVT1kW/eHtC6M9yFiqCfXhpMe8jlnN1peMfc y3oO0WQ1QiTLabQHbDO+n7N5f9G+ykP0/g5t3/veofmWL0wQhCeXvN8zte2AzE6vrlq4ungr /DRx4MVbDu7deqgYvn+1bc3mA0VwcM+0nIu7DKJoBuEZie2NybCIQjjCozUDLTHhWCwK6IeX XKKgmIzyFVVVoWgkJbFl94yslyd+sPSX5e8teXJHyda2qS1FyQdjkm4EllK7BtG80Ui8B2tJ /HAUk7CWm4AEq9LFvGajGLECWi0PDkedNJyuCSQ9iWUiseD60nXr9q5FdkgXT9SWMcCCunng qEPhA5JXREwncYQrjQVste3Iji0HftVUgoEktCGVBw8IbkGjUn8kLlnndABlcNc1l7DlyE54 sDifhEhN4HWsn0OvlMD/cnS3rsJPDpzjBR5mdGRlJRE0rIiWpuKaw3urDjJxEkkEw1Qf+LCE ta0oeLio+iDjdeCViyZKoDCREoLpHKEkMZKCGI2nFPqwc+nuAuwVj1Trf6lHJEVNVNQKInCM SIKLTU4z3O8QigKHmCodAQc9TNWW7ilAD5qX7BFJfAk68/g6+ylfmT0qVgsv3bUBmwrXInAG 4mFPfV4/evQoJf4+weMbHXx0/XdmTNOPVvo9Xl/ktb7wrAHwE4nJAAnZyVoGnjeONVczHDIQ 10SZ8ONwoNC8DTgxIWHImWceONhh5c5OA1JXOPZ8yqiEVlUjvMEWCov6vUxpvA8fD8TjjKSa P1Usf13+5Z3k0f90dR8l+lp509Kd3mqroBYLScFfE1um0nGURy9YLX0IU7M/TtvtcWYgbSss cSSnPU5FBxQSqsHVQuaAZbGc13cc/Gnb9phDZ1yY0nZcGaPfw+oFUwUMxFZyB0wJsEZHUh1T rhZGatgzcc4/7EiFxpfAfqsgFKF/wk/wxZqKaHF78gitjWrn0omcFrHiNGmYLS1iYZoR/7wX SsFPVI8X9o+dPbWZUNATPwvdD+2nuRW0E+B09kkLjmk39Uo6X1J1X3r59m45tY1iKWhGvacc sAgNO23+3uFsuvGH3/56N18ELr/9Y1c9ZEIHetLzXpl020czNOpzIWUb7fMB08c/v/Qj+9XR BNklxK/EmPLIS80/De9pJHjBGw/e/vHz8OvwTrmAQgpKdlz9zhPTvvtQAWDRJLE9qt9Josix tYRjDCFDi9lYTelJ4RbTCBu6BxDGo1+/NfiF2+keaPDRmuoZS+b8XPwrfODyASzCMdAYuPsA j6565/Hr//1MUIu5MOvWAT2wef+eEf+6/8lv/7332IHsxJRe6e3gLFO/ebvn9Fs2le+2zvLy igUAO6776LnFO36ivVFSfXjVvsKSqsMY3FBx8MeizSv3bimtPkIhiJ1uBM4V5/K4HQ5ihFBJ ChESS0dikXAsiso1HIbUiKIYjUb3lhaXl5Wleltcd1b+P26dc/nQSQcDTNmhPayqYDyISgZd jXJa6Aa5usHQjgyORKKXJNKQOBCWhL1SIEKdEiQp0vhCPoxBMc+Yf/KoPMo7OMHJSx7O4QG4 BF94yc3zTl6QAC0Q/muR5R2w8uNEB4/fkfoN+Sd5Fy+6BdHDiy4O4AsP61gJGVp5EhyMkSKk +1iB5UUGfhU8ohAnCT4J/TtugcfaOAEqdPKcW+Q9EuuVYD/r4FnB4MiFCQS6ELGISwS4wJIP fnGJulPgMI8GfsI9xseJe/ADP5FfEQeIfP3v9DD4F6p1i4gh3IQtHj60YL0PxTdWPbzNgwN9 5CSVuETjVxepkLaH7qTnhdPV229vKrYKKpFqGyPwv0VbmBr561kIGm4/rlpjrWfCQUznUeQI eSlVM+Lnd954pBGSNdYrsl5B6HlpYPScaG4+k9aO8cVpIiu168e07s34EnRfPBOXxLZMYZ1M NBhFbMk1Z2+mcCQttVV2m3ZMag6+JDDmIJ+QZmZC0VgWeJI9vAs/nOW+oesogUlKi+OLP9OU iOBN9Ay6PVxdw5pkZY6WbZJvWCCMfJN+9EHPRqJOXY7RNsUPucUz9hM+71/wE5/3utzmqlgg QF5wkr8TDTEJbZ9lL+21Rrnupw3/Ce+PuVkjvJo7vpji78EjQicMGHzhC8wi1B1Afer2eYjO iG9e84C1Ew6ePPJay5QCswgM67CzXuwk3Q/FrYgHmqpjj9+EqYseAzsbtTFQCLJ+ymzrV/iT ApGmnEoneBZoLbSwXrAndALtCrqTXj7N4rE3Dw5oHiicyEbnbAu32QEKzHZwCvjSVNwuTdOl qBGAy0mZZxrGf1gBDfUQCb1M6/LpYRWhwMML35y16kvo5Gcvm0iVeJvqc0AweV36982sQ7yz 7oE34SamTL4EeqBhlJJ1x/tkdqBApyLov+bdJ2cs/ej+4VcZ9CaNmoWQMw2pWDG+BAk5VJwf OY72cO/MDiqRrAMUAnsaBvnClV7y5pStD78HF0LNKuv3bYfLHNNn6PTL/5Lk8VmdBrgErgsa +e2dzwuqtq/iwBVvT413ed++evJlPYbQuA2eFwoPFt3z6auXznr4i/HP9s5oT0/07k+LL+95 1ouj7ojJcjQmK6o8ceDF/1gx719rvxw/4MKLOg9EqjWimUdHfOtmwSU7HBL8BsNZLBaFC6Qe KxjkwrEYzysij78SXV8BLruyqqra709PSendukfv1s93bXvWioIPVm37pKVHiotLM+81qxmy vTpdCFLROZriYjpxVGSLJyCDMWZIRrc0UupatHViPGEUBCLENAKNZnSN1wVMLaRiwJpZFhNV qW2DpPdYpOQGuhGIo4fkj2s06RVNAsZJjdMRBw0vsbqKF0L3w2HYZNJSziS0Z80aMCOBUJDo hI2CginOHr+IPcHaJAu4Rl2Cx/tuLLJPKpKhwYvKNgIX+EbLsY2drqGw3+nhMFOIKhN8uX/8 dQf1hDP69oTvi7/47PzRV69Y/LXL7bzswqFr128rOlT91BNP9B80+Nknp07/x4xgIKzzfN9u bRYuWhGorHzvo49aJvl+Z5849aKqYRnxdkwLhMJSizH+7OsFh+jzyocr4yo3vZ3OBYVrfwzN 7ulRq2Ixhso+HdeRRA+I1hxyHP6WkeEZVQ3vDIcPOisiaGMFyUAnxrOu1d5OeIgFpxDaq+z4 UuqW7+o80r9rkRwoEAUsyEluKat/7bl0pqYq6ks2HlgxqTXDtLZ+jR09plb5pZRkA4ioquhw LNy9t1gMYiYay/7hKN6tnE8YhenU25BLyoomQdUDc+Cul15LHR+0hkb3w5BNz9XQn0LdNzA3 ACZodDaF5tF8B3uzoR6a/tOog+YEz9IQhcBGZ3eoGfZTwwlcxbxxT9arkCa2QIW//S4AHqrn NYDtucsmUgdNMwlEFBrS1sJhsF63rqWZvBi7N4RpWjnPOtJ++XTyhyn5javvp/MxTNJ9szsB XBjdZyjbRJ8v276+X3anRr0qlPNUr+sbst9xnA9VNdHjG937nO93bPhk0wr4IssyTahp3FPD soagjMbGNLU6XPPIl7Ng981nXAQFH/rmbehwuKJ6Dwn13PWbNu7uT/754Y2P0nF2+a6Nt5xx 0UtX3IUKvZomMMbSh7rSAItAD0Cf3/vpK/Dnf/76T4/o0ixuFUXu2DL703FPXTHr0Rs/fG7r Q+/Sa0xweV+6/E7W5EyLylxMlc15B4eJsBwTiRIvJuoQp48hp6chhwnMrB63WxC4SBRFfGFe FkhuC8wNsiI7NBdWanYOFCkuK3NVVHRqnTN20Khze4564+v7C/euK9n/nxbeZAGWZQyvEweN bhCdUa8LwSOswV+G0SQk7xdGVKpJR1MJOMZg0rV8NJwR0cxoHBUkJjYSjtGM6hiDaY3Sehly Abrh5SG1U2DDUcMZgUIs0fvlDB0+3UzkIRRt5PQaDUfALGWqj0NjVsh5SAMEw9DDGmCEq52h qTKgwWXDUpIUqqRsKQrVixr4H99OU1SG4fFkmIFnnSs7k3wesbo6PPyC89u1bz/iqafglu3a uqZDp84denqC1Uc7dugcjYR79ekTDoYAH/bq0bH/kAsOHyg+XFLUMqn37w9EMB8vQh67SCBU vjWqcKoerRESk7OS5f+8o7EuWQ9VrZml11SLAqwVGE5ReE5hT6Dvdu7a3dG1ntm5SYuonCii xQ/ttCwjh6N7Vyu6FDvwKwZ1UUYZyvETqYjs+0mVVc2/HyOkRIe+Y37ElaYBck/qGjv8M7O/ QIF1lD1mFfo/EkSGtJg/uu9neO1Zay1A3oVo6SaR5QzFO/jonHpg663dL7+z4CDRWTy5Hvtd mVVhJmuU58rCIjSKwjqgYRwlnTaa2n8ihpmGk7F1roaV0D1NFTnBs9ihVVOBJnB8U8fYbRKn baAw52NKKQZT3bRvP6iX4lsPi9A2UO8GDX2FglC8qZARGtxzIv6axi/flJsZf+als1Z9uXTH hr6kYy3ZNbv6nb3POVvMuR39KCRZhqrfNbzjLE2N0fUk2x3nCHeQIsuiJPF1o5fqXcWxoB9g 0N5jB56+ZHwuCexdULB8WMe+V/Q6u1EDFdxT6EZiWOAoaHj64nEcTXKJRHSABsjriKt46OQF G3+ADxbZsQH+TEtIicpEbgZjZTUSIMF4OOm6fiPuW/j6W2u+Ht0LFc+Htu9txfzClbk4p6iK nMHNhXO3yPGAOCLRsKqJkujgiIS4Ff1K9fNgvyg6IqFwVEFZHJXE7MJv0WgkJrMepwuBAo9h vF6vNybLm37dmpSUkJ3dZmr+jB/3lHy+9K87y3/1V5d4XHE8LLk4koSr0cmdAAWSNojBGhqd mE2sYbCwmjAD1+EIZHQzs8aCI7opQIMGBmNCN0hHBDMZWLcVZClqsFKFYSUpE5BjqtjgPpTF qQ2SZY1oFWJQMcqS4BVyFQYDiklhz1HNXoO+TafAiOYws0T0VzfbQKX8DMxUy4Zv////9c2y iOTfcGujB2RktnJ74+17Lr+sztTQoX3m/5OWw7uiK7HoIQKX96/gIisEHbNGeA2nbG8cI3NE JmHjVNHLRBRGZhkJOYPk4wb2xmKxRP4Is+rfkcogjFkOeP2hRsTvIhc5pnx7TzQcFRwOd4tk y1ODVpCKQnnRbXIk5vJ4xKQEeHsktSK07K/RYJR3OByJ8epP06NVQb0uEIGhwJuYKAT3Bhff BiCn9unElF1dFAWPLw7jpgkQgeEiUuO/MjPwN0WslrST7bHfD4jQoAcaFNJMRALMXtYs3tSR x4UdNOwRJgyYDinrJR39jxtI0ejW0KlxUmdp5rzUSgHd0nzzKO3Hb+9/e79Z8w0ggGU7NlBs YQGLRgEWNY1QsAi3CZr03V0v5Jr4oB4cacguU89N0+LBi+lOSpUGxzcK+Nq3zICfCsy5H44B XAJ/Fh07kNR0n1NOEb3BOi2Kyw6uyTtOAiYwiuLYAcu6zJHQVMVsvBVK3PAePXvphFEEeWws 3Qk13Dr44kP+SpSwkSS2wcHI01q2i0ZYA2SJd3pM/y4bA+zDKBKaKmCZwwzvlAt3h6Yvje59 DsxfTuI7QUZVPUY4VzFV8JLugwGI7D5SrpIBKMnjs+ca6EQQGFrCkEQeaoHgWV7jUUMPUI2E YS8SEaCBXzTN5AOA491ut6Q7I+GgFpOpEYwn0ZSBcAiglItxUBcW1C8gMXxwy5YtqakpZ7fL Prvdp28sm7du06uHKnbIakASXRzPUwiJ8zBH5nmkQWP1uvfKEKQxGVSNZGSmDjiwyLlI4Inl OTDCWjUDxpgKNSRmlBa0BcASqlfOeDRJEjFhU9P1jMSMkiNl8U4fjPH+cIDGgVJicZ2tZVpj zfhZjWFrIZSpFWy0jmEsw4oJA60/ak0j9CqtLKIEpxeZQsI1Rned2it/gpXoJ053YTX65NY9 p2YjgdcOntji4uI6Mpk2oCZJzqMVflVV/mgQioMXw91Sueb10OHd8P7DIyabGkvwr59M92EL dMZibHofl8MTC+0/rmtmx87tPao+DBYVRTQWIASPQUrUuMixAutJiPck80bMMqVjpgqaghDX KsX0KWJ4KSwgPC1aeFoamtmiI94ZH9/Ys4HHx7VsYTodGUPpl7pjZAU/gBdJVqCs867ytWe1 6vWVf+/JPrS/BxCxklBgFqmX29LU9PwbfRBjZ0+lMad0iqJJOs1HfZ5sNu+Jn+VEYFPzx/zG xBl6CxrtefrcP3fZxP7Tx9/20Yy5tz5x3KpoJhGNyxn5yqTdT3xsNb6ep6bRi6KToh1zQNvg k3T/hcc190IPX/X24zS2NK9TLo2uaOrOGgxddb0qHPU+kHGtmT7nicqdpqrUfELTdij/CHTR iC79Gw1wuap/nk7U74qOHoD9j3w5izprjntTOrTK4kVeUzTdcp0QCkiZiPHSYwB+0ZeIGn4Z QuIuIhyJIkxiDQvBpvJdgUiNcRWmEq+lYkP3u10ulyhBMVUz8mU0XUMri6w4nU6C4TjrTlHt G/jb4/KIohwOh6PUaqJj+qqm6NWRGrfHDcCIuopg5oDmHTx49ODBw+3btf/L8LHwmfL+pM07 P1FiQRbjS0QYMRnNmLFZagshDhiEjjwxMGjmpIwXphuRtAY5mm5KzxjQxKBeRcE8GrBhoGIK RyhkoXEdNs0aYnLDAVnv0qrzmNzRJcfKZq14h+VRxy8zKWPZpIV3vvfAkA6Dumd1ueSlazG9 haE6MrTqOiCDLCN1Sniv17pj9FqwZJpGjORsiyjW8ONYAMo0jWj6+ofemr9+2ZQFr2NUKd/Y RG6hh6am+ROpBDBxp9zczI7mHGM0ff7P3+cPGFYbj8MiY/3MH7+ASnJSMhDB6/YGEEshFhle Kzti7ifkqpyR+3OSWzQateSpG93CSH7/R1TUQwJE5aAj92aJd9oYiOpgqTqh9XJA9R+OhMPN ZwAcOnS4i2dvbNHCihqkabZ8o7i04JTanHmdhmhwdThtG9as12OFbM5wbT5yFmuIatlCdByo FByuNCZcvv3WLsO/Xr1bJ/LOfywgQlMVTpzG9DcyfMC0BDXUC/igQKHftHGn66J+n7M0b5I5 EccHQ9JPKGBq6rB+rTtPHnnt9O8+HNNnqGUnsAJLmzIAUCYSuLl208Jxs2ksEot63go4NdN0 fi+N6/zLx88nuOPWPTjT3uc6sUAMmD6+8aWJSbJe983HFsqUnLgZEjOijlvbCWQWU1QlzuEW eN7uUqS0qjQR2kHoz2D/Fb3PaZucVntGwtpunw3s+NIhSPAuRiIR1eAORTgA+yPRyJFAFe0i eAzsXaeRkFiP06XIaigapJ2e6IoTOeT8IJEdsihINNvWfivhu8PpdCAjSEyORZEjljC8AxwJ hUNQp9OJsnmqadqld5TYVASf2xdTY8FwiAIcwB6iKMCEEYtGXQ6H5HBgfAnHAUaC33fv2Q1o qUPHjtOuf2HTwSef//DafWWL4uOSRUbQeYGu2KgvhLLam1SrhC3esnDoLLUhkP4naY+sEdth OMBNKwhrem0YxnDlWE8IZ8ae2k0jlIHtryPuPqP9oNKjpTMXz2KdPHTekDYINDfv3vzghff8 Z/saPaqyErK9miwvBuQm2jd4BaYgjqGQQzEUZzpx7A4dw0ujW3NR46aRnKTUnJbpew+UsrJK qWfrP6WavuSeF2Hun7lyoaEX0+ApzklGbpKiA6UocddoJaSevI79Jl9wXQMHgDptzB31nddn j+o39Ybc9A7TRt9ef4Tfsq6ovGTamEb2T1/4Ls4y4qmwiWRnZx86dOh4y5M/6KbDVO0vozeU PV678ZnUmcSkJEFobkYOHi1queHvBw9WRImJlgIRVL+ytMEt8h1LQqgRg9ZJzyL1SNyt6FQK RCgKIesmJRSRz9T3pPO+cjb0x7KI0KgCOkbDyGvPn2x0xqWHNWUAP5HTARR485oHmgr4OF0X dRrPAtdrj7Q97SYi2pl0pm9qowE6Dy18s57DohksQlfnzaxXmilr3983qyNApecum2hHKs30 ebLHZ1e/Y0mMBdNsPCxDokNUkpTL2pYIMUVB/sMm5GYYQgitYTagXFs5MrEqAEdgVrbgyLRR t9EEK4zCZtkBbbrS23rvuWNZG+kS7RCHKFpcztQyZL0UTqdTwwiMqKZrlk7N3mP74QIv73kW HAYdNX7IJfX6UJAErxBXeAjlT3tmtDOnXzYUjjKc7AZQwHEKwSJ1epjn47wuWRGD4TDSoqBN hdM4JGytrgkApnBLEhyqmktS6qbReR2ATjwfF47JoUhQN6m5YBitiUa4WMwN1yAIKnHrOBwO KL5169bExMTeGRnv37fw43VLX1kwjpf3JSVkoUnCiNghrhmOMeJEWBv/E0N4+Fmif0dGd3L/ LDOVAUEsrw1jixoRiAwfyZqpXSfWkdnT9TF9r+iW0XXuynlXnjU23Zt6IHQILibe6Ss9WlZV VRXv9u07WMKqKksyh6hRSaOxKqQ3iJmE9DUxrjDkxEgNQi9Dp/s10zRCXDk6RS+GBrEB8jT7 opSl+LVgVyH0PhoziN6jfS4BpJLXpf/MpZ8yUYUk1rKWFd06LCcJK9mwsxCZ0OxCRTpTG4mD dDUY0lR0EJXzzNwkFhe7JgksPskduiV6fbk5XfJ7Dc1JSLX/ROHi/NXf5SSnN7J/zZJaEb6T 37xkY/7cqFNmx45OwR8O/boDc+BisUg0pkcCikNSnCiq7fR4ecZrYAWDelE37CLW4PbbgYjF XUYDVAF8yGhKjZkbwwty8epLs0e/Ubb1pMxg/10gYqVO0FBEmOToGrrR1TmNlviN+i+WPGzD n05jvOfpPQtN+anH+dbQpHRqG8yONOuHpsU2Y4Wis6mdycNuVmk0HNU+IzbKqUpzYJtzpnIc 3PFZq76EKZZCJcumUq+g1edU/c7ysMA2m7gtqOJMk9dIHKU8PcaOhwgc4S3i1IYtJHBEtaYT QxcChncFpgeRmJ2pu8qS76FhK8t3Fjw08lq6drGr30VjMU4A8CDYgab15MOk7nI6oUlROcYR jbpPN/14bse+Nww4729fzoLDJp55qVb3jtD6vyhcDd+HdehLEQMZgnAOC0ciMYFzO1z2ZpgJ MrDO531uT0yJhcIRjajo6aR7YXwJKOipkQRRRxE9tU4yNss6oVMEXygcgqGIRhazmP6qhSLh KMd7AY0QnRooBYu8QCCwbdu21pnZVw3MGzWg+KWFr7315Z1tk0RPXBpJI9EMzwVLLQkkh0Wj 16gbtKwGHStnuAQIHMFEFbLk1OoGiBA3jcHBWivey1hmCcM0Av00Onf0txsXL/r5awAi3TO7 7d9+gFXZrKSMkqOlCU5vvMe3Ze9W05qARYbkDLige96ZHQbsO1q+cse6175/F05ySe+8i3vm 9czq8kvJtn+v+mzFrp+gdXfn3bj3SHmvzM5DOw+oCvof++xVOO+9593QJ7vLpxuWPvrZqwne +KdH3Tl75WfDOvUf1mVA25YZC35eNnvl53uP7odJvTLoB2TA6trwLv3Gn3t5bpvOG/Zun//z svkbvp8w9HL6qKBTuEv/KQteq5RDE84Zld9vGNKzFv48/Zv30euXlAaV5HUbkNdj4PTF7xPq d3yhJgzBR3TKJ69TPjQ4AEetr+dOnzfbENjj2CVPzKQgZsRDt8CenLTMPW99i2+fw0OPB7Qx YsotJqcZQtElj73ZyH5KW8Kyf8KI3765XK6fjg6qHPiqIAdbuFQueDAWKI9jgg4+xou6EjrM hg5zduhAIYjh1WRraWibwSX1Bs9GPDKmOQSGNcAdwepoOAQDWjSC2XWAQ9A3XXXsxiGx2bsZ 2X0SV/dfJDSD+Y+qtsIMR63QdJgGLNIwLBH2UE9/w8zek7UuNGpCoFm4p+vSTu9ZaJQJJXBr 1Ad0aq4Z6FJAFfCB1v6L5MEeFw/R2dR+Oih+20czoCqbyJpROc2BsoBjU5YMrRlwQLaxucOg EjiL1Z/UiE0X8dAn9Gmp1+c0/oMlJPQW3xqm4tfVmqEGtjo+F2rGtDlFqfpdMyRmRimuDt7C 8AZWiypqVFZQnoOkYVsZy/CoQ8tv+/h5p4QSuLodqLEsTCeRKBRVrEbWeykApnhc7ppY5M65 GPD75EW3QCMnDbsSrvSZb97TKS2s2eHw7yebVsxY9vG4wRcPbt8jLi6O9gUsu4nZFlCFGgjW wLjRz5RKrnWQGYSZYpzH63Q4FCumhIRahCPhQCgAMIQQyrP2M7KE/czr9iT4EjDolTgrCJsB Es/7Q8hWLVhObLI2KikvLSkuljRmyqg7Pn9qT2r2jduLS6KRKjOwQjfkglS0LSC4IDIW9F8D fqCAjUEGQhwjNBzV4D1jLd4zrpb3rB4fGjmMfNH1GwffmJmUOfu7WdtKCqtD1a1TMgnBmnZG B/TUnNkNZcNKj5Ri2LOAo/htZ97w/rjXsxPSV25bUxWouiPvpp4pHd+8/rm/5z8MpVZsWxPv jFtw1+s39L8s25s69ZI7H7vkjjaJaZuKCtskZ7w37rl/j3+2KlC9fOvaW866/KlLb7+i+9Bb zhr14bhnr+g7HPXztqwdd86oxfe+ksi7crM6Vdb4q4LVD1xy09w7noWLXbZ5XaLLO++OZ/N7 DWUUFePtavyGAruszZv49LTRfyk6WLp08zrUd3zsnRxfCkZ/1/gxS/GymxIlLyG8QvW+aZf/ BW0ksgp7qBnDGIX6npGXOxi1YySeat8s3bga+07iczv3NBDzji05qRm4CNlfmtcHj4dPYlIS PK+0CICnOvstIrU/schv3rKzs/sPPufcC68YdOFVaQMvjxt0E3/mfZUDJu/u/sCm9vfv6fkI 6/bosSgjy8ZHUQwHimpyjtkFe+sKxNTubHS/zRFDDSGAQgCCHEruV9F+VKT9hdHOlzGdL3J2 OsfVeaiz2zldktw94lN/7xiReowRdkM6XWdbC334c964JwGdtJt6JSVrp+pr8KG+iYZM7Se7 QXGYA2jiKGUVo8tNajb/7eRg/6Wz0G6BD1RLK6T6wDRZlP7aPOarh4qo+i4NDYHi9dJhmor/ gMb3mzaOYik62Vis84BRhpP4UFr5rFVfUrauemahU6N4pxd43qv3jekzFBrcJ6tjVShQdOzA goLlMPVCn7x5zQPN9Pmzl054+IuZducrndFokCkUpP5BWgTK0mYIdQNHaMKq2rRmnlFKQBYv RddM1wFijJga653RnsbZ0L6CD30SoJfgjH2zO/VKb7fk15+Ljx14a83Xe48d6JvVsU1SWgz1 7xC1QD/DS0EZ/e0vBRR/6uJxrRNbwWGTho2Fgo98/daGsl1wLwa06ZLsjafhutBLsOeNq+7T iVWDITKkDA9zlibgtMwpGgCmWIo7AX5aseeXYR37VAQR90DNaO0gaTAuDrCFCEubqBwiHGac qmuaiuIygDlQbI9o+NklRqnVyuvxxNBWHFV1lUcaUQ0KyopcXROQRMklSgAtoN/kmBwIBnfv 2dEyMblbes4bt/9r1dZrnvr4nsP7t6QlJwsOr07TUAAyyCbbFyEXMdjNjUWcJU9j5tSQG2PR jdCbCY1QGDPiBENjaTkzIkPX4xxxNw25df7queVHS6B5/pC/e5vu/A+a1xEf7/IVFm/NbplV cqR0f0Up5xFZTr+q/xUTht50x+z7vvhpET1TVsvMi3PPP6vzwPOeGFt8pIyGg8y/f+bd591c WY1hPS9/Mfvd5QugDS/d+viogSPPfii/+Oh+aM3QbgMTnHFtCQh4a8m85794hyKpZb+snXPv P0b3Pbdvm87fb147fvjoBy+96coXHli2ZR3F5t9OfTO///CxLz4ISAVONvG1xxmBf/OOqblt Ovebcm3RwTI4JtETt+e1r/L7DYOdS39Zu2F3YeLoW3Jbd1y6ayN0FDyTlUE/xm2oqB2fY8Yw WZq60z9/Z0Px9pxWmdQjM3nsuJyM7PzBIxkqC7x7W05qFj6xF42FDy0y4pnblxb+RItMuHAs fGr379xArCzsKcdyFG7d3Cotw+txMyymh4TDQcDKNcGauPgkCa2R2rGKqhZJyUij7xBC/iA8 KJLbGQsFHU63KInRSEhT2UgkkpAYX1V5jBckhNQ8xiS7nVJNTUBluPg4b8XRQ7wzTuJZwkMK aFoJhiOqzgLO1rUYLkN4prqqmhOk5KTEAwcOaLrCsYLD5YHZOCnBV1q2P7lFiwSfD36qCYXT U9P2FO0WBEdqagtG55KSEucWrkxxJg5u00llWLcglFceyUho+cbPi4a16d0xJa0mgiJHZRWH RMHdoWWrZjzddPyBzeVy6Um69Q7CK1nyyzKWQ0kpXifvvmUUoSwjVjAca9NQtNtFrNmh3hcj R0avhTIEkcjRCCO6Xqho/XZhAc9Qdj6G041obm7r1gArM27uxDnNTgMQaZQxAsZTeOgbknPA /j1PzoVVfr3ZGgZfOtn89vbQLFNoktUqqHzJ3S/CqU8XEDntZ4FegrI0J9bu3IH5rGE8bFNR IPWgEuV5s2I+msIH9v32yd66TJjhAHbUaxgcSclFmmmVPVOjTgJeg5bQy4d+gwuh6SHWWR4c cQ18KKpoqs9hUreAiGVToTp2tBQFeRbosV5gkbgPVApZbF6hZkw4HLJ18yy+j0Rf1rD6wKuq /HXYlZQ4lfY5hdoWZbC1ndux79MXj2ubnEahDzUa0XgjCsfrvRTQ/8gfr6Bq3Sv59/TJ6vDC 93M/++VHey89d9nEB/KurvNi8zwMo+FYRCYGU3Q86Xq3tLZ/G3HdM0s+eHvtNwzhGlk47hnq k0IEA+ADwQYvxvgIoBGSHUPyWhgAMTABSJLgEB2WGK+VGwxYh3c6Aazg6WTMKEa/DKPLiOui MRkp6nkBCQugoCwr5YcPBoI1Ga0yRvY6t03qZ0s2/vjuN5NEfV9yQitJ8qhG0ARxynCmNC+L N4kq11g5pObAamr2Ek+NkVWLl0PGT+JH4yy6EfIkwfF3nnsP/Pnt+kWZiRkwXG4r2dotuzsA qKyEDJ/bV3K49IxOZ5QeRnMIDT2+sv8V3xR8+/XPi9AURfwONUrwzgtuffWb2fvgMBHzrKDF X274bsYNj7VJSq8K+heuxoM1jk3w+jYVFRYfLuMkniTgMMUHS3q37bZxT+Hzn85Gm4GEsG9T 2Xa8IlVP9PiKDpSMHzFm78GydsnpOcOuYIw4WT23XRdW0fJ6DgSQAfNjoi8h/4wR81cvyevS n+k6gM73ADVyWmRgJftLl25aW1njz23bden2DbkZnfP7DZ84++lKfxUq0rEMgBUjsGPnVhrx Amgmr/sAY/A5+3z4GLaQXYUT//l4Xr8hxjqzYLXR+RwLLaGKu/X3b16LLO/sqYveRaPRan+w eO9qhy+hRVK8EqqpqAq069AxGArv238oIy21TVbWgdKCHdt/bdEqtcZfqYblMMentkoo2rE7 M6dL6/T4XTv21sS01FaJ4WgwIz3z8MGDBTt2O9zOnNbph8uDW3cVZWa37d2t477S8oA/KAi6 yggeF19TXaMKLl+cVw36Dx471m/Q0HiXWllZGd8C42OOHTlcXVWVnpGhKEGNcezbV3L0WBXL M16XOxiJxXlcOqu5vd6KisPbfz2SkdFa5dnqoP8/Rbt3HtrbLSG5oHxHVPdcOfCcqkD1rPXf d/Y5A6Gq/X41MyVjTO+zmh9Om1rLRaMxV/QgE0EviaDpIjz8aErUGPLWG6p4VrCIPazV8tc0 gj/ML3XtIjRTF24N5xAqA9UBh1IbgWRTrzT5Ak90Y0tLS6mqkCRJTbnJjxst0ejMetyCdtG7 hhCkqeDNE9xvqdvY3Qf2Y5r6foKnO4WznGDldtE7q1uab+FJ9X9F0N/wV/vz3WgEzJ4j5ZbR xdJ5aerFsFrbaBKNZWtptJHzN3xPXTPwq2WDYUwGM9ia6vMEl5caQuw1G6U4bgHpVatIvRYi W5cZlUmrMrwKda+utmZyIiglqwoJniBwhER4+MM1LXyJdpcnZZqh3/tkd2iTmIqZs+R0VeGa 9L9dPmnYlc9dOgFGCkkQ7K4o+0sB7ZM1jE6nHpCC0p0o1MdyLdzxI7oNEAVe1yjbJ25HA1XJ 3niWyPPKqhwlHO+o8cdiPZvLd5dVHQHE0S+7I6zLjShUkzWE5spSzjQY16ChBhUH0dSFtaEk IM2Zqqn2tBrLDYcO4xiWJbkrvKoq0LUiL0oARCQnlfzFfoOlG8+3bNGiZUoKHLhmx4q5qxas 2jTLzUeTEBk4CLcYSZ8hfiKaX0McLRjtY2So0IBPlqIN8xhKR0a4xsykVIQqtK0a2d/Kk/7W zfPiXPWZv0c8fO4Z3c+6f9T9wx8a/ukjn37z86IZX77Au4XsVtnfPfjN3z54fM5/5rKwECei el1TOn8xac4FT+ZvLtnGEtUYZOU5/85L+oz44ZfV5/QYnHvPSNaLxJfrn/5y4dpvH5v7IuMQ 2qRmbXrmyxtemvTE1fcu/2XNXbOeRJEXJ7LptklKK3z280f+/cLTN0z627vPP3PTfUUHS418 X3Ob9d2C2Us+2fn619M/e2f6wncnnDf6zfGPoNRtXVb1mYvmT7vp3rHT7pu/dsn65z+GA8a+ OHnJ1H9VBgNjX3yQCt3Bv/MmPJU/YPjSjWtGTL4ZZUGIls3kUTdPu/ZuqGTKrBm5nbpTLJJ0 xYDKWGjy2HHTbvgrPiQjOhOhYAHJvAVS5Jq76u+XqCAOKgE0scYn85yKCon4r6ziJ6ZsfnpO jx49rKOUWCymyQKHeViCIMHNhDczHAq53BiDIMsRTeNFkQ+FQl7UnY7AwoLnMZRc12C+lB1u N4+y9WERJdwQ3MCDJwgC0avHnC+SX8VpgJBV3SFJiKR1ziEJJKEMKQ1haqQWBVnRoOdCobDD IYmiiIOGqsHjgKyCDE0xZ1VF5QXefC80NaZGWNUfDe73A1hh3RxXXhNsk9jKKSF9zoGaqqqQ P9mTAOOG1+FIj0t2C9IpILajx455fp3D/vBUQEajJt1o3h9DPxxnABH7x24XsQORWhRi2kII CiEWY5XgECUSquE8SbfXDJl7eOep6xri3Tdu/W+1iJxyKgolUD+Fmk9wP40ZbOaYpr6f1AWe 1FlOsPJGu+WUW3gKxzd6QKNXetwaGo1jpX/SVJdGLj93GGNLGa07aqEFopk+J4TrWpI7Tq9b Cma/MX2GNspxYg98oLM4/YmGtugkFIOzEdFaYMqQoSGlFELIQck3vE4PDJ0YGGu+7QAp6sep sJyCEMFgsIaDZEKPCHWe26FPo+sBjuccvMSxHIx0iqb0zeoImEYnZploDMZiGFpFnhhpoT3J hG6SGjl4EYoKCA4AxKjI3d4ro32PtBwkVxUEQAyENg3xgRGOShoEI7IDiV/5GCISBaZxqEXV dRkNM8jpygkYhWrxlDAWhSsxjWDsGhJKa5hZSOBIhEASh+gQoEUoYIxmlQMHDx6rOJadnnFG p3M6tDlneZeBC1bO3F26Mtnt8HrT0fSh0fgRKkNDqT9Y1Neg5g2co1UGZgeW2ELILiODhkS3 UoeMTuOMdUOwVtX0vwy9t+xY6fwVH6HVjOwFUDJp9IPdMrpnJWVWB6vhaJ/HV3aklLdR48W7 4xAXoQEfx/R4Txx5JHz4jCDzDOuVfNefOeaVr2Zf0u+8FVtWswJAS651i6w2LTP3HS1DqT2B O7frGVBq3+GyRE98osfHUn0/YmK55ewrqoL+vYAqGGbBysUARGbMnz1ryQKiIczrhlYxk5vT NdHrKyjaRhK8sXdGTB1fdKDMCBElaCt/4HBEwEXbYOfSLevyzxgxYfgVuW279JtyrSG9S47M aYkBHxt2FxJBO4KHODYxzkdNINPnz87JaE2BSP45F8xc9mliXLwRCNJ3MBHyRVXeoiP7E0lX 1N9/7EBR9aHfbnsWJMAy9ukZL5miENhE0RDmpfk1DvhTtF4z0e02/qAoBA9wOEyDqEltSF5c jhcdPK3QOJcoOeyLJ9xDOs3r9VgmVeqa5GwrMguF0EFCcHBeRvRKTgAZdGeXlNpaM33Jp8U8 X1MTbOGIHvHXRFlJEynUxxGBQi5M+7J8NPSareRe+0LLbgWpG6BKIYiFQhCIRCKCg/HLyulK oP5dKd7/3P4IWzPgoJlc3IZKdSdesKF3pnlPDWPKzegmIqk1DBD/PNv0KelsqtX1sCBW0HW+ MQoT43REZBbeXkXT7Nm2dOHelPodpROlVFyUVYw1te1VU6eGbyxpiOYMs7Zf6YgGyzWYXUTM xRHYxpaRIlWqQz5DGB00Sn4GzY5EozD+iDjyiFQ4huYrQfsp4ICdsBKUAY6oCmU0gYVjVJY5 wpEBp+NNTlVDboZYdD1ut0MWI7EomkZUjSdJv4B9aqIhSYGBGtrJW6DNekKgjV4PH0HoE4NT IB8auTo0lCiqQ8TVJJXpoXBk+549CfHxOa1z8s+4rl3WWZ/++MqmnV+XHdneMq6FJMUhJYhK HES0R1iTpIw12U0pyYhmWcCoE4Mk67JWHA/lssNBNTdr0Lldz3t23qOfrf7YCHBlmbSETAAi WSlZ3bO7Fe7bCv/Gu+MLS7ZyqP3H7K8uLyzddvVZY7fuKyytLk+MTxzc6Yw5K+eXHC37y4Xj qsIBv1LTplXWxOE3wwL3/eXz7rxo3BdrF2NZhm1LJvtNxdvwTw6Ai7f4SFmCy5fg9Z3ba/At w0cv37melfibz77i5rNGPf/FO21TMwGLFB8tL9hT+ED+uI37fq0I1cAdGjNo5NKt6wpKtud2 6EYhdruUjAWrv5t2zV3Tbrh3yr9fIp4aX/4ZI6d//m5OenbRoTK0w4n8hn3bJ4+6GT7TP30b TSwAOGgAqarltkXXDAaXiLyhpkuAjoVOiioPbNizLbdd1wkXjgUgAl8QvqRlLZn+tvVMTvng nwBxGtk/55/Tv/3QsEr9Gav639xqAgGmYl8Y3lKGGmrRf4Ix2rrigPEA0L/Dg4EjVA/antPb 0EFj+xBDsaJGQyrDw4qAAhHKFxIJh6Q44UDAf8q0uX8CkT+3U4QjjUIKa8/JYpFThiPWd67p UjyVDrGTZxAQo6kqToFNiG1zKALP0mwdK4WYwhFEFYRwvdHzCcSIESMMaSpr+BNkTWNVBVf/ PN+obRpK0fWZxcWOp2MwLU4TNFzNNGYagStGaRhOxbAN1Hg1isskod8pAVgx5nhq5KA9Bpfh djgUQQhHwsioqqlI8M7gMZFQlBcUp0MivEicpmp2uRkYvzwImHhM80FTtIp5OBzG50JBr+RG BV+TidXCIvCf0+FwORyBcBCbpaqUPh9OFwqHBFlwudw8V6vPHgyFNmzakJ6a2jezdd9rZizc cMknyx8/ULE76C/3eVJYXMyhcB6RviXKeHAunibsGiovxD/D15KE4AOg0/RdGh0CbYaVIfx1 7aBbtpcXfr5uruBEPAj9oHPskeiBsmOl3XN6ZLbMLlz/TXZKlj9UXV5VBg8E3EAoPenD+164 Zsa/7zUm2q2l2+b8MPfhOY9Pvuzebx6dB3uqQ/6Vv665+t3HkrzxCR5fSUUZL6E1pXXLDEAn pfCniKAHrSNHygBtVNX43/lu7pPXToKDoXhV0D917suzl8x/9dap8J1z8Ne9/MAHf52xZsY8 esa9h8sAhbA8t6Dg+wcO3/Td45gue9vMp6984cG59/59z5vfGH7Aol8BMeSkZlUGA+htEfml 29ZXBv2VNf7pn7zFOETDHMKyua07G/7lw+WEjIR8dJ2iCtwJuMQhzF+3DPAHoB/AGbk5XRo+ kBt2bZ086qbG9hcSEhHulNV4Kysr4V2giwen0+nwejVZDgYCgKc1/U9BntqtpKS4e/AgQP6o EpVhMaPBEMG4E1OEtD7lqUO9akXC7vmc6DTYz0w4wjawiBjioOaGoWnRqCM7Vyn/JVx1SBdc mm7QqEYjuiB6jgAQ8Zym+eg3xoj8uf2vb00FZh5X9aDRgs2XaoZ3tXm6Eb2JklwTFo5aCwpF FXVBDAk35PRmudiQ66yuEYhaO9EG0PQJqcOFsY27NMzWIUlNBdMk3X/h5JHXPn7BzeYUTmlD 0TqBpgNRaGbFAWNCDINDNaupGhJ+8E4iQkEDMqzwWwssqoAGQiFAFeQsxspHZzRRdLhEyaIv s5eldwdATCgS0jUDGhKJUVgs8R7JCe1UNcO7xdjo4WmcShDQD4mLob4zumqDa/O6PYwJXzC+ JBqFE+W0zvb44qGWZz97+edN/wxEApKoSYIbp1UauMoRMXqaAUPYwwyVXsb4ThjSWJM/ndWt f+EiVb2lM7OyurIqUI0PgQPHZvTjyLqL9cbCsOjTq2v8ACDivPFwauRadQByZdWYpoS0Tq06 d8voumXftq3l2xDBsEiadkb7gZktsr5Zv7gq7CdGbzarRWbRkTJO5OEU0Cs+0VtJTqfzXLzT p0eVRy6965xug3rdPiI+PvHywecXHykv2LsNY4MwshWvHaADgU76uV37t22RWVC0rWDfr7qA 2bDwa4LDO6xjLtS5bOtPcEaMpuo2IMETt3TLT0VHytE0EhfPUCEFnstt3WnJ5FfH/v3+pXCw U0TLB1VpVzQmIqPkGvSLJDAukmoLD0JMZcIyYggSRYs3O6pQijO8OhrMoZm5SxxNiiFONFWr sx/KOgU8o9BE+m6zMSIArCORiJGLzjD+UGj3pk3J2dmtMzP/HLTrbQXrf+606rZdPxXA4kxK aCFm9ghmDqmI68r50rJbtzlUumdg4ZTA0TKOlzga+MYa/2JhVaaaeWSsMsZZ+vpHa6q09Nxb d7fpkyT8Ne1A8NfvgzVBeIYRjoR0X+8RgzbGDruVE0+NaTjMWrf+TyDy53aKqIJpNrvkuPig cfvHcVFFw1KUx71ZgldLNcburKHhqGyzp1OosqUxbFJ+cNZwZDS9IYkZsQFYLdDI6SRijGmI RWjoCYAYBVCMrtQzIEmiJDZL/ByORqw0FgJ9GGg3TPPwUvNmhosdBdJ+jsIwH4vKJOLOAB8E DXhcLgBbFoixI0DcqSihaDQcC9MQDOoFAzjkEB1up4slHFlaAyyCBpVYJEQoXCnuoN0L0ARK uSRJtx0P7XK5XJ07dYZbeyDI3PuvS4PVG2NyFLqB40QSuEqp3S1KEAPJ0qdBp7rnrKl4a6jC kAskicWqrKsKiVDE4Ay0nmEQEexXdDlCiO6NyH8Sgkc4vpCERNE1RVOiUJw8vCQuhMGyMJLD T0bP4qyMZi3CvEr4TPA7En5gEY3DsFk9ps67/XVAQje+NInYJ3iKEPFakE8M3Uo6IYIFlIOc qrJm0MXiwQKV1NNlFX8yn3xyG0i3G5UQAtYW6ciYcMezSzevm/ivpxB/OIn/hTMUbYhcCHkT aXwJ/EvxhEIclLQqfDQJwqApoDrJprZeRNbIkaEUtjZqV1InQBlabeNvZnNAJBaLAVxOSMCE 87nvvbdz7dqMli1/fOUVV3b24xs2tBKESDhM3yaRFzFqxzK70N6nJ61ri1m3tzA7PiMtCeuk UaUAjwWB12SFE+u8YlFZZjTtf2X03lNY0Gr53UflxMr0IdVxHXlfSlpaekrLFjCnwyCwZWth v/JZh1e/z4hui9mHon8lUuNK66RFatRQBceLVuQ+MYfIaqRmUdq4WxcvBfDa2ttyYu8uV0nF 0e3LIzUhTWWcQ8YO+elglUs9LUDkT9fMn9spemqYpjlVj+usqUPTWdfs0YxphP6kaBpbdzRT SI5EU9YRlnCq0vgP1rYTJ0JdFxoI49Xx1IiiQsLrTZ0RnNkwYJPlRbHJd8chCCrHUY4Q1lBi gxlIg/W2RMIj7AdbAbAC8cVEZVZBrlIy25KyMTkGeMjpcDTVny6HE64lHAnrFGQA6CFhpMFg EOVfJEe9rqZ/Shj67whHg5EYQ20VyATA8+FIBKZxl9clcjzhDNGsW0wDR7wupJQOhGq0WIze LVGQAEVVBwMSEsM7cbatq1WmqArMFQlxvmAkXBMOMyYfHVQYiqLgjdvlEgWRwbgXFVAINH7T 5l8S4+Nbt2nz8X1fLNq25+U5F0QjRx2iyonQD7xO2B4Yy8FNPW+0zzi9dgaiFAmswdvKUsUY CS6TzJisgVfQf8CzVMGUYieDrt0oSSJhyYMClfMSi9DOIEfDk3ECBg1Tw5FJwsrQKFisHNWK yTmotQbneq5NSuZ7hWt5J3WIcMSRRK045AZSLRvYI+iARTSRo+o4LAFeBLMQgjaNMMbSxDBo gGTyyJI2YGb7pJfhz/lrl06c+bSRxiLUJfwWeGPCtqA8EfOpnVqsnXrd+aOhv7DRndyp5+6i c5O8QS888UTXNm0efe45JhIZ6XZ/+NBD/xDFeyORZKczXFWFHlNRe/LbOUci8qC0trsqDp6X 02dlyaZqRe/oiftx/2636OzUIuOI/5jPkwC9yauFRTXlnVq2v3PoJa8t/Wh/WD43K+eTHRvO zOxUVnVor78CxokLug65vNsZleHq/4nIFsTuKrupy0Oq6EtNTc1MTIBFCF1s4LAQDqe0bLm/ ogusSKJqhOcoECHO3JoqT/vB3yTc2jUpmrZqSkSPsRxvyW5HAtWudkOm/2cLIyFI3adXP7xp 3St83HUdr70xwc9v+a5Gd0TZ04bV/rSI/Ln9V6wj9sX3KThrmi/Y0FND/+SbRhV0U22owsIx SBLKHYf8UZFlRa8zueK8w/KS2ByUV0ieKluvW2AqFIRm3jWdEAMoqmxdCzUg8bzocjSX3Scr ajgasqjoGdMggW+3aATT1+lzcj0IWcKRqBxhjYwThvC6aSKyu7p4VlBRF1ivd7MwBVdRAjV+ S+GFwXQaNEa4BKfH4wbwZD8d3XiWVxlESKFIBMmjTKOLRtbPPrcXwBiar2h8MfGOpaTAQNoS 6vn71x98sex2kY3EudPQzUGoz1iOYc3EXUqnSi0ZhtQYDV4hV6rb0ABFCZZYrmYl+pr7aw8g BQzNGkL0SiNeEYJQEwBaIwylYKJCU1uQiOqRUoQkljEBkibrWb60ov0lxOIiwEBPQA/FVrVz va09Ov2VsenJ6LrxKw2S0c0fjEqIVWBMr6GVVZXIOGKxrfPcqa9fT/9AcxzXTDgW21lU9PzA gbOWLq3YtMm5eLHw1VfwxKxnmOCll16wcGHo8GHA08FwzQ2fz8zL7tI/o+29S999ZcRNC7at 3l5RckGbQV1TWoQi8o+lmzu06Ng/s+27G5dvPFw8NLtbalzi3edcfuG7j84dM+Xub167oVfe p5u/65nWJ8st+MPBLYHqp8677lhNtf6/EIlC32vqA6XLJ+qWtR9TvGVV9vfjKysrqUUEX/Bo zNvjvPWtrhfcCalpaW3KP6tZ8owuukn+Po5aakRd0W7C7d9+r3tFI8BZIPYtXY/XHaOzcwa1 7XDbii80p/Cna+bP7Y+LReoFop4UHKmNRT1e4IjWgDCNiMTyzZ9Opawh9ew3zarfYSn0eBDh GJusKy6Vab5+01sERex0rh6IEQRHsw4XFXNhIowtX4miCnhPRV5opk+iMcxXsS9SURGXJNYK LK/9f+x9CZAdx3le99wz797F7mIXxwILgCBAkAB4iAdIiZRIhlepXFFi0WWJipyKqVg2VWYS 05GLKbmkuCLbimJLkS0rFZflo0qyZTOSeBgiTVEUTt7ERdxYHLuLvfddc0/n7+7pefPe7nsA KJCB4h1uLR/eTs893V////d/H4qiFBs3CQ75gV+3bZepuUdCZo1yTjXd0vVIBGzTmm88D1R3 bNuxIy7vEcWUE1pxY5pwnDS31YxFRIwkrFVrduirgk4bscSXoWtwnDKrckoCxaqqrB5co+qK Q9Bjf/rvdr75v/rzejbbH+G4bgbxIkqJz8JjfRHcSM3EYYM4JsF1R/gYj5AAIgKCsDaRwAGR 8LpvaM2noEYKr/DUTwOCRIkcFIcLyQeWqYkCKugi9OdlghPkwZ+rlAiKOM4YNpHGCJ4cWPqf SKArmr7xQuLTWmtWISzH/i9XUC/TCYgA9Hdk+btf//pLn/vcryO07kMfyj76aGVyEj/2mIHQ HkVZCw/52Bg8SV1W7puvfn+s5m3tWVbQMwemzxydPb/czF+7ZHVfPgOv7PDs2FOH927sv+qW /jU6Qn99bM9HV3+gJ1cYmxv9P6cPfX7zPZ/f+w+/NHRrT76gkDCI/MOzkwPF/luXDTmB9/PS Y3Ms0q7fO3TwwC3H/9upV1+Ebij04Wqj7Ed+7e38PRuuXn/u3Lm77777tdffWHP0m+ee+yam Lx9xq1Fuw7aHduEj7jgrp1JjLjMHslTSligBCWg49GfQ718EIovLu4YjF4NI5lNALohF0q3S KiBy59AIL+7gE9WWVhfkfyQDSLphm4LbZI0gohJhUqq4lhNHNEXrfHq26xJRxpJc285whLAy YNv1EGUpNPYIr76u6ZIsdTg723WCIEySZ9x2WFYkk6ZOcJgiovKUU8Sq/vwgqNq12OOWhUbi mgXNMFmWijFAWhmpAFtq1arte1x0AxFuEUjJoFnDQhhFzbuLf0eRGwTlcplGlhpgiz4rpqZl rDimwttC15QxzBWrBmGdHUePfPk7jx45/uNVy7oNvcg6MzZ6qwxeSKiBQrCgDsTEEUQSUoWI XqTGdfoQBbEnXiM0EiUhima8kg578OhIDAsITxdygdeW0AgLGUWIM1EiImATa0ijU7Gtb9yk NTSSiuIg0oAjRECcGI6QBKejBnGE/1xZ/UsnIAKof8L3f/CVr0w++eQnEepBSCFkz5e+tO7J J5fAyAqvaqWizcwo7G53mTkZYY/WecO7T6Vz4KGxQ9eLqPqZHIavnj324bVbKoFP5dZgbhD6 8JNRDYngAEc6VnwSuiFl5MoMtrmBD/+M6DSDhzYRusTKH/Fm0UgmBeZR0Oo5N6+b5eEKNttp XaudS0Z6zQ7xm9Gx80Pn/m7ih79fc5BqZMLbPjPcdTugEBj0h4eH77rrLtjsrpd/vGLnExP7 9mIAaz6evffLH/7Gn9JwCAARTWkAEZkzh2LV45+pdneRI7K4XFTerr2tLrpE7sgF7WYWbIVT wiEL8z/EoBOJNRut2IReacNjpfruvEQtnalh6QA2YssLwxGmwAHDJuUtMk3VeBSPkOv5MvVq aftCGUzgnA+uCVkMvnHCUGHaQwuenaKqGUXxfd/1veSQQhQ5niNJiq5r7eqQLcOEndlU/yOM FWJhlPXDWljXqAKIGjXFNhgJV1E4kS3w/Eq9iqVYsozBGtv3PQPOQddp2FYQYPlZwGHlslkj 8OsO7NCn5cqMAsTc76qqLAMciRg8aYnuwGF0FYuAmKq1Ci8opOghCgFFwV5Mtr8EjsxWys7R I/09/dvWXfWX//H739vx1Dd++Plg7PjKgWVYNpAU0kFXgn4tpmKwC0HEheTjOM2N87GfVdUg 7twrPGroynKMTuIuVkG0QpqvRq2bxfc4NjWlZwLfBywJFAoHYLYdQkgy6sSfYlk1xpyQWDgt ImmzIxbcaUQ9xNjHI298TZx6/UgipsJbxGVC4jXgsjZSC7j/uel8JKk8Obl069Y5hLIIaffd 9+Iv/mJh40a5rw9NTpaGhsrZbDg6eujo0VrN1qUeNwgNnbjRLH/gpdh8CLAoldbRJeU7Z/ao sucFmoxqEnYRg95CFC5WT5SEVo1MSUPIkCN42Cn/WJZqfjMCoMp6XDMIs+4Gi/ypUEljVz5U dC8K5cAnZka1q1xtHX7BQ53W3eG/4a2pVd1iMVu37dALicy8ppkIoSQ6Fh4j5PwqFJcxUbIb f3/bhlfDyCeDRQ9ZSwZHP/Cb+yfx0oxz4MCB2OGSHcmNt2x7PfzdAfe3zr25r/v6W/ehfqK0 p/hgdMnQrOMiP/744wCLuApb5/z64vLPGY5c0p/SNq0X37ARNZk/aUge+/ZyI9JCjDlyod0x Y1icBGN49x7FU9SFRMxYQEKm0305hL4MR0mmJmJjL0kpsbY25HX8Qv80gVBECIhJbY5TYQqJ HBPEwzXtXIKA1uYwS66FWgEgoLQ1nhJmfS7NwtCPkRcGMOLKDHmkkZ/EMBjTTFF4RIRP1Nik kKIoKmvGAEoLsuSRJMBhKjXYowuFIxTn0UQErYWGv8pKuiCIs3O4XIqmqoTVKDHWhBIyEENr oYMQrrMiKxwqAcopV+dcx+7t6t06tPmWTQ9GUv6f9j2jBjOGXkCcXsrrZlA8DjVABT15hhfS sbMGDOCl4I3HSTxrzKoGC14sFhTYCPOqmgQPsDQLRkn8RVT2JE8fTn214F5IYgMidkRQalvi BRBFQ6nXIf6MeNSnITGFm3Z6hVIvk6QUL8YJo3//4Y/19fVRM4fDh3tvvnn6hRe6zp0rHTtW OHiweOpU4YEHpJtvHv3Up4Lly/fv2jUzO7Mkt3pc/cFx87OSvXZZ4YZSiYrDyIqmK1Imm5MZ 8dcmpRXmjqu8x/qso2Xto5pENEvvLpYQoHlVodbTlmXqJnQGmWwWBkR4zvOmPFGX/nx41Z6p 0sZ8vbdkEkkxDBOer2ze0rUsPOu6maP0c1rXJhe6uqwM/auum7AxWkhvmgAjbti7/bqDO2bM vDJ0tWLbRjYDT3ahUID3wzTNXC4feJ5uGPAuPv/ijnNjk7VaZe3QWsU0MoamqYaRyxqmGfme xLTb4b0wDANmBcWubkXBgYdy+VyhWIS5ReiHibJ7ywLHODpdvXEo95Pc/ZPSkqV9vTpbOABa v349fxOLS/rHsxsL5386dd2vqD1Df/nSD2kNNq974j9JaO0y6Zglt34RiCwuF4VFfhY48i5a 4UsERjjlUk8Wit+QC8ERToMQ1TEo1vZpF4zhrTDT9opEgpYnU1hDCRG8kDYq5ra2ovA1OVOO FSJaLtqmhIfV/ihYoisK2izjunByJ1pYwpWLrbGaEBjWKdphMzYqTEbnUaFMmW1yixszBQ2K Su06JMAEdBcSM3+jzjUBlViFlVUm1JhMzuPpIB0AFLoLgrzAT0Zbn4KKMKJ+NwBHZJK6XxEj 62gK70AVLifNKl1kdmoB1TshkSpTgi+bv1JB65m5GQ3Lg0tX3HbtRwb7rh6vafuP/dSQfU21 WKwjIYDwQZugmOwZG+bFaQ9xa0XIDZGkLphBDR5W4VUvLQgjZqGQBhpIhd6w4KI0HhypgU3i Y0Lp3ZFGmwT0ICEnixu5plgZRUrsh1OApmECiBK4FLfBYj3y8wNE4C/Hjx9HtVr3pz899dZb +ZMnl9x5p/XII9L69WP33DOzdevsoUPHjx/r71tWrrr+2q8+fPvHf3z8e0P6J/t6MrPTs9i0 dEz6enrPj4+7vl+183d0/w5xzg8OnBr3f8GQuit2fXBgWalYyFvW5EQ537ts3WCPbQfZQk9v d+7MmbM5Nfzbw0a0/NqalpMrY/ddv+zk6XOlru5saaCnZMmuNDtXzXUXMrqxcmj10mLh/PjM jTdtnhiZKcEGugpzU2NlrKkHXr+1Pqpfuy3Y8dz52/6FXp3WMlnXIYODa4xsYXCglwT+xOQE TBrOj0/87+88my8u2bV7zy9//GMRIlPjo8SWr9qwPpvNBI4zPTvLhU03b948OTmh6Zk1A10j I9UVa9YO9fdi15kqzzquTxgff/4yM1c9qW0I1axpGHyg5zU18GHjxo38VgASIHrO690wra/I F4rf2v53jQLs9xiILHJEFpdLy3peUsikMf299NIYJBR25g/JnXfK68/aqZ+1bUjYkDuv0lUW 6p9td8fgQDrFwzQjqG661L6Kh9IIeNYhCBrVMYxp205TlS/Qxqd5IT8RTuUf6MwM5mhtzo5Q hXXHoy19GpqhhE3KU+DOL7pKXVIJOxGUKr2G/7uB61IL3yCWTWPrAC7hYmuqrHJySVIgw28N XA3Xdt2Qyr1yxTJGGyEApQxFh2awX17B1BCxZXuEMYMKnPgU7nCdWVqLg7FFrW9UnvniXBbo knPZzNrBIUAxx6Zq23d/7fuvfG9q4tXufEkzCnRwxzwJwst3uVEy989jYzlGoSjf5X0qwZxk igXXMyF/xGxTPmLG30soCjEiKb5I4mvDUFCaAMuvSsSi+UhU2TQ2FW8cRyKBxCtx4jGa7qjB RKF5pTBOI8UbpxoniOeHuIpp7J9DMXGDwYqS+qArqEO5gOnd9u3b4clUCoVo+XJp587+cllb v35CVWuW5YyMvP7qq6VSSTd07OWPeN+2lz1vDt93Q/9nJ2feobq7KhXErdZq+XwenpVA6rbc N+5Y9UcnJ244ZP+6Ls36gQtPgaEoAYmcuqebMDxHup7L5YzR0VF4UDOGMjnr7Cab4Um7yzzU 050bG5+BsdJ2fFWT6GvL3KoBJsPQ7nu+53lWxnLrDjzTVN8vDBTdqBG8ddf2oYlzT998r7Z2 gz16Tod1XI/O+mUFM6lieA01w1Bl6ZkXd4xOVj+49aotW7eMjI7Aa6pEBA6sWinrVg5FAcwa 4I1avXr1yMgINJNJZLs8sUuzfK7n6ZrRrpdOKmuS3gz+yZ0CH3nkkXSPNzY2Bu/28PDwjf/h YSpJpysLcEQuCxBZJKsuLpcdkVywLmbBhvhCqGK++106st2uYVKh0dKQ50c6gRiGRVrZrxwf dKypCUKeq23k/KkSKw+MtgcxfDAGWJG81iHzz1PZoNvhOH06NfLDlFwH7A52ZeiaLCkdzo6q n1GF94gJbsSOu4AqNFXjx5kWQGPhAIlEYd3ldjMsxcPKakgYAF4ydIPXKMXqrKl7TTMpvl+H Pp6CmJDTHDjQMWRV0zUOttJYBAmBmWrN9nwnYBAvFklDoYwVU6cSrrGdUBR5TOq7p7t7+YoV 0PaZfbt3v/U3L+97yvPGClaXolkMVIRUJIRz64TvKM9fkKToNwYiNNLgo1h1JCk/4VIq6eLe FNQQrFJGVk0YrBx2JGgDxebMOEoYpk3rxB/4ExqR2FmYvTDzdtSorBE1O80FNUm9T1O4ASVJ KkxSDJQrHIg8++yz1WqVZwmjYjEE8FqrGlFUmZw6evRooViEYYtSpQHzh3kYU/O5TD0cR4LF TTnXCkXcnLbuRiW77suaamlVHFGKVVL4qig8fUlbAaLQAfXKCkDKjBLZNRteC8U0K/VQ1TU2 baCPBMu/CieEIKCgQZZCP8IqfYpY3RjLFStqFcmAhDKGLteqYsoRseeKxVupWyKgmRDGX11V XMc2LGuuXJUYk527UiS4IQlj6LrOg7jU+5e+JUxAjhbTkc6dcLpLgS1MT09ff/31Dz74YMs6 sM19+/Zt+dy/et+AyCJZdXF5N5mad203gy6T+10s1t6mWczAarab4SEH6DX42InbkFjpgMXm /YQ0aH9cgVRKeeq2LLDNiL3BIe0ZMd8Ulbv0PJUJw+OFahbkmDWCwzBWOI394aiRTKCrtDRm wWvKUyfUUTfweW0w211Ytx0KKqjfjLTg2WVMywvo7I2GcAjVPIVRnlJM/cBkSqyywAc4domj dLysmYHeGfp6jn5oaklW4EOlVoWdGarO6CakUffEy24VpWhla7LreC5lAdMSBujfAzvw3NCz NJMnZNKFwTxTk8uYfqjWHNeHFWHKSTmEdHdz1bKlGzB9VNhxwjgE609NT09OT68aXPnAtbfA z5/9aNPLb3337NjbyJ2wzKJEu+qG4RC9MxILX7AoCSfpEF6zQuJMjhzHErAAKoLKI2oUQlH/ QMSXJObFEg5u4EuFWQYL5BCnYmQuPSLWkcQWxKboypKwFSbxoWFOX+VYJQnYMFILibERRrH0 KhEmgDjBHqLEJslJ4UbRzRW+3HvvvUmwMDYwlC7c1Swul7RUKpX5HXXnGPB7sSySQhaXd4lF 8EJ1aJ0lgHCb5MjFNmyTu2nXkslMtwZAMLO18+dlYVrwgcaInAnmYPwCynvwRcBgwWGeZkeY yEd6is+kmRw6bWmzQBNDiwMSfICIvV1c23O9DhkxXdNMzUwiLowuiV3XrVLEELRrqCnU5AV+ 0/IfRjehvA1Mqna97tihKJdN3y9YDZBWPpPLZrOK4JxKdBYowwWpOHWAGogkLsXxErJISMay 8tm8bugU/9HBmCWeMK7atXKtFoYBJ8olddokTlFREFPI5ihYYVW49PKqqhv60HXSJBODF1Q4 X6MS+CdPntq/f3/oeb96z6/+4Wef37b1Ed3orru261QpMmR5aF4yy3/EZwo6MMuRYMbakWIR M5IUr7AEDi0gkFixLcFxCbCEk6pYwiRPmbo6FU7jjNlYgJ6vgEQrWTSMQzPxOnFzJLaMY+mT eB0RykHNn8Vf562ZJPEbf21QXUUVc0N79kpc4K1JtDGYwRAK8awfTrVMPV57ZfcTT/znaN6s ZnJiAn7/1yd/+6ntL7Vs+dj+vf/pic/7qawVX0bPnbY9/59bT16r1aIrQMx+MSKyuFz+0Ejn ZE3CUpyfOOjA4UjKzMIW8Q8uDN9e/SyO5JPGfJ1HVANGzpDa1KowfEBrMIOU+pnEhmQYdBmR c2H3O0r/1OSAVeoiMWDTyLDv4QBTWnub49R1qsUOGydRXM1BK2nhMG1qHKOp6sKYSZEyiuXQ yIiXWPjC99V6TebSqG12Z5lmSCK7bnuhz8TNKe82pFWyc4aqZy2L+/c217kQOAw9l6u5vuPW WMqAcKYrgBjPU6hSO8U0OL6VJC7ilamXWz7Uw7l61fVdKs7O8utRGE7PzRm6YVkGU0nlmmCN omI48a580fW8cr3KfADhFtAC21q96ni06MBSYuYdj468tf9AoZBfs2bNl375D3ec+I0//ttH J6d228TWFZXIIkgUcV5qkwYC11DnFbVi4OZYBEcinsGziBIPVCARTOHPZoxW4+CHxO4EFwSR UOJ3wx/cOCIhEUGdjetu47qZRhUWXQc3ABFbSxY7jeK6roWKe4XoPUr9NWaqzg+NXKnRETph YJZJMUqo/kPJvMrFr/zgxKc/Ujzc33UV//7Q4SOO6/zJf/+DXbv3bN5605sHD64eWj985NDU zPgzz/2jpGhK4D76mc+MT9url2b2vf3Gf/nyn1j2+NHDR/7tJ35FlqPu7vyylSsnpmfdwJw5 t//hT/7avffcsdixLwKRxeXnD4ugd6U10sFupjMcUThlsnkyB9N/iaUM2trNsBE6YFUZCTGF 64h3onGwqhPMKCAEk6T+gMqIhKFGq1gWbqiwKb4XBFEqv0PhCMvUtJMbgXVM3fCDwA18HNfU 0Lmg53sANEzDbIeZDFUliuI4TkBpKigRFYABW1FVQzcXPEoYmbOZTOAHVdcmAgWqWPUCf7pa sXQD2koCwCU3Gg7LNDTL0Mq1Ks3UcL1XRYGVKrA7WbWobZ4UNoMYmuuRAY5kHVerOvXQD7kJ KIw0cGozc55Fjd4NWejapcVYAf30FkqwO8ensDA+O4Lset2TnayR5d46cH9N04CL8Mabby4b GNg2NLjtiee+/ZPnvv69jxd0V9MzNGGCaaqDNIpVGHSQYmSC46wNEvdaFOAwsCCxfyaS9vE3 IrfCBFsTdgYmDX0P+q3MoA5noErCDZiDBhIjGAEc4sxJkvdhPNaYTRvDlTCWGyEpvBGvSbD4 3CgZir9JhEbijw2DuibpkitnSTqH6dpPyur/JORjL5z6Aq7/62+cvOWLH5xGDKJsu/3OT3zi kV0/fqFv5er7779/584d/SvXWZJ/9uxIuTLT3dvf19f30Yce6lm2evmS7K7du9asXtmdWfXV r15z8sQJhMIXfvSPDzz00dMnT/atWL9siTE1W0MdlcH+v+m0+VvWUr3///KQFsmqi8tl7zha 4iKXqsRKLkJTlauFkubdkdgVVep8lH6K/5E0Vy5Uvh5wVmkz2QX6c5UncdrtLYoc30eprDaz m6Hl+x2U2nlo2vN9zixJggQSlkzD6HxZKlQaFTVFMjABpKJrRofd2a5bd2wpFayivzHKmRnA ClypPQ0WhcI7qVQrAJsSSY6IB04UNZ/JcnJrSxN+TequV6lVYhEOYcYLm8iaGTjUMKUoL64Y 5ne8XJkDUMaUXCJWIUKjOIaqwe4S7m0chpHlweXLM/m8HaDf+qsvvLTzd5cWl6iaBc8HlpJ0 hYAGOFaFF5kPxLMpPJIQCbX4JIwQJjRShBsFNYmy6nyjGQYXQmZ2E5vUpoioUYNDivmrkGwK pQtwUnLypKnuVZTYpDRYUYrEmtZgRc0K8SIi0tjC+9hfdJR4DwLP80zThFvw5thvvlH9H4dG 0bbs1+5e96nHt+d/74NO9xI9SkkVX8ZOLMHcLS9aNE8ZOf2WtZuStZhpI8ErT++RugXLDX6x eEtSq5FQVG237r2hb5cK+nZeYLMjIyNzc3MbNmwYHR0FrDb/Mu7bt++63/iX7xtZdZEjsrhc 5ujI/Be7hTG6YHSkpS0WrvSoXUMW4ZDmtaKuksJurV1DVZaV5qkApaOyitCo/XFS3S1NZSbv qdwTI46kx+nWvcE0XddhLCfpHBPCgDIc1w3b7w6aQC/MyigaYmsRimpO3XG9DmeXs7KGqUeC 3ctsdSWXiqXWgqgtwQUOsitXVGTFD/2EAgInWq7XKlWmspowUVJEH/iqlC8UsnlWZYAIy3TJ WIIrMjU3Q8M/wgg0jUclWbYMvafUbeoGgUNiXJxkdzO1KmALjRUNJbGrJDVWzBcLedgdDnym OClhRZbgFsDuaq6riFY8IHTqzJkTJ06YiHzt33zhqd+bJNlNY1OnfbdCQwohEQwj5iITMSle VtkCH3gdC/ueBjJkhkEkyiCJDWGkRDYdxcyMhA5Cf0soYY1IzG6Ps0akFLMkRRCJt8Z5Hkqq odTYMvsSpRuSBEpJKWoIX1NJMUJQ40/N7BPURBxBaSrJFTOx4c+w52ycHMv8/m3kzrWPfGVv XpFQVtP5Izo9NXFq+BRfvzw7febs2cbMIfBcx56CZWYuPeEJUzQvu15PPjv1Go8mlsuVMGTx PBKOjY3Mlmfrrj1+fhx2V63WQ8pSqsYsqMCbmy2LGENA3xSWkhRcb/p7bq4ccfNL8TwDDnBd B3DA6MgYH44BhdSrVfjoOHVYxfddVgUjOzA/8FwbphZYDkPium6lUkvewVq1HDBPTfjsONAr +C2hxHYLHN7AwAC8m9DqChEPw8PDwzwiwkXZFkfTxeXydiItgONiQiOkedaEOkZH+JTaby64 ZcFxxp3sEKvgwiHNGQTOsegYUyFULzkMEv0JFDvQI5UGVTq9Qa4P7YJWuxmMucRhuyWMAsfx YJBMN6TZEKrneEH3OxcxOS4SJ1UoE8QSikYLXsyA2s1UQyowLTFGTsg9WjRdy9JqSRI2W/jG H6gmgV116pyyijiIpLW/xLIyKlUqCyPS6prMNe8rdh2wHB8dKWZlddmaKud0C3BcEAWt+2I5 j5rnVOs1ym6RGj418H02k9FVJYwa8Be6tVKh1Lu010PB9rfe/NK3Pxa653oLvYqei3AokcYI nBBBMcMXIk3DPGvitAamih0R439gIe+BUj4yIjoSsKRLOjQSoaa4RVLKi1LRjoZmiYiIpEMj ae8bJKIjUWP95tBIa/xjgdBIa3TkfQ6NtImIvPnFv960aRM1ha7VLMuSsQIn+fj3e3KFck8u LHtoW/dffejqh73I0xRt+OTx3S/vmarXtt50gwm4YWJieqbS15sdG53V89lN69YoulWuzB5+ ++16qNywZWPNDk6fPdOdVaYqXi5rdGdzkaLD8A94wnYqslXqK1iv7X113XVbArt63XXXOvX6 8Jkzej43sKQno+k/enlnd1adKvsr+7vGp2tZC42entywecOxI8fvvv+en27/kZbvChHZuH59 rVwZmZrpMtGJs9P33nPHa6+/DaPsxOjp0sDQNWuWP/38S3fdue2Z7/79quu3rl22VDWs11/d o2eLBYucPDm5+YYtvu0FyB89egKVCpXz5z9y34OV6szxN18br6H1a/rPnx5F+VJWIVdv2HDg 4GHs12c95YEH7+sr5d1mu+8OE7+9e/fedNNNExMTS5cund+77t+/f8tjvHxXfs8iIii++0GI YcYAN1tnk7ZFZdXF5T3FIhejGoLmVeoiMRvu7H7HJUBaTOwkxg5BHUEM95dJ7z2u4+j4OkRh 6Aa+FJvHxtgH/uucqQnZ2OtHkSLFVaWEF9+qitbRU5eb8RI+zIsvZWY3I3VwDI5CmCn5gH4S hzzmM6xI1Iy3Q6sgjNgwz9kSlCiCaPRY0hXVoC42ftScpuHi8QAa6rZT9xxaWcOCyyGLZsOV zJoZ6P2iMEx73HCFNCbl7pfrdRr6jvEoG/HhqmhazqTudy0ufRToMMxkwxji2HBgSbExlYOT ZOj0KXEkCIggQWdMs6+7X8/p09WJP3vxqb9//rfVyO5bMoAVHXP8wC8jizlEQq89VabCOR+c L4ojocHOVWJTZnXNgmZi7IetBLHwLo7Lg5OsDYMpPEsUxuZ5DSW0lMpI2jmvyXQ32VEkVuOV 7RFplj8R9JOoEf9v/BUJuZEEi6D3mjWSAJGoCYi88oW/uOaaaxIgQl2HdBMF6MVj31Xw3NLc 7euWbghopjSkOTaGlx3bVg1TpvK/cqVSMwwFML9hmgC+AJlksxahdizwzGsIK27gzoyPZnNd 8EDmcrm648iUlw03IKzMVbP5XOR5kqoHvmtamXqdSqLV6nV4jGGyXrFtU1P8UJo6f3qq7G65 biMgGM3QfNfLFQoRtbB2dDOjKZLj+VTJJKB+eaauz1UqMNunjzu8s7JUrduFQr5eq8Opw+Ed PXLEsKzu7iUygvfO6+oqHDl2orur6MPucjk4OyuToe4HtLTNg7GaKhpGRGOqglXbAbRQqbnd 3V344gguMNwfPnwY2g4NDY2MjPT398/vWg8cOHDT4w/TvEwLEJEua2qGF6/5IX7nnXdMEy6U rnTsQBeXxeXdYZH5edOLhCPRQtlWCaEOqAKldbWaUiGdgjFczd0LwyYQw/mt7aVRWZAhCphw CE7NL3kTpb36WcSYtqHvN6WcGZ9RauN+J6BP5FP3lZBLb8XlQqyGtpOmKpwalRsB7BAoLGAT scFKZkRRTVHb7Y42Caj3L625ZfruXOtdBcxEVUzkMKWmKqz1ME/tO77nhL5KEQyFNYgVE+nU bI8KwAOuaGWNsISa47rQEG6hzEp/4U7CJuEYNepRrNIo1LwniqrO0+po1/VddnaYiTvRs4Nu WqdF0fGRw28432Iu19vfDxt6Z+Tgt57+2q593+kycVdpOWE8VZbDiB8ampKXha57xAVI4jwH 87cTaY9YF0TwOcRY3iJoRkREJIrZra3iqgBBZMIATRLtEDGMKAVoiKj28QnCadPdebgkidWR BvVV4IwkGIMWUD9LQiMNsPI+ARGORYKf/s63Nm7cCPerWq0yyTJ6XLpqSIJF4Xsef/bgUayU y3NzZd3KwHulW6ZXrwLwhin+wQMHMsXuUsYolEpzc3M0hUElx+BdiFQFaUY28Jxcvjg+Pkaf 1kjJGZJqZEr53PjEmKpncjlz4vyUQrMEqFz1+roLs3Nl0zJ8xyWqVshmYGu+CwfodfeWyjMz RNZLOfOdQ0d7B3orM1OFrqUZS5k4PwMvDGBieLqWlAoTU9OGJp+fnFsxuHxqdFQ1LVXBmpUN AY94frFQqNfrsNnQqzietGrVikRbDDVYdDzaGHctXNAYxm3+SASdU9LzekUu4TM5ObkgEDl4 8ODtTzxCUQhgEZUDEelyAxHxAASRAr0Gf58XvWYWl/czTXNBEitZqBm+UMtYUPXS4QgXMQyb 6W8sJIDVDqiCTcP9lABiHOSgYQBMC0bbNAxZbABGXySCHByXxNYwEm4f+AmoGlkUCtUNOkgq DMJ0sN+MmJZ8zbeZuR6XaKTDPLSisZg2l4UGGBByHDcQu+NCqIB8AFEYME9NJZ7TtwC6Rjkk Na8WBYSnTqCPVCiPGOAIwAMqGcmvQJqhB+spBNu+X2edkoyZfx6qqZKsaqpBDfUkHvdKp6jo 8cA8F8uAmcIo4G739GLWMVOUVwEAMSURAn3d7Ozseeh5u3tWFwYf/4UvvrTmjqd3/sWRU6/0 d2Uts4vRQ4QrkRTxyAROuBgceUiYUQwk7gRDmOkuL4qJZdRbeKM8+cLkWeMkWUSBa8N3l526 xHh7hFX0Eu7ki1IC7SROBSERL5GpTi09iigtXpYU+0Yiihii2CM2rjfmWxOCLew8UMDrduJA iCRqfiMmkY+EItt7AkeS4Dzc5yDkY5Jt2zUqMBPCwEyjlex2u4p75uzwvrff3nLDB5YtXQro k9Csn/XWW68ePnyya8nS8uxU10B/UcX7Dx298aYPzE5OobnK9MjpjZs2nzx62LUdFylSWA8l Y92qvmo9mJ2d2bBp86lTJ9asHhyfqp2pj547737wts07fvKSnOktdRkTo+OrhwaPHj5e7F3m rep9/fUDWCEF05qq+8uX9xmS9s47+8ziwNDKpW+98crgumuvWdu/a+fOfHfJLZcV+J+BzoxN rVyxfHpictU1m+bGR17cvWfzVauOnJmRsPfs09uv3nTN8OFD62+61bCnXz90ev3GdZOjY10D y5EzMzwy/dCDD2qKnLa5TiZNibknFu6OSR93qZcfOht+ted3qNSGht4aCe4IfRc4e4g/xOTy MYmEwdD/FWAA00+gX022QKoAAAAASUVORK5CYII= --------------050304050903020008070903-- --------------070202070009010008090902-- From nobody Tue Jan 13 07:40:47 2015 Return-Path: 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 212231A8FD2 for ; Tue, 13 Jan 2015 07:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 AhAuvEstwXE9 for ; Tue, 13 Jan 2015 07:40:29 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991AE1A8BB6 for ; Tue, 13 Jan 2015 07:40:27 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKVLU8awFXPklyar3ilFA5f3qgB/OAdAv9@postini.com; Tue, 13 Jan 2015 07:40:28 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0DFeQL6009507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Jan 2015 10:40:26 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 13 Jan 2015 10:40:25 -0500 From: "Gould, James" To: Michael Holloway Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgIAAF1sAgAAI+AA= Date: Tue, 13 Jan 2015 15:40:25 +0000 Message-ID: <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> In-Reply-To: <54B534E2.8050001@comlaude.com> 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_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 13 Jan 2015 15:40:37 -0000 --_004_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_ Content-Type: multipart/alternative; boundary="_000_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_" --_000_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, I provide feedback inline below. =97 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 On Jan 13, 2015, at 10:08 AM, Michael Holloway > wrote: Hi Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrations.= The post claims lookup seems to be aimed at determining, for information p= urposes only (without "acking" in the create), whether or not there is a tr= ademark registered against the term (i.e. label only) therefore there is no= reason to check claims via TLD. This is a little OT anyway (my fault sorry= ), but hopefully you see where I am coming from. The use case for the claims check post the claims phase is used to address = the release of domain names that did not go through 90 days of claims, whic= h I believe is a modified version of your #2 below. Let=92s take the three basic phases defined in draft-ietf-eppext-launchphas= e as an example with sunrise, claims, and open. We can pretty much remove = the sunrise phase from the example for now, so let=92s focus on the claims = and open phases. Assuming that claims.tld is available through sunrise and= the claims phase, so if a claims check is done with =93open=94 as the phas= e, the response would be exists=3D=930=94, since there is no requirement to= provide the claims notice on create. If reserved.tld was released during = the =93open=94 phase, then a claims check on reserved.tld, with =93open=94 = as the phase, the response would be exists=3D=931=94, since a claims notice= is required on create. Based on Trung=92s use case, a client may want to = know whether or not there is a trademark on the domain name independent of = when the domain name is released, so the client can send a claims check wit= h the phase as =93claims=94 to get that answer. Back to LaunchPhase: my concern with simply using the "claims" phase is tha= t it can cause ambiguity, take the following four phase statuses, and compa= re with the logic below (to which I commented in underlined red) 1) A registry must operate a 90 days claims phase 2) A registry must operate 90 days extended claims period on domains that a= re released at a later date (collisions etc, and I don't know what may be c= oming up in the future) 3) A registry may operate a continued claims phase past the 90 domains for = all domains. [create with claims form] 4) [new]: A registry may operate a post claims (matching trademark past the= claims phase use case) [create without claims] If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create f= orm would be incorrect at this point despite receiving claims=3Dtrue. This = is why I suggest a different sub_phase should be used, OR a different flag = added (more complex of course) to differentiate. Based on the updated text, the client will only receive a claims check resp= onse with exists=3D=931=94 if =93create with claims form=94 is required. T= he updated text does not support #4, since the only time that =93exists=3D0= =94 is if a claims notice is required. This way a client can continue to u= se the claims check without any extra logic of passing special attributes o= r sub-phases to get the answer that is needed, which is whether a claims no= tice is required on create. Trung use case is an exception to the rule, wh= ere a client wants to know whether there is a matching trademark for the do= main name independent of whether a claims notice is required on create, so = passing =93claims=94 as the phase past the =93claims=94 phase may support t= hat. Let me know whether or not this helps. I hope this makes sense; and apologies if I am missing something fundamenta= l! Cheers, Michael 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue ## The claims exists but it is NOT require= d on domain_create * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return ## How does the client know= if 90 days has passed (extended / post claims) or not without external sou= rce? * claims notice is required * else * claims notice is NOT required Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 02:44 PM, Gould, James wrote: Michael, The split out of the responsibility of the registries and the CNIS / TMDB w= as worked out a couple of years ago, where there was a desire to not make t= he CNIS the critical path for the majority of the registrations. The agree= ment was for the registries to provide the claims check service and enforce= the claims notice on create based on a feed of trademark labels from the T= MDB to the registries. The proposal is to support the claims service post the =93claims=94 phase b= y passing the active phase to the server and the server will return whether= or not the claims notice is required based on a combination of a matching = trademark and whether the domain name already went through 90 days of the c= laims service. From a client perspective it means utilizing the claims che= ck in a similar fashion during and post the claims phase. The use case bro= ught up by Trung was more of an exception to the rule, in the client wantin= g to know whether there is a matching trademark for a domain name independe= nt of the requirement for passing the claims notice. In that case, the pro= posal is to pass =93claims=94 as the phase independent of the active phase = to get a true or false answer to whether a trademark matches the domain nam= e. Do the proposals work for you? Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 3:18 AM, Michael Holloway > wrote: Hi all Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= . The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not t= o submit claims data in a domain_create if the domain has a claim. As it is= , various registries are extending the claims periods past 90 days, so its = contradictory to have extended claims and post claims defined the same way = in the query but without a defined (or facilitated) way to differentiate th= e requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 JG [X] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Michael,

I provide feedback inline below.  

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:<= /div>
Hi

Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrati= ons. The post claims lookup seems to be aimed at determining, for informati= on purposes only (without "acking" in the create), whether or not there is a trademark registered against the te= rm (i.e. label only) therefore there is no reason to check claims via TLD. = This is a little OT anyway (my fault sorry), but hopefully you see where I = am coming from.

The use case for the claims check post the claims phase is used to add= ress the release of domain names that did not go through 90 days of claims,= which I believe is a modified version of your #2 below.  

Let=92s take the three basic phases defined in draft-ietf-eppext-= launchphase as an example with sunrise, claims, and open.  We can pret= ty much remove the sunrise phase from the example for now, so let=92s focus= on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a clai= ms check is done with =93open=94 as the phase, the response would be exists= =3D=930=94, since there is no requirement to provide the claims notice on c= reate.  If reserved.tld was released during the =93open=94 phase, then a claims check on reserved.tld, with =93open=94= as the phase, the response would be exists=3D=931=94, since a claims notic= e is required on create.  Based on Trung=92s use case, a client may wa= nt to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client= can send a claims check with the phase as =93claims=94 to get that answer.=    



Back to LaunchPhase: my concern with simply using the "claims" ph= ase is that it can cause ambiguity, take the following four phase statuses,= and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains= that are released at a later date (collisions etc, and I don't know what m= ay be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domai= ns for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create w<= /span>ithout claims]

If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this poi= nt despite receiving claims=3Dtrue. This is why I suggest a different sub_p= hase should be used, OR a different flag added (more complex of course) to = differentiate.


Based on the updated text, the client will only receive a claims check= response with exists=3D=931=94 if =93create with claims form=94 is require= d.  The updated text does not support #4, since the only time that =93= exists=3D0=94 is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic = of passing special attributes or sub-phases to get the answer that is neede= d, which is whether a claims notice is required on create.  Trung use = case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domai= n name independent of whether a claims notice is required on create, so pas= sing =93claims=94 as the phase past the =93claims=94 phase may support that= .  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I = am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue ## The claims exists but it is NOT required on domain_cre= ate
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return ## How does the client know if 90 days has passed (= extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / T= MDB was worked out a couple of years ago, where there was a desire to not m= ake the CNIS the critical path for the majority of the registrations.  = ;The agreement was for the registries to provide the claims check service and enforce the claims notice on creat= e based on a feed of trademark labels from the TMDB to the registries. &nbs= p;

The proposal is to support the claims service post the =93claims=94 ph= ase by passing the active phase to the server and the server will return wh= ether or not the claims notice is required based on a combination of a matc= hing trademark and whether the domain name already went through 90 days of the claims service.  From a clie= nt perspective it means utilizing the claims check in a similar fashion dur= ing and post the claims phase.  The use case brought up by Trung was m= ore of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name in= dependent of the requirement for passing the claims notice.  In that c= ase, the proposal is to pass =93claims=94 as the phase independent of the a= ctive phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<Mail Attachment.png>=

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= .

The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a cla= im. As it is, various registries are extending the claims periods past 90 d= ays, so its contradictory to have extended claims and post claims defined t= he same way in the query but without a defined (or facilitated) way to differentiate the requirement for a doma= in_create.

I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB.=

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign= .com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>= ;
Cc: Francisco Obispo <fobispo@uniregist= ry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

= =97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com=

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:
Fr= om Francisco:
&n= bsp;
Th= anks Jim for bringing this to the eppext.  This will definitely help t= he post claims phase.
&n= bsp;
Wi= th the wording changes, is there still a way to determine if there=92s a tr= ademark against the name regardless on whether or not the claims ack is nee= ded in the create domain?  
 
This could = be accomplished by leaving the =93claims=94 implementation as it is current= ly and introducing a sub-phase for claims named =93extended=94.  When the su= p-phase of =93extended=94 is passed the results from Jim=92s earlier email = would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would = still allow a registrar to determine if a claim currently exists on a domai= n when a claim period does not exist for the TLD (the current implementation).&nb= sp; From a registrar perspective, I=92m not sure if determining if a domain= has a claim when all claims periods have expired is needed.  This imp= lementation also would require additional work by all registrars to support if adopted, while the implementation from Jim= =92s first post would require only updates by the registries which would be= better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) P= lease contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any a= ttachments hereto is intended for use only by the addressee(s) named herein and may contain = confidential information. If you have received this email in error, please = immediately notify the sender and permanently delete the original and any c= opy of this message and its attachments.
 
From: Gould, James [ma= ilto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; ep= pext@ietf.org; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97=
 

JG=


<image001.png>

James Gould
Distinguished Enginee= r
jgould@Verisign.co= m

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fo= bispo@uniregistry.com> wrote:


&l= t;launch:phase>  SHOULD contain the value of "claims" to = indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.c= om> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Fra= ncisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.<= /span>
Newport Beac= h, CA, 92660<= /span>
off= . +1.345.749.6284
fax= . +1.345.746.6263



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinf=
o/eppext
_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinfo/eppext



--_000_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_-- --_004_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 13 Jan 2015 15:40:24 GMT"; modification-date="Tue, 13 Jan 2015 15:40:24 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_80B85CA7F0E5441892E3BACFE1BEDBAAverisigncom_-- From nobody Fri Jan 16 13:39:00 2015 Return-Path: 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 78AC91B2C60 for ; Fri, 16 Jan 2015 13:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.923 X-Spam-Level: * X-Spam-Status: No, score=1.923 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 J0CzAwsAefoa for ; Fri, 16 Jan 2015 13:38:55 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705E11B2C5B for ; Fri, 16 Jan 2015 13:38:54 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so20611119lbi.2 for ; Fri, 16 Jan 2015 13:38:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=3DvvaTTRbYONKZ33mmmDwBHBUE8xQu+XRK+Dq8ghvDo=; b=HvK+l55NbXFy42ZOTbOwenQY56CEalen5E9cukoR9eujdUlmodN2a9r7W/LDtubD7g 8Z5agBMJE4WXupd7/0r8RqiavqffGPiLxPw1qHZwTlA6vhpmJ6incF4m9xlIdfbQR0Pf Pw0YKlIhei8bQoJE0iIYgXmVOESfGENzoxoQQ53pHQsn4LgvsYYhx01lESgy1pxZp3Q9 YK293oiyI35eSqNrREeRoYhpnOOgMLN9sTfEj2+QukJuxaNSzrGnZmiy4zLc/1pdDw/d suHN7HCfC4DZKNktuIB89ZSlZsIW9pTUt8mJDXdQVHFjekaPOPYQZzWNuBdEmOBSOaFk 6CeA== X-Gm-Message-State: ALoCoQm91MuyJ3cNP2K6WdbkE5Dee5KS4HOgmkys8lHIhpkuIOsJOjJoiNpDmDqooiu8XN3zeH1Q X-Received: by 10.152.2.38 with SMTP id 6mr17918914lar.60.1421444332756; Fri, 16 Jan 2015 13:38:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.79 with HTTP; Fri, 16 Jan 2015 13:38:22 -0800 (PST) In-Reply-To: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> From: Jothan Frakes Date: Fri, 16 Jan 2015 13:38:22 -0800 Message-ID: To: "Gould, James" Content-Type: multipart/related; boundary=089e013c6b92863808050ccbcc2e Archived-At: Cc: Jody Kolker , Francisco Obispo , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Fri, 16 Jan 2015 21:38:58 -0000 --089e013c6b92863808050ccbcc2e Content-Type: multipart/alternative; boundary=089e013c6b92863804050ccbcc2d --089e013c6b92863804050ccbcc2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a heads-up - I am testing out some Universal Acceptance stuff for a document with the Domain Name Association, and I have found that some of your registries (hosted or directly) are not correctly inhibiting dashes in the third and fourth positions in check commands. Should that be on the Registrar to enforce or the Registry? IMHO both but think the latter is the right place. Jothan Frakes Tel: +1.206-355-0230 On Fri, Jan 9, 2015 at 8:27 AM, Gould, James wrote: > Jody, > > I believe that passing the active phase is more straight forward as > opposed to defining a special sub-phase like =E2=80=9Cextended" to drive = the > behavior. Having the claims check return =E2=80=9Cexists=3Dtrue=E2=80=9D= only when a claims > notice is required on the create based on the active phase should be able > to handle the use case of releasing domains post the claims phase and als= o > applies to the claims phase. All names that have matching trademarks > during the claims phase will require a claims notice on create, so the > behavior is consistent. > > I=E2=80=99m still not sure why a client would want to know whether there= is a > matching trademark when a claims notice is not required on the create. > Does anyone see a need for this? Since the =E2=80=9Cclaims=E2=80=9D phas= e would always > return =E2=80=9Cexists=3Dtrue=E2=80=9D for domains that have matching tra= demarks, a client > could pass the =E2=80=9Cclaims=E2=80=9D phase when the active phase is no= t the =E2=80=9Cclaims=E2=80=9D > phase to obtain this information. Of course servers would need to suppor= t > referencing a past =E2=80=9Cclaims=E2=80=9D phase to support this use cas= e. The change in > the text should support the logic that I previously posted before, which = I > extend to support addressing the optional matching trademark past the > claims phase use case. Is this use case really needed? > > > 1. During claims phase with a claims check command > 1. If domain has matching trademark > 1. return exists=3Dtrue > 2. else > 1. return exists=3Dfalse > 2. During post claims phase with a claims check command > 1. If domain was released post claims phase start and is within 90 > days of release and has matching trademark > 1. return exists=3Dtrue > 2. else > 1. return exists=3Dfalse > 3. *During post claims phase with a claims phase check and passing > =E2=80=9Cclaims=E2=80=9D as the phase (optional matching trademark pas= t the claims phase > use case)* > 1. *If domains has matching trademark * > 1. *return exists=3Dtrue* > 2. *else* > 1. *return exists=3Dfalse* > > > > 1. During claims phase with a create command > 1. If domain has matching trademark > 1. claims notice is required > 2. else > 1. claims notice is NOT required > 2. During post claims phase with a create command > 1. If domain was released post claims phase start and is within 90 > days of release and has matching trademark return > 1. claims notice is required > 2. else > 1. claims notice is NOT required > > > Thoughts? > > =E2=80=94 > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 8, 2015, at 4:50 PM, Jody Kolker wrote: > > From Francisco: > > Thanks Jim for bringing this to the eppext. This will definitely help > the post claims phase. > > With the wording changes, is there still a way to determine if there=E2= =80=99s a > trademark against the name regardless on whether or not the claims ack is > needed in the create domain? > > This could be accomplished by leaving the =E2=80=9Cclaims=E2=80=9D imple= mentation as it > is currently and introducing a sub-phase for claims named =E2=80=9Cextend= ed=E2=80=9D. When > the sup-phase of =E2=80=9Cextended=E2=80=9D is passed the results from Ji= m=E2=80=99s earlier email > would be below. > > > 1. During claims phase with a claims check command or post claims > phase without a sub-phase of =E2=80=9Cextended=E2=80=9D > 1. If domain has matching trademark > 1. return exists=3Dtrue > 2. else > 1. return exists=3Dfalse > 2. During post claims phase with a claims check command with a > sub-phase of =E2=80=9Cextended=E2=80=9D > 1. If domain was released post claims phase start and is within 90 > days of release and has matching trademark > 1. return exists=3Dtrue > 2. else > 1. return exists=3Dfalse > > > > 1. During claims phase with a create command or post claims phase > without a sub-phase of =E2=80=9Cextended=E2=80=9D > 1. If domain has matching trademark > 1. claims notice is required > 2. else > 1. claims notice is NOT required > 2. During post claims phase with a create command with a sub-phase > of =E2=80=9Cextended=E2=80=9D > 1. If domain was released post claims phase start and is within 90 > days of release and has matching trademark return > 1. claims notice is required > 2. else > 1. claims notice is NOT required > > This would still allow a registrar to determine if a claim currently > exists on a domain when a claim period does not exist for the TLD (the > current implementation). From a registrar perspective, I=E2=80=99m not s= ure if > determining if a domain has a claim when all claims periods have expired = is > needed. This implementation also would require additional work by all > registrars to support if adopted, while the implementation from Jim=E2=80= =99s first > post would require only updates by the registries which would be better f= or > widespread adoption. > > Thoughts? > > Thanks, > Jody Kolker > 319-294-3933 (office) > 319-329-9805 (mobile) Please contact my direct supervisor Charles > Beadnall (cbeadnall@godaddy.com) with any feedback. > > This email message and any attachments hereto is intended for use only > by the addressee(s) named herein and may contain confidential information= . > If you have received this email in error, please immediately notify the > sender and permanently delete the original and any copy of this message a= nd > its attachments. > > *From:* Gould, James [mailto:JGould@verisign.com ] > *Sent:* Thursday, January 08, 2015 12:24 PM > *To:* Francisco Obispo > *Cc:* Jody Kolker; eppext@ietf.org; Tran, Trung > *Subject:* Re: [eppext] draft-ietf-eppext-launchphase Support for a > "Claims Service" post the Claims Phase > > Francisco, > > I would have gone with the sub-phase approach as well, since if the > behavior between the two claims phases are consistent (e.g. requirement f= or > claims check and claims notice) I=E2=80=99m not sure the value in definin= g a new > top-level phase name. Is there a material behavior change between the tw= o > phases and is the concept of an extended claims phase a generic use case? > We have stuck with the standard set of =E2=80=9Csunrise=E2=80=9D, =E2=80= =9Cclaims=E2=80=9D, and =E2=80=9Copen=E2=80=9D > phases. Have others utilized the use of sub-phases or have created custo= m > top-level phase names to meet their needs? If so, can you share your > scheme? It would be good to know if there are any common patterns. > > Thanks, > > =E2=80=94 > > > JG > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: > > > SHOULD contain the value of "claims" to indicate the > claims launch phase. A value other than "claims" MAY be used to > pass the claims notice for domain names outside of the claims phase. > > > > Once a TLD has ended the mandatory 90 day period of =E2=80=9Cclaims=E2= =80=9D a registry > might decide to call it something else. > > We are not supporting extended claims, but we had to support an > extended sunrise for the names on the ICANN names-collision block list (3= 0 > day period instead of a 60 day end-date sunrise), and we initially though= t > about having a phase called =E2=80=9Csunrise=E2=80=9D with a sub-phase ca= lled =E2=80=9Cextended=E2=80=9D > but we thought it would be too complicated for RARs to change their code, > so we decided just to trigger it by calling the phase =E2=80=9Csunsrise= =E2=80=9D, but in > reality, a registry can call it anything they want in order to support it= , > because they are different things. > > Since there is no guidance on what the phases should be called, it > seems like we=E2=80=99re going to end up with discrete phase names for an= ything > that is not: claims or sunrise. > > > > On Jan 8, 2015, at 11:35 AM, Gould, James wrote: > > What do you mean by the extended claims phase? Is there a past mail list > thread on this or is this a new issue? Please clarify. > > > *Francisco Obispo* > CTO - Registry Operations > > > > > 2161 San Joaquin Hills Rd. > Newport Beach, CA, 92660 > off. +1.345.749.6284 > fax. +1.345.746.6263 > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > --089e013c6b92863804050ccbcc2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just a heads-up - I am testing out some Universal Acceptan= ce stuff for a document with the Domain Name Association, and I have found = that some of your registries (hosted or directly) are not correctly inhibit= ing dashes in the third and fourth positions in check commands.

Should that be on the Registrar to enforce or the Registry?=C2=A0 I= MHO both but think the latter is the right place.


Jothan Frakes
Tel: +1.206-355-0230


On Fri, Jan 9, 2015 at 8:27 AM, Gould, James= <JGould@verisign.com> wrote:
Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =E2=80=9Cextended" to drive= the behavior.=C2=A0 Having the claims check return =E2=80=9Cexists=3Dtrue= =E2=80=9D only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.=C2=A0 All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent. =C2=A0

I=E2=80=99m still not sure why a client would want to know whether the= re is a matching trademark when a claims notice is not required on the crea= te.=C2=A0 Does anyone see a need for this?=C2=A0 Since the =E2=80=9Cclaims= =E2=80=9D phase would always return =E2=80=9Cexists=3Dtrue=E2=80=9D for dom= ains that have matching trademarks, a client could pass the =E2=80=9Cclaims=E2=80=9D= phase when the active phase is not the =E2=80=9Cclaims=E2=80=9D phase to o= btain this information.=C2=A0 Of course servers would need to support refer= encing a past =E2=80=9Cclaims=E2=80=9D phase to support this use case.=C2= =A0 The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.=C2=A0 Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark=C2=A0
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse
  2. During post claims phase with a claims che= ck command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse=C2=A0
  3. During post claims phase with a claims phase check and p= assing =E2=80=9Cclaims=E2=80=9D as the phase (optional matching trademark p= ast the claims phase use case)
    1. If domains has matching trademark=C2=A0
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command=C2=A0
    1. If domain has matching trademark=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required
  2. During post claims phase with a=C2=A0creat= e command=C2=A0
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required=C2=A0

Thoughts?

<= span style=3D"font-size:15px">=E2=80=94


JG




James Gould
Distinguished Engineer
jgould@Verisign.co= m

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Franci= sco:
=C2=A0
Thanks Jim = for bringing this to the eppext.=C2=A0 This will definitely help the post c= laims phase.
=C2=A0
With the wo= rding changes, is there still a way to determine if there=E2=80=99s a trade= mark against the name regardless on whether or not the claims ack is needed= in the create domain? =C2=A0
=C2=A0
This could be accomplished by leaving the =E2=80=9Cclaims=E2=80=9D = implementation as it is currently and introducing a sub-phase for claims na= med =E2=80=9Cextended=E2=80=9D.=C2=A0 When the sup-phase of =E2=80=9Cextend= ed=E2=80=9D is passed the results from Jim=E2=80=99s earlier email would be below.<= /u>
=C2=A0
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =E2=80=9Cextended=E2=80=9D
    1. If domain has matching trademark=C2=A0
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =E2=80=9Cextended=E2=80=9D
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse=C2=A0
=C2=A0
  1. During claims phase with a create command=C2=A0or post claims phase without= a sub-phase of =E2=80=9Cextended=E2=80=9D
    1. If domain has matching trademark=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required
  2. During post claims phase with a=C2=A0create command=C2=A0with a sub-phase o= f =E2=80=9Cextended=E2=80=9D
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required=C2=A0
This would still allow a registrar to determine if a claim currentl= y exists on a domain when a claim period does not exist for the TLD (the cu= rrent implementation).=C2=A0 From a registrar perspective, I=E2=80=99m not sure if determining if a domain h= as a claim when all claims periods have expired is needed.=C2=A0 This imple= mentation also would require additional work by all registrars to support i= f adopted, while the implementation from Jim=E2=80=99s first post would require only updates by the registries which would be bet= ter for widespread adoption.
=C2=A0
Thoughts?
=C2=A0
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile)=C2=A0Please contact my direct supervisor Charl= es Beadnall (cbeadnall@godad= dy.com) with any feedback.
=C2=A0
This email message and any attachments hereto is intended for use o= nly by the addressee(s) named herein and may contain confidential informati= on. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.
=C2=A0
From:= =C2=A0Gould, James [mailto:JGould@ver= isign.com]=C2=A0
Sent:=C2=A0Thursday, January 08, 2015 12:24 PM
To:=C2=A0Francisco Obispo
Cc:=C2=A0Jody Kolker;=C2=A0eppext@ietf.org; Tran, Trung
Subject:=C2=A0Re: [eppext] draft-ietf-eppext-launchphas= e Support for a "Claims Service" post the Claims Phase<= /u>
=C2=A0
Francisco,
=C2=A0
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=E2=80=99m not sure the value in defining a new = top-level phase name.=C2=A0 Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?=C2=A0 We have stuck with the standard set o= f =E2=80=9Csunrise=E2=80=9D, =E2=80=9Cclaims=E2=80=9D, and =E2=80=9Copen=E2= =80=9D phases.=C2=A0 Have others utilized the use of sub-phases or have cre= ated custom top-level phase names to meet their needs?=C2=A0 If so, can you share your scheme?= =C2=A0 It would be good to know if there are any common patterns. =C2=A0=
=C2=A0
Thanks,
=C2=A0
=E2=80=94
=C2=A0<= /div>

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<= /a>

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com
=C2=A0
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase> =C2=A0SH= OULD contain the value of "claims" to indicate the
=C2=A0 =C2=A0 =C2=A0 =C2=A0claims launch phase.=C2=A0 A value other than &q= uot;claims" MAY be used to=C2=A0
pass the claims notice for domain names outside of the claims phase.=C2=A0= =C2=A0
=C2=A0
=C2=A0
Once a TLD has ended the mandatory 90 day period of =E2=80=9Cclaims=E2=80= =9D a registry might decide to call it something else.=C2=A0<= /div>
=C2=A0
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =E2=80=9Csunrise=E2=80=9D with a sub-phase called =E2=80=9Cextended=E2=80=9D but we thought it would be t= oo complicated for RARs to change their code, so we decided just to trigger= it by calling the phase =E2=80=9Csunsrise=E2=80=9D, but in reality, a regi= stry can call it anything they want in order to support it, because they are different things.
=C2=A0
Since there is no guidance on what the phases should be called, it seems li= ke we=E2=80=99re going to end up with discrete phase names for anything tha= t is not: claims or sunrise.
=C2=A0
=C2=A0

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?=C2=A0 Is there a past mail l= ist thread on this or is this a new issue?=C2=A0 Please clarify.<= /u>

=C2=A0
Francisco Obisp= o
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Be= ach, CA, 92660


_______________________________________________
EppExt mailing list
EppExt@ietf.org
= https://www.ietf.org/mailman/listinfo/eppext


--089e013c6b92863804050ccbcc2d-- --089e013c6b92863808050ccbcc2e Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Transfer-Encoding: base64 Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> X-Attachment-Id: c30a0da9e221e151_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --089e013c6b92863808050ccbcc2e-- From nobody Fri Jan 16 14:25:14 2015 Return-Path: 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 C59DD1A898E for ; Fri, 16 Jan 2015 14:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 aBRGPIbJKqcV for ; Fri, 16 Jan 2015 14:25:09 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15C81A6FD5 for ; Fri, 16 Jan 2015 14:25:08 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id u14so11232610lbd.12 for ; Fri, 16 Jan 2015 14:25:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PucpMJ/o+/aIGwsdnXdqLYxUh4QXhzHDdLAoVi3HxYk=; b=aNpGpfH+Q3iWCIfbsYvX9irkdVgMt4NrpfXwm072yI6WkLN2/l/2RwwfjIdkqjGONw D1qEe6y3/YKqmgsVGCqQkogUvPrb5ynKBRtJCpSbSlbx4QDCQaY31Kr9PJTUNBQuqkNS w9+hq9F/fLJ19YY57+thOdRfZE4KVgrkYkyGH9rS8Ltu5pKIS//mW0ADhPLkHTo17dBl r0lmEHbopd2uAeBpBBVpJBcIlOhQieZqUsvoDfpnj18RLD2jHTzmeN6BlaWAzwTq9rve Qk8n/E1YvRWPO6s4L09Tuo+6+w5Imaluymsu0s0OkirQ+b7Zb5gdp1RfxKLL5U8FnP6p mDpA== X-Gm-Message-State: ALoCoQkHvB+J3HdzqTMltItvXvjtBJivC1dGb+rPDC2IUTZHVZOc/M3juL7BlUAYG8L9dzNayo0Y X-Received: by 10.152.29.6 with SMTP id f6mr18222823lah.32.1421447107003; Fri, 16 Jan 2015 14:25:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.89.79 with HTTP; Fri, 16 Jan 2015 14:24:36 -0800 (PST) In-Reply-To: References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> From: Jothan Frakes Date: Fri, 16 Jan 2015 14:24:36 -0800 Message-ID: To: "Gould, James" Content-Type: multipart/related; boundary=089e0158c78ae1a722050ccc712b Archived-At: Cc: Jody Kolker , Francisco Obispo , "Tran, Trung" , "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Fri, 16 Jan 2015 22:25:13 -0000 --089e0158c78ae1a722050ccc712b Content-Type: multipart/alternative; boundary=089e0158c78ae1a720050ccc712a --089e0158c78ae1a720050ccc712a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I should have been more specific on this I tested a check command for the string 'jo--than' against a suite of registries and many returned that the name was available, which is incorrect as it should be blocked by policy. XN-- is the only exception to the restriction on dashes at third and fourth position. Verisign - you're good on this - Uniregistry and Afilias and Centralnic as well. Others - mileage varies. Jothan Frakes Tel: +1.206-355-0230 On Fri, Jan 16, 2015 at 1:38 PM, Jothan Frakes wrote: > Just a heads-up - I am testing out some Universal Acceptance stuff for a > document with the Domain Name Association, and I have found that some of > your registries (hosted or directly) are not correctly inhibiting dashes = in > the third and fourth positions in check commands. > > Should that be on the Registrar to enforce or the Registry? IMHO both bu= t > think the latter is the right place. > > > Jothan Frakes > Tel: +1.206-355-0230 > > > On Fri, Jan 9, 2015 at 8:27 AM, Gould, James wrote: > >> Jody, >> >> I believe that passing the active phase is more straight forward as >> opposed to defining a special sub-phase like =E2=80=9Cextended" to drive= the >> behavior. Having the claims check return =E2=80=9Cexists=3Dtrue=E2=80= =9D only when a claims >> notice is required on the create based on the active phase should be abl= e >> to handle the use case of releasing domains post the claims phase and al= so >> applies to the claims phase. All names that have matching trademarks >> during the claims phase will require a claims notice on create, so the >> behavior is consistent. >> >> I=E2=80=99m still not sure why a client would want to know whether ther= e is a >> matching trademark when a claims notice is not required on the create. >> Does anyone see a need for this? Since the =E2=80=9Cclaims=E2=80=9D pha= se would always >> return =E2=80=9Cexists=3Dtrue=E2=80=9D for domains that have matching tr= ademarks, a client >> could pass the =E2=80=9Cclaims=E2=80=9D phase when the active phase is n= ot the =E2=80=9Cclaims=E2=80=9D >> phase to obtain this information. Of course servers would need to suppo= rt >> referencing a past =E2=80=9Cclaims=E2=80=9D phase to support this use ca= se. The change in >> the text should support the logic that I previously posted before, which= I >> extend to support addressing the optional matching trademark past the >> claims phase use case. Is this use case really needed? >> >> >> 1. During claims phase with a claims check command >> 1. If domain has matching trademark >> 1. return exists=3Dtrue >> 2. else >> 1. return exists=3Dfalse >> 2. During post claims phase with a claims check command >> 1. If domain was released post claims phase start and is within 90 >> days of release and has matching trademark >> 1. return exists=3Dtrue >> 2. else >> 1. return exists=3Dfalse >> 3. *During post claims phase with a claims phase check and >> passing =E2=80=9Cclaims=E2=80=9D as the phase (optional matching trad= emark past the claims >> phase use case)* >> 1. *If domains has matching trademark * >> 1. *return exists=3Dtrue* >> 2. *else* >> 1. *return exists=3Dfalse* >> >> >> >> 1. During claims phase with a create command >> 1. If domain has matching trademark >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> 2. During post claims phase with a create command >> 1. If domain was released post claims phase start and is within 90 >> days of release and has matching trademark return >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> >> >> Thoughts? >> >> =E2=80=94 >> >> >> JG >> >> >> >> >> >> *James Gould *Distinguished Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com >> >> On Jan 8, 2015, at 4:50 PM, Jody Kolker wrote: >> >> From Francisco: >> >> Thanks Jim for bringing this to the eppext. This will definitely help >> the post claims phase. >> >> With the wording changes, is there still a way to determine if there=E2= =80=99s >> a trademark against the name regardless on whether or not the claims ack= is >> needed in the create domain? >> >> This could be accomplished by leaving the =E2=80=9Cclaims=E2=80=9D impl= ementation as it >> is currently and introducing a sub-phase for claims named =E2=80=9Cexten= ded=E2=80=9D. When >> the sup-phase of =E2=80=9Cextended=E2=80=9D is passed the results from J= im=E2=80=99s earlier email >> would be below. >> >> >> 1. During claims phase with a claims check command or post claims >> phase without a sub-phase of =E2=80=9Cextended=E2=80=9D >> 1. If domain has matching trademark >> 1. return exists=3Dtrue >> 2. else >> 1. return exists=3Dfalse >> 2. During post claims phase with a claims check command with a >> sub-phase of =E2=80=9Cextended=E2=80=9D >> 1. If domain was released post claims phase start and is within 90 >> days of release and has matching trademark >> 1. return exists=3Dtrue >> 2. else >> 1. return exists=3Dfalse >> >> >> >> 1. During claims phase with a create command or post claims phase >> without a sub-phase of =E2=80=9Cextended=E2=80=9D >> 1. If domain has matching trademark >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> 2. During post claims phase with a create command with a >> sub-phase of =E2=80=9Cextended=E2=80=9D >> 1. If domain was released post claims phase start and is within 90 >> days of release and has matching trademark return >> 1. claims notice is required >> 2. else >> 1. claims notice is NOT required >> >> This would still allow a registrar to determine if a claim currently >> exists on a domain when a claim period does not exist for the TLD (the >> current implementation). From a registrar perspective, I=E2=80=99m not = sure if >> determining if a domain has a claim when all claims periods have expired= is >> needed. This implementation also would require additional work by all >> registrars to support if adopted, while the implementation from Jim=E2= =80=99s first >> post would require only updates by the registries which would be better = for >> widespread adoption. >> >> Thoughts? >> >> Thanks, >> Jody Kolker >> 319-294-3933 (office) >> 319-329-9805 (mobile) Please contact my direct supervisor Charles >> Beadnall (cbeadnall@godaddy.com) with any feedback. >> >> This email message and any attachments hereto is intended for use only >> by the addressee(s) named herein and may contain confidential informatio= n. >> If you have received this email in error, please immediately notify the >> sender and permanently delete the original and any copy of this message = and >> its attachments. >> >> *From:* Gould, James [mailto:JGould@verisign.com = ] >> >> *Sent:* Thursday, January 08, 2015 12:24 PM >> *To:* Francisco Obispo >> *Cc:* Jody Kolker; eppext@ietf.org; Tran, Trung >> *Subject:* Re: [eppext] draft-ietf-eppext-launchphase Support for a >> "Claims Service" post the Claims Phase >> >> Francisco, >> >> I would have gone with the sub-phase approach as well, since if the >> behavior between the two claims phases are consistent (e.g. requirement = for >> claims check and claims notice) I=E2=80=99m not sure the value in defini= ng a new >> top-level phase name. Is there a material behavior change between the t= wo >> phases and is the concept of an extended claims phase a generic use case= ? >> We have stuck with the standard set of =E2=80=9Csunrise=E2=80=9D, =E2=80= =9Cclaims=E2=80=9D, and =E2=80=9Copen=E2=80=9D >> phases. Have others utilized the use of sub-phases or have created cust= om >> top-level phase names to meet their needs? If so, can you share your >> scheme? It would be good to know if there are any common patterns. >> >> Thanks, >> >> =E2=80=94 >> >> >> JG >> >> >> >> >> *James Gould *Distinguished Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com >> >> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >> wrote: >> >> >> SHOULD contain the value of "claims" to indicate the >> claims launch phase. A value other than "claims" MAY be used to >> pass the claims notice for domain names outside of the claims phase. >> >> >> >> Once a TLD has ended the mandatory 90 day period of =E2=80=9Cclaims=E2= =80=9D a >> registry might decide to call it something else. >> >> We are not supporting extended claims, but we had to support an >> extended sunrise for the names on the ICANN names-collision block list (= 30 >> day period instead of a 60 day end-date sunrise), and we initially thoug= ht >> about having a phase called =E2=80=9Csunrise=E2=80=9D with a sub-phase c= alled =E2=80=9Cextended=E2=80=9D >> but we thought it would be too complicated for RARs to change their code= , >> so we decided just to trigger it by calling the phase =E2=80=9Csunsrise= =E2=80=9D, but in >> reality, a registry can call it anything they want in order to support i= t, >> because they are different things. >> >> Since there is no guidance on what the phases should be called, it >> seems like we=E2=80=99re going to end up with discrete phase names for a= nything >> that is not: claims or sunrise. >> >> >> >> On Jan 8, 2015, at 11:35 AM, Gould, James wrote: >> >> What do you mean by the extended claims phase? Is there a past mail lis= t >> thread on this or is this a new issue? Please clarify. >> >> >> *Francisco Obispo* >> CTO - Registry Operations >> >> >> >> >> 2161 San Joaquin Hills Rd. >> Newport Beach, CA, 92660 >> off. +1.345.749.6284 >> fax. +1.345.746.6263 >> >> >> >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext >> >> > --089e0158c78ae1a720050ccc712a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I should have been more specific on this

I tested a check command for the string 'jo--than' against a suit= e of registries and many returned that the name was available, which is inc= orrect as it should be blocked by policy.=C2=A0 XN-- is the only exception = to the restriction on dashes at third and fourth position.

Verisign - you're good on this - Uniregistry and Afilias and C= entralnic as well.=C2=A0 Others - mileage varies.


Jothan Frakes
Tel: +1.206-355-0230


On Fri, Jan 16, 2015 at 1:38 PM, Jothan Frak= es <jothan@jothan.com> wrote:
Just a heads-up - I am testing out some Universal Acce= ptance stuff for a document with the Domain Name Association, and I have fo= und that some of your registries (hosted or directly) are not correctly inh= ibiting dashes in the third and fourth positions in check commands.
Should that be on the Registrar to enforce or the Registry?=C2= =A0 IMHO both but think the latter is the right place.


Jothan Frakes
Tel: +1.206-355-02= 30


On Fri,= Jan 9, 2015 at 8:27 AM, Gould, James <JGould@verisign.com> wrote:
Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =E2=80=9Cextended" to drive= the behavior.=C2=A0 Having the claims check return =E2=80=9Cexists=3Dtrue= =E2=80=9D only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.=C2=A0 All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent. =C2=A0

I=E2=80=99m still not sure why a client would want to know whether the= re is a matching trademark when a claims notice is not required on the crea= te.=C2=A0 Does anyone see a need for this?=C2=A0 Since the =E2=80=9Cclaims= =E2=80=9D phase would always return =E2=80=9Cexists=3Dtrue=E2=80=9D for dom= ains that have matching trademarks, a client could pass the =E2=80=9Cclaims=E2=80=9D= phase when the active phase is not the =E2=80=9Cclaims=E2=80=9D phase to o= btain this information.=C2=A0 Of course servers would need to support refer= encing a past =E2=80=9Cclaims=E2=80=9D phase to support this use case.=C2= =A0 The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.=C2=A0 Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark=C2=A0
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse=C2=A0
  3. During post claims phase with a claims phase check and p= assing =E2=80=9Cclaims=E2=80=9D as the phase (optional matching trademark p= ast the claims phase use case)
    1. If domains has matching trademark=C2=A0
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command=C2=A0
    1. If domain has matching trademark=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required
  2. During post claims phase with a=C2=A0create command= =C2=A0
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required=C2=A0

Thoughts?

<= span style=3D"font-size:15px">=E2=80=94


JG




James Gould
Distinguished Engineer
jgould@Verisign.co= m

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Franci= sco:
=C2=A0
Thanks Jim = for bringing this to the eppext.=C2=A0 This will definitely help the post c= laims phase.
=C2=A0
With the wo= rding changes, is there still a way to determine if there=E2=80=99s a trade= mark against the name regardless on whether or not the claims ack is needed= in the create domain? =C2=A0
=C2=A0
This could be accomplished by leaving the =E2=80=9Cclaims=E2=80=9D = implementation as it is currently and introducing a sub-phase for claims na= med =E2=80=9Cextended=E2=80=9D.=C2=A0 When the sup-phase of =E2=80=9Cextend= ed=E2=80=9D is passed the results from Jim=E2=80=99s earlier email would be below.<= /u>
=C2=A0
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =E2=80=9Cextended=E2=80=9D
    1. If domain has matching trademark=C2=A0
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =E2=80=9Cextended=E2=80=9D
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue=C2=A0
    2. else=C2=A0
      1. return exists=3Dfalse=C2=A0
=C2=A0
  1. During claims phase with a create command=C2=A0or post claims phase without= a sub-phase of =E2=80=9Cextended=E2=80=9D
    1. If domain has matching trademark=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required
  2. During post claims phase with a=C2=A0create command=C2=A0with a sub-phase o= f =E2=80=9Cextended=E2=80=9D
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return=C2=A0
      1. claims notice is required=C2=A0
    2. else=C2=A0
      1. claims notice is NOT required=C2=A0
This would still allow a registrar to determine if a claim currentl= y exists on a domain when a claim period does not exist for the TLD (the cu= rrent implementation).=C2=A0 From a registrar perspective, I=E2=80=99m not sure if determining if a domain h= as a claim when all claims periods have expired is needed.=C2=A0 This imple= mentation also would require additional work by all registrars to support i= f adopted, while the implementation from Jim=E2=80=99s first post would require only updates by the registries which would be bet= ter for widespread adoption.
=C2=A0
Thoughts?
=C2=A0
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile)=C2=A0Please contact my direct supervisor Charl= es Beadnall (cbeadnall@godad= dy.com) with any feedback.
=C2=A0
This email message and any attachments hereto is intended for use o= nly by the addressee(s) named herein and may contain confidential informati= on. If you have received this email in error, please immediately notify the sender and permanently = delete the original and any copy of this message and its attachments.
=C2=A0
From:= =C2=A0Gould, James [mailto:JGould@ver= isign.com]=C2=A0
Sent:=C2=A0Thursday, January 08, 2015 12:24 PM
To:=C2=A0Francisco Obispo
Cc:=C2=A0Jody Kolker;=C2=A0eppext@ietf.org; Tran, Trung
Subject:=C2=A0Re: [eppext] draft-ietf-eppext-launchphas= e Support for a "Claims Service" post the Claims Phase<= /u>
=C2=A0
Francisco,
=C2=A0
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=E2=80=99m not sure the value in defining a new = top-level phase name.=C2=A0 Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?=C2=A0 We have stuck with the standard set o= f =E2=80=9Csunrise=E2=80=9D, =E2=80=9Cclaims=E2=80=9D, and =E2=80=9Copen=E2= =80=9D phases.=C2=A0 Have others utilized the use of sub-phases or have cre= ated custom top-level phase names to meet their needs?=C2=A0 If so, can you share your scheme?= =C2=A0 It would be good to know if there are any common patterns. =C2=A0=
=C2=A0
Thanks,
=C2=A0
=E2=80=94
=C2=A0<= /div>

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com<= /a>

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com
=C2=A0
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase> =C2=A0SH= OULD contain the value of "claims" to indicate the
=C2=A0 =C2=A0 =C2=A0 =C2=A0claims launch phase.=C2=A0 A value other than &q= uot;claims" MAY be used to=C2=A0
pass the claims notice for domain names outside of the claims phase.=C2=A0= =C2=A0
=C2=A0
=C2=A0
Once a TLD has ended the mandatory 90 day period of =E2=80=9Cclaims=E2=80= =9D a registry might decide to call it something else.=C2=A0<= /div>
=C2=A0
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =E2=80=9Csunrise=E2=80=9D with a sub-phase called =E2=80=9Cextended=E2=80=9D but we thought it would be t= oo complicated for RARs to change their code, so we decided just to trigger= it by calling the phase =E2=80=9Csunsrise=E2=80=9D, but in reality, a regi= stry can call it anything they want in order to support it, because they are different things.
=C2=A0
Since there is no guidance on what the phases should be called, it seems li= ke we=E2=80=99re going to end up with discrete phase names for anything tha= t is not: claims or sunrise.
=C2=A0
=C2=A0

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?=C2=A0 Is there a past mail l= ist thread on this or is this a new issue?=C2=A0 Please clarify.<= /u>

=C2=A0
Francisco Obisp= o
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Be= ach, CA, 92660


__________________________________________= _____
EppExt mailing list
EppExt@ietf.org = https://www.ietf.org/mailman/listinfo/eppext



--089e0158c78ae1a720050ccc712a-- --089e0158c78ae1a722050ccc712b Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Transfer-Encoding: base64 Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> X-Attachment-Id: c30a0da9e221e151_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --089e0158c78ae1a722050ccc712b-- From nobody Mon Jan 19 01:47:41 2015 Return-Path: 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 8260D1AD377 for ; Mon, 19 Jan 2015 01:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-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 Vd6cNNxtZOi9 for ; Mon, 19 Jan 2015 01:47:38 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C081AD35B for ; Mon, 19 Jan 2015 01:47:37 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id r20so7343564wiv.4 for ; Mon, 19 Jan 2015 01:47: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:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=T04xUaBN0v7Q2j7FhAOXgVVc1tjf7L04X+vzfCgUmQA=; b=Hdn3qgrKNc4qrTW3VgM2m2ow7jB6PS8tQYNEpV7V819xFP6D3fbr2dLVv2p94qzgrj QnmfGaC62g/EdliFrc81Lwjp5nzr+caGq8Cd6wMixe8wmRyKf0BYbk9xcTOPzbZtnlDs 8dDurkz7/t8cX1puW2rjIZ8YkVaK0+nxp4igpDKELLjysfBaY6XyYTNW3SU92l/GBBGa GsST3psOtVMgrSP6H8aigkH+1mXXGlu2+0oXRMUi6RFK0KxM0AdVAO0sP/ILX3r1XrOa 5lxkztZ2UrApmO/z0Sztht+RZFTy8Mzs0O3hHCdQVU/elz4v+MDRiLaAh1rlyPvSdldV UnLg== X-Gm-Message-State: ALoCoQkIBxq50PQuQ616ZY/qIeu88TyXe5+qxrg4R5/e/ZDKT1tjx6yLTGAaYKl49QzIqv6HUWH8 X-Received: by 10.194.78.229 with SMTP id e5mr6139142wjx.11.1421660856304; Mon, 19 Jan 2015 01:47:36 -0800 (PST) Received: from miek.nl ([2a01:7e00::f03c:91ff:feae:e74c]) by mx.google.com with ESMTPSA id td6sm13511294wic.15.2015.01.19.01.47.35 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 19 Jan 2015 01:47:35 -0800 (PST) Date: Mon, 19 Jan 2015 09:47:34 +0000 From: Miek Gieben To: "Gould, James" Message-ID: <20150119094734.GA27180@miek.nl> Mail-Followup-To: "Gould, James" , Rik Ribbers , "eppext@ietf.org" References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Cc: Rik Ribbers , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Mon, 19 Jan 2015 09:47:39 -0000 [ Quoting in "Re: [eppext] New draft for keyrelay..." ] >All, > >I agree with Rik that more from the WG must weigh in on this. I believe Rik >and I understood fully each others perspective, but we simply don’t agree. >Please take some time to review the two different approaches and reply to the >list with your opinion. I didn't see any replies, so I'm assuming not that many people care about this issue. As one of the draft authors I think we should leave the draft in its current state. /Miek -- Miek Gieben From nobody Mon Jan 19 03:31:31 2015 Return-Path: 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 2D42E1B2A2D for ; Mon, 19 Jan 2015 03:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 X-cPQvPXTwbm for ; Mon, 19 Jan 2015 03:31:26 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D0E1AD4A1 for ; Mon, 19 Jan 2015 03:31:25 -0800 (PST) Received: from DB4PR06MB128.eurprd06.prod.outlook.com (10.242.155.27) by DB4PR06MB126.eurprd06.prod.outlook.com (10.242.155.21) with Microsoft SMTP Server (TLS) id 15.1.59.20; Mon, 19 Jan 2015 11:26:16 +0000 Received: from DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.245]) by DB4PR06MB128.eurprd06.prod.outlook.com ([169.254.16.245]) with mapi id 15.01.0059.007; Mon, 19 Jan 2015 11:26:16 +0000 From: Maarten Bosteels To: Miek Gieben , "Gould, James" , "eppext@ietf.org" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEbw5wAAAWKvYA= Date: Mon, 19 Jan 2015 11:26:16 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> In-Reply-To: <20150119094734.GA27180@miek.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [77.67.63.234] authentication-results: spf=none (sender IP is ) smtp.mailfrom=maarten.bosteels@dnsbelgium.be; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:DB4PR06MB126; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB126; x-forefront-prvs: 046164D5C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(24454002)(51704005)(53754006)(199003)(87936001)(102836002)(15975445007)(2950100001)(2900100001)(83716003)(40100003)(68736005)(2501002)(2656002)(19580405001)(46102003)(97736003)(64706001)(62966003)(74482002)(122556002)(77156002)(66066001)(36756003)(101416001)(33656002)(86362001)(93886004)(105586002)(54356999)(76176999)(50986999)(82746002)(19580395003)(92566002)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB126; H:DB4PR06MB128.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: dnsbelgium.be does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dnsbelgium.be X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2015 11:26:16.2766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 695195de-c0cb-4478-9204-2a861e60e59c X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB126 Archived-At: Cc: Rik Ribbers Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Mon, 19 Jan 2015 11:31:29 -0000 SGkgYWxsLA0KDQpJIGFncmVlIHdpdGggSmFtZXMgdGhhdCBjcmVhdGluZyBhIEtleSBSZWxheSBP YmplY3QgTWFwcGluZyBpbnN0ZWFkIG9mIA0KbWl4aW5nIG9mIGEgcHJvdG9jb2wgZXh0ZW5zaW9u IGZvciB0aGUgY29tbWFuZCBhbmQgYW4gb2JqZWN0IG1hcHBpbmcgZm9yIA0KdGhlIHBvbGwgcmVz cG9uc2Ugc2VlbXMgc2ltcGxlci4NCkFuZCBJIGFtIGFsbCBmb3Igc2ltcGxlciA7LSkNCkF0IERO UyBCZWxnaXVtIHdlIGhhdmUgaW4gdGhlIHBhc3QgY3JlYXRlZCBleHRyYSB2ZXJicyB1c2luZyBh IHByb3RvY29sIA0KZXh0ZW5zaW9uLCBidXQgaW4gbW9zdCBjYXNlcyBpdCBwcm92ZWQgYWZ0ZXJ3 YXJkcyB0byBiZSBtb3JlIGFwcHJvcHJpYXRlIA0KdG8gdXNlIGFuIHBsYWluIGNvbW1hbmQvcmVz cG9uc2UgZXh0ZW5zaW9uIG9yIGEgbmV3IE9iamVjdCBNYXBwaW5nLg0KIA0KDQpMaWtlIE1pZWss IEkgYWxzbyBhc3N1bWUgbm90IG1hbnkgcGVvcGxlIGNhcmUgYWJvdXQgdGhpcyBpc3N1ZS4gSSB0 aGluayANCmZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQpBKSBCb3RoIG9wdGlvbnMgd2lsbCB3 b3JrOiBpdCdzIGEgdmVyeSB0ZWNobmljYWwgY2hvaWNlIHdpdGggbGl0dGxlIGltcGFjdCANCm9u IHRoZSBhY3R1YWwgdXNlcnMNCkIpIEkgYXNzdW1lIG5vdCBtYW55IHJlZ2lzdHJpZXMgKGFuZCBS QVIncykgYXJlIGNvbnNpZGVyaW5nIGltcGxlbWVudGluZyANCmtleSByZWxheSBpbiB0aGUgbmVh ciBmdXR1cmUuIEJ1dCBJJ2QgbG92ZSB0byBiZSBwcm92ZWQgd3JvbmcgaGVyZSAhDQoNCg0KTWll ayBvciBSaWssIGlzIHRoZSBrZXktcmVsYXkgZnVuY3Rpb25hbGl0eSBpbXBsZW1lbnRlZCBieSBT SUROIGFjdGl2ZWx5IA0KdXNlZCBieSBtYW55IHJlZ2lzdHJhcnMgPyAgT24gYm90aCBzaWRlcyBv ZiB0aGUgdHJhbnNmZXIvcmVsYXkgPw0KDQpSZWdhcmRzDQpNYWFydGVuDQoNCg0KDQoNCk9uIDE5 LzAxLzE1IDA5OjQ3LCAiTWllayBHaWViZW4iIDxtaWVrQG1pZWsubmw+IHdyb3RlOg0KDQo+WyBR dW90aW5nIDxKR291bGRAdmVyaXNpZ24uY29tPiBpbiAiUmU6IFtlcHBleHRdIE5ldyBkcmFmdCBm b3IgDQo+a2V5cmVsYXkuLi4iIF0NCj4+QWxsLA0KPj4NCj4+SSBhZ3JlZSB3aXRoIFJpayB0aGF0 IG1vcmUgZnJvbSB0aGUgV0cgbXVzdCB3ZWlnaCBpbiBvbiB0aGlzLiAgSSBiZWxpZXZlIA0KPj5S aWsNCj4+YW5kIEkgdW5kZXJzdG9vZCBmdWxseSBlYWNoIG90aGVycyBwZXJzcGVjdGl2ZSwgYnV0 IHdlIHNpbXBseSBkb27igJl0IA0KPj5hZ3JlZS4NCj4+UGxlYXNlIHRha2Ugc29tZSB0aW1lIHRv IHJldmlldyB0aGUgdHdvIGRpZmZlcmVudCBhcHByb2FjaGVzIGFuZCByZXBseSANCj4+dG8gdGhl DQo+Pmxpc3Qgd2l0aCB5b3VyIG9waW5pb24uDQo+DQo+SSBkaWRuJ3Qgc2VlIGFueSByZXBsaWVz LCBzbyBJJ20gYXNzdW1pbmcgbm90IHRoYXQgbWFueSBwZW9wbGUgY2FyZSBhYm91dCANCj50aGlz DQo+aXNzdWUuDQo+DQo+QXMgb25lIG9mIHRoZSBkcmFmdCBhdXRob3JzIEkgdGhpbmsgd2Ugc2hv dWxkIGxlYXZlIHRoZSBkcmFmdCBpbiBpdHMgDQo+Y3VycmVudA0KPnN0YXRlLg0KPg0KPi9NaWVr DQo+DQo+LS0NCj5NaWVrIEdpZWJlbg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+RXBwRXh0IG1haWxpbmcgbGlzdA0KPkVwcEV4dEBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZXBwZXh0DQo= From nobody Tue Jan 20 00:02:02 2015 Return-Path: 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 80AA81B2D92 for ; Tue, 20 Jan 2015 00:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.294 X-Spam-Level: X-Spam-Status: No, score=0.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 hyvGJauxAa-J for ; Tue, 20 Jan 2015 00:01:57 -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 A79251B2D82 for ; Tue, 20 Jan 2015 00:01:55 -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-originating-ip:content-type:content-transfer-encoding:mime-version; bh=HlE8BGSHQmXpcgXV1MHlOu6TuNVKG0kMVlHqCKKGoKw=; b=TDL6ouSp6sHI9JlWMYzsRsEnwGEkZ3/m3RkyjR8mGBA7DzUpf1C9GNXvQTv4jsNnH9WAhq1dyu1huC08jWLiSI2fBzCN+wiMo4LLW1aEQBByfKi7i2VF5tTOOwts8LUjW0v7Jm67J2xHBQdPMbiXyVccA8eLgCH5QREYjZ7hjMc= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0K81mtI026912-t0K81mtK026912 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Tue, 20 Jan 2015 09:01:48 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Tue, 20 Jan 2015 09:01:46 +0100 From: Rik Ribbers To: "'Maarten Bosteels'" , Miek Gieben , "Gould, James" , "eppext@ietf.org" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMA== Date: Tue, 20 Jan 2015 08:01:45 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.152] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Tue, 20 Jan 2015 08:02:00 -0000 SGVsbG8gTWFhcnRlbiwNCg0KVGh4IGZvciB0aGUgZmVlZGJhY2ssIEkgaG9wZSBtb3JlIHBlb3Bs ZSB3aXRoIGV4cGVyaWVuY2Ugb24gZXh0ZW5kaW5nIEVQUCB3aWxsIHN0YXRlIHRoZWlyIG9waW5p b24gb24gdGhlIGxpc3QuDQoNCldlIGhhdmUgaW1wbGVtZW50ZWQgdGhlIGZ1bmN0aW9uYWxpdHkg aW4gb3VyIHJlZ2lzdHJhdGlvbiBzeXN0ZW0sIGJ1dCBpdCBpcyBub3QgdmVyeSBhY3RpdmVseSB1 c2VkLiBXaGF0IHdlIHNlZSBpcyB0aGF0IG1vc3QgcmVnaXN0cmFycyBnbyBpbnNlY3VyZS4gTW9z dCBvZiB0aGUgdGltZSB3ZSBzZWUgYSB0cmFuc2ZlciBjb21tYW5kIGZvbGxvd2VkIChzb21lIHRp bWUgbGF0ZXIgaW4gdGltZSkgYnkgYSBkb21haW4gdXBkYXRlIHRvIHJlbW92ZSB0aGUgb2xkIGtl eSBtYXRlcmlhbCBhbmQgYWRkIG5ldyBrZXkgbWF0ZXJpYWwuIFRoZXJlIGlzIGV2ZW4gYSBsb3Np bmcgcmVnaXN0cmFyIHRoYXQgcmVtb3ZlcyBhbGwgRE5TIGtleSBkYXRhIHdoZW4gYSByZWdpc3Ry YW50IHJlcXVlc3RzIGl0cyBhdXRob3JpemF0aW9uIHRva2VuIGJlZm9yZSB0aGUgYWN0dWFsIHRy YW5zZmVyLg0KDQpLaW5kIHJlZ2FyZHMsDQpSaWsgUmliYmVycw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFhcnRlbiBCb3N0ZWVscyBbbWFpbHRvOm1hYXJ0ZW4uYm9zdGVl bHNAZG5zYmVsZ2l1bS5iZV0gDQpTZW50OiBtYWFuZGFnIDE5IGphbnVhcmkgMjAxNSAxMjoyNg0K VG86IE1pZWsgR2llYmVuOyBHb3VsZCwgSmFtZXM7IGVwcGV4dEBpZXRmLm9yZw0KQ2M6IFJpayBS aWJiZXJzDQpTdWJqZWN0OiBSZTogW2VwcGV4dF0gTmV3IGRyYWZ0IGZvciBrZXlyZWxheSBhdmFp bGFibGUNCg0KSGkgYWxsLA0KDQpJIGFncmVlIHdpdGggSmFtZXMgdGhhdCBjcmVhdGluZyBhIEtl eSBSZWxheSBPYmplY3QgTWFwcGluZyBpbnN0ZWFkIG9mIG1peGluZyBvZiBhIHByb3RvY29sIGV4 dGVuc2lvbiBmb3IgdGhlIGNvbW1hbmQgYW5kIGFuIG9iamVjdCBtYXBwaW5nIGZvciB0aGUgcG9s bCByZXNwb25zZSBzZWVtcyBzaW1wbGVyLg0KQW5kIEkgYW0gYWxsIGZvciBzaW1wbGVyIDstKQ0K QXQgRE5TIEJlbGdpdW0gd2UgaGF2ZSBpbiB0aGUgcGFzdCBjcmVhdGVkIGV4dHJhIHZlcmJzIHVz aW5nIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLCBidXQgaW4gbW9zdCBjYXNlcyBpdCBwcm92ZWQgYWZ0 ZXJ3YXJkcyB0byBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIHVzZSBhbiBwbGFpbiBjb21tYW5kL3Jl c3BvbnNlIGV4dGVuc2lvbiBvciBhIG5ldyBPYmplY3QgTWFwcGluZy4NCiANCg0KTGlrZSBNaWVr LCBJIGFsc28gYXNzdW1lIG5vdCBtYW55IHBlb3BsZSBjYXJlIGFib3V0IHRoaXMgaXNzdWUuIEkg dGhpbmsgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCkEpIEJvdGggb3B0aW9ucyB3aWxsIHdv cms6IGl0J3MgYSB2ZXJ5IHRlY2huaWNhbCBjaG9pY2Ugd2l0aCBsaXR0bGUgaW1wYWN0IG9uIHRo ZSBhY3R1YWwgdXNlcnMNCkIpIEkgYXNzdW1lIG5vdCBtYW55IHJlZ2lzdHJpZXMgKGFuZCBSQVIn cykgYXJlIGNvbnNpZGVyaW5nIGltcGxlbWVudGluZyBrZXkgcmVsYXkgaW4gdGhlIG5lYXIgZnV0 dXJlLiBCdXQgSSdkIGxvdmUgdG8gYmUgcHJvdmVkIHdyb25nIGhlcmUgIQ0KDQoNCk1pZWsgb3Ig UmlrLCBpcyB0aGUga2V5LXJlbGF5IGZ1bmN0aW9uYWxpdHkgaW1wbGVtZW50ZWQgYnkgU0lETiBh Y3RpdmVseSB1c2VkIGJ5IG1hbnkgcmVnaXN0cmFycyA/ICBPbiBib3RoIHNpZGVzIG9mIHRoZSB0 cmFuc2Zlci9yZWxheSA/DQoNClJlZ2FyZHMNCk1hYXJ0ZW4NCg0KDQoNCg0KT24gMTkvMDEvMTUg MDk6NDcsICJNaWVrIEdpZWJlbiIgPG1pZWtAbWllay5ubD4gd3JvdGU6DQoNCj5bIFF1b3Rpbmcg PEpHb3VsZEB2ZXJpc2lnbi5jb20+IGluICJSZTogW2VwcGV4dF0gTmV3IGRyYWZ0IGZvciANCj5r ZXlyZWxheS4uLiIgXQ0KPj5BbGwsDQo+Pg0KPj5JIGFncmVlIHdpdGggUmlrIHRoYXQgbW9yZSBm cm9tIHRoZSBXRyBtdXN0IHdlaWdoIGluIG9uIHRoaXMuICBJIA0KPj5iZWxpZXZlIFJpayBhbmQg SSB1bmRlcnN0b29kIGZ1bGx5IGVhY2ggb3RoZXJzIHBlcnNwZWN0aXZlLCBidXQgd2UgDQo+PnNp bXBseSBkb27igJl0IGFncmVlLg0KPj5QbGVhc2UgdGFrZSBzb21lIHRpbWUgdG8gcmV2aWV3IHRo ZSB0d28gZGlmZmVyZW50IGFwcHJvYWNoZXMgYW5kIHJlcGx5IA0KPj50byB0aGUgbGlzdCB3aXRo IHlvdXIgb3Bpbmlvbi4NCj4NCj5JIGRpZG4ndCBzZWUgYW55IHJlcGxpZXMsIHNvIEknbSBhc3N1 bWluZyBub3QgdGhhdCBtYW55IHBlb3BsZSBjYXJlIA0KPmFib3V0IHRoaXMgaXNzdWUuDQo+DQo+ QXMgb25lIG9mIHRoZSBkcmFmdCBhdXRob3JzIEkgdGhpbmsgd2Ugc2hvdWxkIGxlYXZlIHRoZSBk cmFmdCBpbiBpdHMgDQo+Y3VycmVudCBzdGF0ZS4NCj4NCj4vTWllaw0KPg0KPi0tDQo+TWllayBH aWViZW4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPkVwcEV4dCBtYWlsaW5nIGxpc3QNCj5FcHBFeHRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VwcGV4dA0K From nobody Tue Jan 20 05:50:07 2015 Return-Path: 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 26ACA1B2A3A; Tue, 20 Jan 2015 05:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 tyLdAriIETPm; Tue, 20 Jan 2015 05:50:00 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B981B2A18; Tue, 20 Jan 2015 05:49:59 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVL5c8sNNce4WXj9irHfnU6BoE20/P4xp@postini.com; Tue, 20 Jan 2015 05:50:00 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0KDnccs032116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Jan 2015 08:49:38 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 20 Jan 2015 08:49:37 -0500 From: "Gould, James" To: "eppext@ietf.org" , EPP Provreg , "gtld-tech@icann.org" Thread-Topic: Publishing of the Change Poll EPP Extension IETF Draft Thread-Index: AQHQNLfubNb4XttaHk+typCoyhUfuw== Date: Tue, 20 Jan 2015 13:49:37 +0000 Message-ID: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com> 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_211D042018A343D79A3D553B34C6DF43verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] Publishing of the Change Poll EPP Extension IETF Draft X-BeenThere: eppext@ietf.org 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: Tue, 20 Jan 2015 13:50:03 -0000 --_004_211D042018A343D79A3D553B34C6DF43verisigncom_ Content-Type: multipart/alternative; boundary="_000_211D042018A343D79A3D553B34C6DF43verisigncom_" --_000_211D042018A343D79A3D553B34C6DF43verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/ht= ml/draft-gould-change-poll-00 ) has been submitted to the IETF. I co-autho= red this draft with Trung Tran from Neustar to provide a mechanism within E= PP to notify clients of any server-side change, including but not limited t= o regular batch processes, customer support actions, Uniform Domain-Name Di= spute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, c= ourt directed actions, and bulk updates based on customer requests. Sinc= e the client is not directly involved or knowledgable of these operations, = the extension is used along with an EPP object mapping to provide the resul= ting state of the post-operation object, and optionally a pre-operation obj= ect, with the operation meta-data of what, when, who, and why. We would li= ke this draft to be included in a re-charting of the EPPEXT Working Group. Please review the draft and provide any feedback. Thanks, =97 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 =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_211D042018A343D79A3D553B34C6DF43verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <74B38EE251CC4542BEC669D7ED1C399B@verisign.com> Content-Transfer-Encoding: quoted-printable
The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/h= tml/draft-gould-change-poll-00 ) has been submitted to the IETF.  = I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-= side change, including but not limited to regular batch processes, customer= support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or U= niform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests.  = ;  Since the client is not directly involved or knowledgable of these = operations, the extension is used along with an EPP object mapping to provi= de the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-dat= a of what, when, who, and why.  We would like this draft to be include= d in a re-charting of the EPPEXT Working Group.  

Please review the draft and provide any feedback.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_211D042018A343D79A3D553B34C6DF43verisigncom_-- --_004_211D042018A343D79A3D553B34C6DF43verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 20 Jan 2015 13:49:37 GMT"; modification-date="Tue, 20 Jan 2015 13:49:37 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_211D042018A343D79A3D553B34C6DF43verisigncom_-- From nobody Tue Jan 20 05:59:00 2015 Return-Path: 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 75C381B2A24 for ; Tue, 20 Jan 2015 05:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 AYbQ7GiQmoWs for ; Tue, 20 Jan 2015 05:58:48 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E02F1AD481 for ; Tue, 20 Jan 2015 05:58:47 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVL5fFs8BPYNh8wyO3GfHgb42EM76cobx@postini.com; Tue, 20 Jan 2015 05:58:47 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0KDwk7X000762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 20 Jan 2015 08:58:46 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 20 Jan 2015 08:58:45 -0500 From: "Gould, James" To: "eppext@ietf.org" Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgIAAF1sAgAAI+ACACuPxAA== Date: Tue, 20 Jan 2015 13:58:44 +0000 Message-ID: <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> In-Reply-To: <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> 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_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Tue, 20 Jan 2015 13:58:58 -0000 --_004_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_ Content-Type: multipart/alternative; boundary="_000_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_" --_000_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I had a private thread with some about the proposal of referencing the past= =93claims=94 phase in the claims check command to support Trung=92s reques= t. The issue is that some clients are hard coding =93claims=94 as the phas= e in the claims check command and currently there is little to no support f= or the claims check command outside of the =93claims=94 phase, so clients m= ay inadvertently go through the claims process when it is not required or e= ven potentially rejected on create. I see the concern with adding a new fe= ature that may inadvertently cause interface issues. Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a = name independent of the requirement for a claims notice for other use cases= like the resale of domain names. We already support a =93type" attribute in the element, sect= ion 3.1, to define the check form of the command, which currently support = =93claims=94 and =93avail=94 for the Claims Check Form and the Availability= Check Form, respectively. The default form is the Claims Check Form, whic= h is updated to return =93exists=3D1=94 if there is a matching trademark an= d a claims notice is required on create, per the proposed check changes. W= e could add a Trademark Check Form (e.g. add section 3.1.3) that is indicat= ed by setting the =93type=94 attribute to =93trademark=94. The interface f= or the Trademark Check Form is consistent with the Claims Check Form, excep= t the element is not applicable, so therefore in the schema = we would make the element optional, and the server would onl= y match the domain to the matching set of trademarks to return the same res= ponse as with the Claims Check Form. The element would stil= l be required for the Claims Check Form and the Availability Check Form bas= ed on the draft text. As stated in section 3.1, the forms supported by the= server is determined by server policy, so the Trademark Check Form would i= s an option but is not required. The check command using the Trademark Che= ck Form would look like: C: C: C: C: C: C: example1.tld C: example2.tld C: C: C: C: C: C: ABC-12345 C: C: To support this, section 3.1.3 Trademark Check Form would need to be added = along with some text changes on the =93trademark=94 value for the =93type= =94 attribute in section 3.1, would = need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema. Let me know your thoughts on this option. Thanks, =97 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 On Jan 13, 2015, at 10:40 AM, Gould, James > wrote: Michael, I provide feedback inline below. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 10:08 AM, Michael Holloway > wrote: Hi Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrations.= The post claims lookup seems to be aimed at determining, for information p= urposes only (without "acking" in the create), whether or not there is a tr= ademark registered against the term (i.e. label only) therefore there is no= reason to check claims via TLD. This is a little OT anyway (my fault sorry= ), but hopefully you see where I am coming from. The use case for the claims check post the claims phase is used to address = the release of domain names that did not go through 90 days of claims, whic= h I believe is a modified version of your #2 below. Let=92s take the three basic phases defined in draft-ietf-eppext-launchphas= e as an example with sunrise, claims, and open. We can pretty much remove = the sunrise phase from the example for now, so let=92s focus on the claims = and open phases. Assuming that claims.tld is available through sunrise and= the claims phase, so if a claims check is done with =93open=94 as the phas= e, the response would be exists=3D=930=94, since there is no requirement to= provide the claims notice on create. If reserved.tld was released during = the =93open=94 phase, then a claims check on reserved.tld, with =93open=94 = as the phase, the response would be exists=3D=931=94, since a claims notice= is required on create. Based on Trung=92s use case, a client may want to = know whether or not there is a trademark on the domain name independent of = when the domain name is released, so the client can send a claims check wit= h the phase as =93claims=94 to get that answer. Back to LaunchPhase: my concern with simply using the "claims" phase is tha= t it can cause ambiguity, take the following four phase statuses, and compa= re with the logic below (to which I commented in underlined red) 1) A registry must operate a 90 days claims phase 2) A registry must operate 90 days extended claims period on domains that a= re released at a later date (collisions etc, and I don't know what may be c= oming up in the future) 3) A registry may operate a continued claims phase past the 90 domains for = all domains. [create with claims form] 4) [new]: A registry may operate a post claims (matching trademark past the= claims phase use case) [create without claims] If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create f= orm would be incorrect at this point despite receiving claims=3Dtrue. This = is why I suggest a different sub_phase should be used, OR a different flag = added (more complex of course) to differentiate. Based on the updated text, the client will only receive a claims check resp= onse with exists=3D=931=94 if =93create with claims form=94 is required. T= he updated text does not support #4, since the only time that =93exists=3D0= =94 is if a claims notice is required. This way a client can continue to u= se the claims check without any extra logic of passing special attributes o= r sub-phases to get the answer that is needed, which is whether a claims no= tice is required on create. Trung use case is an exception to the rule, wh= ere a client wants to know whether there is a matching trademark for the do= main name independent of whether a claims notice is required on create, so = passing =93claims=94 as the phase past the =93claims=94 phase may support t= hat. Let me know whether or not this helps. I hope this makes sense; and apologies if I am missing something fundamenta= l! Cheers, Michael 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue ## The claims exists but it is NOT require= d on domain_create * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return ## How does the client know= if 90 days has passed (extended / post claims) or not without external sou= rce? * claims notice is required * else * claims notice is NOT required Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 02:44 PM, Gould, James wrote: Michael, The split out of the responsibility of the registries and the CNIS / TMDB w= as worked out a couple of years ago, where there was a desire to not make t= he CNIS the critical path for the majority of the registrations. The agree= ment was for the registries to provide the claims check service and enforce= the claims notice on create based on a feed of trademark labels from the T= MDB to the registries. The proposal is to support the claims service post the =93claims=94 phase b= y passing the active phase to the server and the server will return whether= or not the claims notice is required based on a combination of a matching = trademark and whether the domain name already went through 90 days of the c= laims service. From a client perspective it means utilizing the claims che= ck in a similar fashion during and post the claims phase. The use case bro= ught up by Trung was more of an exception to the rule, in the client wantin= g to know whether there is a matching trademark for a domain name independe= nt of the requirement for passing the claims notice. In that case, the pro= posal is to pass =93claims=94 as the phase independent of the active phase = to get a true or false answer to whether a trademark matches the domain nam= e. Do the proposals work for you? Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 3:18 AM, Michael Holloway > wrote: Hi all Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= . The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not t= o submit claims data in a domain_create if the domain has a claim. As it is= , various registries are extending the claims periods past 90 days, so its = contradictory to have extended claims and post claims defined the same way = in the query but without a defined (or facilitated) way to differentiate th= e requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 JG [X] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5B0A0F4C9327EB4F8B5C143DCF0E2FB6@verisign.com> Content-Transfer-Encoding: quoted-printable
All,

I had a private thread with some about the proposal of referencing the= past =93claims=94 phase in the claims check command to support Trung=92s r= equest.  The issue is that some clients are hard coding =93claims=94 a= s the phase in the claims check command and currently there is little to no support for the claims check command outside of the = =93claims=94 phase, so clients may inadvertently go through the claims proc= ess when it is not required or even potentially rejected on create.  I= see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a name independent of the requirement for a cla= ims notice for other use cases like the resale of domain names.

We already support a =93type" attribute in the <launch:check&g= t; element, section 3.1, to define the check form of the command, which cur= rently support =93claims=94 and =93avail=94 for the Claims Check Form and t= he Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return =93exists=3D1=94= if there is a matching trademark and a claims notice is required on create= , per the proposed check changes.  We could add a Trademark Check Form= (e.g. add section 3.1.3) that is indicated by setting the =93type=94 attribute to =93trademark=94.  The interfac= e for the Trademark Check Form is consistent with the Claims Check Form, ex= cept the <launch:phase> element is not applicable, so therefore in th= e schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademar= ks to return the same response as with the Claims Check Form.  The <= ;launch:phase> element would still be required for the Claims Check Form= and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the ser= ver is determined by server policy, so the Trademark Check Form would is an= option but is not required.  The check command using the Trademark Ch= eck Form would look like:

   C:<?xml version=3D"1.0&quo=
t; encoding=3D"UTF-8" standalone=3D"no"?>
   C:<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0"
   C:     type=3D=93trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be a= dded along with some text changes on the =93trademark=94 value for the =93t= ype=94 attribute in section 3.1, <e= numeration value=3D=93trademark=94/> would need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema.    

Let me know your thoughts on this option. 

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:

Michael,

I provide feedback inline below.  

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Verisign= Inc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:<= /div>
Hi

Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrati= ons. The post claims lookup seems to be aimed at determining, for informati= on purposes only (without "acking" in the create), whether or not there is a trademark registered against the te= rm (i.e. label only) therefore there is no reason to check claims via TLD. = This is a little OT anyway (my fault sorry), but hopefully you see where I = am coming from.

The use case for the claims check post the claims phase is used to add= ress the release of domain names that did not go through 90 days of claims,= which I believe is a modified version of your #2 below.  

Let=92s take the three basic phases defined in draft-ietf-eppext-= launchphase as an example with sunrise, claims, and open.  We can pret= ty much remove the sunrise phase from the example for now, so let=92s focus= on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a clai= ms check is done with =93open=94 as the phase, the response would be exists= =3D=930=94, since there is no requirement to provide the claims notice on c= reate.  If reserved.tld was released during the =93open=94 phase, then a claims check on reserved.tld, with =93open=94= as the phase, the response would be exists=3D=931=94, since a claims notic= e is required on create.  Based on Trung=92s use case, a client may wa= nt to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client= can send a claims check with the phase as =93claims=94 to get that answer.=    



Back to LaunchPhase: my concern with simply using the "claims" ph= ase is that it can cause ambiguity, take the following four phase statuses,= and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains= that are released at a later date (collisions etc, and I don't know what m= ay be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domai= ns for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create w<= /span>ithout claims]

If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this poi= nt despite receiving claims=3Dtrue. This is why I suggest a different sub_p= hase should be used, OR a different flag added (more complex of course) to = differentiate.


Based on the updated text, the client will only receive a claims check= response with exists=3D=931=94 if =93create with claims form=94 is require= d.  The updated text does not support #4, since the only time that =93= exists=3D0=94 is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic = of passing special attributes or sub-phases to get the answer that is neede= d, which is whether a claims notice is required on create.  Trung use = case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domai= n name independent of whether a claims notice is required on create, so pas= sing =93claims=94 as the phase past the =93claims=94 phase may support that= .  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I = am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue ## The claims exists but it is NOT required on domain_cre= ate
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return ## How does the client know if 90 days has passed (= extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / T= MDB was worked out a couple of years ago, where there was a desire to not m= ake the CNIS the critical path for the majority of the registrations.  = ;The agreement was for the registries to provide the claims check service and enforce the claims notice on creat= e based on a feed of trademark labels from the TMDB to the registries. &nbs= p;

The proposal is to support the claims service post the =93claims=94 ph= ase by passing the active phase to the server and the server will return wh= ether or not the claims notice is required based on a combination of a matc= hing trademark and whether the domain name already went through 90 days of the claims service.  From a clie= nt perspective it means utilizing the claims check in a similar fashion dur= ing and post the claims phase.  The use case brought up by Trung was m= ore of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name in= dependent of the requirement for passing the claims notice.  In that c= ase, the proposal is to pass =93claims=94 as the phase independent of the a= ctive phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<Mail Attachment.png>=

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= .

The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a cla= im. As it is, various registries are extending the claims periods past 90 d= ays, so its contradictory to have extended claims and post claims defined t= he same way in the query but without a defined (or facilitated) way to differentiate the requirement for a doma= in_create.

I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB.=

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign= .com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>= ;
Cc: Francisco Obispo <fobispo@uniregist= ry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

= =97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com=

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:
Fr= om Francisco:
&n= bsp;
Th= anks Jim for bringing this to the eppext.  This will definitely help t= he post claims phase.
&n= bsp;
Wi= th the wording changes, is there still a way to determine if there=92s a tr= ademark against the name regardless on whether or not the claims ack is nee= ded in the create domain?  
 
This could = be accomplished by leaving the =93claims=94 implementation as it is current= ly and introducing a sub-phase for claims named =93extended=94.  When the su= p-phase of =93extended=94 is passed the results from Jim=92s earlier email = would be below.
 
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would = still allow a registrar to determine if a claim currently exists on a domai= n when a claim period does not exist for the TLD (the current implementation).&nb= sp; From a registrar perspective, I=92m not sure if determining if a domain= has a claim when all claims periods have expired is needed.  This imp= lementation also would require additional work by all registrars to support if adopted, while the implementation from Jim= =92s first post would require only updates by the registries which would be= better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) P= lease contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any a= ttachments hereto is intended for use only by the addressee(s) named herein and may contain = confidential information. If you have received this email in error, please = immediately notify the sender and permanently delete the original and any c= opy of this message and its attachments.
 
From: Gould, James [ma= ilto:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; ep= pext@ietf.org; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97=
 

JG=


<image001.png>

James Gould
Distinguished Enginee= r
jgould@Verisign.co= m

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fo= bispo@uniregistry.com> wrote:


&l= t;launch:phase>  SHOULD contain the value of "claims" to = indicate the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.c= om> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Fra= ncisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.<= /span>
Newport Beac= h, CA, 92660<= /span>
off= . +1.345.749.6284
fax= . +1.345.746.6263



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinf=
o/eppext
_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinfo/eppext



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

--_000_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_-- --_004_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Tue, 20 Jan 2015 13:58:44 GMT"; modification-date="Tue, 20 Jan 2015 13:58:44 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_4DA7DF42F833484E82BCDBB0B823AFC2verisigncom_-- From nobody Wed Jan 21 05:41:29 2015 Return-Path: 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 9D8701A1AB3 for ; Wed, 21 Jan 2015 05:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.281 X-Spam-Level: X-Spam-Status: No, score=0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 jfO5XoxxRsVy for ; Wed, 21 Jan 2015 05:41:18 -0800 (PST) Received: from smtp115.ord1c.emailsrvr.com (smtp115.ord1c.emailsrvr.com [108.166.43.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7432F1A1AB1 for ; Wed, 21 Jan 2015 05:41:17 -0800 (PST) Received: from smtp23.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id D33FF2804E3 for ; Wed, 21 Jan 2015 08:41:16 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id CECFF280428 for ; Wed, 21 Jan 2015 08:41:16 -0500 (EST) X-Virus-Scanned: OK Received: by smtp23.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 536F428054E for ; Wed, 21 Jan 2015 08:41:15 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 21 Jan 2015 13:41:16 GMT Message-ID: <54BFAC7A.7090500@comlaude.com> Date: Wed, 21 Jan 2015 14:41:14 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext@ietf.org References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> In-Reply-To: <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> Content-Type: multipart/alternative; boundary="------------030901050102090804080808" Archived-At: Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Wed, 21 Jan 2015 13:41:26 -0000 This is a multi-part message in MIME format. --------------030901050102090804080808 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks James From a registrar perspective I would say this solves the issue without the risk of breaking working clients. I would be interested to hear the opinion of anyone [else] representing registries here whether they would support the extra type attribute since its essentially optional extra, or whether they would prefer to support using he existing schema. I think in the case of the latter it would suggest using Claims check on phases outside of "claims" (e.g. "open"), and then some guidance would need to be offered (in the draft) to define exactly what the "open" phase is; .I.E is it the period _after_ claims, or is the 'open registration' (aka general availability) period _during_ the claims period; and therefore when to and when not to use the "open" phase. Some minor wording changes would be required in 3.1.1 Claims check form to change it from `/The launch phase that SHOULD be "claims"`/ , to "MAY", perhaps with a bit more info. In light of the above I think it would be far simpler to go with the Trademark check form, so hopefully we can agree with that! That would be my vote anyway! Regards, Michael *Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com On 01/20/2015 02:58 PM, Gould, James wrote: > All, > > I had a private thread with some about the proposal of referencing the > past “claims” phase in the claims check command to support Trung’s > request. The issue is that some clients are hard coding “claims” as > the phase in the claims check command and currently there is little to > no support for the claims check command outside of the “claims” phase, > so clients may inadvertently go through the claims process when it is > not required or even potentially rejected on create. I see the > concern with adding a new feature that may inadvertently cause > interface issues. Although I am not crazy about making an XML schema > change, we may be able to tweak things to support both the the claims > check outside of the “claims” phase and also support Trung’s request > to determine whether or not a trademark matches a name independent of > the requirement for a claims notice for other use cases like the > resale of domain names. > > We already support a “type" attribute in the element, > section 3.1, to define the check form of the command, which currently > support “claims” and “avail” for the Claims Check Form and the > Availability Check Form, respectively. The default form is the Claims > Check Form, which is updated to return “exists=1” if there is a > matching trademark and a claims notice is required on create, per the > proposed check changes. We could add a Trademark Check Form (e.g. add > section 3.1.3) that is indicated by setting the “type” attribute to > “trademark”. The interface for the Trademark Check Form is consistent > with the Claims Check Form, except the element is not > applicable, so therefore in the schema we would make the > element optional, and the server would only match the > domain to the matching set of trademarks to return the same response > as with the Claims Check Form. The element would still > be required for the Claims Check Form and the Availability Check Form > based on the draft text. As stated in section 3.1, the forms > supported by the server is determined by server policy, so the > Trademark Check Form would is an option but is not required. The > check command using the Trademark Check Form would look like: > > C: > C: > C: > C: > C: C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> > C: example1.tld > C: example2.tld > C: > C: > C: > C: C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" > C: type=“trademark"/> > C: > C: ABC-12345 > C: > C: > > > To support this, section 3.1.3 Trademark Check Form would need to be > added along with some text changes on the “trademark” value for the > “type” attribute in section 3.1, > would need to be added to the checkFormType in the schema, and > minOccurs=“0” would need to be added to the “phase” element of > checkType in the schema. > > Let me know your thoughts on this option. > > Thanks, > > — > > > JG > > > > > *James Gould > *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 13, 2015, at 10:40 AM, Gould, James > wrote: > >> Michael, >> >> I provide feedback inline below. >> >> — >> >> JG >> >> >> >> >> *James Gould >> *Distinguished Engineer >> jgould@Verisign.com >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com >> >> On Jan 13, 2015, at 10:08 AM, Michael Holloway >> > > wrote: >> >>> Hi >>> >>> Re TMDB: I was thinking specifically of the post claims phase since >>> at this point the CNIS (label+tld) itself it no longer required for >>> registrations. The post claims lookup seems to be aimed at >>> determining, for information purposes only (without "acking" in the >>> create), whether or not there is a trademark registered against the >>> term (i.e. label only) therefore there is no reason to check claims >>> via TLD. This is a little OT anyway (my fault sorry), but hopefully >>> you see where I am coming from. >> >> The use case for the claims check post the claims phase is used to >> address the release of domain names that did not go through 90 days >> of claims, which I believe is a modified version of your #2 below. >> >> Let’s take the three basic phases defined >> in draft-ietf-eppext-launchphase as an example with sunrise, claims, >> and open. We can pretty much remove the sunrise phase from the >> example for now, so let’s focus on the claims and open phases. >> Assuming that claims.tld is available through sunrise and the claims >> phase, so if a claims check is done with “open” as the phase, the >> response would be exists=“0”, since there is no requirement to >> provide the claims notice on create. If reserved.tld was released >> during the “open” phase, then a claims check on reserved.tld, with >> “open” as the phase, the response would be exists=“1”, since a claims >> notice is required on create. Based on Trung’s use case, a client >> may want to know whether or not there is a trademark on the domain >> name independent of when the domain name is released, so the client >> can send a claims check with the phase as “claims” to get that answer. >> >> >>> >>> Back to LaunchPhase: my concern with simply using the "claims" phase >>> is that it can cause ambiguity, take the following four phase >>> statuses, and compare with the logic below (to which I commented in >>> _underlined red_) >>> 1) A registry _must_ operate a 90 days claims phase >>> 2) A registry _must_ operate 90 days extended claims period on >>> domains that are released at a later date (collisions etc, and I >>> don't know what may be coming up in the future) >>> 3) A registry _may_ operate a continued claims phase past the 90 >>> domains for all domains. [create with claims form] >>> 4) [new]: A registry _may_ operate a post claims (matching trademark >>> past the claims phase use case) [create without claims] >>> >>> If the client checks a domain for claims and gets result >>> claims=true, then how does it know which of the above rules matched? >>> In the case of (4) the claims lookup returns true even though the >>> domain is no longer in (1) or (2) [and the registry has opted not to >>> do (3)], so using the claims create form would be incorrect at this >>> point despite receiving claims=true. This is why I suggest a >>> different sub_phase should be used, OR a different flag added (more >>> complex of course) to differentiate. >>> >> >> Based on the updated text, the client will only receive a claims >> check response with exists=“1” if “create with claims form” is >> required. The updated text does not support #4, since the only time >> that “exists=0” is if a claims notice is required. This way a client >> can continue to use the claims check without any extra logic of >> passing special attributes or sub-phases to get the answer that is >> needed, which is whether a claims notice is required on create. >> Trung use case is an exception to the rule, where a client wants to >> know whether there is a matching trademark for the domain name >> independent of whether a claims notice is required on create, so >> passing “claims” as the phase past the “claims” phase may support that. >> >> Let me know whether or not this helps. >> >> >>> I hope this makes sense; and apologies if I am missing something >>> fundamental! >>> >>> Cheers, >>> Michael >>> >>> 1. During claims phase with a claims check command >>> 1. If domain has matching trademark >>> 1. return exists=true >>> 2. else >>> 1. return exists=false >>> 2. During post claims phase with a claims check command >>> 1. If domain was released post claims phase start and is within >>> 90 days of release and has matching trademark >>> 1. return exists=true >>> 2. else >>> 1. return exists=false >>> 3. *During post claims phase with a claims phase check and passing >>> “claims” as the phase (optional matching trademark past the >>> claims phase use case)* >>> 1. *If domains has matching trademark * >>> 1. *return exists=true *_## The claims exists but it is NOT >>> required on domain_create_ >>> 2. *else* >>> 1. *return exists=false* >>> >>> >>> 1. During claims phase with a create command >>> 1. If domain has matching trademark >>> 1. claims notice is required >>> 2. else >>> 1. claims notice is NOT required >>> 2. During post claims phase with a create command >>> 1. If domain was released post claims phase start and is within >>> 90 days of release and has matching trademark return ## How >>> does the client know if 90 days has passed (extended / post >>> claims) or not without external source? >>> 1. claims notice is required >>> 2. else >>> 1. claims notice is NOT required >>> >>> >>> >>> * >>> Michael Holloway >>> Senior Systems Administrator**| Com Laude* >>> E: michael.holloway@comlaude.com >>> >>> On 01/13/2015 02:44 PM, Gould, James wrote: >>>> Michael, >>>> >>>> The split out of the responsibility of the registries and the CNIS >>>> / TMDB was worked out a couple of years ago, where there was a >>>> desire to not make the CNIS the critical path for the majority of >>>> the registrations. The agreement was for the registries to provide >>>> the claims check service and enforce the claims notice on create >>>> based on a feed of trademark labels from the TMDB to the registries. >>>> >>>> The proposal is to support the claims service post the “claims” >>>> phase by passing the active phase to the server and the server will >>>> return whether or not the claims notice is required based on a >>>> combination of a matching trademark and whether the domain name >>>> already went through 90 days of the claims service. From a client >>>> perspective it means utilizing the claims check in a similar >>>> fashion during and post the claims phase. The use case brought up >>>> by Trung was more of an exception to the rule, in the client >>>> wanting to know whether there is a matching trademark for a domain >>>> name independent of the requirement for passing the claims notice. >>>> In that case, the proposal is to pass “claims” as the phase >>>> independent of the active phase to get a true or false answer to >>>> whether a trademark matches the domain name. >>>> >>>> Do the proposals work for you? >>>> >>>> Thanks, >>>> >>>> — >>>> >>>> JG >>>> >>>> >>>> >>>> >>>> *James Gould >>>> *Distinguished Engineer >>>> jgould@Verisign.com >>>> >>>> 703-948-3271 >>>> 12061 Bluemont Way >>>> Reston, VA 20190 >>>> >>>> VerisignInc.com >>>> >>>> On Jan 13, 2015, at 3:18 AM, Michael Holloway >>>> >>> > wrote: >>>> >>>>> Hi all >>>>> >>>>> Just a thought; would it not be more appropriate to facilitate >>>>> this on the TMDB by adding a lookup based on label. This could >>>>> return a simple true/false value, or all the info returned on a >>>>> CNIS lookup exception notice_id etc. >>>>> >>>>> The problem with having and post claims service on the EPP server >>>>> without changing the phase name is that the EPP client then has to >>>>> decide when /not/ to submit claims data in a domain_create if the >>>>> domain has a claim. As it is, various registries are extending the >>>>> claims periods past 90 days, so its contradictory to have extended >>>>> claims and post claims defined the same way in the query but >>>>> without a defined (or facilitated) way to differentiate the >>>>> requirement for a domain_create. >>>>> >>>>> I would be more comfortable with defining a specific sub_phase for >>>>> the purpose, or even better skipping the middle man and going >>>>> straight to the TMDB. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> *Michael Holloway >>>>> Senior Systems Administrator**| Com Laude* >>>>> E: michael.holloway@comlaude.com >>>>> >>>>> >>>>> >>>>> On 01/13/2015 04:04 AM, Tran, Trung wrote: >>>>>> This works for me, Jim. Though it’s not often, we have cases >>>>>> where change in ownership of a domain might not occur if there’s >>>>>> trademark against the name. So a potential registrant might not >>>>>> want to buy an existing registered name if there’s trademark >>>>>> against it in the TMCH. >>>>>> >>>>>> Thanks, >>>>>> Trung >>>>>> From: , James >>>>> > >>>>>> Date: Friday, January 9, 2015 at 11:27 AM >>>>>> To: Jody Kolker > >>>>>> Cc: Francisco Obispo >>>>> >, "eppext@ietf.org >>>>>> " >>>>> >, "Tran, Trung" >>>>> > >>>>>> Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a >>>>>> "Claims Service" post the Claims Phase >>>>>> >>>>>> Jody, >>>>>> >>>>>> I believe that passing the active phase is more straight >>>>>> forward as opposed to defining a special sub-phase like >>>>>> “extended" to drive the behavior. Having the claims check >>>>>> return “exists=true” only when a claims notice is required on >>>>>> the create based on the active phase should be able to handle >>>>>> the use case of releasing domains post the claims phase and >>>>>> also applies to the claims phase. All names that have >>>>>> matching trademarks during the claims phase will require a >>>>>> claims notice on create, so the behavior is consistent. >>>>>> >>>>>> I’m still not sure why a client would want to know whether >>>>>> there is a matching trademark when a claims notice is not >>>>>> required on the create. Does anyone see a need for this? >>>>>> Since the “claims” phase would always return “exists=true” >>>>>> for domains that have matching trademarks, a client could >>>>>> pass the “claims” phase when the active phase is not the >>>>>> “claims” phase to obtain this information. Of course servers >>>>>> would need to support referencing a past “claims” phase to >>>>>> support this use case. The change in the text should support >>>>>> the logic that I previously posted before, which I extend to >>>>>> support addressing the optional matching trademark past the >>>>>> claims phase use case. Is this use case really needed? >>>>>> >>>>>> 1. During claims phase with a claims check command >>>>>> 1. If domain has matching trademark >>>>>> 1. return exists=true >>>>>> 2. else >>>>>> 1. return exists=false >>>>>> 2. During post claims phase with a claims check command >>>>>> 1. If domain was released post claims phase start and is >>>>>> within 90 days of release and has matching trademark >>>>>> 1. return exists=true >>>>>> 2. else >>>>>> 1. return exists=false >>>>>> 3. *During post claims phase with a claims phase check and >>>>>> passing “claims” as the phase (optional matching >>>>>> trademark past the claims phase use case)* >>>>>> 1. *If domains has matching trademark * >>>>>> 1. *return exists=true* >>>>>> 2. *else* >>>>>> 1. *return exists=false* >>>>>> >>>>>> >>>>>> 1. During claims phase with a create command >>>>>> 1. If domain has matching trademark >>>>>> 1. claims notice is required >>>>>> 2. else >>>>>> 1. claims notice is NOT required >>>>>> 2. During post claims phase with a create command >>>>>> 1. If domain was released post claims phase start and is >>>>>> within 90 days of release and has matching trademark >>>>>> return >>>>>> 1. claims notice is required >>>>>> 2. else >>>>>> 1. claims notice is NOT required >>>>>> >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> — >>>>>> >>>>>> JG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *James Gould >>>>>> *Distinguished Engineer >>>>>> jgould@Verisign.com >>>>>> >>>>>> 703-948-3271 >>>>>> 12061 Bluemont Way >>>>>> Reston, VA 20190 >>>>>> >>>>>> VerisignInc.com >>>>>> >>>>>> >>>>>> On Jan 8, 2015, at 4:50 PM, Jody Kolker >>>>> > wrote: >>>>>> >>>>>>> From Francisco: >>>>>>> Thanks Jim for bringing this to the eppext. This will >>>>>>> definitely help the post claims phase. >>>>>>> With the wording changes, is there still a way to determine >>>>>>> if there’s a trademark against the name regardless on >>>>>>> whether or not the claims ack is needed in the create domain? >>>>>>> This could be accomplished by leaving the “claims” >>>>>>> implementation as it is currently and introducing a >>>>>>> sub-phase for claims named “extended”. When the sup-phase >>>>>>> of “extended” is passed the results from Jim’s earlier email >>>>>>> would be below. >>>>>>> >>>>>>> 1. During claims phase with a claims check command or post >>>>>>> claims phase without a sub-phase of “extended” >>>>>>> 1. If domain has matching trademark >>>>>>> 1. return exists=true >>>>>>> 2. else >>>>>>> 1. return exists=false >>>>>>> 2. During post claims phase with a claims check command >>>>>>> with a sub-phase of “extended” >>>>>>> 1. If domain was released post claims phase start and >>>>>>> is within 90 days of release and has matching trademark >>>>>>> 1. return exists=true >>>>>>> 2. else >>>>>>> 1. return exists=false >>>>>>> >>>>>>> 1. During claims phase with a create command or post claims >>>>>>> phase without a sub-phase of “extended” >>>>>>> 1. If domain has matching trademark >>>>>>> 1. claims notice is required >>>>>>> 2. else >>>>>>> 1. claims notice is NOT required >>>>>>> 2. During post claims phase with a create command with a >>>>>>> sub-phase of “extended” >>>>>>> 1. If domain was released post claims phase start and >>>>>>> is within 90 days of release and has matching >>>>>>> trademark return >>>>>>> 1. claims notice is required >>>>>>> 2. else >>>>>>> 1. claims notice is NOT required >>>>>>> >>>>>>> This would still allow a registrar to determine if a claim >>>>>>> currently exists on a domain when a claim period does not >>>>>>> exist for the TLD (the current implementation). From a >>>>>>> registrar perspective, I’m not sure if determining if a >>>>>>> domain has a claim when all claims periods have expired is >>>>>>> needed. This implementation also would require additional >>>>>>> work by all registrars to support if adopted, while the >>>>>>> implementation from Jim’s first post would require only >>>>>>> updates by the registries which would be better for >>>>>>> widespread adoption. >>>>>>> Thoughts? >>>>>>> Thanks, >>>>>>> Jody Kolker >>>>>>> 319-294-3933 (office) >>>>>>> 319-329-9805 (mobile) Please contact my direct supervisor >>>>>>> Charles Beadnall (cbeadnall@godaddy.com >>>>>>> ) with any feedback. >>>>>>> This email message and any attachments hereto is intended >>>>>>> for use only by the addressee(s) named herein and may >>>>>>> contain confidential information. If you have received this >>>>>>> email in error, please immediately notify the sender and >>>>>>> permanently delete the original and any copy of this message >>>>>>> and its attachments. >>>>>>> *From:*Gould, James [mailto:JGould@verisign.com] >>>>>>> *Sent:*Thursday, January 08, 2015 12:24 PM >>>>>>> *To:*Francisco Obispo >>>>>>> *Cc:*Jody Kolker;eppext@ietf.org ; >>>>>>> Tran, Trung >>>>>>> *Subject:*Re: [eppext] draft-ietf-eppext-launchphase Support >>>>>>> for a "Claims Service" post the Claims Phase >>>>>>> Francisco, >>>>>>> I would have gone with the sub-phase approach as well, since >>>>>>> if the behavior between the two claims phases are consistent >>>>>>> (e.g. requirement for claims check and claims notice) I’m >>>>>>> not sure the value in defining a new top-level phase name. >>>>>>> Is there a material behavior change between the two phases >>>>>>> and is the concept of an extended claims phase a generic use >>>>>>> case? We have stuck with the standard set of “sunrise”, >>>>>>> “claims”, and “open” phases. Have others utilized the use >>>>>>> of sub-phases or have created custom top-level phase names >>>>>>> to meet their needs? If so, can you share your scheme? It >>>>>>> would be good to know if there are any common patterns. >>>>>>> Thanks, >>>>>>> — >>>>>>> >>>>>>> JG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *James Gould >>>>>>> *Distinguished Engineer >>>>>>> jgould@Verisign.com >>>>>>> >>>>>>> 703-948-3271 >>>>>>> 12061 Bluemont Way >>>>>>> Reston, VA 20190 >>>>>>> >>>>>>> VerisignInc.com >>>>>>> >>>>>>> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> SHOULD contain the value of >>>>>>> "claims" to indicate the >>>>>>> claims launch phase. A value other >>>>>>> than "claims" MAY be used to >>>>>>> pass the claims notice for domain names >>>>>>> outside of the claims phase. >>>>>>> >>>>>>> Once a TLD has ended the mandatory 90 day period of >>>>>>> “claims” a registry might decide to call it something else. >>>>>>> We are not supporting extended claims, but we had to >>>>>>> support an extended sunrise for the names on the ICANN >>>>>>> names-collision block list (30 day period instead of a >>>>>>> 60 day end-date sunrise), and we initially thought about >>>>>>> having a phase called “sunrise” with a sub-phase called >>>>>>> “extended” but we thought it would be too complicated >>>>>>> for RARs to change their code, so we decided just to >>>>>>> trigger it by calling the phase “sunsrise”, but in >>>>>>> reality, a registry can call it anything they want in >>>>>>> order to support it, because they are different things. >>>>>>> Since there is no guidance on what the phases should be >>>>>>> called, it seems like we’re going to end up with >>>>>>> discrete phase names for anything that is not: claims or >>>>>>> sunrise. >>>>>>> >>>>>>> On Jan 8, 2015, at 11:35 AM, Gould, James >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>> What do you mean by the extended claims phase? Is >>>>>>> there a past mail list thread on this or is this a >>>>>>> new issue? Please clarify. >>>>>>> >>>>>>> *Francisco Obispo* >>>>>>> CTO - Registry Operations >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2161 San Joaquin Hills Rd. >>>>>>> Newport Beach, CA, 92660 >>>>>>> off. +1.345.749.6284 >>>>>>> fax. +1.345.746.6263 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EppExt mailing list >>>>>> EppExt@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>> _______________________________________________ >>>>> EppExt mailing list >>>>> EppExt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/eppext >>>> >>> >> >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --------------030901050102090804080808 Content-Type: multipart/related; boundary="------------010402070602050405060207" --------------010402070602050405060207 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks James

From a registrar perspective I would say this solves the issue without the risk of breaking working clients. I would be interested to hear the opinion of anyone [else] representing registries here whether they would support the extra type attribute since its essentially optional extra, or whether they would prefer to support using he existing schema.

I think in the case of the latter it would suggest using Claims check on phases outside of "claims" (e.g. "open"),  and then some guidance would need to be offered (in the draft) to define exactly what the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availability) period during the claims period; and therefore when to and when not to use the "open" phase. Some minor wording changes would be required in 3.1.1 Claims check form to change it from `The launch phase that SHOULD be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Trademark check form, so hopefully we can agree with that! That would be my vote anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the past “claims” phase in the claims check command to support Trung’s request.  The issue is that some clients are hard coding “claims” as the phase in the claims check command and currently there is little to no support for the claims check command outside of the “claims” phase, so clients may inadvertently go through the claims process when it is not required or even potentially rejected on create.  I see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not crazy about making an XML schema change, we may be able to tweak things to support both the the claims check outside of the “claims” phase and also support Trung’s request to determine whether or not a trademark matches a name independent of the requirement for a claims notice for other use cases like the resale of domain names.

We already support a “type" attribute in the <launch:check> element, section 3.1, to define the check form of the command, which currently support “claims” and “avail” for the Claims Check Form and the Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return “exists=1” if there is a matching trademark and a claims notice is required on create, per the proposed check changes.  We could add a Trademark Check Form (e.g. add section 3.1.3) that is indicated by setting the “type” attribute to “trademark”.  The interface for the Trademark Check Form is consistent with the Claims Check Form, except the <launch:phase> element is not applicable, so therefore in the schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademarks to return the same response as with the Claims Check Form.  The <launch:phase> element would still be required for the Claims Check Form and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the server is determined by server policy, so the Trademark Check Form would is an option but is not required.  The check command using the Trademark Check Form would look like:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
   C:     type=“trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be added along with some text changes on the “trademark” value for the “type” attribute in section 3.1, <enumeration value=“trademark”/> would need to be added to the checkFormType in the schema, and minOccurs=“0” would need to be added to the “phase” element of checkType in the schema.    

Let me know your thoughts on this option. 

Thanks,

—


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:

Michael,

I provide feedback inline below.  

—

JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from.

The use case for the claims check post the claims phase is used to address the release of domain names that did not go through 90 days of claims, which I believe is a modified version of your #2 below.  

Let’s take the three basic phases defined in draft-ietf-eppext-launchphase as an example with sunrise, claims, and open.  We can pretty much remove the sunrise phase from the example for now, so let’s focus on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a claims check is done with “open” as the phase, the response would be exists=“0”, since there is no requirement to provide the claims notice on create.  If reserved.tld was released during the “open” phase, then a claims check on reserved.tld, with “open” as the phase, the response would be exists=“1”, since a claims notice is required on create.  Based on Trung’s use case, a client may want to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client can send a claims check with the phase as “claims” to get that answer.    



Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domains for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create without claims]

If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate.


Based on the updated text, the client will only receive a claims check response with exists=“1” if “create with claims form” is required.  The updated text does not support #4, since the only time that “exists=0” is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic of passing special attributes or sub-phases to get the answer that is needed, which is whether a claims notice is required on create.  Trung use case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domain name independent of whether a claims notice is required on create, so passing “claims” as the phase past the “claims” phase may support that.  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true ## The claims exists but it is NOT required on domain_create
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return ## How does the client know if 90 days has passed (extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / TMDB was worked out a couple of years ago, where there was a desire to not make the CNIS the critical path for the majority of the registrations.  The agreement was for the registries to provide the claims check service and enforce the claims notice on create based on a feed of trademark labels from the TMDB to the registries.  

The proposal is to support the claims service post the “claims” phase by passing the active phase to the server and the server will return whether or not the claims notice is required based on a combination of a matching trademark and whether the domain name already went through 90 days of the claims service.  From a client perspective it means utilizing the claims check in a similar fashion during and post the claims phase.  The use case brought up by Trung was more of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name independent of the requirement for passing the claims notice.  In that case, the proposal is to pass “claims” as the phase independent of the active phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.  

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

—

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.
 
With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
 
  1. During claims phase with a create command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
 
From: Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.  
 
Thanks,
 
—
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase.  
 
 
Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



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



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



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


--------------010402070602050405060207 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vL JtmQhEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjT DnhDEEWC1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBg wDFuRRaXOiUlhX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2Thp UA4w9Pf39/X19fT0UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvCl pSFvipAimGy1wQmrMgV4aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZn ZGSMLYejx4biEautrQ3eUlNTLUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwo MYA5nZ+duXiyur6ju88u5ZL5s+ffmJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMyg UvRoijp7AnuPXdhz9PyeyvPI7khxqtoUyTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIe aOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+ MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUYu3T5MoyxMZEDbJTK81fWlR242NrrcHsd ToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5KhL1kjDMBbMQMDKa6pgaE6enpggp4 r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg8NF7Crc99XNeG/ZQIvkQ3xt1 bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SFSVPIxDKpBVuYQOABMtg3 f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+aw+1xuLQ1Ag9s1p9u C9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhDED8wSxgTYLsq LihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z0S70CNsj wiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4eQOP cELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT 6T5+saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1o PoiPDXtouXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z 3HTYGyVlH5+oalTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScx ZZBtnd0lr31oF9G0l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEY B2jEkLZ91vDtONgwQhgjZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjR rCkTYo5c/fK7yshlTXVkc739+RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffr UI5Aqf7SNz6NuTpInl2xQHlXKJDlCZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z +lCdcbChKoAJY7SBV9PUobMTE3VwQ9MeX/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2cea NI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL 5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/FdrdgkvZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6 dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQLMor+WhVsSozwfVnMdWJ2DpcDZF0M Elj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUpKzYoR7UX1IS7qg+I62+BLALV UGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw1oN3znOkZTsyJg3+pecQ h3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6fG8frR4qH2xaXZzl 12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaUfDqolJR9FHNn 8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/Ly9ASKFfQ soWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg6+nt xeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNc RkE09LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9 So6/0ZoloVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAl DIgT6qCijr9RpfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKF S+dOSHMNqAO+OgSL74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgA Q6EYJGJEKSpORxx/YzZWzlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu3 7FUpnnAKfqWFsEbURI0KfQFs+aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc 4NWWGWZPtG6FUO1Lbm91c9emdypkWT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRs w/SPCBs649ejosWLyePA69W/jD6+aNL0TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOl v+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eBLq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rv jfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHtheMFApjuwY+19N+XlMEIdwrjCCAYzMzPB lmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfrxU8bLnaElNzqRkDukuUTUx8TddxT 0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPxiLiyxRyQADa0QH6rra19b88e fkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/NyN782J1ZGT4FTBcuDjP9 fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI4NQUqa0NNWkqPMIb pAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2eOTHpM8vdh3+ ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzYu3r16ifl 5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfnFWSn MYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqc NpaYTgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtk TMATCfNyc/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55Mkdw IOGi/IgB4GRgxJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav 8CIKCCnSNuPHqTEu2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4 pS5wGNCFnE4CHH5wzLfujS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VX XyVZ298iRFFR0dKlS+k0b1966SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQF U6euf/ppGma6SLVz586TJ0/Sj/DO24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABj QEVFxfPPP09+jxgMMKCKFpCBIoNf0fjNYPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7 oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqqFVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFB oYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxItm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBX ZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQexTCSw616MzcyJwIZr8UqYoQHJZqQ0 0KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwqbMYsASa82UljgCjbzIloGKrp R4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNauLDPXNBQ2Y5Zsb2aaETTQ jTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McYO3syWGgnRNkB29eh bZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCxJ+ONl8ojtTAJ IWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1ol2MUFaQ GrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8JGPDD ecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --------------010402070602050405060207-- --------------030901050102090804080808-- From nobody Wed Jan 21 07:38:43 2015 Return-Path: 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 2D3BD1A1AE2 for ; Wed, 21 Jan 2015 07:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 GSKCEBEKDtax for ; Wed, 21 Jan 2015 07:38:35 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC851A1A6F for ; Wed, 21 Jan 2015 07:38:35 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id v8so33314693qal.7 for ; Wed, 21 Jan 2015 07:38:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=2ttQ0Os1QyHeyKQZhxFCAimt+YLPi+Xh4+e5p6ztmNs=; b=I1Q99CCv86++f+ON1C5pDwumJDMI6KtAdkxzX0ZPZhReyRrL0aPRy30EiJXDWDldKG TjHUNlj7YhLE7zz4xj08pgz41w8Y0f3RsKJ/oHEgAnnzkDGenIfvCAhfLoaVZCZUTAjS 8sdojQmd9Hs26SUBHbnkkf9ML65DnNjoSceO1qnDHM2LXkWNqxvwVo3JWqnUeKhthhUB Eh3NLd5gnBhRoLT9ZvbIpNLk3mfq1J+BLt6E99rVIh5cYy4G+4BFvHSOGN9xnWzBdUwz cSFsMzqlcgX2/xBo4o8pXAqO7T/Ysh0dJ/5fabf23dMQlwVvJ04Rj8KAwM2u6t988JDj SikA== X-Gm-Message-State: ALoCoQmgRsPWqnOYuUv5/Q2VUUqfutTuRqm783+YYZ/iKZLHaFBtONOtKLBEsZbxTVqZXcRaK1gV X-Received: by 10.140.28.54 with SMTP id 51mr23869684qgy.6.1421854714916; Wed, 21 Jan 2015 07:38:34 -0800 (PST) Received: from jgalvin-lt.local ([68.50.155.245]) by mx.google.com with ESMTPSA id 7sm3602802qak.20.2015.01.21.07.38.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jan 2015 07:38:34 -0800 (PST) Message-ID: <54BFC82E.1070208@elistx.com> Date: Wed, 21 Jan 2015 10:39:26 -0500 From: James Galvin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [eppext] moving documents along X-BeenThere: eppext@ietf.org 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: Wed, 21 Jan 2015 15:38:41 -0000 Speaking as Chair, I want to bring folks up to date on where I believe we are. Please do speak up if you disagree or have any corrections. We have 5 documents in our working group. 1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible Provisioning Protocol If you've been tracking the status updates from the RFC Editor on the list then you know this document is close to publication as an RFC. Scott Hollenbeck has been doing his part to move this along. There is no action for the working group at this time. 2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP) There has been very little discussion on the mailing list about this document. Andrew Sullivan posted some extensive comments to which there has been limited response. It's tough to declare consensus with so little discussion. It would be helpful if folks would review the document and comments and post at least a "no objection". 3. draft-ietf-eppext-keyrelay-01 Relay Extension for the Extensible Provisioning Protocol There has been lively discussion here and we appear to have a difference of opinion on a technical point. We very much need to hear from other folks. Please review the thread and let everyone know what you think. 4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) I believe we're close to consensus on this document. There's been some discussion but nothing too contentious as far as I can see. I'm expecting Jim Gould to submit a revised document in the not too distant future and we'll review where we are at that time. 5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping This document has expired and is waiting for the author to resubmit. There was one change proposed on the mailing list last year that needs to be incorporated in the revision. At one time there was concern about the relationship between this document and the launchphase document but I don't believe that concern exists any more. I suppose it's fair to ask if the working group is still interested in publishing this document. If so, I'll press Gustavo to submit a revised document and we can review where we are at that time. Comments and corrections are welcome! Jim From nobody Wed Jan 21 08:19:00 2015 Return-Path: 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 914B41A1AFA for ; Wed, 21 Jan 2015 08:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 z5DsvRa6gghf for ; Wed, 21 Jan 2015 08:18:54 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CAC1A1B0B for ; Wed, 21 Jan 2015 08:18:47 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKVL/RZ0MAOHxWxYyK0qB2uEohF5pvmPjX@postini.com; Wed, 21 Jan 2015 08:18:48 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0LGIkFr024067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 11:18:46 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 21 Jan 2015 11:18:45 -0500 From: "Gould, James" To: James Galvin Thread-Topic: [eppext] moving documents along Thread-Index: AQHQNZBXLn9djlD9hECwzjkZ6yfo4JzLFIsA Date: Wed, 21 Jan 2015 16:18:44 +0000 Message-ID: <02C73E30-8495-4C59-9CC4-A8F7A23D92EA@verisign.com> References: <54BFC82E.1070208@elistx.com> In-Reply-To: <54BFC82E.1070208@elistx.com> 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_02C73E3084954C599CC4A8F7A23D92EAverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: eppext Subject: Re: [eppext] moving documents along X-BeenThere: eppext@ietf.org 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: Wed, 21 Jan 2015 16:18:56 -0000 --_004_02C73E3084954C599CC4A8F7A23D92EAverisigncom_ Content-Type: multipart/alternative; boundary="_000_02C73E3084954C599CC4A8F7A23D92EAverisigncom_" --_000_02C73E3084954C599CC4A8F7A23D92EAverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim, My feedback is included below. =97 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 On Jan 21, 2015, at 10:39 AM, James Galvin > wrote: Speaking as Chair, I want to bring folks up to date on where I believe we a= re. Please do speak up if you disagree or have any corrections. We have 5 documents in our working group. 1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible Provision= ing Protocol If you've been tracking the status updates from the RFC Editor on the list = then you know this document is close to publication as an RFC. Scott Hollen= beck has been doing his part to move this along. There is no action for th= e working group at this time. 2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping Extens= ion for the Extensible Provisioning Protocol (EPP) There has been very little discussion on the mailing list about this docume= nt. Andrew Sullivan posted some extensive comments to which there has been= limited response. It's tough to declare consensus with so little discussion. It would be hel= pful if folks would review the document and comments and post at least a "n= o objection". My objections of not having a mechanism or standard for a client to know wh= at to pass for the table identifier () is being addressed by cr= eating a separate EPP Mapping called the IDN Table EPP Mapping. We have a = version of the IDN Table EPP Mapping that is pretty far along and is hopefu= lly close to posting as a 00 draft. Our goal would be to include the IDN T= able EPP Mapping in a re-charting of the working group. With that in mind,= I have =93no objection=94 to moving forward with the Internationalized Dom= ain Name Mapping Extension. 3. draft-ietf-eppext-keyrelay-01 Relay Extension for the Extensible Provisi= oning Protocol There has been lively discussion here and we appear to have a difference of= opinion on a technical point. We very much need to hear from other folks.= Please review the thread and let everyone know what you think. Yes, I encourage others to weigh in on this to break the difference in opin= ion. 4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the Extensible= Provisioning Protocol (EPP) I believe we're close to consensus on this document. There's been some dis= cussion but nothing too contentious as far as I can see. I'm expecting Jim= Gould to submit a revised document in the not too distant future and we'll= review where we are at that time. I am in the process of revising the draft to add the =93Trademark Check For= m=94, to update the text in the "Claims Check Form" and the "Claims Create = Form=94, as discussed on the list. I am including the Implementation Stat= us section as well to address the action item from the IETF-91 WG Meeting. = It would be great to receive additional input for the Implementation Statu= s section, so please reply to my list message publicly or privately to be i= ncluded in draft-ietf-eppext-launchphase-03. 5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping This document has expired and is waiting for the author to resubmit. There = was one change proposed on the mailing list last year that needs to be inco= rporated in the revision. At one time there was concern about the relationship between this document = and the launchphase document but I don't believe that concern exists any mo= re. I suppose it's fair to ask if the working group is still interested in publ= ishing this document. If so, I'll press Gustavo to submit a revised docume= nt and we can review where we are at that time. I would like this document to move forward along with draft-ietf-eppext-lau= nchphase. I provided Gustavo privately my Implementation Status input for = inclusion in draft-ietf-eppext-tmch-smd. I encourage others to do the same= . Comments and corrections are welcome! Jim _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_02C73E3084954C599CC4A8F7A23D92EAverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Jim,

My feedback is included below.

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 21, 2015, at 10:39 AM, James Galvin <galvin@elistx.com> wrote:

Speaking as Chair, I want to bring folks up to da= te on where I believe we are.  Please do speak up if you disagree or h= ave any corrections.

We have 5 documents in our working group.


1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible Provision= ing Protocol

If you've been tracking the status updates from the RFC Editor on the list = then you know this document is close to publication as an RFC. Scott Hollen= beck has been doing his part to move this along.  There is no action f= or the working group at this time.


2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping Extens= ion for the Extensible Provisioning Protocol (EPP)

There has been very little discussion on the mailing list about this docume= nt.  Andrew Sullivan posted some extensive comments to which there has= been limited response.

It's tough to declare consensus with so little discussion.  It would b= e helpful if folks would review the document and comments and post at least= a "no objection".



My objections of not having a mechanism or standard for a client to kn= ow what to pass for the table identifier  (<idn:table>) is being= addressed by creating a separate EPP Mapping called the IDN Table EPP Mapp= ing.  We have a version of the IDN Table EPP Mapping that is pretty far along and is hopefully close to posting as a 00= draft.  Our goal would be to include the IDN Table EPP Mapping in a r= e-charting of the working group.  With that in mind, I have =93no obje= ction=94 to moving forward with the Internationalized Domain Name Mapping Extension.  

3. draft-ietf-eppext-keyrelay-01 Relay Extension for the Extensible Provisioning Protocol

There has been lively discussion here and we appear to have a difference of= opinion on a technical point.  We very much need to hear from other f= olks.  Please review the thread and let everyone know what you think.<= br>

Yes, I encourage others to weigh in on this to break the difference in= opinion.  


4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the Extensible= Provisioning Protocol (EPP)

I believe we're close to consensus on this document.  There's been som= e discussion but nothing too contentious as far as I can see.  I'm exp= ecting Jim Gould to submit a revised document in the not too distant future= and we'll review where we are at that time.


I am in the process of revising the draft to add the =93Trademark Chec= k Form=94, to update the text in the "Claims Check Form" and the = "Claims Create Form=94, as discussed on the list.   I am includin= g the Implementation Status section as well to address the action item from the IETF-91 WG Meeting.  It would be great to receiv= e additional input for the Implementation Status section, so please reply t= o my list message publicly or privately to be included in draft-ietf-eppext= -launchphase-03.  


5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping

This document has expired and is waiting for the author to resubmit. There = was one change proposed on the mailing list last year that needs to be inco= rporated in the revision.

At one time there was concern about the relationship between this document = and the launchphase document but I don't believe that concern exists any mo= re.

I suppose it's fair to ask if the working group is still interested in publ= ishing this document.  If so, I'll press Gustavo to submit a revised d= ocument and we can review where we are at that time.


I would like this document to move forward along with draft-ietf-eppex= t-launchphase.  I provided Gustavo privately my Implementation Status = input for inclusion in draft-ietf-eppext-tmch-smd.  I encourage others= to do the same.  


Comments and corrections are welcome!

Jim

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

--_000_02C73E3084954C599CC4A8F7A23D92EAverisigncom_-- --_004_02C73E3084954C599CC4A8F7A23D92EAverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Wed, 21 Jan 2015 16:18:44 GMT"; modification-date="Wed, 21 Jan 2015 16:18:44 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_02C73E3084954C599CC4A8F7A23D92EAverisigncom_-- From nobody Wed Jan 21 08:31:06 2015 Return-Path: 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 5E1D01A1B21 for ; Wed, 21 Jan 2015 08:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 cDR-aQ8usNIz for ; Wed, 21 Jan 2015 08:30:56 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924001A1B1C for ; Wed, 21 Jan 2015 08:30:51 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKVL/UOzkS4IgfceOgZdexL0NlWU5ZiJ81@postini.com; Wed, 21 Jan 2015 08:30:52 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0LGUoYx004175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Jan 2015 11:30:50 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Wed, 21 Jan 2015 11:30:49 -0500 From: "Gould, James" To: Michael Holloway Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgIAAF1sAgAAI+ACACuPxAIABjWoAgAAvWQA= Date: Wed, 21 Jan 2015 16:30:48 +0000 Message-ID: <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com> References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> <54BFAC7A.7090500@comlaude.com> In-Reply-To: <54BFAC7A.7090500@comlaude.com> 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_378DCFEE69D7468EB928EE35378FE875verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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: Wed, 21 Jan 2015 16:31:04 -0000 --_004_378DCFEE69D7468EB928EE35378FE875verisigncom_ Content-Type: multipart/alternative; boundary="_000_378DCFEE69D7468EB928EE35378FE875verisigncom_" --_000_378DCFEE69D7468EB928EE35378FE875verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, How about just using a more generic description of the eleme= nt in both the Claims Check Form of section 3.1.1 and the Claims Create For= m of section 3.3.2, since both forms can be executed outside of the =93clai= ms=94 phase? Something like the description from the General Create Form o= f section 3.3.3: Contains the value of the active launch phas= e of the server. The server SHOULD validate the value against the active s= erver launch phase. =97 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 On Jan 21, 2015, at 8:41 AM, Michael Holloway > wrote: Thanks James >From a registrar perspective I would say this solves the issue without the = risk of breaking working clients. I would be interested to hear the opinion= of anyone [else] representing registries here whether they would support t= he extra type attribute since its essentially optional extra, or whether th= ey would prefer to support using he existing schema. I think in the case of the latter it would suggest using Claims check on ph= ases outside of "claims" (e.g. "open"), and then some guidance would need = to be offered (in the draft) to define exactly what the "open" phase is; .I= .E is it the period after claims, or is the 'open registration' (aka genera= l availability) period during the claims period; and therefore when to and = when not to use the "open" phase. Some minor wording changes would be requi= red in 3.1.1 Claims check form to change it from `The launch phase that SHO= ULD be "claims"` , to "MAY", perhaps with a bit more info. In light of the above I think it would be far simpler to go with the Tradem= ark check form, so hopefully we can agree with that! That would be my vote = anyway! Regards, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/20/2015 02:58 PM, Gould, James wrote: All, I had a private thread with some about the proposal of referencing the past= =93claims=94 phase in the claims check command to support Trung=92s reques= t. The issue is that some clients are hard coding =93claims=94 as the phas= e in the claims check command and currently there is little to no support f= or the claims check command outside of the =93claims=94 phase, so clients m= ay inadvertently go through the claims process when it is not required or e= ven potentially rejected on create. I see the concern with adding a new fe= ature that may inadvertently cause interface issues. Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a = name independent of the requirement for a claims notice for other use cases= like the resale of domain names. We already support a =93type" attribute in the element, sect= ion 3.1, to define the check form of the command, which currently support = =93claims=94 and =93avail=94 for the Claims Check Form and the Availability= Check Form, respectively. The default form is the Claims Check Form, whic= h is updated to return =93exists=3D1=94 if there is a matching trademark an= d a claims notice is required on create, per the proposed check changes. W= e could add a Trademark Check Form (e.g. add section 3.1.3) that is indicat= ed by setting the =93type=94 attribute to =93trademark=94. The interface f= or the Trademark Check Form is consistent with the Claims Check Form, excep= t the element is not applicable, so therefore in the schema = we would make the element optional, and the server would onl= y match the domain to the matching set of trademarks to return the same res= ponse as with the Claims Check Form. The element would stil= l be required for the Claims Check Form and the Availability Check Form bas= ed on the draft text. As stated in section 3.1, the forms supported by the= server is determined by server policy, so the Trademark Check Form would i= s an option but is not required. The check command using the Trademark Che= ck Form would look like: C: C: C: C: C: C: example1.tld C: example2.tld C: C: C: C: C: C: ABC-12345 C: C: To support this, section 3.1.3 Trademark Check Form would need to be added = along with some text changes on the =93trademark=94 value for the =93type= =94 attribute in section 3.1, would = need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema. Let me know your thoughts on this option. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 10:40 AM, Gould, James > wrote: Michael, I provide feedback inline below. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 10:08 AM, Michael Holloway > wrote: Hi Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrations.= The post claims lookup seems to be aimed at determining, for information p= urposes only (without "acking" in the create), whether or not there is a tr= ademark registered against the term (i.e. label only) therefore there is no= reason to check claims via TLD. This is a little OT anyway (my fault sorry= ), but hopefully you see where I am coming from. The use case for the claims check post the claims phase is used to address = the release of domain names that did not go through 90 days of claims, whic= h I believe is a modified version of your #2 below. Let=92s take the three basic phases defined in draft-ietf-eppext-launchphas= e as an example with sunrise, claims, and open. We can pretty much remove = the sunrise phase from the example for now, so let=92s focus on the claims = and open phases. Assuming that claims.tld is available through sunrise and= the claims phase, so if a claims check is done with =93open=94 as the phas= e, the response would be exists=3D=930=94, since there is no requirement to= provide the claims notice on create. If reserved.tld was released during = the =93open=94 phase, then a claims check on reserved.tld, with =93open=94 = as the phase, the response would be exists=3D=931=94, since a claims notice= is required on create. Based on Trung=92s use case, a client may want to = know whether or not there is a trademark on the domain name independent of = when the domain name is released, so the client can send a claims check wit= h the phase as =93claims=94 to get that answer. Back to LaunchPhase: my concern with simply using the "claims" phase is tha= t it can cause ambiguity, take the following four phase statuses, and compa= re with the logic below (to which I commented in underlined red) 1) A registry must operate a 90 days claims phase 2) A registry must operate 90 days extended claims period on domains that a= re released at a later date (collisions etc, and I don't know what may be c= oming up in the future) 3) A registry may operate a continued claims phase past the 90 domains for = all domains. [create with claims form] 4) [new]: A registry may operate a post claims (matching trademark past the= claims phase use case) [create without claims] If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create f= orm would be incorrect at this point despite receiving claims=3Dtrue. This = is why I suggest a different sub_phase should be used, OR a different flag = added (more complex of course) to differentiate. Based on the updated text, the client will only receive a claims check resp= onse with exists=3D=931=94 if =93create with claims form=94 is required. T= he updated text does not support #4, since the only time that =93exists=3D0= =94 is if a claims notice is required. This way a client can continue to u= se the claims check without any extra logic of passing special attributes o= r sub-phases to get the answer that is needed, which is whether a claims no= tice is required on create. Trung use case is an exception to the rule, wh= ere a client wants to know whether there is a matching trademark for the do= main name independent of whether a claims notice is required on create, so = passing =93claims=94 as the phase past the =93claims=94 phase may support t= hat. Let me know whether or not this helps. I hope this makes sense; and apologies if I am missing something fundamenta= l! Cheers, Michael 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue ## The claims exists but it is NOT require= d on domain_create * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return ## How does the client know= if 90 days has passed (extended / post claims) or not without external sou= rce? * claims notice is required * else * claims notice is NOT required Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 02:44 PM, Gould, James wrote: Michael, The split out of the responsibility of the registries and the CNIS / TMDB w= as worked out a couple of years ago, where there was a desire to not make t= he CNIS the critical path for the majority of the registrations. The agree= ment was for the registries to provide the claims check service and enforce= the claims notice on create based on a feed of trademark labels from the T= MDB to the registries. The proposal is to support the claims service post the =93claims=94 phase b= y passing the active phase to the server and the server will return whether= or not the claims notice is required based on a combination of a matching = trademark and whether the domain name already went through 90 days of the c= laims service. From a client perspective it means utilizing the claims che= ck in a similar fashion during and post the claims phase. The use case bro= ught up by Trung was more of an exception to the rule, in the client wantin= g to know whether there is a matching trademark for a domain name independe= nt of the requirement for passing the claims notice. In that case, the pro= posal is to pass =93claims=94 as the phase independent of the active phase = to get a true or false answer to whether a trademark matches the domain nam= e. Do the proposals work for you? Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 3:18 AM, Michael Holloway > wrote: Hi all Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= . The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not t= o submit claims data in a domain_create if the domain has a claim. As it is= , various registries are extending the claims periods past 90 days, so its = contradictory to have extended claims and post claims defined the same way = in the query but without a defined (or facilitated) way to differentiate th= e requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 JG [X] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_378DCFEE69D7468EB928EE35378FE875verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <74B680E410702A40997BCC8FF9C54FB2@verisign.com> Content-Transfer-Encoding: quoted-printable Michael,

How about just using a more generic description of the <launch:phas= e> element in both the Claims Check Form of section 3.1.1 and the Claims= Create Form of section 3.3.2, since both forms can be executed outside of = the =93claims=94 phase?  Something like the description from the General Create Form of section 3.3.3:

              <launch:phase> =   Contains the value of the active launch phase of the server.  T= he server SHOULD validate the value against the active server launch phase.=


=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 21, 2015, at 8:41 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:
Thanks James

>From a registrar perspective I would say this solves the issue without the = risk of breaking working clients. I would be interested to hear the opinion= of anyone [else] representing registries here whether they would support t= he extra type attribute since its essentially optional extra, or whether they would prefer to support using = he existing schema.

I think in the case of the latter it would suggest using Claims check on ph= ases outside of "claims" (e.g. "open"),  and then = some guidance would need to be offered (in the draft) to define exactly wha= t the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availabilit= y) period during the claims period; and therefore when to and when not to use = the "open" phase. Some minor wording changes would be required in= 3.1.1 Claims check form to change it from `The launch phase that SHOULD= be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Tradem= ark check form, so hopefully we can agree with that! That would be my vote = anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the= past =93claims=94 phase in the claims check command to support Trung=92s r= equest.  The issue is that some clients are hard coding =93claims=94 a= s the phase in the claims check command and currently there is little to no support for the claims check command outside of the = =93claims=94 phase, so clients may inadvertently go through the claims proc= ess when it is not required or even potentially rejected on create.  I= see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a name independent of the requirement for a cla= ims notice for other use cases like the resale of domain names.

We already support a =93type" attribute in the <launch:check&g= t; element, section 3.1, to define the check form of the command, which cur= rently support =93claims=94 and =93avail=94 for the Claims Check Form and t= he Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return =93exists=3D1=94= if there is a matching trademark and a claims notice is required on create= , per the proposed check changes.  We could add a Trademark Check Form= (e.g. add section 3.1.3) that is indicated by setting the =93type=94 attribute to =93trademark=94.  The interfac= e for the Trademark Check Form is consistent with the Claims Check Form, ex= cept the <launch:phase> element is not applicable, so therefore in th= e schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademar= ks to return the same response as with the Claims Check Form.  The <= ;launch:phase> element would still be required for the Claims Check Form= and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the ser= ver is determined by server policy, so the Trademark Check Form would is an= option but is not required.  The check command using the Trademark Ch= eck Form would look like:

   C:<?xml version=3D"1.0&quo=
t; encoding=3D"UTF-8" standalone=3D"no"?>
   C:<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0"
   C:     type=3D=93trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be a= dded along with some text changes on the =93trademark=94 value for the =93t= ype=94 attribute in section 3.1, <e= numeration value=3D=93trademark=94/> would need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema.    

Let me know your thoughts on this option. 

Thanks,

=97=
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<Mail Attachment.png>=

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:=

Michael,

I provide feedback inline below.  

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<B= F09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrati= ons. The post claims lookup seems to be aimed at determining, for informati= on purposes only (without "acking" in the create), whether or not there is a trademark registered against the te= rm (i.e. label only) therefore there is no reason to check claims via TLD. = This is a little OT anyway (my fault sorry), but hopefully you see where I = am coming from.

The use case for the claims check post the claims phase is used to add= ress the release of domain names that did not go through 90 days of claims,= which I believe is a modified version of your #2 below.  

Let=92s take the three basic phases defined in draft-ietf-eppext-= launchphase as an example with sunrise, claims, and open.  We can pret= ty much remove the sunrise phase from the example for now, so let=92s focus= on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a clai= ms check is done with =93open=94 as the phase, the response would be exists= =3D=930=94, since there is no requirement to provide the claims notice on c= reate.  If reserved.tld was released during the =93open=94 phase, then a claims check on reserved.tld, with =93open=94= as the phase, the response would be exists=3D=931=94, since a claims notic= e is required on create.  Based on Trung=92s use case, a client may wa= nt to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client= can send a claims check with the phase as =93claims=94 to get that answer.=    



Back to LaunchPhase: my concern with simply using the "claims" ph= ase is that it can cause ambiguity, take the following four phase statuses,= and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains= that are released at a later date (collisions etc, and I don't know what m= ay be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domai= ns for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create w<= /span>ithout claims]

If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this poi= nt despite receiving claims=3Dtrue. This is why I suggest a different sub_p= hase should be used, OR a different flag added (more complex of course) to = differentiate.


Based on the updated text, the client will only receive a claims check= response with exists=3D=931=94 if =93create with claims form=94 is require= d.  The updated text does not support #4, since the only time that =93= exists=3D0=94 is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic = of passing special attributes or sub-phases to get the answer that is neede= d, which is whether a claims notice is required on create.  Trung use = case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domai= n name independent of whether a claims notice is required on create, so pas= sing =93claims=94 as the phase past the =93claims=94 phase may support that= .  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I = am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue ## The claims exists but it is NOT required on domain_cre= ate
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return ## How does the client know if 90 days has passed (= extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / T= MDB was worked out a couple of years ago, where there was a desire to not m= ake the CNIS the critical path for the majority of the registrations.  = ;The agreement was for the registries to provide the claims check service and enforce the claims notice on creat= e based on a feed of trademark labels from the TMDB to the registries. &nbs= p;

The proposal is to support the claims service post the =93claims=94 ph= ase by passing the active phase to the server and the server will return wh= ether or not the claims notice is required based on a combination of a matc= hing trademark and whether the domain name already went through 90 days of the claims service.  From a clie= nt perspective it means utilizing the claims check in a similar fashion dur= ing and post the claims phase.  The use case brought up by Trung was m= ore of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name in= dependent of the requirement for passing the claims notice.  In that c= ase, the proposal is to pass =93claims=94 as the phase independent of the a= ctive phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

=97=
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


= <Mail Attachment.png>
 James Gould
<= font color=3D"#6B6D71">Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= .

The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a cla= im. As it is, various registries are extending the claims periods past 90 d= ays, so its contradictory to have extended claims and post claims defined t= he same way in the query but without a defined (or facilitated) way to differentiate the requirement for a doma= in_create.

I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB.=

Cheers,
Michael

Michael Hollo= way
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign= .com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>= ;
Cc: Francisco Obispo <fobispo@uniregist= ry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

= =97

JG



James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com=

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:
From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the p= ost claims phase.
 
With the wording changes, is there still a way to determine if there=92s a trad= emark against the name regardless on whether or not the claims ack is neede= d in the create domain?  
&n= bsp;
Th= is could be accomplished by leaving the =93claims=94 implementation as it is = currently and introducing a sub-phase for claims named =93extended=94. = ; When the sup-phase of =93extended=94 is passed the results from Jim=92s e= arlier email would be below.
&n= bsp;
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
Th= is would still allow a registrar to determine if a claim currently exists on = a domain when a claim period does not exist for the TLD (the current implem= entation).  From a registrar perspective, I=92m not sure if determinin= g if a domain has a claim when all claims periods have expired is needed.  This implementation also would requi= re additional work by all registrars to support if adopted, while the imple= mentation from Jim=92s first post would require only updates by the registr= ies which would be better for widespread adoption.
&n= bsp;
Th= oughts?
&n= bsp;
Thanks,<= o:p>
Jody Kolker
319-294-= 3933 (office)
319-329-= 9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadn= all@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the a= ddressee(s) named herein and may contain confidential information. If you h= ave received this email in error, please immediately notify the sender and = permanently delete the original and any copy of this message and its attachments.
&n= bsp;
From= : Gould, James [mailt= o:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppex= t@ietf.org; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97<= /span>
&nbs= p;

JG


<image001.png>
 James Gould
Distinguis= hed Engineer
jgou= ld@Verisign.com

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

Veri= signInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobis= po@uniregistry.com> wrote:


<launc= h:phase>  SHOULD contain the value of "claims" to indicat= e the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGoul= d@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Fr= ancisco Obispo CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newp= ort Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinf=
o/eppext
_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinf= o/eppext



_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinfo/eppext



_______________________________________________
EppExt mailing list
EppEx=
t@ietf.org
https://www.ietf.org/mailman/listinfo/eppext


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

--_000_378DCFEE69D7468EB928EE35378FE875verisigncom_-- --_004_378DCFEE69D7468EB928EE35378FE875verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Wed, 21 Jan 2015 16:30:48 GMT"; modification-date="Wed, 21 Jan 2015 16:30:48 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_378DCFEE69D7468EB928EE35378FE875verisigncom_-- From nobody Thu Jan 22 03:21:47 2015 Return-Path: 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 1E2D81AC44D for ; Thu, 22 Jan 2015 03:21:45 -0800 (PST) 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 wDo9Q3cAOZs0 for ; Thu, 22 Jan 2015 03:21:42 -0800 (PST) Received: from smtp75.ord1c.emailsrvr.com (smtp75.ord1c.emailsrvr.com [108.166.43.75]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F92E1A01EA for ; Thu, 22 Jan 2015 03:21:42 -0800 (PST) Received: from smtp2.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C7A3A180359 for ; Thu, 22 Jan 2015 06:21:41 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C3D591802F0 for ; Thu, 22 Jan 2015 06:21:41 -0500 (EST) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 0F73B180359 for ; Thu, 22 Jan 2015 06:21:40 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 22 Jan 2015 11:21:41 GMT Message-ID: <54C0DD43.1040007@comlaude.com> Date: Thu, 22 Jan 2015 12:21:39 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext@ietf.org References: <54BFC82E.1070208@elistx.com> In-Reply-To: <54BFC82E.1070208@elistx.com> Content-Type: multipart/alternative; boundary="------------010708060109030106000400" Archived-At: Subject: Re: [eppext] moving documents along X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 11:21:45 -0000 This is a multi-part message in MIME format. --------------010708060109030106000400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 2. draft-ietf-eppext-idnmap-02 : I am happy to stamp a "no objection" on this one. 3. draft-ietf-eppext-launchphase-02 : The discussions are ongoing, hopefully we are close. 5. draft-ietf-eppext-tmch-smd-00 : To me this document seems to be ready as is, and as it has implemented by TMCH and LaunchPhase extension as see no reason not to push it forward. I am afraid I have no comments on 1. eppext-reg and 4. eppext-keyrelay have not really been following these. regards, Michael *Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com D: +44 20 7421 8273 On 01/21/2015 04:39 PM, James Galvin wrote: > Speaking as Chair, I want to bring folks up to date on where I believe > we are. Please do speak up if you disagree or have any corrections. > > We have 5 documents in our working group. > > > 1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible > Provisioning Protocol > > If you've been tracking the status updates from the RFC Editor on the > list then you know this document is close to publication as an RFC. > Scott Hollenbeck has been doing his part to move this along. There is > no action for the working group at this time. > > > 2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping > Extension for the Extensible Provisioning Protocol (EPP) > > There has been very little discussion on the mailing list about this > document. Andrew Sullivan posted some extensive comments to which > there has been limited response. > > It's tough to declare consensus with so little discussion. It would > be helpful if folks would review the document and comments and post at > least a "no objection". > > > 3. draft-ietf-eppext-keyrelay-01 Relay Extension for the > Extensible Provisioning Protocol > > There has been lively discussion here and we appear to have a > difference of opinion on a technical point. We very much need to hear > from other folks. Please review the thread and let everyone know what > you think. > > > 4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the > Extensible Provisioning Protocol (EPP) > > I believe we're close to consensus on this document. There's been > some discussion but nothing too contentious as far as I can see. I'm > expecting Jim Gould to submit a revised document in the not too > distant future and we'll review where we are at that time. > > > 5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping > > This document has expired and is waiting for the author to resubmit. > There was one change proposed on the mailing list last year that needs > to be incorporated in the revision. > > At one time there was concern about the relationship between this > document and the launchphase document but I don't believe that concern > exists any more. > > I suppose it's fair to ask if the working group is still interested in > publishing this document. If so, I'll press Gustavo to submit a > revised document and we can review where we are at that time. > > > Comments and corrections are welcome! > > Jim > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext --------------010708060109030106000400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
2. draft-ietf-eppext-idnmap-02 : I am happy to stamp a "no objection" on this one.

3. draft-ietf-eppext-launchphase-02 : The discussions are ongoing, hopefully we are close.

5. draft-ietf-eppext-tmch-smd-00 : To me this document seems to be ready as is, and as it has implemented by TMCH and LaunchPhase extension as see no reason not to push it forward.

I am afraid I have no comments on 1. eppext-reg and 4. eppext-keyrelay have not really been following these.

regards,
Michael

 
Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com
D: +44 20 7421 8273



On 01/21/2015 04:39 PM, James Galvin wrote:
Speaking as Chair, I want to bring folks up to date on where I believe we are.  Please do speak up if you disagree or have any corrections.

We have 5 documents in our working group.


1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible Provisioning Protocol

If you've been tracking the status updates from the RFC Editor on the list then you know this document is close to publication as an RFC. Scott Hollenbeck has been doing his part to move this along.  There is no action for the working group at this time.


2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)   

There has been very little discussion on the mailing list about this document.  Andrew Sullivan posted some extensive comments to which there has been limited response.

It's tough to declare consensus with so little discussion.  It would be helpful if folks would review the document and comments and post at least a "no objection".


3. draft-ietf-eppext-keyrelay-01     Relay Extension for the Extensible Provisioning Protocol

There has been lively discussion here and we appear to have a difference of opinion on a technical point.  We very much need to hear from other folks.  Please review the thread and let everyone know what you think.


4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)

I believe we're close to consensus on this document.  There's been some discussion but nothing too contentious as far as I can see.  I'm expecting Jim Gould to submit a revised document in the not too distant future and we'll review where we are at that time.


5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping

This document has expired and is waiting for the author to resubmit. There was one change proposed on the mailing list last year that needs to be incorporated in the revision.

At one time there was concern about the relationship between this document and the launchphase document but I don't believe that concern exists any more.

I suppose it's fair to ask if the working group is still interested in publishing this document.  If so, I'll press Gustavo to submit a revised document and we can review where we are at that time.


Comments and corrections are welcome!

Jim

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



--------------010708060109030106000400-- From nobody Thu Jan 22 04:08:06 2015 Return-Path: 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 6841C1A1A10 for ; Thu, 22 Jan 2015 04:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.438 X-Spam-Level: * X-Spam-Status: No, score=1.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 RirL84VMOLnI for ; Thu, 22 Jan 2015 04:07:49 -0800 (PST) Received: from smtp75.ord1c.emailsrvr.com (smtp75.ord1c.emailsrvr.com [108.166.43.75]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2804F1ACC86 for ; Thu, 22 Jan 2015 04:07:49 -0800 (PST) Received: from smtp10.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7F065380137; Thu, 22 Jan 2015 07:07:48 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7817C3802C4; Thu, 22 Jan 2015 07:07:48 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 7BD1C380137; Thu, 22 Jan 2015 07:07:46 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 22 Jan 2015 12:07:48 GMT Message-ID: <54C0E811.8030602@comlaude.com> Date: Thu, 22 Jan 2015 13:07:45 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Gould, James" References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> <54BFAC7A.7090500@comlaude.com> <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com> In-Reply-To: <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com> Content-Type: multipart/alternative; boundary="------------030803080700000003030502" Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 12:07:59 -0000 This is a multi-part message in MIME format. --------------030803080700000003030502 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi James Yes I think that wording is fine, but [at the risk of pointlessly complicating the issue again], there are possibly multiple concurrent phases. In some instances, a domain might be valid in more than one (e.g. a regional TLD where phases depend on the registrants location or type), and in some cases such as collisions the domain might only be available in one of the active phases (e.g. collisions). Is it worth loosing to an "an" instead of "the" phase? Veto if you think its pointless. Contains the value of an active launch phase of the server supporting claims. The server SHOULD validate the value against the active server launch phase supporting claims. Also, TM check form should be a SHOULD 3.1.3 Trademark Check Form ... The launch phase that SHOULD be "trademark" Cheers, Michael *Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com On 01/21/2015 05:30 PM, Gould, James wrote: > Michael, > > How about just using a more generic description of the > element in both the Claims Check Form of section 3.1.1 and the Claims > Create Form of section 3.3.2, since both forms can be executed outside > of the “claims” phase? Something like the description from the > General Create Form of section 3.3.3: > > Contains the value of the active launch > phase of the server. The server SHOULD validate the value against the > active server launch phase. > > > — > > > JG > > > > > *James Gould > *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 21, 2015, at 8:41 AM, Michael Holloway > > > wrote: > >> Thanks James >> >> From a registrar perspective I would say this solves the issue >> without the risk of breaking working clients. I would be interested >> to hear the opinion of anyone [else] representing registries here >> whether they would support the extra type attribute since its >> essentially optional extra, or whether they would prefer to support >> using he existing schema. >> >> I think in the case of the latter it would suggest using Claims check >> on phases outside of "claims" (e.g. "open"), and then some guidance >> would need to be offered (in the draft) to define exactly what the >> "open" phase is; .I.E is it the period _after_ claims, or is the >> 'open registration' (aka general availability) period _during_ the >> claims period; and therefore when to and when not to use the "open" >> phase. Some minor wording changes would be required in 3.1.1 Claims >> check form to change it from `/The launch phase that SHOULD be >> "claims"`/ , to "MAY", perhaps with a bit more info. >> >> In light of the above I think it would be far simpler to go with the >> Trademark check form, so hopefully we can agree with that! That would >> be my vote anyway! >> >> Regards, >> Michael >> >> >> >> *Michael Holloway >> Senior Systems Administrator**| Com Laude* >> E: michael.holloway@comlaude.com >> >> On 01/20/2015 02:58 PM, Gould, James wrote: >>> All, >>> >>> I had a private thread with some about the proposal of referencing >>> the past “claims” phase in the claims check command to support >>> Trung’s request. The issue is that some clients are hard coding >>> “claims” as the phase in the claims check command and currently >>> there is little to no support for the claims check command outside >>> of the “claims” phase, so clients may inadvertently go through the >>> claims process when it is not required or even potentially rejected >>> on create. I see the concern with adding a new feature that may >>> inadvertently cause interface issues. Although I am not crazy about >>> making an XML schema change, we may be able to tweak things to >>> support both the the claims check outside of the “claims” phase and >>> also support Trung’s request to determine whether or not a trademark >>> matches a name independent of the requirement for a claims notice >>> for other use cases like the resale of domain names. >>> >>> We already support a “type" attribute in the element, >>> section 3.1, to define the check form of the command, which >>> currently support “claims” and “avail” for the Claims Check Form and >>> the Availability Check Form, respectively. The default form is the >>> Claims Check Form, which is updated to return “exists=1” if there is >>> a matching trademark and a claims notice is required on create, per >>> the proposed check changes. We could add a Trademark Check Form >>> (e.g. add section 3.1.3) that is indicated by setting the “type” >>> attribute to “trademark”. The interface for the Trademark Check >>> Form is consistent with the Claims Check Form, except the >>> element is not applicable, so therefore in the schema >>> we would make the element optional, and the server >>> would only match the domain to the matching set of trademarks to >>> return the same response as with the Claims Check Form. The >>> element would still be required for the Claims Check >>> Form and the Availability Check Form based on the draft text. As >>> stated in section 3.1, the forms supported by the server is >>> determined by server policy, so the Trademark Check Form would is an >>> option but is not required. The check command using the Trademark >>> Check Form would look like: >>> >>> C: >>> C: >>> C: >>> C: >>> C: >> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> >>> C: example1.tld >>> C: example2.tld >>> C: >>> C: >>> C: >>> C: >> C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" >>> C: type=“trademark"/> >>> C: >>> C: ABC-12345 >>> C: >>> C: >>> >>> >>> To support this, section 3.1.3 Trademark Check Form would need to be >>> added along with some text changes on the “trademark” value for the >>> “type” attribute in section 3.1, >>> would need to be added to the checkFormType in the schema, and >>> minOccurs=“0” would need to be added to the “phase” element of >>> checkType in the schema. >>> >>> Let me know your thoughts on this option. >>> >>> Thanks, >>> >>> — >>> >>> JG >>> >>> >>> >>> >>> *James Gould >>> *Distinguished Engineer >>> jgould@Verisign.com >>> >>> 703-948-3271 >>> 12061 Bluemont Way >>> Reston, VA 20190 >>> >>> VerisignInc.com >>> >>> On Jan 13, 2015, at 10:40 AM, Gould, James >> > wrote: >>> >>>> Michael, >>>> >>>> I provide feedback inline below. >>>> >>>> — >>>> >>>> JG >>>> >>>> >>>> >>>> >>>> *James Gould >>>> *Distinguished Engineer >>>> jgould@Verisign.com >>>> >>>> 703-948-3271 >>>> 12061 Bluemont Way >>>> Reston, VA 20190 >>>> >>>> VerisignInc.com >>>> >>>> On Jan 13, 2015, at 10:08 AM, Michael Holloway >>>> >>> > wrote: >>>> >>>>> Hi >>>>> >>>>> Re TMDB: I was thinking specifically of the post claims phase >>>>> since at this point the CNIS (label+tld) itself it no longer >>>>> required for registrations. The post claims lookup seems to be >>>>> aimed at determining, for information purposes only (without >>>>> "acking" in the create), whether or not there is a trademark >>>>> registered against the term (i.e. label only) therefore there is >>>>> no reason to check claims via TLD. This is a little OT anyway (my >>>>> fault sorry), but hopefully you see where I am coming from. >>>> >>>> The use case for the claims check post the claims phase is used to >>>> address the release of domain names that did not go through 90 days >>>> of claims, which I believe is a modified version of your #2 below. >>>> >>>> Let’s take the three basic phases defined >>>> in draft-ietf-eppext-launchphase as an example with sunrise, >>>> claims, and open. We can pretty much remove the sunrise phase from >>>> the example for now, so let’s focus on the claims and open phases. >>>> Assuming that claims.tld is available through sunrise and the >>>> claims phase, so if a claims check is done with “open” as the >>>> phase, the response would be exists=“0”, since there is no >>>> requirement to provide the claims notice on create. If >>>> reserved.tld was released during the “open” phase, then a claims >>>> check on reserved.tld, with “open” as the phase, the response would >>>> be exists=“1”, since a claims notice is required on create. Based >>>> on Trung’s use case, a client may want to know whether or not there >>>> is a trademark on the domain name independent of when the domain >>>> name is released, so the client can send a claims check with the >>>> phase as “claims” to get that answer. >>>> >>>> >>>>> >>>>> Back to LaunchPhase: my concern with simply using the "claims" >>>>> phase is that it can cause ambiguity, take the following four >>>>> phase statuses, and compare with the logic below (to which I >>>>> commented in _underlined red_) >>>>> 1) A registry _must_ operate a 90 days claims phase >>>>> 2) A registry _must_ operate 90 days extended claims period on >>>>> domains that are released at a later date (collisions etc, and I >>>>> don't know what may be coming up in the future) >>>>> 3) A registry _may_ operate a continued claims phase past the 90 >>>>> domains for all domains. [create with claims form] >>>>> 4) [new]: A registry _may_ operate a post claims (matching >>>>> trademark past the claims phase use case) [create without claims] >>>>> >>>>> If the client checks a domain for claims and gets result >>>>> claims=true, then how does it know which of the above rules >>>>> matched? In the case of (4) the claims lookup returns true even >>>>> though the domain is no longer in (1) or (2) [and the registry has >>>>> opted not to do (3)], so using the claims create form would be >>>>> incorrect at this point despite receiving claims=true. This is why >>>>> I suggest a different sub_phase should be used, OR a different >>>>> flag added (more complex of course) to differentiate. >>>>> >>>> >>>> Based on the updated text, the client will only receive a claims >>>> check response with exists=“1” if “create with claims form” is >>>> required. The updated text does not support #4, since the only >>>> time that “exists=0” is if a claims notice is required. This way a >>>> client can continue to use the claims check without any extra logic >>>> of passing special attributes or sub-phases to get the answer that >>>> is needed, which is whether a claims notice is required on create. >>>> Trung use case is an exception to the rule, where a client wants >>>> to know whether there is a matching trademark for the domain name >>>> independent of whether a claims notice is required on create, so >>>> passing “claims” as the phase past the “claims” phase may support >>>> that. >>>> >>>> Let me know whether or not this helps. >>>> >>>> >>>>> I hope this makes sense; and apologies if I am missing something >>>>> fundamental! >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> 1. During claims phase with a claims check command >>>>> 1. If domain has matching trademark >>>>> 1. return exists=true >>>>> 2. else >>>>> 1. return exists=false >>>>> 2. During post claims phase with a claims check command >>>>> 1. If domain was released post claims phase start and is >>>>> within 90 days of release and has matching trademark >>>>> 1. return exists=true >>>>> 2. else >>>>> 1. return exists=false >>>>> 3. *During post claims phase with a claims phase check and >>>>> passing “claims” as the phase (optional matching trademark >>>>> past the claims phase use case)* >>>>> 1. *If domains has matching trademark * >>>>> 1. *return exists=true *_## The claims exists but it is >>>>> NOT required on domain_create_ >>>>> 2. *else* >>>>> 1. *return exists=false* >>>>> >>>>> >>>>> 1. During claims phase with a create command >>>>> 1. If domain has matching trademark >>>>> 1. claims notice is required >>>>> 2. else >>>>> 1. claims notice is NOT required >>>>> 2. During post claims phase with a create command >>>>> 1. If domain was released post claims phase start and is >>>>> within 90 days of release and has matching trademark >>>>> return ## How does the client know if 90 days has passed >>>>> (extended / post claims) or not without external source? >>>>> 1. claims notice is required >>>>> 2. else >>>>> 1. claims notice is NOT required >>>>> >>>>> >>>>> >>>>> * >>>>> Michael Holloway >>>>> Senior Systems Administrator**| Com Laude* >>>>> E: michael.holloway@comlaude.com >>>>> >>>>> >>>>> On 01/13/2015 02:44 PM, Gould, James wrote: >>>>>> Michael, >>>>>> >>>>>> The split out of the responsibility of the registries and the >>>>>> CNIS / TMDB was worked out a couple of years ago, where there was >>>>>> a desire to not make the CNIS the critical path for the majority >>>>>> of the registrations. The agreement was for the registries to >>>>>> provide the claims check service and enforce the claims notice on >>>>>> create based on a feed of trademark labels from the TMDB to the >>>>>> registries. >>>>>> >>>>>> The proposal is to support the claims service post the “claims” >>>>>> phase by passing the active phase to the server and the server >>>>>> will return whether or not the claims notice is required based on >>>>>> a combination of a matching trademark and whether the domain name >>>>>> already went through 90 days of the claims service. From a >>>>>> client perspective it means utilizing the claims check in a >>>>>> similar fashion during and post the claims phase. The use case >>>>>> brought up by Trung was more of an exception to the rule, in the >>>>>> client wanting to know whether there is a matching trademark for >>>>>> a domain name independent of the requirement for passing the >>>>>> claims notice. In that case, the proposal is to pass “claims” as >>>>>> the phase independent of the active phase to get a true or false >>>>>> answer to whether a trademark matches the domain name. >>>>>> >>>>>> Do the proposals work for you? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> — >>>>>> >>>>>> JG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *James Gould >>>>>> *Distinguished Engineer >>>>>> jgould@Verisign.com >>>>>> >>>>>> 703-948-3271 >>>>>> 12061 Bluemont Way >>>>>> Reston, VA 20190 >>>>>> >>>>>> VerisignInc.com >>>>>> >>>>>> On Jan 13, 2015, at 3:18 AM, Michael Holloway >>>>>> >>>>> > wrote: >>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> Just a thought; would it not be more appropriate to facilitate >>>>>>> this on the TMDB by adding a lookup based on label. This could >>>>>>> return a simple true/false value, or all the info returned on a >>>>>>> CNIS lookup exception notice_id etc. >>>>>>> >>>>>>> The problem with having and post claims service on the EPP >>>>>>> server without changing the phase name is that the EPP client >>>>>>> then has to decide when /not/ to submit claims data in a >>>>>>> domain_create if the domain has a claim. As it is, various >>>>>>> registries are extending the claims periods past 90 days, so its >>>>>>> contradictory to have extended claims and post claims defined >>>>>>> the same way in the query but without a defined (or facilitated) >>>>>>> way to differentiate the requirement for a domain_create. >>>>>>> >>>>>>> I would be more comfortable with defining a specific sub_phase >>>>>>> for the purpose, or even better skipping the middle man and >>>>>>> going straight to the TMDB. >>>>>>> >>>>>>> Cheers, >>>>>>> Michael >>>>>>> >>>>>>> *Michael Holloway >>>>>>> Senior Systems Administrator**| Com Laude* >>>>>>> E: michael.holloway@comlaude.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/13/2015 04:04 AM, Tran, Trung wrote: >>>>>>>> This works for me, Jim. Though it’s not often, we have cases >>>>>>>> where change in ownership of a domain might not occur if >>>>>>>> there’s trademark against the name. So a potential registrant >>>>>>>> might not want to buy an existing registered name if there’s >>>>>>>> trademark against it in the TMCH. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Trung >>>>>>>> From: , James >>>>>>> > >>>>>>>> Date: Friday, January 9, 2015 at 11:27 AM >>>>>>>> To: Jody Kolker > >>>>>>>> Cc: Francisco Obispo >>>>>>> >, "eppext@ietf.org >>>>>>>> " >>>>>>> >, "Tran, Trung" >>>>>>>> > >>>>>>>> Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for >>>>>>>> a "Claims Service" post the Claims Phase >>>>>>>> >>>>>>>> Jody, >>>>>>>> >>>>>>>> I believe that passing the active phase is more straight >>>>>>>> forward as opposed to defining a special sub-phase like >>>>>>>> “extended" to drive the behavior. Having the claims check >>>>>>>> return “exists=true” only when a claims notice is required >>>>>>>> on the create based on the active phase should be able to >>>>>>>> handle the use case of releasing domains post the claims >>>>>>>> phase and also applies to the claims phase. All names that >>>>>>>> have matching trademarks during the claims phase will >>>>>>>> require a claims notice on create, so the behavior is >>>>>>>> consistent. >>>>>>>> >>>>>>>> I’m still not sure why a client would want to know whether >>>>>>>> there is a matching trademark when a claims notice is not >>>>>>>> required on the create. Does anyone see a need for this? >>>>>>>> Since the “claims” phase would always return “exists=true” >>>>>>>> for domains that have matching trademarks, a client could >>>>>>>> pass the “claims” phase when the active phase is not the >>>>>>>> “claims” phase to obtain this information. Of course >>>>>>>> servers would need to support referencing a past “claims” >>>>>>>> phase to support this use case. The change in the text >>>>>>>> should support the logic that I previously posted before, >>>>>>>> which I extend to support addressing the optional matching >>>>>>>> trademark past the claims phase use case. Is this use case >>>>>>>> really needed? >>>>>>>> >>>>>>>> 1. During claims phase with a claims check command >>>>>>>> 1. If domain has matching trademark >>>>>>>> 1. return exists=true >>>>>>>> 2. else >>>>>>>> 1. return exists=false >>>>>>>> 2. During post claims phase with a claims check command >>>>>>>> 1. If domain was released post claims phase start and >>>>>>>> is within 90 days of release and has matching >>>>>>>> trademark >>>>>>>> 1. return exists=true >>>>>>>> 2. else >>>>>>>> 1. return exists=false >>>>>>>> 3. *During post claims phase with a claims phase check and >>>>>>>> passing “claims” as the phase (optional matching >>>>>>>> trademark past the claims phase use case)* >>>>>>>> 1. *If domains has matching trademark * >>>>>>>> 1. *return exists=true* >>>>>>>> 2. *else* >>>>>>>> 1. *return exists=false* >>>>>>>> >>>>>>>> >>>>>>>> 1. During claims phase with a create command >>>>>>>> 1. If domain has matching trademark >>>>>>>> 1. claims notice is required >>>>>>>> 2. else >>>>>>>> 1. claims notice is NOT required >>>>>>>> 2. During post claims phase with a create command >>>>>>>> 1. If domain was released post claims phase start and >>>>>>>> is within 90 days of release and has matching >>>>>>>> trademark return >>>>>>>> 1. claims notice is required >>>>>>>> 2. else >>>>>>>> 1. claims notice is NOT required >>>>>>>> >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> — >>>>>>>> >>>>>>>> JG >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *James Gould >>>>>>>> *Distinguished Engineer >>>>>>>> jgould@Verisign.com >>>>>>>> >>>>>>>> 703-948-3271 >>>>>>>> 12061 Bluemont Way >>>>>>>> Reston, VA 20190 >>>>>>>> >>>>>>>> VerisignInc.com >>>>>>>> >>>>>>>> >>>>>>>> On Jan 8, 2015, at 4:50 PM, Jody Kolker >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> From Francisco: >>>>>>>>> Thanks Jim for bringing this to the eppext. This will >>>>>>>>> definitely help the post claims phase. >>>>>>>>> With the wording changes, is there still a way to >>>>>>>>> determine if there’s a trademark against the name >>>>>>>>> regardless on whether or not the claims ack is needed in >>>>>>>>> the create domain? >>>>>>>>> This could be accomplished by leaving the “claims” >>>>>>>>> implementation as it is currently and introducing a >>>>>>>>> sub-phase for claims named “extended”. When the sup-phase >>>>>>>>> of “extended” is passed the results from Jim’s earlier >>>>>>>>> email would be below. >>>>>>>>> >>>>>>>>> 1. During claims phase with a claims check command or >>>>>>>>> post claims phase without a sub-phase of “extended” >>>>>>>>> 1. If domain has matching trademark >>>>>>>>> 1. return exists=true >>>>>>>>> 2. else >>>>>>>>> 1. return exists=false >>>>>>>>> 2. During post claims phase with a claims check command >>>>>>>>> with a sub-phase of “extended” >>>>>>>>> 1. If domain was released post claims phase start and >>>>>>>>> is within 90 days of release and has matching >>>>>>>>> trademark >>>>>>>>> 1. return exists=true >>>>>>>>> 2. else >>>>>>>>> 1. return exists=false >>>>>>>>> >>>>>>>>> 1. During claims phase with a create command or post >>>>>>>>> claims phase without a sub-phase of “extended” >>>>>>>>> 1. If domain has matching trademark >>>>>>>>> 1. claims notice is required >>>>>>>>> 2. else >>>>>>>>> 1. claims notice is NOT required >>>>>>>>> 2. During post claims phase with a create command with a >>>>>>>>> sub-phase of “extended” >>>>>>>>> 1. If domain was released post claims phase start and >>>>>>>>> is within 90 days of release and has matching >>>>>>>>> trademark return >>>>>>>>> 1. claims notice is required >>>>>>>>> 2. else >>>>>>>>> 1. claims notice is NOT required >>>>>>>>> >>>>>>>>> This would still allow a registrar to determine if a claim >>>>>>>>> currently exists on a domain when a claim period does not >>>>>>>>> exist for the TLD (the current implementation). From a >>>>>>>>> registrar perspective, I’m not sure if determining if a >>>>>>>>> domain has a claim when all claims periods have expired is >>>>>>>>> needed. This implementation also would require additional >>>>>>>>> work by all registrars to support if adopted, while the >>>>>>>>> implementation from Jim’s first post would require only >>>>>>>>> updates by the registries which would be better for >>>>>>>>> widespread adoption. >>>>>>>>> Thoughts? >>>>>>>>> Thanks, >>>>>>>>> Jody Kolker >>>>>>>>> 319-294-3933 (office) >>>>>>>>> 319-329-9805 (mobile) Please contact my direct supervisor >>>>>>>>> Charles Beadnall (cbeadnall@godaddy.com >>>>>>>>> ) with any feedback. >>>>>>>>> This email message and any attachments hereto is intended >>>>>>>>> for use only by the addressee(s) named herein and may >>>>>>>>> contain confidential information. If you have received >>>>>>>>> this email in error, please immediately notify the sender >>>>>>>>> and permanently delete the original and any copy of this >>>>>>>>> message and its attachments. >>>>>>>>> *From:*Gould, James [mailto:JGould@verisign.com] >>>>>>>>> *Sent:*Thursday, January 08, 2015 12:24 PM >>>>>>>>> *To:*Francisco Obispo >>>>>>>>> *Cc:*Jody Kolker;eppext@ietf.org ; >>>>>>>>> Tran, Trung >>>>>>>>> *Subject:*Re: [eppext] draft-ietf-eppext-launchphase >>>>>>>>> Support for a "Claims Service" post the Claims Phase >>>>>>>>> Francisco, >>>>>>>>> I would have gone with the sub-phase approach as well, >>>>>>>>> since if the behavior between the two claims phases are >>>>>>>>> consistent (e.g. requirement for claims check and claims >>>>>>>>> notice) I’m not sure the value in defining a new top-level >>>>>>>>> phase name. Is there a material behavior change between >>>>>>>>> the two phases and is the concept of an extended claims >>>>>>>>> phase a generic use case? We have stuck with the standard >>>>>>>>> set of “sunrise”, “claims”, and “open” phases. Have >>>>>>>>> others utilized the use of sub-phases or have created >>>>>>>>> custom top-level phase names to meet their needs? If so, >>>>>>>>> can you share your scheme? It would be good to know if >>>>>>>>> there are any common patterns. >>>>>>>>> Thanks, >>>>>>>>> — >>>>>>>>> >>>>>>>>> JG >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *James Gould >>>>>>>>> *Distinguished Engineer >>>>>>>>> jgould@Verisign.com >>>>>>>>> >>>>>>>>> 703-948-3271 >>>>>>>>> 12061 Bluemont Way >>>>>>>>> Reston, VA 20190 >>>>>>>>> >>>>>>>>> VerisignInc.com >>>>>>>>> >>>>>>>>> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> SHOULD contain the value >>>>>>>>> of "claims" to indicate the >>>>>>>>> claims launch phase. A value other >>>>>>>>> than "claims" MAY be used to >>>>>>>>> pass the claims notice for domain names >>>>>>>>> outside of the claims phase. >>>>>>>>> >>>>>>>>> Once a TLD has ended the mandatory 90 day period of >>>>>>>>> “claims” a registry might decide to call it something >>>>>>>>> else. >>>>>>>>> We are not supporting extended claims, but we had to >>>>>>>>> support an extended sunrise for the names on the ICANN >>>>>>>>> names-collision block list (30 day period instead of a >>>>>>>>> 60 day end-date sunrise), and we initially thought >>>>>>>>> about having a phase called “sunrise” with a sub-phase >>>>>>>>> called “extended” but we thought it would be too >>>>>>>>> complicated for RARs to change their code, so we >>>>>>>>> decided just to trigger it by calling the phase >>>>>>>>> “sunsrise”, but in reality, a registry can call it >>>>>>>>> anything they want in order to support it, because >>>>>>>>> they are different things. >>>>>>>>> Since there is no guidance on what the phases should >>>>>>>>> be called, it seems like we’re going to end up with >>>>>>>>> discrete phase names for anything that is not: claims >>>>>>>>> or sunrise. >>>>>>>>> >>>>>>>>> On Jan 8, 2015, at 11:35 AM, Gould, James >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> What do you mean by the extended claims phase? Is >>>>>>>>> there a past mail list thread on this or is this a >>>>>>>>> new issue? Please clarify. >>>>>>>>> >>>>>>>>> *Francisco Obispo* >>>>>>>>> CTO - Registry Operations >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2161 San Joaquin Hills Rd. >>>>>>>>> Newport Beach, CA, 92660 >>>>>>>>> off. +1.345.749.6284 >>>>>>>>> fax. +1.345.746.6263 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> EppExt mailing list >>>>>>>> EppExt@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>>>> _______________________________________________ >>>>>>> EppExt mailing list >>>>>>> EppExt@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> EppExt mailing list >>>> EppExt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eppext >>> >>> >>> >>> _______________________________________________ >>> EppExt mailing list >>> EppExt@ietf.org >>> https://www.ietf.org/mailman/listinfo/eppext >> >> >> _______________________________________________ >> EppExt mailing list >> EppExt@ietf.org >> https://www.ietf.org/mailman/listinfo/eppext > --------------030803080700000003030502 Content-Type: multipart/related; boundary="------------060501040206040609030701" --------------060501040206040609030701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi James

Yes I think that wording is fine, but [at the risk of pointlessly complicating the issue again], there are possibly multiple concurrent phases. In some instances, a domain might be valid in more than one (e.g. a regional TLD where phases depend on the registrants location or type), and in some cases such as collisions the domain might only be available in one of the active phases (e.g. collisions). Is it worth loosing to an "an" instead of "the" phase? Veto if you think its pointless.

<launch:phase>   Contains the value of an active launch phase of the server supporting claims.  The server SHOULD validate the value against the active server launch phase supporting claims.

Also, TM check form should be a SHOULD
3.1.3 Trademark Check Form
...
<launch:phase>   The launch phase that SHOULD be "trademark"


Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/21/2015 05:30 PM, Gould, James wrote:
Michael,

How about just using a more generic description of the <launch:phase> element in both the Claims Check Form of section 3.1.1 and the Claims Create Form of section 3.3.2, since both forms can be executed outside of the “claims” phase?  Something like the description from the General Create Form of section 3.3.3:

              <launch:phase>   Contains the value of the active launch phase of the server.  The server SHOULD validate the value against the active server launch phase.


—


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 21, 2015, at 8:41 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Thanks James

From a registrar perspective I would say this solves the issue without the risk of breaking working clients. I would be interested to hear the opinion of anyone [else] representing registries here whether they would support the extra type attribute since its essentially optional extra, or whether they would prefer to support using he existing schema.

I think in the case of the latter it would suggest using Claims check on phases outside of "claims" (e.g. "open"),  and then some guidance would need to be offered (in the draft) to define exactly what the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availability) period during the claims period; and therefore when to and when not to use the "open" phase. Some minor wording changes would be required in 3.1.1 Claims check form to change it from `The launch phase that SHOULD be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Trademark check form, so hopefully we can agree with that! That would be my vote anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the past “claims” phase in the claims check command to support Trung’s request.  The issue is that some clients are hard coding “claims” as the phase in the claims check command and currently there is little to no support for the claims check command outside of the “claims” phase, so clients may inadvertently go through the claims process when it is not required or even potentially rejected on create.  I see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not crazy about making an XML schema change, we may be able to tweak things to support both the the claims check outside of the “claims” phase and also support Trung’s request to determine whether or not a trademark matches a name independent of the requirement for a claims notice for other use cases like the resale of domain names.

We already support a “type" attribute in the <launch:check> element, section 3.1, to define the check form of the command, which currently support “claims” and “avail” for the Claims Check Form and the Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return “exists=1” if there is a matching trademark and a claims notice is required on create, per the proposed check changes.  We could add a Trademark Check Form (e.g. add section 3.1.3) that is indicated by setting the “type” attribute to “trademark”.  The interface for the Trademark Check Form is consistent with the Claims Check Form, except the <launch:phase> element is not applicable, so therefore in the schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademarks to return the same response as with the Claims Check Form.  The <launch:phase> element would still be required for the Claims Check Form and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the server is determined by server policy, so the Trademark Check Form would is an option but is not required.  The check command using the Trademark Check Form would look like:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
   C:     type=“trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be added along with some text changes on the “trademark” value for the “type” attribute in section 3.1, <enumeration value=“trademark”/> would need to be added to the checkFormType in the schema, and minOccurs=“0” would need to be added to the “phase” element of checkType in the schema.    

Let me know your thoughts on this option. 

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:

Michael,

I provide feedback inline below.  

—

JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from.

The use case for the claims check post the claims phase is used to address the release of domain names that did not go through 90 days of claims, which I believe is a modified version of your #2 below.  

Let’s take the three basic phases defined in draft-ietf-eppext-launchphase as an example with sunrise, claims, and open.  We can pretty much remove the sunrise phase from the example for now, so let’s focus on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a claims check is done with “open” as the phase, the response would be exists=“0”, since there is no requirement to provide the claims notice on create.  If reserved.tld was released during the “open” phase, then a claims check on reserved.tld, with “open” as the phase, the response would be exists=“1”, since a claims notice is required on create.  Based on Trung’s use case, a client may want to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client can send a claims check with the phase as “claims” to get that answer.    



Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domains for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create without claims]

If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate.


Based on the updated text, the client will only receive a claims check response with exists=“1” if “create with claims form” is required.  The updated text does not support #4, since the only time that “exists=0” is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic of passing special attributes or sub-phases to get the answer that is needed, which is whether a claims notice is required on create.  Trung use case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domain name independent of whether a claims notice is required on create, so passing “claims” as the phase past the “claims” phase may support that.  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true ## The claims exists but it is NOT required on domain_create
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return ## How does the client know if 90 days has passed (extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / TMDB was worked out a couple of years ago, where there was a desire to not make the CNIS the critical path for the majority of the registrations.  The agreement was for the registries to provide the claims check service and enforce the claims notice on create based on a feed of trademark labels from the TMDB to the registries.  

The proposal is to support the claims service post the “claims” phase by passing the active phase to the server and the server will return whether or not the claims notice is required based on a combination of a matching trademark and whether the domain name already went through 90 days of the claims service.  From a client perspective it means utilizing the claims check in a similar fashion during and post the claims phase.  The use case brought up by Trung was more of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name independent of the requirement for passing the claims notice.  In that case, the proposal is to pass “claims” as the phase independent of the active phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.  

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

—

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.
 
With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
 
  1. During claims phase with a create command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
 
From: Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.  
 
Thanks,
 
—
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase.  
 
 
Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



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



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



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


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

--------------060501040206040609030701 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vL JtmQhEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjT DnhDEEWC1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBg wDFuRRaXOiUlhX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2Thp UA4w9Pf39/X19fT0UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvCl pSFvipAimGy1wQmrMgV4aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZn ZGSMLYejx4biEautrQ3eUlNTLUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwo MYA5nZ+duXiyur6ju88u5ZL5s+ffmJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMyg UvRoijp7AnuPXdhz9PyeyvPI7khxqtoUyTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIe aOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+ MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUYu3T5MoyxMZEDbJTK81fWlR242NrrcHsd ToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5KhL1kjDMBbMQMDKa6pgaE6enpggp4 r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg8NF7Crc99XNeG/ZQIvkQ3xt1 bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SFSVPIxDKpBVuYQOABMtg3 f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+aw+1xuLQ1Ag9s1p9u C9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhDED8wSxgTYLsq LihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z0S70CNsj wiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4eQOP cELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT 6T5+saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1o PoiPDXtouXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z 3HTYGyVlH5+oalTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScx ZZBtnd0lr31oF9G0l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEY B2jEkLZ91vDtONgwQhgjZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjR rCkTYo5c/fK7yshlTXVkc739+RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffr UI5Aqf7SNz6NuTpInl2xQHlXKJDlCZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z +lCdcbChKoAJY7SBV9PUobMTE3VwQ9MeX/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2cea NI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL 5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/FdrdgkvZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6 dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQLMor+WhVsSozwfVnMdWJ2DpcDZF0M Elj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUpKzYoR7UX1IS7qg+I62+BLALV UGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw1oN3znOkZTsyJg3+pecQ h3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6fG8frR4qH2xaXZzl 12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaUfDqolJR9FHNn 8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/Ly9ASKFfQ soWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg6+nt xeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNc RkE09LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9 So6/0ZoloVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAl DIgT6qCijr9RpfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKF S+dOSHMNqAO+OgSL74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgA Q6EYJGJEKSpORxx/YzZWzlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu3 7FUpnnAKfqWFsEbURI0KfQFs+aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc 4NWWGWZPtG6FUO1Lbm91c9emdypkWT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRs w/SPCBs649ejosWLyePA69W/jD6+aNL0TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOl v+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eBLq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rv jfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHtheMFApjuwY+19N+XlMEIdwrjCCAYzMzPB lmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfrxU8bLnaElNzqRkDukuUTUx8TddxT 0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPxiLiyxRyQADa0QH6rra19b88e fkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/NyN782J1ZGT4FTBcuDjP9 fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI4NQUqa0NNWkqPMIb pAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2eOTHpM8vdh3+ ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzYu3r16ifl 5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfnFWSn MYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqc NpaYTgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtk TMATCfNyc/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55Mkdw IOGi/IgB4GRgxJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav 8CIKCCnSNuPHqTEu2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4 pS5wGNCFnE4CHH5wzLfujS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VX XyVZ298iRFFR0dKlS+k0b1966SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQF U6euf/ppGma6SLVz586TJ0/Sj/DO24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABj QEVFxfPPP09+jxgMMKCKFpCBIoNf0fjNYPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7 oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqqFVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFB oYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxItm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBX ZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQexTCSw616MzcyJwIZr8UqYoQHJZqQ0 0KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwqbMYsASa82UljgCjbzIloGKrp R4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNauLDPXNBQ2Y5Zsb2aaETTQ jTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McYO3syWGgnRNkB29eh bZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCxJ+ONl8ojtTAJ IWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1ol2MUFaQ GrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8JGPDD ecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --------------060501040206040609030701-- --------------030803080700000003030502-- From nobody Thu Jan 22 05:46:35 2015 Return-Path: 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 C889A1ACC8B for ; Thu, 22 Jan 2015 05:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 4z6PUBnwMfic for ; Thu, 22 Jan 2015 05:46:24 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067711A017D for ; Thu, 22 Jan 2015 05:46:23 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKVMD/LkuCqrFqmRTjLto7iQBhN3e3kWp7@postini.com; Thu, 22 Jan 2015 05:46:23 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0MDkLt4019330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Jan 2015 08:46:21 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 Jan 2015 08:46:20 -0500 From: "Gould, James" To: Michael Holloway Thread-Topic: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase Thread-Index: AQHQK2YwQl5JVElI9UChfyCYUoIA/Jy20n+AgAAe+YCAAAk6AIAABGEAgAAYOoCAATgXAIAFFNgAgACr8ICAAFsEgIAAF1sAgAAI+ACACuPxAIABjWoAgAAvWQCAAUjdgIAAG44A Date: Thu, 22 Jan 2015 13:46:20 +0000 Message-ID: <22C1A66A-7868-486E-A120-AE7C4912AE7A@verisign.com> References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> <54BFAC7A.7090500@comlaude.com> <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com> <54C0E811.8030602@comlaude.com> In-Reply-To: <54C0E811.8030602@comlaude.com> 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_22C1A66A7868486EA120AE7C4912AE7Averisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 13:46:34 -0000 --_004_22C1A66A7868486EA120AE7C4912AE7Averisigncom_ Content-Type: multipart/alternative; boundary="_000_22C1A66A7868486EA120AE7C4912AE7Averisigncom_" --_000_22C1A66A7868486EA120AE7C4912AE7Averisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, We had the discussion a while back on the provreg mailing list ( http://www= .ietf.org/mail-archive/web/provreg/current/msg07286.html ) about support fo= r overlapping phases, which resulted in adding the text in the 09 draft to = handle the overlap of the =93claims=94 and =93landrush=94 phases. I view a= phase as a TLD level attribute as opposed to a domain level attribute that= defines the interface expected by the server. Supporting a list of phases= adds undue complexity in draft-ietf-eppext-launchphase. For the Trademark Check Form, the element is not passed in t= he command or returned in the response since it=92s really not applicable. = The element is being set to optional (minOccurs=3D=930=94) = for the check command (checkType) and response (chkDataType), but is define= d as required in the text for the Claims Check Form and Availability Check = Form. Let me know whether this makes sense. Thanks, =97 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 On Jan 22, 2015, at 7:07 AM, Michael Holloway > wrote: Hi James Yes I think that wording is fine, but [at the risk of pointlessly complicat= ing the issue again], there are possibly multiple concurrent phases. In som= e instances, a domain might be valid in more than one (e.g. a regional TLD = where phases depend on the registrants location or type), and in some cases= such as collisions the domain might only be available in one of the active= phases (e.g. collisions). Is it worth loosing to an "an" instead of "the" = phase? Veto if you think its pointless. Contains the value of an active launch phase of the server= supporting claims. The server SHOULD validate the value against the activ= e server launch phase supporting claims. Also, TM check form should be a SHOULD 3.1.3 Trademark Check Form ... The launch phase that SHOULD be "trademark" Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/21/2015 05:30 PM, Gould, James wrote: Michael, How about just using a more generic description of the eleme= nt in both the Claims Check Form of section 3.1.1 and the Claims Create For= m of section 3.3.2, since both forms can be executed outside of the =93clai= ms=94 phase? Something like the description from the General Create Form o= f section 3.3.3: Contains the value of the active launch phas= e of the server. The server SHOULD validate the value against the active s= erver launch phase. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 21, 2015, at 8:41 AM, Michael Holloway > wrote: Thanks James >From a registrar perspective I would say this solves the issue without the = risk of breaking working clients. I would be interested to hear the opinion= of anyone [else] representing registries here whether they would support t= he extra type attribute since its essentially optional extra, or whether th= ey would prefer to support using he existing schema. I think in the case of the latter it would suggest using Claims check on ph= ases outside of "claims" (e.g. "open"), and then some guidance would need = to be offered (in the draft) to define exactly what the "open" phase is; .I= .E is it the period after claims, or is the 'open registration' (aka genera= l availability) period during the claims period; and therefore when to and = when not to use the "open" phase. Some minor wording changes would be requi= red in 3.1.1 Claims check form to change it from `The launch phase that SHO= ULD be "claims"` , to "MAY", perhaps with a bit more info. In light of the above I think it would be far simpler to go with the Tradem= ark check form, so hopefully we can agree with that! That would be my vote = anyway! Regards, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/20/2015 02:58 PM, Gould, James wrote: All, I had a private thread with some about the proposal of referencing the past= =93claims=94 phase in the claims check command to support Trung=92s reques= t. The issue is that some clients are hard coding =93claims=94 as the phas= e in the claims check command and currently there is little to no support f= or the claims check command outside of the =93claims=94 phase, so clients m= ay inadvertently go through the claims process when it is not required or e= ven potentially rejected on create. I see the concern with adding a new fe= ature that may inadvertently cause interface issues. Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a = name independent of the requirement for a claims notice for other use cases= like the resale of domain names. We already support a =93type" attribute in the element, sect= ion 3.1, to define the check form of the command, which currently support = =93claims=94 and =93avail=94 for the Claims Check Form and the Availability= Check Form, respectively. The default form is the Claims Check Form, whic= h is updated to return =93exists=3D1=94 if there is a matching trademark an= d a claims notice is required on create, per the proposed check changes. W= e could add a Trademark Check Form (e.g. add section 3.1.3) that is indicat= ed by setting the =93type=94 attribute to =93trademark=94. The interface f= or the Trademark Check Form is consistent with the Claims Check Form, excep= t the element is not applicable, so therefore in the schema = we would make the element optional, and the server would onl= y match the domain to the matching set of trademarks to return the same res= ponse as with the Claims Check Form. The element would stil= l be required for the Claims Check Form and the Availability Check Form bas= ed on the draft text. As stated in section 3.1, the forms supported by the= server is determined by server policy, so the Trademark Check Form would i= s an option but is not required. The check command using the Trademark Che= ck Form would look like: C: C: C: C: C: C: example1.tld C: example2.tld C: C: C: C: C: C: ABC-12345 C: C: To support this, section 3.1.3 Trademark Check Form would need to be added = along with some text changes on the =93trademark=94 value for the =93type= =94 attribute in section 3.1, would = need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema. Let me know your thoughts on this option. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 10:40 AM, Gould, James > wrote: Michael, I provide feedback inline below. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 10:08 AM, Michael Holloway > wrote: Hi Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrations.= The post claims lookup seems to be aimed at determining, for information p= urposes only (without "acking" in the create), whether or not there is a tr= ademark registered against the term (i.e. label only) therefore there is no= reason to check claims via TLD. This is a little OT anyway (my fault sorry= ), but hopefully you see where I am coming from. The use case for the claims check post the claims phase is used to address = the release of domain names that did not go through 90 days of claims, whic= h I believe is a modified version of your #2 below. Let=92s take the three basic phases defined in draft-ietf-eppext-launchphas= e as an example with sunrise, claims, and open. We can pretty much remove = the sunrise phase from the example for now, so let=92s focus on the claims = and open phases. Assuming that claims.tld is available through sunrise and= the claims phase, so if a claims check is done with =93open=94 as the phas= e, the response would be exists=3D=930=94, since there is no requirement to= provide the claims notice on create. If reserved.tld was released during = the =93open=94 phase, then a claims check on reserved.tld, with =93open=94 = as the phase, the response would be exists=3D=931=94, since a claims notice= is required on create. Based on Trung=92s use case, a client may want to = know whether or not there is a trademark on the domain name independent of = when the domain name is released, so the client can send a claims check wit= h the phase as =93claims=94 to get that answer. Back to LaunchPhase: my concern with simply using the "claims" phase is tha= t it can cause ambiguity, take the following four phase statuses, and compa= re with the logic below (to which I commented in underlined red) 1) A registry must operate a 90 days claims phase 2) A registry must operate 90 days extended claims period on domains that a= re released at a later date (collisions etc, and I don't know what may be c= oming up in the future) 3) A registry may operate a continued claims phase past the 90 domains for = all domains. [create with claims form] 4) [new]: A registry may operate a post claims (matching trademark past the= claims phase use case) [create without claims] If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create f= orm would be incorrect at this point despite receiving claims=3Dtrue. This = is why I suggest a different sub_phase should be used, OR a different flag = added (more complex of course) to differentiate. Based on the updated text, the client will only receive a claims check resp= onse with exists=3D=931=94 if =93create with claims form=94 is required. T= he updated text does not support #4, since the only time that =93exists=3D0= =94 is if a claims notice is required. This way a client can continue to u= se the claims check without any extra logic of passing special attributes o= r sub-phases to get the answer that is needed, which is whether a claims no= tice is required on create. Trung use case is an exception to the rule, wh= ere a client wants to know whether there is a matching trademark for the do= main name independent of whether a claims notice is required on create, so = passing =93claims=94 as the phase past the =93claims=94 phase may support t= hat. Let me know whether or not this helps. I hope this makes sense; and apologies if I am missing something fundamenta= l! Cheers, Michael 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue ## The claims exists but it is NOT require= d on domain_create * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return ## How does the client know= if 90 days has passed (extended / post claims) or not without external sou= rce? * claims notice is required * else * claims notice is NOT required Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 02:44 PM, Gould, James wrote: Michael, The split out of the responsibility of the registries and the CNIS / TMDB w= as worked out a couple of years ago, where there was a desire to not make t= he CNIS the critical path for the majority of the registrations. The agree= ment was for the registries to provide the claims check service and enforce= the claims notice on create based on a feed of trademark labels from the T= MDB to the registries. The proposal is to support the claims service post the =93claims=94 phase b= y passing the active phase to the server and the server will return whether= or not the claims notice is required based on a combination of a matching = trademark and whether the domain name already went through 90 days of the c= laims service. From a client perspective it means utilizing the claims che= ck in a similar fashion during and post the claims phase. The use case bro= ught up by Trung was more of an exception to the rule, in the client wantin= g to know whether there is a matching trademark for a domain name independe= nt of the requirement for passing the claims notice. In that case, the pro= posal is to pass =93claims=94 as the phase independent of the active phase = to get a true or false answer to whether a trademark matches the domain nam= e. Do the proposals work for you? Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 13, 2015, at 3:18 AM, Michael Holloway > wrote: Hi all Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= . The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not t= o submit claims data in a domain_create if the domain has a claim. As it is= , various registries are extending the claims periods past 90 days, so its = contradictory to have extended claims and post claims defined the same way = in the query but without a defined (or facilitated) way to differentiate th= e requirement for a domain_create. I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB. Cheers, Michael Michael Holloway Senior Systems Administrator | Com Laude E: michael.holloway@comlaude.com On 01/13/2015 04:04 AM, Tran, Trung wrote: This works for me, Jim. Though it=92s not often, we have cases where chang= e in ownership of a domain might not occur if there=92s trademark against t= he name. So a potential registrant might not want to buy an existing regis= tered name if there=92s trademark against it in the TMCH. Thanks, Trung From: , James > Date: Friday, January 9, 2015 at 11:27 AM To: Jody Kolker > Cc: Francisco Obispo >, "eppext@ietf.org" >, "Tran, Trung" > Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Jody, I believe that passing the active phase is more straight forward as opposed= to defining a special sub-phase like =93extended" to drive the behavior. = Having the claims check return =93exists=3Dtrue=94 only when a claims notic= e is required on the create based on the active phase should be able to han= dle the use case of releasing domains post the claims phase and also applie= s to the claims phase. All names that have matching trademarks during the = claims phase will require a claims notice on create, so the behavior is con= sistent. I=92m still not sure why a client would want to know whether there is a mat= ching trademark when a claims notice is not required on the create. Does a= nyone see a need for this? Since the =93claims=94 phase would always retur= n =93exists=3Dtrue=94 for domains that have matching trademarks, a client c= ould pass the =93claims=94 phase when the active phase is not the =93claims= =94 phase to obtain this information. Of course servers would need to supp= ort referencing a past =93claims=94 phase to support this use case. The ch= ange in the text should support the logic that I previously posted before, = which I extend to support addressing the optional matching trademark past t= he claims phase use case. Is this use case really needed? 1. During claims phase with a claims check command * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 3. During post claims phase with a claims phase check and passing =93cla= ims=94 as the phase (optional matching trademark past the claims phase use = case) * If domains has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required Thoughts? =97 JG [X] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 4:50 PM, Jody Kolker > wrote: >From Francisco: Thanks Jim for bringing this to the eppext. This will definitely help the = post claims phase. With the wording changes, is there still a way to determine if there=92s a = trademark against the name regardless on whether or not the claims ack is n= eeded in the create domain? This could be accomplished by leaving the =93claims=94 implementation as it= is currently and introducing a sub-phase for claims named =93extended=94. = When the sup-phase of =93extended=94 is passed the results from Jim=92s ea= rlier email would be below. 1. During claims phase with a claims check command or post claims phase = without a sub-phase of =93extended=94 * If domain has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 2. During post claims phase with a claims check command with a sub-phase= of =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark * return exists=3Dtrue * else * return exists=3Dfalse 1. During claims phase with a create command or post claims phase withou= t a sub-phase of =93extended=94 * If domain has matching trademark * claims notice is required * else * claims notice is NOT required 2. During post claims phase with a create command with a sub-phase of = =93extended=94 * If domain was released post claims phase start and is within 90 da= ys of release and has matching trademark return * claims notice is required * else * claims notice is NOT required This would still allow a registrar to determine if a claim currently exists= on a domain when a claim period does not exist for the TLD (the current im= plementation). From a registrar perspective, I=92m not sure if determining= if a domain has a claim when all claims periods have expired is needed. T= his implementation also would require additional work by all registrars to = support if adopted, while the implementation from Jim=92s first post would = require only updates by the registries which would be better for widespread= adoption. Thoughts? Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall = (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by t= he addressee(s) named herein and may contain confidential information. If y= ou have received this email in error, please immediately notify the sender = and permanently delete the original and any copy of this message and its at= tachments. From: Gould, James [mailto:JGould@verisign.com] Sent: Thursday, January 08, 2015 12:24 PM To: Francisco Obispo Cc: Jody Kolker; eppext@ietf.org; Tran, Trung Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims S= ervice" post the Claims Phase Francisco, I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name. Is there a material behavior change between the two phases= and is the concept of an extended claims phase a generic use case? We hav= e stuck with the standard set of =93sunrise=94, =93claims=94, and =93open= =94 phases. Have others utilized the use of sub-phases or have created cus= tom top-level phase names to meet their needs? If so, can you share your s= cheme? It would be good to know if there are any common patterns. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 8, 2015, at 3:08 PM, Francisco Obispo > wrote: SHOULD contain the value of "claims" to indicate the claims launch phase. A value other than "claims" MAY be used to pass the claims notice for domain names outside of the claims phase. Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but w= e thought it would be too complicated for RARs to change their code, so we = decided just to trigger it by calling the phase =93sunsrise=94, but in real= ity, a registry can call it anything they want in order to support it, beca= use they are different things. Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise. On Jan 8, 2015, at 11:35 AM, Gould, James > wrote: What do you mean by the extended claims phase? Is there a past mail list t= hread on this or is this a new issue? Please clarify. Francisco Obispo CTO - Registry Operations 2161 San Joaquin Hills Rd. Newport Beach, CA, 92660 off. +1.345.749.6284 fax. +1.345.746.6263 _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_22C1A66A7868486EA120AE7C4912AE7Averisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8FA5451B70D9124DBD4BE9F5A23BA7F2@verisign.com> Content-Transfer-Encoding: quoted-printable Michael,

We had the discussion a while back on the provreg mailing list ( http://www.ietf.org/mail-archive/web/provreg/current/msg07286.html ) ab= out support for overlapping phases, which resulted in adding the text in th= e 09 draft to handle the overlap of the =93claims=94 and =93landrush=94 pha= ses.  I view a phase as a TLD level attribute as opposed to a domain level attribute that defines the interface expected= by the server.  Supporting a list of phases adds undue complexity in&= nbsp;draft-ietf-eppext-launchphase.

For the Trademark Check Form, the <launch:phase> element is not = passed in the command or returned in the response since it=92s really not a= pplicable.  The <launch:phase> element is being set to optional = (minOccurs=3D=930=94) for the check command (checkType) and response (chkDataType), but is defined as required in the text for the Cla= ims Check Form and Availability Check Form.  Let me know whether this = makes sense.

Thanks,

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 22, 2015, at 7:07 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:
Hi James

Yes I think that wording is fine, but [at the risk of pointlessly complicat= ing the issue again], there are possibly multiple concurrent phases. In som= e instances, a domain might be valid in more than one (e.g. a regional TLD = where phases depend on the registrants location or type), and in some cases such as collisions the domain might o= nly be available in one of the active phases (e.g. collisions). Is it worth= loosing to an "an" instead of "the" phase? Veto if you= think its pointless.

<launch:phase>   Contains the value of an active launch phase of= the server supporting claims.  The server SHOULD validate the value a= gainst the active server launch phase supporting claims.

Also, TM check form should be a SHOULD
3.1.3 Trademark Check Form
...
<launch:phase>   The launch phase that SHOULD be "trademark= "


Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/21/2015 05:30 PM, Gould, James wrote:
Michael,

How about just using a more generic description of the <launch:phas= e> element in both the Claims Check Form of section 3.1.1 and the Claims= Create Form of section 3.3.2, since both forms can be executed outside of = the =93claims=94 phase?  Something like the description from the General Create Form of section 3.3.3:

              <launch:phase> =   Contains the value of the active launch phase of the server.  T= he server SHOULD validate the value against the active server launch phase.=


=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<Mail Attachment.png>=

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 21, 2015, at 8:41 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Thanks James

>From a registrar perspective I would say this solves the issue without the = risk of breaking working clients. I would be interested to hear the opinion= of anyone [else] representing registries here whether they would support t= he extra type attribute since its essentially optional extra, or whether they would prefer to support using = he existing schema.

I think in the case of the latter it would suggest using Claims check on ph= ases outside of "claims" (e.g. "open"),  and then = some guidance would need to be offered (in the draft) to define exactly wha= t the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availabilit= y) period during the claims period; and therefore when to and when not to use = the "open" phase. Some minor wording changes would be required in= 3.1.1 Claims check form to change it from `The launch phase that SHOULD= be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Tradem= ark check form, so hopefully we can agree with that! That would be my vote = anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the= past =93claims=94 phase in the claims check command to support Trung=92s r= equest.  The issue is that some clients are hard coding =93claims=94 a= s the phase in the claims check command and currently there is little to no support for the claims check command outside of the = =93claims=94 phase, so clients may inadvertently go through the claims proc= ess when it is not required or even potentially rejected on create.  I= see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not cra= zy about making an XML schema change, we may be able to tweak things to sup= port both the the claims check outside of the =93claims=94 phase and also s= upport Trung=92s request to determine whether or not a trademark matches a name independent of the requirement for a cla= ims notice for other use cases like the resale of domain names.

We already support a =93type" attribute in the <launch:check&g= t; element, section 3.1, to define the check form of the command, which cur= rently support =93claims=94 and =93avail=94 for the Claims Check Form and t= he Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return =93exists=3D1=94= if there is a matching trademark and a claims notice is required on create= , per the proposed check changes.  We could add a Trademark Check Form= (e.g. add section 3.1.3) that is indicated by setting the =93type=94 attribute to =93trademark=94.  The interfac= e for the Trademark Check Form is consistent with the Claims Check Form, ex= cept the <launch:phase> element is not applicable, so therefore in th= e schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademar= ks to return the same response as with the Claims Check Form.  The <= ;launch:phase> element would still be required for the Claims Check Form= and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the ser= ver is determined by server policy, so the Trademark Check Form would is an= option but is not required.  The check command using the Trademark Ch= eck Form would look like:

   C:<?xml version=3D"1.0&quo=
t; encoding=3D"UTF-8" standalone=3D"no"?>
   C:<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain=3D"urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch=3D"urn:ietf:params:xml:ns:launch-1.0"
   C:     type=3D=93trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be a= dded along with some text changes on the =93trademark=94 value for the =93t= ype=94 attribute in section 3.1, <e= numeration value=3D=93trademark=94/> would need to be added to the checkFormType in the schema, and minOccurs=3D=930= =94 would need to be added to the =93phase=94 element of checkType in the s= chema.    

Let me know your thoughts on this option. 

Thanks,

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<= ;Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:=

Michael,

I provide feedback inline below.  

=97=
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


= <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
 James Gould
<= font color=3D"#6B6D71">Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this= point the CNIS (label+tld) itself it no longer required for registrati= ons. The post claims lookup seems to be aimed at determining, for informati= on purposes only (without "acking" in the create), whether or not there is a trademark registered against the te= rm (i.e. label only) therefore there is no reason to check claims via TLD. = This is a little OT anyway (my fault sorry), but hopefully you see where I = am coming from.

The use case for the claims check post the claims phase is used to add= ress the release of domain names that did not go through 90 days of claims,= which I believe is a modified version of your #2 below.  

Let=92s take the three basic phases defined in draft-ietf-eppext-= launchphase as an example with sunrise, claims, and open.  We can pret= ty much remove the sunrise phase from the example for now, so let=92s focus= on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a clai= ms check is done with =93open=94 as the phase, the response would be exists= =3D=930=94, since there is no requirement to provide the claims notice on c= reate.  If reserved.tld was released during the =93open=94 phase, then a claims check on reserved.tld, with =93open=94= as the phase, the response would be exists=3D=931=94, since a claims notic= e is required on create.  Based on Trung=92s use case, a client may wa= nt to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client= can send a claims check with the phase as =93claims=94 to get that answer.=    



Back to LaunchPhase: my concern with simply using the "claims" ph= ase is that it can cause ambiguity, take the following four phase statuses,= and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains= that are released at a later date (collisions etc, and I don't know what m= ay be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domai= ns for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create w<= /span>ithout claims]

If the client checks a domain for claims and gets result claims=3Dtrue, the= n how does it know which of the above rules matched? In the case of (4) the= claims lookup returns true even though the domain is no longer in (1) or (= 2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this poi= nt despite receiving claims=3Dtrue. This is why I suggest a different sub_p= hase should be used, OR a different flag added (more complex of course) to = differentiate.


Based on the updated text, the client will only receive a claims check= response with exists=3D=931=94 if =93create with claims form=94 is require= d.  The updated text does not support #4, since the only time that =93= exists=3D0=94 is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic = of passing special attributes or sub-phases to get the answer that is neede= d, which is whether a claims notice is required on create.  Trung use = case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domai= n name independent of whether a claims notice is required on create, so pas= sing =93claims=94 as the phase past the =93claims=94 phase may support that= .  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I = am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue ## The claims exists but it is NOT required on domain_cre= ate
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return ## How does the client know if 90 days has passed (= extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / T= MDB was worked out a couple of years ago, where there was a desire to not m= ake the CNIS the critical path for the majority of the registrations.  = ;The agreement was for the registries to provide the claims check service and enforce the claims notice on creat= e based on a feed of trademark labels from the TMDB to the registries. &nbs= p;

The proposal is to support the claims service post the =93claims=94 ph= ase by passing the active phase to the server and the server will return wh= ether or not the claims notice is required based on a combination of a matc= hing trademark and whether the domain name already went through 90 days of the claims service.  From a clie= nt perspective it means utilizing the claims check in a similar fashion dur= ing and post the claims phase.  The use case brought up by Trung was m= ore of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name in= dependent of the requirement for passing the claims notice.  In that c= ase, the proposal is to pass =93claims=94 as the phase independent of the a= ctive phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

=97
<= span style=3D"font-size: 11pt;">
<= span style=3D"font-size: 11pt;">JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@co= mlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the = TMDB by adding a lookup based on label. This could return a simple true/fal= se value, or all the info returned on a CNIS lookup exception notice_id etc= .

The problem with having and post claims service on the EPP server without c= hanging the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a cla= im. As it is, various registries are extending the claims periods past 90 d= ays, so its contradictory to have extended claims and post claims defined t= he same way in the query but without a defined (or facilitated) way to differentiate the requirement for a doma= in_create.

I would be more comfortable with defining a specific sub_phase for the purp= ose, or even better skipping the middle man and going straight to the TMDB.=

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: <= span style=3D"color:#219547">michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it=92s not often, we have cases w= here change in ownership of a domain might not occur if there=92s trademark= against the name.  So a potential registrant might not want to buy an= existing registered name if there=92s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign= .com>
Date: Friday, January 9, 2015 at 11= :27 AM
To: Jody Kolker <jkolker@godaddy.com>= ;
Cc: Francisco Obispo <fobispo@uniregist= ry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-ep= pext-launchphase Support for a "Claims Service" post the Claims P= hase

Jody,

I believe that passing the active phase is more straight forward as op= posed to defining a special sub-phase like =93extended" to drive the b= ehavior.  Having the claims check return =93exists=3Dtrue=94 only when= a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domain= s post the claims phase and also applies to the claims phase.  All nam= es that have matching trademarks during the claims phase will require a cla= ims notice on create, so the behavior is consistent.  

I=92m still not sure why a client would want to know whether there is = a matching trademark when a claims notice is not required on the create. &n= bsp;Does anyone see a need for this?  Since the =93claims=94 phase wou= ld always return =93exists=3Dtrue=94 for domains that have matching trademarks, a client could pass the =93claims=94 phase when = the active phase is not the =93claims=94 phase to obtain this information. =  Of course servers would need to support referencing a past =93claims= =94 phase to support this use case.  The change in the text should support the logic that I previously posted before, which I= extend to support addressing the optional matching trademark past the clai= ms phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
  3. During post claims phase with a claims phase check and passing = =93claims=94 as the phase (optional matching trademark past the claims phas= e use case)
    1. If domains has matching trademark 
      1. return exists=3Dtrue
    2. else
      1. return exists=3Dfalse

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of= release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

=97=

JG




James Gould
Distinguished Engineer
jgould@= Verisign.com

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

VerisignInc.com=

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:
From Francisco:
&nbs= p;
Than= ks Jim for bringing this to the eppext.  This will definitely help the p= ost claims phase.
&nbs= p;
With the wording changes, is there still a way to determine if there=92s a trad= emark against the name regardless on whether or not the claims ack is neede= d in the create domain?  
 =
This could be accomplished by leaving the =93claims=94 implementation as it is = currently and introducing a sub-phase for claims named =93extended=94. = ; When the sup-phase of =93extended=94 is passed the results from Jim=92s e= arlier email would be below.
 =
  1. During claims phase with a claims check command or post claims phase withou= t a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse
  2. During post claims phase with a claims check command with a sub-phase of = =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    2. else 
      1. return exists=3Dfalse 
 
  1. During claims phase with a create command or post claims phase without= a sub-phase of =93extended=94
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase o= f =93extended=94
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on = a domain when a claim period does not exist for the TLD (the current implem= entation).  From a registrar perspective, I=92m not sure if determinin= g if a domain has a claim when all claims periods have expired is needed.  This implementation also would requi= re additional work by all registrars to support if adopted, while the imple= mentation from Jim=92s first post would require only updates by the registr= ies which would be better for widespread adoption.
 =
Though= ts?
 =
Thanks= ,
Jody Kolker
319-29= 4-3933 (office)
319-32= 9-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadn= all@godaddy.com) with any feedback.
 =
This email message and any attachments hereto is intended for use only by the a= ddressee(s) named herein and may contain confidential information. If you h= ave received this email in error, please immediately notify the sender and = permanently delete the original and any copy of this message and its attachments.
 =
From= : Gould, James [mailt= o:JGould@verisign.com] 
Sent: Thursday, Ja= nuary 08, 2015 12:24 PM
To: Francisco Obis= po
Cc: Jody Kolker; eppex= t@ietf.org; Tran, Trung
Subject: Re: [eppe= xt] draft-ietf-eppext-launchphase Support for a "Claims Service" = post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavio= r between the two claims phases are consistent (e.g. requirement for claims= check and claims notice) I=92m not sure the value in defining a new top-le= vel phase name.  Is there a material behavior change between the two phases and is the concept of an extended c= laims phase a generic use case?  We have stuck with the standard set o= f =93sunrise=94, =93claims=94, and =93open=94 phases.  Have others uti= lized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme? &= nbsp;It would be good to know if there are any common patterns.  =
 
Thanks,
 
=97<= /span>
&nbs= p;

JG


<image001.png>
 James Gould
Distinguis= hed Engineer
jgou= ld@Verisign.com

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

Veri= signInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobis= po@uniregistry.com> wrote:


<launc= h:phase>  SHOULD contain the value of "claims" to indicat= e the
       claims launch phase.  A value other than &q= uot;claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase. &= nbsp;
 
 
Once a TLD has ended the mandatory 90 day period of =93claims=94 a registry= might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended su= nrise for the names on the ICANN names-collision block list (30 day period = instead of a 60 day end-date sunrise), and we initially thought about havin= g a phase called =93sunrise=94 with a sub-phase called =93extended=94 but we thought it would be too complicat= ed for RARs to change their code, so we decided just to trigger it by calli= ng the phase =93sunsrise=94, but in reality, a registry can call it anythin= g they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems li= ke we=92re going to end up with discrete phase names for anything that is n= ot: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGoul= d@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail l= ist thread on this or is this a new issue?  Please clarify.=

 
Fr= ancisco Obispo CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newp= ort Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinf=
o/eppext
_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinf= o/eppext



_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinf= o/eppext



_______________________________________________
EppExt mailing list
EppExt@ietf.org
https://www.ietf.org/mailman/listinf=
o/eppext


_______________________________________________
EppExt mailing list
EppExt@ietf.org=
https://www.ietf.org/mailman/listinfo/eppext


--_000_22C1A66A7868486EA120AE7C4912AE7Averisigncom_-- --_004_22C1A66A7868486EA120AE7C4912AE7Averisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 22 Jan 2015 13:46:20 GMT"; modification-date="Thu, 22 Jan 2015 13:46:20 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_22C1A66A7868486EA120AE7C4912AE7Averisigncom_-- From nobody Thu Jan 22 05:52:36 2015 Return-Path: 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 C46491ACCC7 for ; Thu, 22 Jan 2015 05:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.438 X-Spam-Level: * X-Spam-Status: No, score=1.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 oCvHEwriS8dH for ; Thu, 22 Jan 2015 05:52:23 -0800 (PST) Received: from smtp75.ord1c.emailsrvr.com (smtp75.ord1c.emailsrvr.com [108.166.43.75]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37AA1A1A31 for ; Thu, 22 Jan 2015 05:52:22 -0800 (PST) Received: from smtp10.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 673B638044E; Thu, 22 Jan 2015 08:52:22 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5FCEA38017D; Thu, 22 Jan 2015 08:52:22 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.ord1c.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id 81C6138044E; Thu, 22 Jan 2015 08:52:19 -0500 (EST) X-Sender-Id: m4bh@comlaude.com Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Thu, 22 Jan 2015 13:52:22 GMT Message-ID: <54C10092.4040906@comlaude.com> Date: Thu, 22 Jan 2015 14:52:18 +0100 From: Michael Holloway User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Gould, James" References: <64BB8C0B-ED45-4384-AC10-BC0E5206E26E@uniregistry.com> <54B4D4F1.6070405@comlaude.com> <54B534E2.8050001@comlaude.com> <80B85CA7-F0E5-4418-92E3-BACFE1BEDBAA@verisign.com> <4DA7DF42-F833-484E-82BC-DBB0B823AFC2@verisign.com> <54BFAC7A.7090500@comlaude.com> <378DCFEE-69D7-468E-B928-EE35378FE875@verisign.com> <54C0E811.8030602@comlaude.com> <22C1A66A-7868-486E-A120-AE7C4912AE7A@verisign.com> In-Reply-To: <22C1A66A-7868-486E-A120-AE7C4912AE7A@verisign.com> Content-Type: multipart/alternative; boundary="------------080704020109060007090100" Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 13:52:33 -0000 This is a multi-part message in MIME format. --------------080704020109060007090100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Okay agreed, all good. Sorry I got my lanes crossed on the Trademark Claims Check re type attribute vs phase name... *Michael Holloway Senior Systems Administrator**| Com Laude* E: michael.holloway@comlaude.com D: +44 20 7421 8273 On 01/22/2015 02:46 PM, Gould, James wrote: > Michael, > > We had the discussion a while back on the provreg mailing list ( > http://www.ietf.org/mail-archive/web/provreg/current/msg07286.html ) > about support for overlapping phases, which resulted in adding the > text in the 09 draft to handle the overlap of the “claims” and > “landrush” phases. I view a phase as a TLD level attribute as opposed > to a domain level attribute that defines the interface expected by the > server. Supporting a list of phases adds undue complexity > in draft-ietf-eppext-launchphase. > > For the Trademark Check Form, the element is not passed > in the command or returned in the response since it’s really not > applicable. The element is being set to optional > (minOccurs=“0”) for the check command (checkType) and response > (chkDataType), but is defined as required in the text for the Claims > Check Form and Availability Check Form. Let me know whether this > makes sense. > > Thanks, > > — > > > JG > > > > > *James Gould > *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > On Jan 22, 2015, at 7:07 AM, Michael Holloway > > > wrote: > >> Hi James >> >> Yes I think that wording is fine, but [at the risk of pointlessly >> complicating the issue again], there are possibly multiple concurrent >> phases. In some instances, a domain might be valid in more than one >> (e.g. a regional TLD where phases depend on the registrants location >> or type), and in some cases such as collisions the domain might only >> be available in one of the active phases (e.g. collisions). Is it >> worth loosing to an "an" instead of "the" phase? Veto if you think >> its pointless. >> >> Contains the value of an active launch phase of the >> server supporting claims. The server SHOULD validate the value >> against the active server launch phase supporting claims. >> >> Also, TM check form should be a SHOULD >> 3.1.3 Trademark Check Form >> ... >> The launch phase that SHOULD be "trademark" >> >> >> Cheers, >> Michael >> >> *Michael Holloway >> Senior Systems Administrator**| Com Laude* >> E: michael.holloway@comlaude.com >> >> >> On 01/21/2015 05:30 PM, Gould, James wrote: >>> Michael, >>> >>> How about just using a more generic description of the >>> element in both the Claims Check Form of section >>> 3.1.1 and the Claims Create Form of section 3.3.2, since both forms >>> can be executed outside of the “claims” phase? Something like the >>> description from the General Create Form of section 3.3.3: >>> >>> Contains the value of the active >>> launch phase of the server. The server SHOULD validate the value >>> against the active server launch phase. >>> >>> >>> — >>> >>> JG >>> >>> >>> >>> >>> *James Gould >>> *Distinguished Engineer >>> jgould@Verisign.com >>> >>> 703-948-3271 >>> 12061 Bluemont Way >>> Reston, VA 20190 >>> >>> VerisignInc.com >>> >>> On Jan 21, 2015, at 8:41 AM, Michael Holloway >>> >> > wrote: >>> >>>> Thanks James >>>> >>>> From a registrar perspective I would say this solves the issue >>>> without the risk of breaking working clients. I would be interested >>>> to hear the opinion of anyone [else] representing registries here >>>> whether they would support the extra type attribute since its >>>> essentially optional extra, or whether they would prefer to support >>>> using he existing schema. >>>> >>>> I think in the case of the latter it would suggest using Claims >>>> check on phases outside of "claims" (e.g. "open"), and then some >>>> guidance would need to be offered (in the draft) to define exactly >>>> what the "open" phase is; .I.E is it the period _after_ claims, or >>>> is the 'open registration' (aka general availability) period >>>> _during_ the claims period; and therefore when to and when not to >>>> use the "open" phase. Some minor wording changes would be required >>>> in 3.1.1 Claims check form to change it from `/The launch phase >>>> that SHOULD be "claims"`/ , to "MAY", perhaps with a bit more info. >>>> >>>> In light of the above I think it would be far simpler to go with >>>> the Trademark check form, so hopefully we can agree with that! That >>>> would be my vote anyway! >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> >>>> *Michael Holloway >>>> Senior Systems Administrator**| Com Laude* >>>> E: michael.holloway@comlaude.com >>>> >>>> On 01/20/2015 02:58 PM, Gould, James wrote: >>>>> All, >>>>> >>>>> I had a private thread with some about the proposal of referencing >>>>> the past “claims” phase in the claims check command to support >>>>> Trung’s request. The issue is that some clients are hard coding >>>>> “claims” as the phase in the claims check command and currently >>>>> there is little to no support for the claims check command outside >>>>> of the “claims” phase, so clients may inadvertently go through the >>>>> claims process when it is not required or even potentially >>>>> rejected on create. I see the concern with adding a new feature >>>>> that may inadvertently cause interface issues. Although I am not >>>>> crazy about making an XML schema change, we may be able to tweak >>>>> things to support both the the claims check outside of the >>>>> “claims” phase and also support Trung’s request to determine >>>>> whether or not a trademark matches a name independent of the >>>>> requirement for a claims notice for other use cases like the >>>>> resale of domain names. >>>>> >>>>> We already support a “type" attribute in the >>>>> element, section 3.1, to define the check form of the command, >>>>> which currently support “claims” and “avail” for the Claims Check >>>>> Form and the Availability Check Form, respectively. The default >>>>> form is the Claims Check Form, which is updated to return >>>>> “exists=1” if there is a matching trademark and a claims notice is >>>>> required on create, per the proposed check changes. We could add >>>>> a Trademark Check Form (e.g. add section 3.1.3) that is indicated >>>>> by setting the “type” attribute to “trademark”. The interface for >>>>> the Trademark Check Form is consistent with the Claims Check Form, >>>>> except the element is not applicable, so therefore >>>>> in the schema we would make the element optional, >>>>> and the server would only match the domain to the matching set of >>>>> trademarks to return the same response as with the Claims Check >>>>> Form. The element would still be required for the >>>>> Claims Check Form and the Availability Check Form based on the >>>>> draft text. As stated in section 3.1, the forms supported by the >>>>> server is determined by server policy, so the Trademark Check Form >>>>> would is an option but is not required. The check command using >>>>> the Trademark Check Form would look like: >>>>> >>>>> C: >>>>> C: >>>>> C: >>>>> C: >>>>> C: >>>> C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> >>>>> C: example1.tld >>>>> C: example2.tld >>>>> C: >>>>> C: >>>>> C: >>>>> C: >>>> C: xmlns:launch="urn:ietf:params:xml:ns:launch-1.0" >>>>> C: type=“trademark"/> >>>>> C: >>>>> C: ABC-12345 >>>>> C: >>>>> C: >>>>> >>>>> >>>>> To support this, section 3.1.3 Trademark Check Form would need to >>>>> be added along with some text changes on the “trademark” value for >>>>> the “type” attribute in section 3.1, >>>> value=“trademark”/> would need to be added to the checkFormType in >>>>> the schema, and minOccurs=“0” would need to be added to the >>>>> “phase” element of checkType in the schema. >>>>> >>>>> Let me know your thoughts on this option. >>>>> >>>>> Thanks, >>>>> >>>>> — >>>>> >>>>> JG >>>>> >>>>> >>>>> >>>>> >>>>> *James Gould >>>>> *Distinguished Engineer >>>>> jgould@Verisign.com >>>>> >>>>> 703-948-3271 >>>>> 12061 Bluemont Way >>>>> Reston, VA 20190 >>>>> >>>>> VerisignInc.com >>>>> >>>>> On Jan 13, 2015, at 10:40 AM, Gould, James >>>> > wrote: >>>>> >>>>>> Michael, >>>>>> >>>>>> I provide feedback inline below. >>>>>> >>>>>> — >>>>>> >>>>>> JG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *James Gould >>>>>> *Distinguished Engineer >>>>>> jgould@Verisign.com >>>>>> >>>>>> 703-948-3271 >>>>>> 12061 Bluemont Way >>>>>> Reston, VA 20190 >>>>>> >>>>>> VerisignInc.com >>>>>> >>>>>> On Jan 13, 2015, at 10:08 AM, Michael Holloway >>>>>> >>>>> > wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> Re TMDB: I was thinking specifically of the post claims phase >>>>>>> since at this point the CNIS (label+tld) itself it no longer >>>>>>> required for registrations. The post claims lookup seems to be >>>>>>> aimed at determining, for information purposes only (without >>>>>>> "acking" in the create), whether or not there is a trademark >>>>>>> registered against the term (i.e. label only) therefore there is >>>>>>> no reason to check claims via TLD. This is a little OT anyway >>>>>>> (my fault sorry), but hopefully you see where I am coming from. >>>>>> >>>>>> The use case for the claims check post the claims phase is used >>>>>> to address the release of domain names that did not go through 90 >>>>>> days of claims, which I believe is a modified version of your #2 >>>>>> below. >>>>>> >>>>>> Let’s take the three basic phases defined >>>>>> in draft-ietf-eppext-launchphase as an example with sunrise, >>>>>> claims, and open. We can pretty much remove the sunrise phase >>>>>> from the example for now, so let’s focus on the claims and open >>>>>> phases. Assuming that claims.tld is available through sunrise >>>>>> and the claims phase, so if a claims check is done with “open” as >>>>>> the phase, the response would be exists=“0”, since there is no >>>>>> requirement to provide the claims notice on create. If >>>>>> reserved.tld was released during the “open” phase, then a claims >>>>>> check on reserved.tld, with “open” as the phase, the response >>>>>> would be exists=“1”, since a claims notice is required on create. >>>>>> Based on Trung’s use case, a client may want to know whether or >>>>>> not there is a trademark on the domain name independent of when >>>>>> the domain name is released, so the client can send a claims >>>>>> check with the phase as “claims” to get that answer. >>>>>> >>>>>> >>>>>>> >>>>>>> Back to LaunchPhase: my concern with simply using the "claims" >>>>>>> phase is that it can cause ambiguity, take the following four >>>>>>> phase statuses, and compare with the logic below (to which I >>>>>>> commented in _underlined red_) >>>>>>> 1) A registry _must_ operate a 90 days claims phase >>>>>>> 2) A registry _must_ operate 90 days extended claims period on >>>>>>> domains that are released at a later date (collisions etc, and I >>>>>>> don't know what may be coming up in the future) >>>>>>> 3) A registry _may_ operate a continued claims phase past the 90 >>>>>>> domains for all domains. [create with claims form] >>>>>>> 4) [new]: A registry _may_ operate a post claims (matching >>>>>>> trademark past the claims phase use case) [create without claims] >>>>>>> >>>>>>> If the client checks a domain for claims and gets result >>>>>>> claims=true, then how does it know which of the above rules >>>>>>> matched? In the case of (4) the claims lookup returns true even >>>>>>> though the domain is no longer in (1) or (2) [and the registry >>>>>>> has opted not to do (3)], so using the claims create form would >>>>>>> be incorrect at this point despite receiving claims=true. This >>>>>>> is why I suggest a different sub_phase should be used, OR a >>>>>>> different flag added (more complex of course) to differentiate. >>>>>>> >>>>>> >>>>>> Based on the updated text, the client will only receive a claims >>>>>> check response with exists=“1” if “create with claims form” is >>>>>> required. The updated text does not support #4, since the only >>>>>> time that “exists=0” is if a claims notice is required. This way >>>>>> a client can continue to use the claims check without any extra >>>>>> logic of passing special attributes or sub-phases to get the >>>>>> answer that is needed, which is whether a claims notice is >>>>>> required on create. Trung use case is an exception to the rule, >>>>>> where a client wants to know whether there is a matching >>>>>> trademark for the domain name independent of whether a claims >>>>>> notice is required on create, so passing “claims” as the phase >>>>>> past the “claims” phase may support that. >>>>>> >>>>>> Let me know whether or not this helps. >>>>>> >>>>>> >>>>>>> I hope this makes sense; and apologies if I am missing something >>>>>>> fundamental! >>>>>>> >>>>>>> Cheers, >>>>>>> Michael >>>>>>> >>>>>>> 1. During claims phase with a claims check command >>>>>>> 1. If domain has matching trademark >>>>>>> 1. return exists=true >>>>>>> 2. else >>>>>>> 1. return exists=false >>>>>>> 2. During post claims phase with a claims check command >>>>>>> 1. If domain was released post claims phase start and is >>>>>>> within 90 days of release and has matching trademark >>>>>>> 1. return exists=true >>>>>>> 2. else >>>>>>> 1. return exists=false >>>>>>> 3. *During post claims phase with a claims phase check and >>>>>>> passing “claims” as the phase (optional matching trademark >>>>>>> past the claims phase use case)* >>>>>>> 1. *If domains has matching trademark * >>>>>>> 1. *return exists=true *_## The claims exists but it is >>>>>>> NOT required on domain_create_ >>>>>>> 2. *else* >>>>>>> 1. *return exists=false* >>>>>>> >>>>>>> >>>>>>> 1. During claims phase with a create command >>>>>>> 1. If domain has matching trademark >>>>>>> 1. claims notice is required >>>>>>> 2. else >>>>>>> 1. claims notice is NOT required >>>>>>> 2. During post claims phase with a create command >>>>>>> 1. If domain was released post claims phase start and is >>>>>>> within 90 days of release and has matching trademark >>>>>>> return ## How does the client know if 90 days has passed >>>>>>> (extended / post claims) or not without external source? >>>>>>> 1. claims notice is required >>>>>>> 2. else >>>>>>> 1. claims notice is NOT required >>>>>>> >>>>>>> >>>>>>> >>>>>>> * >>>>>>> Michael Holloway >>>>>>> Senior Systems Administrator**| Com Laude* >>>>>>> E: michael.holloway@comlaude.com >>>>>>> >>>>>>> >>>>>>> On 01/13/2015 02:44 PM, Gould, James wrote: >>>>>>>> Michael, >>>>>>>> >>>>>>>> The split out of the responsibility of the registries and the >>>>>>>> CNIS / TMDB was worked out a couple of years ago, where there >>>>>>>> was a desire to not make the CNIS the critical path for the >>>>>>>> majority of the registrations. The agreement was for the >>>>>>>> registries to provide the claims check service and enforce the >>>>>>>> claims notice on create based on a feed of trademark labels >>>>>>>> from the TMDB to the registries. >>>>>>>> >>>>>>>> The proposal is to support the claims service post the “claims” >>>>>>>> phase by passing the active phase to the server and the server >>>>>>>> will return whether or not the claims notice is required based >>>>>>>> on a combination of a matching trademark and whether the domain >>>>>>>> name already went through 90 days of the claims service. From >>>>>>>> a client perspective it means utilizing the claims check in a >>>>>>>> similar fashion during and post the claims phase. The use case >>>>>>>> brought up by Trung was more of an exception to the rule, in >>>>>>>> the client wanting to know whether there is a matching >>>>>>>> trademark for a domain name independent of the requirement for >>>>>>>> passing the claims notice. In that case, the proposal is to >>>>>>>> pass “claims” as the phase independent of the active phase to >>>>>>>> get a true or false answer to whether a trademark matches the >>>>>>>> domain name. >>>>>>>> >>>>>>>> Do the proposals work for you? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> — >>>>>>>> >>>>>>>> JG >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *James Gould >>>>>>>> *Distinguished Engineer >>>>>>>> jgould@Verisign.com >>>>>>>> >>>>>>>> 703-948-3271 >>>>>>>> 12061 Bluemont Way >>>>>>>> Reston, VA 20190 >>>>>>>> >>>>>>>> VerisignInc.com >>>>>>>> >>>>>>>> On Jan 13, 2015, at 3:18 AM, Michael Holloway >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Hi all >>>>>>>>> >>>>>>>>> Just a thought; would it not be more appropriate to facilitate >>>>>>>>> this on the TMDB by adding a lookup based on label. This could >>>>>>>>> return a simple true/false value, or all the info returned on >>>>>>>>> a CNIS lookup exception notice_id etc. >>>>>>>>> >>>>>>>>> The problem with having and post claims service on the EPP >>>>>>>>> server without changing the phase name is that the EPP client >>>>>>>>> then has to decide when /not/ to submit claims data in a >>>>>>>>> domain_create if the domain has a claim. As it is, various >>>>>>>>> registries are extending the claims periods past 90 days, so >>>>>>>>> its contradictory to have extended claims and post claims >>>>>>>>> defined the same way in the query but without a defined (or >>>>>>>>> facilitated) way to differentiate the requirement for a >>>>>>>>> domain_create. >>>>>>>>> >>>>>>>>> I would be more comfortable with defining a specific sub_phase >>>>>>>>> for the purpose, or even better skipping the middle man and >>>>>>>>> going straight to the TMDB. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Michael >>>>>>>>> >>>>>>>>> *Michael Holloway >>>>>>>>> Senior Systems Administrator**| Com Laude* >>>>>>>>> E: michael.holloway@comlaude.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 01/13/2015 04:04 AM, Tran, Trung wrote: >>>>>>>>>> This works for me, Jim. Though it’s not often, we have cases >>>>>>>>>> where change in ownership of a domain might not occur if >>>>>>>>>> there’s trademark against the name. So a potential >>>>>>>>>> registrant might not want to buy an existing registered name >>>>>>>>>> if there’s trademark against it in the TMCH. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Trung >>>>>>>>>> From: , James >>>>>>>>> > >>>>>>>>>> Date: Friday, January 9, 2015 at 11:27 AM >>>>>>>>>> To: Jody Kolker >>>>>>>>> > >>>>>>>>>> Cc: Francisco Obispo >>>>>>>>> >, "eppext@ietf.org >>>>>>>>>> " >>>>>>>>> >, "Tran, Trung" >>>>>>>>>> > >>>>>>>>>> Subject: Re: [eppext] draft-ietf-eppext-launchphase Support >>>>>>>>>> for a "Claims Service" post the Claims Phase >>>>>>>>>> >>>>>>>>>> Jody, >>>>>>>>>> >>>>>>>>>> I believe that passing the active phase is more straight >>>>>>>>>> forward as opposed to defining a special sub-phase like >>>>>>>>>> “extended" to drive the behavior. Having the claims >>>>>>>>>> check return “exists=true” only when a claims notice is >>>>>>>>>> required on the create based on the active phase should >>>>>>>>>> be able to handle the use case of releasing domains post >>>>>>>>>> the claims phase and also applies to the claims phase. >>>>>>>>>> All names that have matching trademarks during the >>>>>>>>>> claims phase will require a claims notice on create, so >>>>>>>>>> the behavior is consistent. >>>>>>>>>> >>>>>>>>>> I’m still not sure why a client would want to know >>>>>>>>>> whether there is a matching trademark when a claims >>>>>>>>>> notice is not required on the create. Does anyone see a >>>>>>>>>> need for this? Since the “claims” phase would always >>>>>>>>>> return “exists=true” for domains that have matching >>>>>>>>>> trademarks, a client could pass the “claims” phase when >>>>>>>>>> the active phase is not the “claims” phase to obtain this >>>>>>>>>> information. Of course servers would need to support >>>>>>>>>> referencing a past “claims” phase to support this use >>>>>>>>>> case. The change in the text should support the logic >>>>>>>>>> that I previously posted before, which I extend to >>>>>>>>>> support addressing the optional matching trademark past >>>>>>>>>> the claims phase use case. Is this use case really needed? >>>>>>>>>> >>>>>>>>>> 1. During claims phase with a claims check command >>>>>>>>>> 1. If domain has matching trademark >>>>>>>>>> 1. return exists=true >>>>>>>>>> 2. else >>>>>>>>>> 1. return exists=false >>>>>>>>>> 2. During post claims phase with a claims check command >>>>>>>>>> 1. If domain was released post claims phase start >>>>>>>>>> and is within 90 days of release and has matching >>>>>>>>>> trademark >>>>>>>>>> 1. return exists=true >>>>>>>>>> 2. else >>>>>>>>>> 1. return exists=false >>>>>>>>>> 3. *During post claims phase with a claims phase check >>>>>>>>>> and passing “claims” as the phase (optional matching >>>>>>>>>> trademark past the claims phase use case)* >>>>>>>>>> 1. *If domains has matching trademark * >>>>>>>>>> 1. *return exists=true* >>>>>>>>>> 2. *else* >>>>>>>>>> 1. *return exists=false* >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 1. During claims phase with a create command >>>>>>>>>> 1. If domain has matching trademark >>>>>>>>>> 1. claims notice is required >>>>>>>>>> 2. else >>>>>>>>>> 1. claims notice is NOT required >>>>>>>>>> 2. During post claims phase with a create command >>>>>>>>>> 1. If domain was released post claims phase start >>>>>>>>>> and is within 90 days of release and has matching >>>>>>>>>> trademark return >>>>>>>>>> 1. claims notice is required >>>>>>>>>> 2. else >>>>>>>>>> 1. claims notice is NOT required >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> — >>>>>>>>>> >>>>>>>>>> JG >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *James Gould >>>>>>>>>> *Distinguished Engineer >>>>>>>>>> jgould@Verisign.com >>>>>>>>>> >>>>>>>>>> 703-948-3271 >>>>>>>>>> 12061 Bluemont Way >>>>>>>>>> Reston, VA 20190 >>>>>>>>>> >>>>>>>>>> VerisignInc.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Jan 8, 2015, at 4:50 PM, Jody Kolker >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> From Francisco: >>>>>>>>>>> Thanks Jim for bringing this to the eppext. This will >>>>>>>>>>> definitely help the post claims phase. >>>>>>>>>>> With the wording changes, is there still a way to >>>>>>>>>>> determine if there’s a trademark against the name >>>>>>>>>>> regardless on whether or not the claims ack is needed in >>>>>>>>>>> the create domain? >>>>>>>>>>> This could be accomplished by leaving the “claims” >>>>>>>>>>> implementation as it is currently and introducing a >>>>>>>>>>> sub-phase for claims named “extended”. When the >>>>>>>>>>> sup-phase of “extended” is passed the results from Jim’s >>>>>>>>>>> earlier email would be below. >>>>>>>>>>> >>>>>>>>>>> 1. During claims phase with a claims check command or >>>>>>>>>>> post claims phase without a sub-phase of “extended” >>>>>>>>>>> 1. If domain has matching trademark >>>>>>>>>>> 1. return exists=true >>>>>>>>>>> 2. else >>>>>>>>>>> 1. return exists=false >>>>>>>>>>> 2. During post claims phase with a claims check command >>>>>>>>>>> with a sub-phase of “extended” >>>>>>>>>>> 1. If domain was released post claims phase start >>>>>>>>>>> and is within 90 days of release and has >>>>>>>>>>> matching trademark >>>>>>>>>>> 1. return exists=true >>>>>>>>>>> 2. else >>>>>>>>>>> 1. return exists=false >>>>>>>>>>> >>>>>>>>>>> 1. During claims phase with a create command or post >>>>>>>>>>> claims phase without a sub-phase of “extended” >>>>>>>>>>> 1. If domain has matching trademark >>>>>>>>>>> 1. claims notice is required >>>>>>>>>>> 2. else >>>>>>>>>>> 1. claims notice is NOT required >>>>>>>>>>> 2. During post claims phase with a create command with >>>>>>>>>>> a sub-phase of “extended” >>>>>>>>>>> 1. If domain was released post claims phase start >>>>>>>>>>> and is within 90 days of release and has >>>>>>>>>>> matching trademark return >>>>>>>>>>> 1. claims notice is required >>>>>>>>>>> 2. else >>>>>>>>>>> 1. claims notice is NOT required >>>>>>>>>>> >>>>>>>>>>> This would still allow a registrar to determine if a >>>>>>>>>>> claim currently exists on a domain when a claim period >>>>>>>>>>> does not exist for the TLD (the current implementation). >>>>>>>>>>> From a registrar perspective, I’m not sure if >>>>>>>>>>> determining if a domain has a claim when all claims >>>>>>>>>>> periods have expired is needed. This implementation also >>>>>>>>>>> would require additional work by all registrars to >>>>>>>>>>> support if adopted, while the implementation from Jim’s >>>>>>>>>>> first post would require only updates by the registries >>>>>>>>>>> which would be better for widespread adoption. >>>>>>>>>>> Thoughts? >>>>>>>>>>> Thanks, >>>>>>>>>>> Jody Kolker >>>>>>>>>>> 319-294-3933 (office) >>>>>>>>>>> 319-329-9805 (mobile) Please contact my direct >>>>>>>>>>> supervisor Charles Beadnall (cbeadnall@godaddy.com >>>>>>>>>>> ) with any feedback. >>>>>>>>>>> This email message and any attachments hereto is >>>>>>>>>>> intended for use only by the addressee(s) named herein >>>>>>>>>>> and may contain confidential information. If you have >>>>>>>>>>> received this email in error, please immediately notify >>>>>>>>>>> the sender and permanently delete the original and any >>>>>>>>>>> copy of this message and its attachments. >>>>>>>>>>> *From:*Gould, James [mailto:JGould@verisign.com] >>>>>>>>>>> *Sent:*Thursday, January 08, 2015 12:24 PM >>>>>>>>>>> *To:*Francisco Obispo >>>>>>>>>>> *Cc:*Jody Kolker;eppext@ietf.org >>>>>>>>>>> ; Tran, Trung >>>>>>>>>>> *Subject:*Re: [eppext] draft-ietf-eppext-launchphase >>>>>>>>>>> Support for a "Claims Service" post the Claims Phase >>>>>>>>>>> Francisco, >>>>>>>>>>> I would have gone with the sub-phase approach as well, >>>>>>>>>>> since if the behavior between the two claims phases are >>>>>>>>>>> consistent (e.g. requirement for claims check and claims >>>>>>>>>>> notice) I’m not sure the value in defining a new >>>>>>>>>>> top-level phase name. Is there a material behavior >>>>>>>>>>> change between the two phases and is the concept of an >>>>>>>>>>> extended claims phase a generic use case? We have stuck >>>>>>>>>>> with the standard set of “sunrise”, “claims”, and “open” >>>>>>>>>>> phases. Have others utilized the use of sub-phases or >>>>>>>>>>> have created custom top-level phase names to meet their >>>>>>>>>>> needs? If so, can you share your scheme? It would be >>>>>>>>>>> good to know if there are any common patterns. >>>>>>>>>>> Thanks, >>>>>>>>>>> — >>>>>>>>>>> >>>>>>>>>>> JG >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *James Gould >>>>>>>>>>> *Distinguished Engineer >>>>>>>>>>> jgould@Verisign.com >>>>>>>>>>> >>>>>>>>>>> 703-948-3271 >>>>>>>>>>> 12061 Bluemont Way >>>>>>>>>>> Reston, VA 20190 >>>>>>>>>>> >>>>>>>>>>> VerisignInc.com >>>>>>>>>>> >>>>>>>>>>> On Jan 8, 2015, at 3:08 PM, Francisco Obispo >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> SHOULD contain the value >>>>>>>>>>> of "claims" to indicate the >>>>>>>>>>> claims launch phase. A value >>>>>>>>>>> other than "claims" MAY be used to >>>>>>>>>>> pass the claims notice for domain names >>>>>>>>>>> outside of the claims phase. >>>>>>>>>>> >>>>>>>>>>> Once a TLD has ended the mandatory 90 day period of >>>>>>>>>>> “claims” a registry might decide to call it >>>>>>>>>>> something else. >>>>>>>>>>> We are not supporting extended claims, but we had to >>>>>>>>>>> support an extended sunrise for the names on the >>>>>>>>>>> ICANN names-collision block list (30 day period >>>>>>>>>>> instead of a 60 day end-date sunrise), and we >>>>>>>>>>> initially thought about having a phase called >>>>>>>>>>> “sunrise” with a sub-phase called “extended” but we >>>>>>>>>>> thought it would be too complicated for RARs to >>>>>>>>>>> change their code, so we decided just to trigger it >>>>>>>>>>> by calling the phase “sunsrise”, but in reality, a >>>>>>>>>>> registry can call it anything they want in order to >>>>>>>>>>> support it, because they are different things. >>>>>>>>>>> Since there is no guidance on what the phases should >>>>>>>>>>> be called, it seems like we’re going to end up with >>>>>>>>>>> discrete phase names for anything that is not: >>>>>>>>>>> claims or sunrise. >>>>>>>>>>> >>>>>>>>>>> On Jan 8, 2015, at 11:35 AM, Gould, James >>>>>>>>>>> >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> What do you mean by the extended claims phase? >>>>>>>>>>> Is there a past mail list thread on this or is >>>>>>>>>>> this a new issue? Please clarify. >>>>>>>>>>> >>>>>>>>>>> *Francisco Obispo* >>>>>>>>>>> CTO - Registry Operations >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2161 San Joaquin Hills Rd. >>>>>>>>>>> Newport Beach, CA, 92660 >>>>>>>>>>> off. +1.345.749.6284 >>>>>>>>>>> fax. +1.345.746.6263 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> EppExt mailing list >>>>>>>>>> EppExt@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>>>>>> _______________________________________________ >>>>>>>>> EppExt mailing list >>>>>>>>> EppExt@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> EppExt mailing list >>>>>> EppExt@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/eppext >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> EppExt mailing list >>>>> EppExt@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/eppext >>>> >>>> >>>> _______________________________________________ >>>> EppExt mailing list >>>> EppExt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/eppext >>> > --------------080704020109060007090100 Content-Type: multipart/related; boundary="------------030608010905000505080809" --------------030608010905000505080809 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Okay agreed, all good.

Sorry I got my lanes crossed on the Trademark Claims Check re type attribute vs phase name...

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com
D: +44 20 7421 8273


On 01/22/2015 02:46 PM, Gould, James wrote:
Michael,

We had the discussion a while back on the provreg mailing list ( http://www.ietf.org/mail-archive/web/provreg/current/msg07286.html ) about support for overlapping phases, which resulted in adding the text in the 09 draft to handle the overlap of the “claims” and “landrush” phases.  I view a phase as a TLD level attribute as opposed to a domain level attribute that defines the interface expected by the server.  Supporting a list of phases adds undue complexity in draft-ietf-eppext-launchphase.

For the Trademark Check Form, the <launch:phase> element is not passed in the command or returned in the response since it’s really not applicable.  The <launch:phase> element is being set to optional (minOccurs=“0”) for the check command (checkType) and response (chkDataType), but is defined as required in the text for the Claims Check Form and Availability Check Form.  Let me know whether this makes sense.

Thanks,

—


JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 22, 2015, at 7:07 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi James

Yes I think that wording is fine, but [at the risk of pointlessly complicating the issue again], there are possibly multiple concurrent phases. In some instances, a domain might be valid in more than one (e.g. a regional TLD where phases depend on the registrants location or type), and in some cases such as collisions the domain might only be available in one of the active phases (e.g. collisions). Is it worth loosing to an "an" instead of "the" phase? Veto if you think its pointless.

<launch:phase>   Contains the value of an active launch phase of the server supporting claims.  The server SHOULD validate the value against the active server launch phase supporting claims.

Also, TM check form should be a SHOULD
3.1.3 Trademark Check Form
...
<launch:phase>   The launch phase that SHOULD be "trademark"


Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/21/2015 05:30 PM, Gould, James wrote:
Michael,

How about just using a more generic description of the <launch:phase> element in both the Claims Check Form of section 3.1.1 and the Claims Create Form of section 3.3.2, since both forms can be executed outside of the “claims” phase?  Something like the description from the General Create Form of section 3.3.3:

              <launch:phase>   Contains the value of the active launch phase of the server.  The server SHOULD validate the value against the active server launch phase.


—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 21, 2015, at 8:41 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Thanks James

From a registrar perspective I would say this solves the issue without the risk of breaking working clients. I would be interested to hear the opinion of anyone [else] representing registries here whether they would support the extra type attribute since its essentially optional extra, or whether they would prefer to support using he existing schema.

I think in the case of the latter it would suggest using Claims check on phases outside of "claims" (e.g. "open"),  and then some guidance would need to be offered (in the draft) to define exactly what the "open" phase is; .I.E is it the period after claims, or is the 'open registration' (aka general availability) period during the claims period; and therefore when to and when not to use the "open" phase. Some minor wording changes would be required in 3.1.1 Claims check form to change it from `The launch phase that SHOULD be "claims"` , to "MAY", perhaps with a bit more info.

In light of the above I think it would be far simpler to go with the Trademark check form, so hopefully we can agree with that! That would be my vote anyway!

Regards,
Michael



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/20/2015 02:58 PM, Gould, James wrote:
All,

I had a private thread with some about the proposal of referencing the past “claims” phase in the claims check command to support Trung’s request.  The issue is that some clients are hard coding “claims” as the phase in the claims check command and currently there is little to no support for the claims check command outside of the “claims” phase, so clients may inadvertently go through the claims process when it is not required or even potentially rejected on create.  I see the concern with adding a new feature that may inadvertently cause interface issues.  Although I am not crazy about making an XML schema change, we may be able to tweak things to support both the the claims check outside of the “claims” phase and also support Trung’s request to determine whether or not a trademark matches a name independent of the requirement for a claims notice for other use cases like the resale of domain names.

We already support a “type" attribute in the <launch:check> element, section 3.1, to define the check form of the command, which currently support “claims” and “avail” for the Claims Check Form and the Availability Check Form, respectively.  The default form is the Claims Check Form, which is updated to return “exists=1” if there is a matching trademark and a claims notice is required on create, per the proposed check changes.  We could add a Trademark Check Form (e.g. add section 3.1.3) that is indicated by setting the “type” attribute to “trademark”.  The interface for the Trademark Check Form is consistent with the Claims Check Form, except the <launch:phase> element is not applicable, so therefore in the schema we would make the <launch:phase> element optional, and the server would only match the domain to the matching set of trademarks to return the same response as with the Claims Check Form.  The <launch:phase> element would still be required for the Claims Check Form and the Availability Check Form based on the draft text.  As stated in section 3.1, the forms supported by the server is determined by server policy, so the Trademark Check Form would is an option but is not required.  The check command using the Trademark Check Form would look like:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:   <check>
   C:    <domain:check
   C:     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:      <domain:name>example1.tld</domain:name>
   C:      <domain:name>example2.tld</domain:name>
   C:    </domain:check>
   C:   </check>
   C:   <extension>
   C:    <launch:check
   C:     xmlns:launch="urn:ietf:params:xml:ns:launch-1.0"
   C:     type=“trademark"/>
   C:   </extension>
   C:   <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>


To support this, section 3.1.3 Trademark Check Form would need to be added along with some text changes on the “trademark” value for the “type” attribute in section 3.1, <enumeration value=“trademark”/> would need to be added to the checkFormType in the schema, and minOccurs=“0” would need to be added to the “phase” element of checkType in the schema.    

Let me know your thoughts on this option. 

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:40 AM, Gould, James <JGould@verisign.com> wrote:

Michael,

I provide feedback inline below.  

—

JG


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

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 10:08 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi

Re TMDB: I was thinking specifically of the post claims phase since at this point the CNIS (label+tld) itself it no longer required for registrations. The post claims lookup seems to be aimed at determining, for information purposes only (without "acking" in the create), whether or not there is a trademark registered against the term (i.e. label only) therefore there is no reason to check claims via TLD. This is a little OT anyway (my fault sorry), but hopefully you see where I am coming from.

The use case for the claims check post the claims phase is used to address the release of domain names that did not go through 90 days of claims, which I believe is a modified version of your #2 below.  

Let’s take the three basic phases defined in draft-ietf-eppext-launchphase as an example with sunrise, claims, and open.  We can pretty much remove the sunrise phase from the example for now, so let’s focus on the claims and open phases.  Assuming that claims.tld is available through sunrise and the claims phase, so if a claims check is done with “open” as the phase, the response would be exists=“0”, since there is no requirement to provide the claims notice on create.  If reserved.tld was released during the “open” phase, then a claims check on reserved.tld, with “open” as the phase, the response would be exists=“1”, since a claims notice is required on create.  Based on Trung’s use case, a client may want to know whether or not there is a trademark on the domain name independent of when the domain name is released, so the client can send a claims check with the phase as “claims” to get that answer.    



Back to LaunchPhase: my concern with simply using the "claims" phase is that it can cause ambiguity, take the following four phase statuses, and compare with the logic below (to which I commented in underlined red)
1) A registry must operate a 90 days claims phase
2) A registry must operate 90 days extended claims period on domains that are released at a later date (collisions etc, and I don't know what may be coming up in the future)
3) A registry may operate a continued claims phase past the 90 domains for all domains. [create with claims form]
4) [new]: A registry may operate a post claims (matching trademark past the claims phase use case) [create without claims]

If the client checks a domain for claims and gets result claims=true, then how does it know which of the above rules matched? In the case of (4) the claims lookup returns true even though the domain is no longer in (1) or (2) [and the registry has opted not to do (3)], so using the claims create form would be incorrect at this point despite receiving claims=true. This is why I suggest a different sub_phase should be used, OR a different flag added (more complex of course) to differentiate.


Based on the updated text, the client will only receive a claims check response with exists=“1” if “create with claims form” is required.  The updated text does not support #4, since the only time that “exists=0” is if a claims notice is required.  This way a client can continue to use the claims check without any extra logic of passing special attributes or sub-phases to get the answer that is needed, which is whether a claims notice is required on create.  Trung use case is an exception to the rule, where a client wants to know whether there is a matching trademark for the domain name independent of whether a claims notice is required on create, so passing “claims” as the phase past the “claims” phase may support that.  

Let me know whether or not this helps.  


I hope this makes sense; and apologies if I am missing something fundamental!

Cheers,
Michael

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true ## The claims exists but it is NOT required on domain_create
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return ## How does the client know if 90 days has passed (extended / post claims) or not without external source?
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 



Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com

On 01/13/2015 02:44 PM, Gould, James wrote:
Michael,

The split out of the responsibility of the registries and the CNIS / TMDB was worked out a couple of years ago, where there was a desire to not make the CNIS the critical path for the majority of the registrations.  The agreement was for the registries to provide the claims check service and enforce the claims notice on create based on a feed of trademark labels from the TMDB to the registries.  

The proposal is to support the claims service post the “claims” phase by passing the active phase to the server and the server will return whether or not the claims notice is required based on a combination of a matching trademark and whether the domain name already went through 90 days of the claims service.  From a client perspective it means utilizing the claims check in a similar fashion during and post the claims phase.  The use case brought up by Trung was more of an exception to the rule, in the client wanting to know whether there is a matching trademark for a domain name independent of the requirement for passing the claims notice.  In that case, the proposal is to pass “claims” as the phase independent of the active phase to get a true or false answer to whether a trademark matches the domain name.  

Do the proposals work for you?

Thanks,

—

JG


<Mail Attachment.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 13, 2015, at 3:18 AM, Michael Holloway <michael.holloway@comlaude.com> wrote:

Hi all

Just a thought; would it not be more appropriate to facilitate this on the TMDB by adding a lookup based on label. This could return a simple true/false value, or all the info returned on a CNIS lookup exception notice_id etc.

The problem with having and post claims service on the EPP server without changing the phase name is that the EPP client then has to decide when not to submit claims data in a domain_create if the domain has a claim. As it is, various registries are extending the claims periods past 90 days, so its contradictory to have extended claims and post claims defined the same way in the query but without a defined (or facilitated) way to differentiate the requirement for a domain_create.

I would be more comfortable with defining a specific sub_phase for the purpose, or even better skipping the middle man and going straight to the TMDB.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: michael.holloway@comlaude.com


On 01/13/2015 04:04 AM, Tran, Trung wrote:
This works for me, Jim.  Though it’s not often, we have cases where change in ownership of a domain might not occur if there’s trademark against the name.  So a potential registrant might not want to buy an existing registered name if there’s trademark against it in the TMCH.

Thanks,
Trung
From: <Gould>, James <JGould@verisign.com>
Date: Friday, January 9, 2015 at 11:27 AM
To: Jody Kolker <jkolker@godaddy.com>
Cc: Francisco Obispo <fobispo@uniregistry.com>, "eppext@ietf.org" <eppext@ietf.org>, "Tran, Trung" <trung.tran@neustar.biz>
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase

Jody,

I believe that passing the active phase is more straight forward as opposed to defining a special sub-phase like “extended" to drive the behavior.  Having the claims check return “exists=true” only when a claims notice is required on the create based on the active phase should be able to handle the use case of releasing domains post the claims phase and also applies to the claims phase.  All names that have matching trademarks during the claims phase will require a claims notice on create, so the behavior is consistent.  

I’m still not sure why a client would want to know whether there is a matching trademark when a claims notice is not required on the create.  Does anyone see a need for this?  Since the “claims” phase would always return “exists=true” for domains that have matching trademarks, a client could pass the “claims” phase when the active phase is not the “claims” phase to obtain this information.  Of course servers would need to support referencing a past “claims” phase to support this use case.  The change in the text should support the logic that I previously posted before, which I extend to support addressing the optional matching trademark past the claims phase use case.  Is this use case really needed?

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
  3. During post claims phase with a claims phase check and passing “claims” as the phase (optional matching trademark past the claims phase use case)
    1. If domains has matching trademark 
      1. return exists=true
    2. else
      1. return exists=false

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command 
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 

Thoughts?

—

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com

On Jan 8, 2015, at 4:50 PM, Jody Kolker <jkolker@godaddy.com> wrote:

From Francisco:
 
Thanks Jim for bringing this to the eppext.  This will definitely help the post claims phase.
 
With the wording changes, is there still a way to determine if there’s a trademark against the name regardless on whether or not the claims ack is needed in the create domain?  
 
This could be accomplished by leaving the “claims” implementation as it is currently and introducing a sub-phase for claims named “extended”.  When the sup-phase of “extended” is passed the results from Jim’s earlier email would be below.
 
  1. During claims phase with a claims check command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. return exists=true 
    2. else 
      1. return exists=false
  2. During post claims phase with a claims check command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark
      1. return exists=true 
    2. else 
      1. return exists=false 
 
  1. During claims phase with a create command or post claims phase without a sub-phase of “extended”
    1. If domain has matching trademark 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required
  2. During post claims phase with a create command with a sub-phase of “extended”
    1. If domain was released post claims phase start and is within 90 days of release and has matching trademark return 
      1. claims notice is required 
    2. else 
      1. claims notice is NOT required 
This would still allow a registrar to determine if a claim currently exists on a domain when a claim period does not exist for the TLD (the current implementation).  From a registrar perspective, I’m not sure if determining if a domain has a claim when all claims periods have expired is needed.  This implementation also would require additional work by all registrars to support if adopted, while the implementation from Jim’s first post would require only updates by the registries which would be better for widespread adoption.
 
Thoughts?
 
Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback.
 
This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.
 
From: Gould, James [mailto:JGould@verisign.com] 
Sent: Thursday, January 08, 2015 12:24 PM
To: Francisco Obispo
Cc: Jody Kolker; eppext@ietf.org; Tran, Trung
Subject: Re: [eppext] draft-ietf-eppext-launchphase Support for a "Claims Service" post the Claims Phase
 
Francisco,
 
I would have gone with the sub-phase approach as well, since if the behavior between the two claims phases are consistent (e.g. requirement for claims check and claims notice) I’m not sure the value in defining a new top-level phase name.  Is there a material behavior change between the two phases and is the concept of an extended claims phase a generic use case?  We have stuck with the standard set of “sunrise”, “claims”, and “open” phases.  Have others utilized the use of sub-phases or have created custom top-level phase names to meet their needs?  If so, can you share your scheme?  It would be good to know if there are any common patterns.  
 
Thanks,
 
—
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 8, 2015, at 3:08 PM, Francisco Obispo <fobispo@uniregistry.com> wrote:


<launch:phase>  SHOULD contain the value of "claims" to indicate the
       claims launch phase.  A value other than "claims" MAY be used to 
pass the claims notice for domain names outside of the claims phase.  
 
 
Once a TLD has ended the mandatory 90 day period of “claims” a registry might decide to call it something else. 
 
We are not supporting extended claims, but we had to support an extended sunrise for the names on the ICANN names-collision block list (30 day period instead of a 60 day end-date sunrise), and we initially thought about having a phase called “sunrise” with a sub-phase called “extended” but we thought it would be too complicated for RARs to change their code, so we decided just to trigger it by calling the phase “sunsrise”, but in reality, a registry can call it anything they want in order to support it, because they are different things.
 
Since there is no guidance on what the phases should be called, it seems like we’re going to end up with discrete phase names for anything that is not: claims or sunrise.
 
 

On Jan 8, 2015, at 11:35 AM, Gould, James <JGould@verisign.com> wrote:

What do you mean by the extended claims phase?  Is there a past mail list thread on this or is this a new issue?  Please clarify.

 
Francisco Obispo
CTO - Registry Operations

<Mail Attachment.png>


2161 San Joaquin Hills Rd.
Newport Beach, CA, 92660
off. +1.345.749.6284
fax. +1.345.746.6263



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



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



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


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



--------------030608010905000505080809 Content-Type: image/png Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vL JtmQhEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjT DnhDEEWC1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBg wDFuRRaXOiUlhX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2Thp UA4w9Pf39/X19fT0UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvCl pSFvipAimGy1wQmrMgV4aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZn ZGSMLYejx4biEautrQ3eUlNTLUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwo MYA5nZ+duXiyur6ju88u5ZL5s+ffmJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMyg UvRoijp7AnuPXdhz9PyeyvPI7khxqtoUyTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIe aOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+ MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUYu3T5MoyxMZEDbJTK81fWlR242NrrcHsd ToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5KhL1kjDMBbMQMDKa6pgaE6enpggp4 r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg8NF7Crc99XNeG/ZQIvkQ3xt1 bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SFSVPIxDKpBVuYQOABMtg3 f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+aw+1xuLQ1Ag9s1p9u C9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhDED8wSxgTYLsq LihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z0S70CNsj wiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4eQOP cELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT 6T5+saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1o PoiPDXtouXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z 3HTYGyVlH5+oalTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScx ZZBtnd0lr31oF9G0l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEY B2jEkLZ91vDtONgwQhgjZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjR rCkTYo5c/fK7yshlTXVkc739+RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffr UI5Aqf7SNz6NuTpInl2xQHlXKJDlCZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z +lCdcbChKoAJY7SBV9PUobMTE3VwQ9MeX/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2cea NI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL 5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/FdrdgkvZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6 dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQLMor+WhVsSozwfVnMdWJ2DpcDZF0M Elj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUpKzYoR7UX1IS7qg+I62+BLALV UGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw1oN3znOkZTsyJg3+pecQ h3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6fG8frR4qH2xaXZzl 12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaUfDqolJR9FHNn 8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/Ly9ASKFfQ soWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg6+nt xeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNc RkE09LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9 So6/0ZoloVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAl DIgT6qCijr9RpfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKF S+dOSHMNqAO+OgSL74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgA Q6EYJGJEKSpORxx/YzZWzlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu3 7FUpnnAKfqWFsEbURI0KfQFs+aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc 4NWWGWZPtG6FUO1Lbm91c9emdypkWT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRs w/SPCBs649ejosWLyePA69W/jD6+aNL0TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOl v+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eBLq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rv jfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHtheMFApjuwY+19N+XlMEIdwrjCCAYzMzPB lmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfrxU8bLnaElNzqRkDukuUTUx8TddxT 0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPxiLiyxRyQADa0QH6rra19b88e fkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/NyN782J1ZGT4FTBcuDjP9 fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI4NQUqa0NNWkqPMIb pAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2eOTHpM8vdh3+ ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzYu3r16ifl 5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfnFWSn MYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqc NpaYTgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtk TMATCfNyc/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55Mkdw IOGi/IgB4GRgxJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav 8CIKCCnSNuPHqTEu2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4 pS5wGNCFnE4CHH5wzLfujS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VX XyVZ298iRFFR0dKlS+k0b1966SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQF U6euf/ppGma6SLVz586TJ0/Sj/DO24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABj QEVFxfPPP09+jxgMMKCKFpCBIoNf0fjNYPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7 oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqqFVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFB oYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxItm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBX ZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQexTCSw616MzcyJwIZr8UqYoQHJZqQ0 0KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwqbMYsASa82UljgCjbzIloGKrp R4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNauLDPXNBQ2Y5Zsb2aaETTQ jTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McYO3syWGgnRNkB29eh bZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCxJ+ONl8ojtTAJ IWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1ol2MUFaQ GrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8JGPDD ecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --------------030608010905000505080809-- --------------080704020109060007090100-- From nobody Thu Jan 22 11:18:53 2015 Return-Path: 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 6DE041A1BC7 for ; Thu, 22 Jan 2015 11:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] 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 w7IKvHP_NTXT for ; Thu, 22 Jan 2015 11:18:50 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (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 548851A1BB9 for ; Thu, 22 Jan 2015 11:18:38 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i8so2917571qcq.3 for ; Thu, 22 Jan 2015 11:18:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Z0l5BIytgL5OMVaKqQ/NgHVWN7f8TCyfO5n/rZO/0Jc=; b=MOpBKnnw1Mf1NrZLJFenHK8H1mMeP2iinMu6C9QbRnjjTpJhdT2OlXelxYtCnX153R miHzY8KJsbNX/J49OMKnVm7BxQw0Dx3x8w8DSe26dDbSqHQSlM34SqlS1mMiEzjMEtjm elMyMI0imaBcBIdLeKDFSHQLnxg6THLb5yPyU66WOm4nhsRJz2KBFWdjW05JEOW2tNqF MQOaQJsB3H/FycJnDB/bRRhStOne8dKxq0mAChz3LKE1kBcyA4x56sKxW7Wqrv4ynvfj 2w3FznKJZ9yQnfB+ouSSqAbFarmQ/A1FOeC7wFGf9vyxRQlRenlTW5Hn0aEmtLIPwqq3 CDqg== X-Gm-Message-State: ALoCoQkh6FdJz49P4pTASM8XRXMve1XsWZ/SD/ps9kls9JbXQ3BonSlmRhGCC7TWJN0ewhWOieqq X-Received: by 10.140.98.166 with SMTP id o35mr5386968qge.70.1421954317569; Thu, 22 Jan 2015 11:18:37 -0800 (PST) Received: from jgalvin-lt.local ([2601:a:1480:3e1:bc12:ecd:4348:9e7a]) by mx.google.com with ESMTPSA id j6sm4076609qga.9.2015.01.22.11.18.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jan 2015 11:18:36 -0800 (PST) Message-ID: <54C14D0D.6020507@elistx.com> Date: Thu, 22 Jan 2015 14:18:37 -0500 From: James Galvin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: eppext , gavin.brown@centralnic.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [eppext] correction to draft-brown-epp-fees X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 19:18:51 -0000 Gavin, Our team found what I believe is just an oversight in V3 of the draft. It seems pretty clear throughout the text that the intent is for the "currency" element to be optional on commands but mandatory in the result. However, the XSD in Section 4.3 does not agree. Excerpt: I'm pretty sure you want a "minOccurs=0" included on the currency element for the command. Is that correct? Thanks, Jim From nobody Thu Jan 22 12:00:50 2015 Return-Path: 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 B84E11B2A2C for ; Thu, 22 Jan 2015 12:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 0NNos6JQHRsi for ; Thu, 22 Jan 2015 12:00:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0714.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:714]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5581B2A15 for ; Thu, 22 Jan 2015 12:00:42 -0800 (PST) Received: from BN1PR02MB119.namprd02.prod.outlook.com (10.255.204.21) by BN1PR02MB119.namprd02.prod.outlook.com (10.255.204.21) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 22 Jan 2015 20:00:19 +0000 Received: from BN1PR02MB119.namprd02.prod.outlook.com ([169.254.8.49]) by BN1PR02MB119.namprd02.prod.outlook.com ([169.254.8.49]) with mapi id 15.01.0059.007; Thu, 22 Jan 2015 20:00:19 +0000 From: Roger D Carney To: eppext Thread-Topic: [eppext] correction to draft-brown-epp-fees Thread-Index: AQHQNnhEv4pZjxNruEev1BTxHuidVZzMjfQg Date: Thu, 22 Jan 2015 20:00:18 +0000 Message-ID: References: <54C14D0D.6020507@elistx.com> In-Reply-To: <54C14D0D.6020507@elistx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.202.161.57] authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=godaddy.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN1PR02MB119; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR02MB119; x-forefront-prvs: 0464DBBBC4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(52604005)(13464003)(164054003)(377454003)(33656002)(54206007)(15975445007)(2900100001)(86362001)(2950100001)(92566002)(46102003)(74316001)(110136001)(54356999)(99286002)(50986999)(76176999)(54606007)(106116001)(2656002)(40100003)(19580405001)(76576001)(122556002)(62966003)(450100001)(77156002)(102836002)(107886001)(19580395003)(230783001)(66066001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR02MB119; H:BN1PR02MB119.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: godaddy.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2015 20:00:18.6985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d5f1622b-14a3-45a6-b069-003f8dc4851f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR02MB119 Archived-At: Subject: Re: [eppext] correction to draft-brown-epp-fees X-BeenThere: eppext@ietf.org 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, 22 Jan 2015 20:00:47 -0000 Agreed, that is how we expect it to work as well: optional on commands and = mandatory on results, thanks for catching Jim! -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of James Galvin Sent: Thursday, January 22, 2015 1:19 PM To: eppext; gavin.brown@centralnic.com Subject: [eppext] correction to draft-brown-epp-fees Gavin, Our team found what I believe is just an oversight in V3 of the draft.=20 It seems pretty clear throughout the text that the intent is for the "curre= ncy" element to be optional on commands but mandatory in the result. Howev= er, the XSD in Section 4.3 does not agree. Excerpt: I'm pretty sure you want a "minOccurs=3D0" included on the currency element= for the command. Is that correct? Thanks, Jim _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext From nobody Fri Jan 23 10:01:45 2015 Return-Path: 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 2D3201ACCF4 for ; Fri, 23 Jan 2015 10:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] 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 9qdAmP88UPtU for ; Fri, 23 Jan 2015 10:01:35 -0800 (PST) Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953E41ACD00 for ; Fri, 23 Jan 2015 10:00:40 -0800 (PST) Received: from [192.168.1.143] (unknown [213.205.251.110]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 969DE9E46; Fri, 23 Jan 2015 18:00:38 +0000 (UTC) Message-ID: <54C28C47.2060700@centralnic.com> Date: Fri, 23 Jan 2015 18:00:39 +0000 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: James Galvin , eppext References: <54C14D0D.6020507@elistx.com> In-Reply-To: <54C14D0D.6020507@elistx.com> OpenPGP: id=F923B4CE Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sqNHbk3afqsmVt0VSllxml2SX3JkUvrX0" Archived-At: Subject: Re: [eppext] correction to draft-brown-epp-fees X-BeenThere: eppext@ietf.org 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: Fri, 23 Jan 2015 18:01:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sqNHbk3afqsmVt0VSllxml2SX3JkUvrX0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Jim, Thanks for pointing this out. I've fixed my working draft. G. On 22/01/2015 19:18, James Galvin wrote: > Gavin, >=20 > Our team found what I believe is just an oversight in V3 of the draft. > It seems pretty clear throughout the text that the intent is for the > "currency" element to be optional on commands but mandatory in the > result. However, the XSD in Section 4.3 does not agree. >=20 > Excerpt: >=20 >=20 > > > > > maxOccurs=3D"unbounded" /> > > >=20 > > > > > maxOccurs=3D"unbounded" /> > minOccurs=3D"0" /> > minOccurs=3D"0" /> > > >=20 >=20 > I'm pretty sure you want a "minOccurs=3D0" included on the currency > element for the command. >=20 > Is that correct? >=20 > Thanks, >=20 > Jim --=20 Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. --sqNHbk3afqsmVt0VSllxml2SX3JkUvrX0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iEYEARECAAYFAlTCjEcACgkQ6H45IPkjtM6hbwCgjxZlFSY3JoKMr3oXg4ZEfgon zR4AoICixqWyGxD7cAwbDRZwcRH2Eoan =Pcdc -----END PGP SIGNATURE----- --sqNHbk3afqsmVt0VSllxml2SX3JkUvrX0-- From nobody Thu Jan 29 05:52:49 2015 Return-Path: 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 95B371A0470; Thu, 29 Jan 2015 05:52:46 -0800 (PST) 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] 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 tkK9NqxRKeOW; Thu, 29 Jan 2015 05:52:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6FC1A06FD; Thu, 29 Jan 2015 05:52:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129135239.404.21812.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 05:52:39 -0800 Archived-At: Cc: eppext@ietf.org Subject: [eppext] I-D Action: draft-ietf-eppext-launchphase-03.txt X-BeenThere: eppext@ietf.org X-Mailman-Version: 2.1.15 List-Id: EPPEXT List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 13:52:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Provisioning Protocol Extensions Working Group of the IETF. Title : Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) Authors : James Gould Wil Tan Gavin Brown Filename : draft-ietf-eppext-launchphase-03.txt Pages : 58 Date : 2015-01-29 Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchphase/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-eppext-launchphase-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 29 06:12:45 2015 Return-Path: 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 263EA1A047A; Thu, 29 Jan 2015 06:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fiSb3RqOiMoc; Thu, 29 Jan 2015 06:12:36 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EA11A039A; Thu, 29 Jan 2015 06:12:35 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKVMo/vsOr6NrCDxCcnRNZCTEmEJOee0mh@postini.com; Thu, 29 Jan 2015 06:12:35 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0TECDHp006026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Jan 2015 09:12:13 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 29 Jan 2015 09:12:13 -0500 From: "Gould, James" To: "eppext@ietf.org" , EPP Provreg , "tmch-tech@icann.org" , "gtld-tech@icann.org" Thread-Topic: draft-ietf-eppext-launchphase-03 Posted Thread-Index: AQHQO82TU9lmxDtzjUOQgxsedNRifw== Date: Thu, 29 Jan 2015 14:12:12 +0000 Message-ID: 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_CD9AA6B553724901BCDB87E559B360CEverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [eppext] draft-ietf-eppext-launchphase-03 Posted X-BeenThere: eppext@ietf.org 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, 29 Jan 2015 14:12:40 -0000 --_004_CD9AA6B553724901BCDB87E559B360CEverisigncom_ Content-Type: multipart/alternative; boundary="_000_CD9AA6B553724901BCDB87E559B360CEverisigncom_" --_000_CD9AA6B553724901BCDB87E559B360CEverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, The fourth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-launch= phase-03) was posted to the IETF as what should be ready for Working Group = Last Call by the EPPEXT Working Group. There is a dependency to draft-iet= f-eppext-tmch-smd, so the hope is that draft-ietf-eppext-tmch-smd can be re= posted for Working Group Last Call as well. The following is the draft inf= ormation: URL: http://www.ietf.org/internet-drafts/draft-ietf-eppext-launc= hphase-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-eppext-launchph= ase/ Htmlized: http://tools.ietf.org/html/draft-ietf-eppext-launchphase-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-eppext-launch= phase-03 The following is a description of the changes from draft-ietf-eppext-launch= phase-02 to draft-ietf-eppext-launchphase-03: 1. Added the "Implementation Status" section based on an action item fro= m the eppext IETF-91 meeting. 2. Moved Section 7 "IANA Considerations" and Section 9 "Security Conside= rations" before Section 5 "Acknowledgements". Moved "Change Log" Section to= end. 3. Updated the text for the Claims Check Form and the Claims Create Form= to support checking for the need of the claims notice and passing the clai= ms notice outside of the "claims" phase. 4. Added the new Trademark Check Form to support determining whether or = not a trademark exists that matches the domain name independent of whether = a claims notice is required on create. This was based on a request from Tru= ng Tran and a discussion on the eppext mailing list. Please review draft-ietf-eppext-launchphase-03 and post any issues to the e= ppext mailing list. I want to thank everyone that has contributed to this = draft version as well as all the past draft versions. Thanks, =97 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 =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 --_000_CD9AA6B553724901BCDB87E559B360CEverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5C3878F2EF42EB4E81A2D903D41F4582@verisign.com> Content-Transfer-Encoding: quoted-printable All,

The fourth draft of draft-ietf-eppext-launchphase (draft-ietf-eppext-l= aunchphase-03) was posted to the IETF as what should be ready for Working G= roup Last Call by the EPPEXT Working Group.   There is a dependen= cy to draft-ietf-eppext-tmch-smd, so the hope is that draft-ietf-eppext-tmch-smd can be reposted for Working Group Last = Call as well.  The following is the draft information:


The following is a description of the changes from draft-ietf-eppext-l= aunchphase-02 to draft-ietf-eppext-launchphase-03:   
  1. Added the "Implementation Status" section based on an action = item from the eppext IETF-91 meeting.
  2. Moved Section 7 "IANA Co= nsiderations" and Section 9 "Security Considerations" before= Section 5 "Acknowledgements". Moved "Change Log" Secti= on to end.
  3. Updated the text for the Claims Check Form and the Claim= s Create Form to support checking for the need of the claims notice and pas= sing the claims notice outside of the "claims" phase.
  4. Add= ed the new Trademark Check Form to support determining whether or not a tra= demark exists that matches the domain name independent of whether a claims = notice is required on create. This was based on a request from Trung Tran a= nd a discussion on the eppext mailing list.
Please review draft-ietf-eppext-launchphase-03 and post any issues to = the eppext mailing list.  I want to thank everyone that has contribute= d to this draft version as well as all the past draft versions.   &nbs= p;

Thanks,
    

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94
--_000_CD9AA6B553724901BCDB87E559B360CEverisigncom_-- --_004_CD9AA6B553724901BCDB87E559B360CEverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Thu, 29 Jan 2015 14:12:12 GMT"; modification-date="Thu, 29 Jan 2015 14:12:12 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CD9AA6B553724901BCDB87E559B360CEverisigncom_-- From nobody Fri Jan 30 01:08:15 2015 Return-Path: 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 CF8E81A8A72 for ; Fri, 30 Jan 2015 01:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.723 X-Spam-Level: X-Spam-Status: No, score=0.723 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, 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 vExtwlxXYHMN for ; Fri, 30 Jan 2015 01:08:05 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451F51A8A71 for ; Fri, 30 Jan 2015 01:08:05 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id b6so35281795lbj.11 for ; Fri, 30 Jan 2015 01:08:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=00R+Oz1RQr5oyiHv22Pbjslj/VS5EOJ0fqnuFZnUVuI=; b=Ie+69OOmfoozBt72TxBBQmf63YMsWQId9UBoITMCCTWMI/h0tj8EwhK3OMzS9Gj0Ia VRHFAgdQqxMCRJjFHR4h4C6b+ODMkrI86QbIKLTK5jo9McdQgdZvTa2Zyebp4kpVn3TA NJs4/dEdL2qLwcwvLneuvSn/sboFS0/29S6H6qC4uVazKC9ahh2/HdN5jqVtm53V0Dmo WXzpEdQe/ABPDDmDC1qjIEx9wu+lSdpfDki6+l96b2kpAiUFp3SWmeapjGLMDZzrX17q gkBMqlrR7P/OMsZ3VF7ZIfaZTqmc3GMAYt6Ccs9JAhVLm63ZPSBqZzpwwbkkq9JxE9Og ehZg== X-Gm-Message-State: ALoCoQmBQJyYoTDcz+y8aus+n3CAAg/dTnSrtfCSmo5H8lCpVuA7OuCv6Vg3Yo+5EpQVjs2YpCtz MIME-Version: 1.0 X-Received: by 10.112.199.39 with SMTP id jh7mr5511441lbc.46.1422608883306; Fri, 30 Jan 2015 01:08:03 -0800 (PST) Received: by 10.25.29.134 with HTTP; Fri, 30 Jan 2015 01:08:03 -0800 (PST) In-Reply-To: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com> References: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com> Date: Fri, 30 Jan 2015 10:08:03 +0100 Message-ID: From: Ulrich Wisser To: "eppext@ietf.org" Content-Type: multipart/related; boundary=001a11c32cf0254e49050ddaf18c Archived-At: Subject: Re: [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 09:08:08 -0000 --001a11c32cf0254e49050ddaf18c Content-Type: multipart/alternative; boundary=001a11c32cf0254e44050ddaf18b --001a11c32cf0254e44050ddaf18b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James and Trung! You two did a nice job on the extension. I would prefer the transform command instead of the info response. That would eliminate the need for before/after indicator. I have some problems with the operators - Why is autoRenew a special operation instead of operation renew with op=3D"auto"? - What is the difference between delete and delete op=3D"purge"? - Why autoPurge / autoDelete? Kind regards from Stockholm Ulrich 2015-01-20 14:49 GMT+01:00 Gould, James : > The first draft of the Change Poll EPP Extension ( > http://tools.ietf.org/html/draft-gould-change-poll-00 ) has been > submitted to the IETF. I co-authored this draft with Trung Tran from > Neustar to provide a mechanism within EPP to notify clients of any > server-side change, including but not limited to regular batch processes, > customer support actions, Uniform Domain-Name Dispute-Resolution Policy > (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, > and bulk updates based on customer requests. Since the client is not > directly involved or knowledgable of these operations, the extension is > used along with an EPP object mapping to provide the resulting state of t= he > post-operation object, and optionally a pre-operation object, with the > operation meta-data of what, when, who, and why. We would like this draf= t > to be included in a re-charting of the EPPEXT Working Group. > > Please review the draft and provide any feedback. > > Thanks, > > =E2=80=94 > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > =E2=80=9CThis message (including any attachments) is intended only for th= e use of > the individual or entity to which it is addressed, and may contain > information that is non-public, proprietary, privileged, confidential and > exempt from disclosure under applicable law or may be constituted as > attorney work product. If you are not the intended recipient, you are > hereby notified that any use, dissemination, distribution, or copying of > this communication is strictly prohibited. If you have received this > message in error, notify sender immediately and delete this message > immediately.=E2=80=9D > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > --001a11c32cf0254e44050ddaf18b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi James and Trung!

You two did a nice = job on the extension. =C2=A0

I =C2=A0would prefer = the transform command instead of the info response. That would eliminate th= e need for before/after indicator.

I have some pro= blems with the operators

- Why is autoRenew a spec= ial operation instead of operation renew with op=3D"auto"?
<= div>- What is the difference between delete and delete op=3D"purge&quo= t;?=C2=A0
- Why autoPurge / autoDelete?

= Kind regards from Stockholm

Ulrich

<= /div>


2015-01-20 14:49 GMT+01:00 Gould, James <JGould@verisign.com>:
The first draft of the Change Poll EPP Extension (=C2=A0http:= //tools.ietf.org/html/draft-gould-change-poll-00 ) has been submitted t= o the IETF.=C2=A0 I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-= side change, including but not limited to regular batch processes, customer= support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or U= niform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. =C2= =A0 =C2=A0Since the client is not directly involved or knowledgable of thes= e operations, the extension is used along with an EPP object mapping to pro= vide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-dat= a of what, when, who, and why.=C2=A0 We would like this draft to be include= d in a re-charting of the EPPEXT Working Group. =C2=A0

Please review the draft and provide any feedback.

Thanks,

<= span style=3D"font-size:15px">=E2=80=94


JG


<= br>
James Gould
Distinguished Engineer
jgould@Verisign.co= m

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

=E2=80=9CThis message (including any attachments) = is intended only for the use of the individual or entity to which it is add= ressed, and may contain information that is non-public, proprietary, privil= eged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=E2=80=9D

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg


--001a11c32cf0254e44050ddaf18b-- --001a11c32cf0254e49050ddaf18c Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Transfer-Encoding: base64 Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> X-Attachment-Id: f6d3e6730b59039_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --001a11c32cf0254e49050ddaf18c-- From nobody Fri Jan 30 01:14:41 2015 Return-Path: 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 B8C861A8A68 for ; Fri, 30 Jan 2015 01:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, 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 1uT4aKQFTT8W for ; Fri, 30 Jan 2015 01:14:32 -0800 (PST) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B647B1A8A43 for ; Fri, 30 Jan 2015 01:14:31 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id gq15so22598318lab.12 for ; Fri, 30 Jan 2015 01:14:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=5JbJ78Eawy+voRxw1kLXfOBpLflJZCCYT9JVk2bUwzs=; b=i52bLNW1YTo01qJPXtO9E4IATNExIxBKZJhEjBokcW8J5xMqW2lMlxUr4OEMjpmR6j 9yAwkG/1IZlCaDUUNfixQpZqVNcWNTlVzASt9YWVtRHkL7WnNNo14MDzQ+qHt7a3Ee+Y 0brK661suG1C4Z09yxRKLxMYcsAaACqvLs9WDLxfsoJ2f+kzlpAqyDhq+zGWxDIe7+pP qczpPic61tr3gBiww8aovJ6CWkcqFda5zeA0NvVcrp/zC5feT6cuhjRAwL8dzXNC5OKu J0sLwEvWRk8gA2WUe/y3IZ/aJ17VIyazequZPUEqsFC1ZfPXGEN6pNu5bVjSnHKFs7Sq pvhA== X-Gm-Message-State: ALoCoQkK5oz1AYTeTeHSfbFYwm4uPW7wCgK3p22ZHTtdGGMgrrE6EW4t/AKa8zh6EKC0G4g5zsmL MIME-Version: 1.0 X-Received: by 10.112.130.34 with SMTP id ob2mr5528130lbb.78.1422609270130; Fri, 30 Jan 2015 01:14:30 -0800 (PST) Received: by 10.25.29.134 with HTTP; Fri, 30 Jan 2015 01:14:29 -0800 (PST) In-Reply-To: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> Date: Fri, 30 Jan 2015 10:14:29 +0100 Message-ID: From: Ulrich Wisser To: "eppext@ietf.org" Content-Type: multipart/related; boundary=047d7b3a7f0a33be5a050ddb080e Archived-At: Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 09:14:39 -0000 --047d7b3a7f0a33be5a050ddb080e Content-Type: multipart/alternative; boundary=047d7b3a7f0a33be55050ddb080d --047d7b3a7f0a33be55050ddb080d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! At first I would like to point out that both yours and James ideas are not that far apart. Introduction of a new temporary object which is send from registrar to registrar via the registry. That would obviously need some changes to current systems at the registry and registrars. I believe we should keep the needed changes as small as possible. Therefor I think that James idea to use existing commands is the way to go. Kind regards Ulrich 2015-01-13 11:09 GMT+01:00 Rik Ribbers : > James, > > > > Thank you for the feedback. > > > > My feedback on issue 1 and 2: > > > > I get a feeling we are running in circles. All arguments have been > mentioned in previous posts on this mailinglist. So what it boils down to > is what the rest of the WG thinks of this. So I politely , but urgently > ask the other members on this list to respond to the question: Should we > reconsider extending EPP with a new command and use the object or protoco= l > extension James proposes (see > http://www.ietf.org/mail-archive/web/eppext/current/msg00241.html) If > there are no responses the authors and the WG cannot make progress on thi= s > document. > > > > For issue 3 and 4: We will incorporate the changes in the next version of > the draft. > > > > Gr, > > Rik > > > > > > > > *From:* Gould, James [mailto:JGould@verisign.com] > *Sent:* vrijdag 9 januari 2015 15:29 > *To:* Rik Ribbers > *Cc:* eppext@ietf.org > *Subject:* Re: [eppext] New draft for keyrelay available > > > > Rik, > > > > Below is my feedback to the updated draft: > > > > 1. As noted in past mailing list comments and in person discussions, I > don=E2=80=99t agree with the mixing of a protocol extension for the co= mmand and an > object mapping for the poll response. I have provided examples of > implementing this draft using either an object mapping or a command > response extension of domain. In it=E2=80=99s current form, I=E2=80= =99m assuming that the > EPP greeting and login would include the urn:ietf:params:xml:ns:relay-= 1.0 > URI in both a and an element. I highly recommend th= at > you reconsider this. > 2. You are making keyrelay more generic by creating a new extension > point of the data to relay, with the key data being one concrete type.= I > still believe that creating a Key Relay Object Mapping would have been= the > best route to go, since the creation of a Key Relay object would add i= t > into the poll queue for consumption by the losing registrar. The only > command supported by the mapping is create along with the poll info > response. The create is creating a transient object. If other types = of > data need to be =E2=80=9Crelayed=E2=80=9D, a similar approach could be= taken without having > to add an additional layer of extensibility. A new EPP object mapping > would be defined for the new type. The key relay along with any other > relay objects will be properly exposed in the EPP greeting and login > elements. > 3. Nit in 3.1.1, =E2=80=9CAn OPTIONAL (client transaction ide= ntifier) > element that MAY be used to uniquely identify the command to the > registrar=E2=80=9D, should reference client instead of registrar. > 4. What is the expected response to the command? I=E2=80=99m = assuming > that it=E2=80=99s as EPP response as defined in section 2.6 of RFC 573= 0 where the > value is set with the value associated with the co= mmand > if supplied by the client. > > > > Regards, > > > > =E2=80=94 > > > > JG > > > > > > *James Gould *Distinguished Engineer > jgould@Verisign.com > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com > > > > On Jan 8, 2015, at 8:41 AM, Rik Ribbers wrote: > > > > All, > > > > As you (may) have noticed we submitted a new version of the keyrelay > draft. In this draft we tried to solve all the open issues, remarks and > feedback we received. > > > > The major changes are: > > > > 1. Introducing the command, and thus seperating the data and > > the command. > > > > 2. Updated the Introduction, describing the general use of relay vs > > the intended use-case of relaying DNSSEC key data. > > > > 3. Restructuring the document to make it more inline with existing > > EPP extensions. > > > > In the end it has become a major rewrite and as always feedback is welcom= e. > > > > Kind regards, > > Rik Ribbers > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > > --047d7b3a7f0a33be55050ddb080d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

At first I would like to point out = that both yours and James ideas are not that far apart.=C2=A0
Int= roduction of a new temporary object which is send from registrar to registr= ar via the registry.=C2=A0
That would obviously need some changes= to current systems at the registry and registrars.
I believe we = should keep the needed changes as small as possible.=C2=A0
Theref= or I think that James idea to use existing commands is the way to go.
=

Kind regards

Ulrich
=

2= 015-01-13 11:09 GMT+01:00 Rik Ribbers <rik.ribbers@sidn.nl>:

James,<= /u>

=C2= =A0

Thank you = for the feedback.

=C2= =A0

My feedbac= k on issue 1 and 2:

=C2= =A0

I get a fe= eling we are running in circles. All arguments have been mentioned in previ= ous posts on this mailinglist. So what it boils down to is what the rest of the WG thinks of this. So I politely , but =C2=A0urgently= ask the other members on this list to respond to the question: Should we r= econsider extending EPP with a new command and use the object or protocol e= xtension James proposes (see http://www.ietf.org/mail-archive/web/eppext/current/ms= g00241.html) If there are no responses the authors and the WG cannot ma= ke progress on this document.

=C2= =A0

For issue = 3 and 4: We will incorporate the changes in the next version of the draft.<= u>

=C2= =A0

Gr,=

Rik =C2=A0=

=C2= =A0

=C2= =A0

=C2= =A0

From: Gould, James [mailto:JGould@verisign.com]
Sent: vrijdag 9 januari 2015 15:29
To: Rik Ribbers
Cc: eppext@ietf= .org
Subject: Re: [eppext] New draft for keyrelay available=

=C2=A0

Rik,

=C2=A0

Below is my feedback to the updated draft:=

=C2=A0

  1. As noted in past mailing list comments and in person discussions, I don=E2= =80=99t agree with the mixing of a protocol extension for the command and a= n object mapping for the poll response.=C2=A0 I have provided examples of i= mplementing this draft using either an object mapping or a command response extension of domain.=C2=A0 In it=E2=80=99s c= urrent form, I=E2=80=99m assuming that the EPP greeting and login would inc= lude the urn:ietf:params:xml:ns:relay-1.0 URI in both a <objURI> and = an <extURI> element.=C2=A0 I highly recommend that you reconsider this. =C2=A0 =C2=A0
  2. You are making keyrelay more generic by creating a new extension point of t= he data to relay, with the key data being one concrete type.=C2=A0 I still = believe that creating a Key Relay Object Mapping would have been the best r= oute to go, since the creation of a Key Relay object would add it into the poll queue for consumption by the losin= g registrar.=C2=A0 The only command supported by the mapping is create alon= g with the poll info response.=C2=A0 The create is creating a transient obj= ect.=C2=A0 If other types of data need to be =E2=80=9Crelayed=E2=80=9D, a similar approach could be taken without having to add an additional laye= r of extensibility.=C2=A0 A new EPP object mapping would be defined for the= new type.=C2=A0 The key relay along with any other relay objects will be p= roperly exposed in the EPP greeting and login <objURI> elements. =C2=A0
  3. Nit in 3.1.1, =E2=80=9CAn OPTIONAL <clTRID> (client transaction ident= ifier) element that MAY be used to uniquely identify the command to the reg= istrar=E2=80=9D, should reference client instead of registrar.=C2=A0=
  4. What is the expected response to the <relay> command?=C2=A0 I=E2=80= =99m assuming that it=E2=80=99s as EPP response as defined in section 2.6 o= f RFC 5730 where the <clTRID> value is set with the <r:clTRID> = value associated with the command if supplied by the client.<= /li>

=C2=A0

Regards,

=C2=A0

=E2= =80=94

=C2=A0

JG




James Gould
Distinguished Engineer
jgould@Verisign.co= m

703-9= 48-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

=C2=A0

On Jan 8, 2015, at 8:41 AM, Rik Ribbers <rik.ribbers@sidn.nl&g= t; wrote:



All,

=C2=A0

As you (may) have notice= d we submitted a new version of the keyrelay draft. In this draft we tried = to solve all the open issues, remarks and feedback we received.

=C2=A0

The major=C2=A0 changes = are:

=C2=A0

=C2=A0 1.=C2=A0 Introduc= ing the <relay> command, and thus seperating the data and

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 the command.

=C2=A0

=C2=A0=C2=A0 2.=C2=A0 Up= dated the Introduction, describing the general use of relay vs

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 the intended use-case of relaying DNSSEC key data.

=C2=A0

=C2=A0=C2=A0 3.=C2=A0 Re= structuring the document to make it more inline with existing

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 EPP extensions.

=C2=A0

In the end it has become= a major rewrite and as always feedback is welcome.<= /u>

=C2=A0

Kind regards,

Rik Ribbers

________________________________________= _______
EppExt mailing list
EppExt@ietf.org
= https://www.ietf.org/mailman/listinfo/eppext

=C2=A0


_______________________________________________
EppExt mailing list
EppExt@ietf.org
= https://www.ietf.org/mailman/listinfo/eppext


--047d7b3a7f0a33be55050ddb080d-- --047d7b3a7f0a33be5a050ddb080e Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ff03fc346e2c9281_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --047d7b3a7f0a33be5a050ddb080e-- From nobody Fri Jan 30 01:32:37 2015 Return-Path: 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 E697B1A8A77 for ; Fri, 30 Jan 2015 01:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.943 X-Spam-Level: X-Spam-Status: No, score=0.943 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] 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 iKZrfuSPMppK for ; Fri, 30 Jan 2015 01:32:34 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 077821A8A6D for ; Fri, 30 Jan 2015 01:32:34 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id s18so22746776lam.5 for ; Fri, 30 Jan 2015 01:32:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=VkK8p8w64tkNYD/IUp3RrmM+U0splOHWUT2tCrGTFCQ=; b=cHROaT1Cs7b6JwwS9z0kqsNXJs8gBtNT+wcCynkd/y7Bj+4r7yAYxnGf890h90Liab hm052uE20qgMuXORCzQUhEIKvL1/uBVlL1vbZxeh50Gvi9UBEoaBm3d3uCWZeVhqwJ/g gktjxAQsxNqNtpGvQZiuKaa+M7k3m3ETQC0aNQU3JV8jXriVtLic5Oo8nNU/eYlJwbEY 2S4DozyLuFvzSYkJ4+aimr1KxCCvVBamO7l0gZSvLVMwQUsOYczcqj6SkHq/YrmHFeVM ZwKnWm09MvAaL/sVU9ByGR/fjvScP2qtvDCRjHDBfhmE3ZC7p5xfaVBNY6ZlArvZLGGB xFXQ== X-Gm-Message-State: ALoCoQld8jK2rR72ApYB4wTnZUCOUIT89JHJ3Y2m2TPCc7xYgXCY3ddaVNnYCGcSXSEiCppdI7n2 MIME-Version: 1.0 X-Received: by 10.112.243.12 with SMTP id wu12mr5459549lbc.91.1422610352094; Fri, 30 Jan 2015 01:32:32 -0800 (PST) Received: by 10.25.29.134 with HTTP; Fri, 30 Jan 2015 01:32:32 -0800 (PST) In-Reply-To: <54BFC82E.1070208@elistx.com> References: <54BFC82E.1070208@elistx.com> Date: Fri, 30 Jan 2015 10:32:32 +0100 Message-ID: From: Ulrich Wisser Cc: eppext Content-Type: multipart/alternative; boundary=001a1133ac52b0e8f5050ddb48cd Archived-At: Subject: Re: [eppext] moving documents along X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 09:32:36 -0000 --001a1133ac52b0e8f5050ddb48cd Content-Type: text/plain; charset=UTF-8 Hi James! Besides the old documents I would like to see us discuss if we want to adopt new ones / recharter. draft-ietf-eppext-idnmap-02 is not very controversial except that we need to defines the table names. Otherwise it doesn't help much. draft-ietf-eppext-launchphase-02 and draft-ietf-eppext-tmch-smd-00 seem technically sound so no objections there. /Ulrich 2015-01-21 16:39 GMT+01:00 James Galvin : > Speaking as Chair, I want to bring folks up to date on where I believe we > are. Please do speak up if you disagree or have any corrections. > > We have 5 documents in our working group. > > > 1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible > Provisioning Protocol > > If you've been tracking the status updates from the RFC Editor on the list > then you know this document is close to publication as an RFC. Scott > Hollenbeck has been doing his part to move this along. There is no action > for the working group at this time. > > > 2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping > Extension for the Extensible Provisioning Protocol (EPP) > > There has been very little discussion on the mailing list about this > document. Andrew Sullivan posted some extensive comments to which there > has been limited response. > > It's tough to declare consensus with so little discussion. It would be > helpful if folks would review the document and comments and post at least a > "no objection". > > > 3. draft-ietf-eppext-keyrelay-01 Relay Extension for the > Extensible Provisioning Protocol > > There has been lively discussion here and we appear to have a difference > of opinion on a technical point. We very much need to hear from other > folks. Please review the thread and let everyone know what you think. > > > 4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the > Extensible Provisioning Protocol (EPP) > > I believe we're close to consensus on this document. There's been some > discussion but nothing too contentious as far as I can see. I'm expecting > Jim Gould to submit a revised document in the not too distant future and > we'll review where we are at that time. > > > 5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping > > This document has expired and is waiting for the author to resubmit. There > was one change proposed on the mailing list last year that needs to be > incorporated in the revision. > > At one time there was concern about the relationship between this document > and the launchphase document but I don't believe that concern exists any > more. > > I suppose it's fair to ask if the working group is still interested in > publishing this document. If so, I'll press Gustavo to submit a revised > document and we can review where we are at that time. > > > Comments and corrections are welcome! > > Jim > > _______________________________________________ > EppExt mailing list > EppExt@ietf.org > https://www.ietf.org/mailman/listinfo/eppext > --001a1133ac52b0e8f5050ddb48cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi =C2=A0James!

Besides the old documen= ts I would like to see us discuss if we want to adopt new ones / recharter.= =C2=A0

draft-ietf-eppext-idnmap-02 is not very controversial except that we need= to defines the table names. Otherwise it doesn't help much.=C2=A0

draft-ietf-eppext-lau= nchphase-02 and=C2=A0draft-ietf-eppext-tmch-smd-00 seem technically sound= so no objections there.

/Ulrich<= /div>


2015-01-21 16:= 39 GMT+01:00 James Galvin <galvin@elistx.com>:
Speaking as Chair, I want to bring folks up to date on= where I believe we are.=C2=A0 Please do speak up if you disagree or have a= ny corrections.

We have 5 documents in our working group.


1. draft-ietf-eppext-reg-10 Extension Registry for the Extensible Provision= ing Protocol

If you've been tracking the status updates from the RFC Editor on the l= ist then you know this document is close to publication as an RFC. Scott Ho= llenbeck has been doing his part to move this along.=C2=A0 There is no acti= on for the working group at this time.


2. draft-ietf-eppext-idnmap-02 Internationalized Domain Name Mapping Extens= ion for the Extensible Provisioning Protocol (EPP)=C2=A0 =C2=A0

There has been very little discussion on the mailing list about this docume= nt.=C2=A0 Andrew Sullivan posted some extensive comments to which there has= been limited response.

It's tough to declare consensus with so little discussion.=C2=A0 It wou= ld be helpful if folks would review the document and comments and post at l= east a "no objection".


3. draft-ietf-eppext-keyrelay-01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Relay Ext= ension for the Extensible Provisioning Protocol

There has been lively discussion here and we appear to have a difference of= opinion on a technical point.=C2=A0 We very much need to hear from other f= olks.=C2=A0 Please review the thread and let everyone know what you think.<= br>

4. draft-ietf-eppext-launchphase-02 Launch Phase Mapping for the Ext= ensible Provisioning Protocol (EPP)

I believe we're close to consensus on this document.=C2=A0 There's = been some discussion but nothing too contentious as far as I can see.=C2=A0= I'm expecting Jim Gould to submit a revised document in the not too di= stant future and we'll review where we are at that time.


5. draft-ietf-eppext-tmch-smd-00 Mark and Signed Mark Objects Mapping

This document has expired and is waiting for the author to resubmit. There = was one change proposed on the mailing list last year that needs to be inco= rporated in the revision.

At one time there was concern about the relationship between this document = and the launchphase document but I don't believe that concern exists an= y more.

I suppose it's fair to ask if the working group is still interested in = publishing this document.=C2=A0 If so, I'll press Gustavo to submit a r= evised document and we can review where we are at that time.


Comments and corrections are welcome!

Jim

_______________________________________________
EppExt mailing list
EppExt@ietf.org = https://www.ietf.org/mailman/listinfo/eppext

--001a1133ac52b0e8f5050ddb48cd-- From nobody Fri Jan 30 01:35:10 2015 Return-Path: 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 E77DA1A8A77 for ; Fri, 30 Jan 2015 01:35:06 -0800 (PST) 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 tNllTdtQyWIz for ; Fri, 30 Jan 2015 01:35:04 -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 18A051A8A6D for ; Fri, 30 Jan 2015 01:35:03 -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-originating-ip:content-type:mime-version; bh=uc/xmQKjtBv7Ps/NHnBRu975qiGTwoDQ76tBmqTipn4=; b=OiwdpHAJetZLofU5wCtfTpArqwQ6gAMaUcdqHOiKM3BlVeWlteEJc/d9vB8aQxoYBXztKvJq4lBNq6fykHnZBqUAg35HdkGeggUQGPSlZJZoefBmVGJM95ejNwm45Qr9B4abGnRoDbd/IrD/UPHTPJZ1s8+dV84dpqaTb5+bCtw= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id t0U9Z2Gw016529-t0U9Z2H0016529 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Fri, 30 Jan 2015 10:35:02 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 10:34:59 +0100 From: Rik Ribbers To: "'Ulrich Wisser'" , "eppext@ietf.org" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qADU33BgAACiZ0g Date: Fri, 30 Jan 2015 09:34:59 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 09:35:07 -0000 --_004_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVWxscmljaCwNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLCBpdCBsb29rcyBsaWtl IHdl4oCZcmUgZ2V0dGluZyBzb21ld2hlcmUuIExpa2UgSSBzYWlkIGluIEhvbm9sdWx1IEphbWVz IGFuZCBJIGRvbuKAmXQgYWdyZWUgYnV0IHdlIG5lZWQgb3RoZXJzIHRvIHNoYXJlIHRoZWlyIHRo b3VnaHRzIG9uIHRoaXMgYW5kIHRoYXQgaXMgc3RhcnRpbmcgdG8gaGFwcGVuLg0KDQpIb3BlZnVs bHkgbW9yZSBwZW9wbGUgZXhwcmVzcyB0aGVyZSBvcGluaW9uIG9uIHRoZSBpc3N1ZSBhbmQgZ2V0 IHRoZSBkcmFmdCBtb3ZpbmcgYWdhaW4uDQoNCktpbmQgcmVnYXJkcywNCg0KUmlrIFJpYmJlcnMN Cg0KRnJvbTogRXBwRXh0IFttYWlsdG86ZXBwZXh0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBVbHJpY2ggV2lzc2VyDQpTZW50OiB2cmlqZGFnIDMwIGphbnVhcmkgMjAxNSAxMDoxNA0K VG86IGVwcGV4dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtlcHBleHRdIE5ldyBkcmFmdCBmb3Ig a2V5cmVsYXkgYXZhaWxhYmxlDQoNCkhpIQ0KDQpBdCBmaXJzdCBJIHdvdWxkIGxpa2UgdG8gcG9p bnQgb3V0IHRoYXQgYm90aCB5b3VycyBhbmQgSmFtZXMgaWRlYXMgYXJlIG5vdCB0aGF0IGZhciBh cGFydC4NCkludHJvZHVjdGlvbiBvZiBhIG5ldyB0ZW1wb3Jhcnkgb2JqZWN0IHdoaWNoIGlzIHNl bmQgZnJvbSByZWdpc3RyYXIgdG8gcmVnaXN0cmFyIHZpYSB0aGUgcmVnaXN0cnkuDQpUaGF0IHdv dWxkIG9idmlvdXNseSBuZWVkIHNvbWUgY2hhbmdlcyB0byBjdXJyZW50IHN5c3RlbXMgYXQgdGhl IHJlZ2lzdHJ5IGFuZCByZWdpc3RyYXJzLg0KSSBiZWxpZXZlIHdlIHNob3VsZCBrZWVwIHRoZSBu ZWVkZWQgY2hhbmdlcyBhcyBzbWFsbCBhcyBwb3NzaWJsZS4NClRoZXJlZm9yIEkgdGhpbmsgdGhh dCBKYW1lcyBpZGVhIHRvIHVzZSBleGlzdGluZyBjb21tYW5kcyBpcyB0aGUgd2F5IHRvIGdvLg0K DQpLaW5kIHJlZ2FyZHMNCg0KVWxyaWNoDQoNCg0KMjAxNS0wMS0xMyAxMTowOSBHTVQrMDE6MDAg UmlrIFJpYmJlcnMgPHJpay5yaWJiZXJzQHNpZG4ubmw8bWFpbHRvOnJpay5yaWJiZXJzQHNpZG4u bmw+PjoNCkphbWVzLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjay4NCg0KTXkgZmVlZGJh Y2sgb24gaXNzdWUgMSBhbmQgMjoNCg0KSSBnZXQgYSBmZWVsaW5nIHdlIGFyZSBydW5uaW5nIGlu IGNpcmNsZXMuIEFsbCBhcmd1bWVudHMgaGF2ZSBiZWVuIG1lbnRpb25lZCBpbiBwcmV2aW91cyBw b3N0cyBvbiB0aGlzIG1haWxpbmdsaXN0LiBTbyB3aGF0IGl0IGJvaWxzIGRvd24gdG8gaXMgd2hh dCB0aGUgcmVzdCBvZiB0aGUgV0cgdGhpbmtzIG9mIHRoaXMuIFNvIEkgcG9saXRlbHkgLCBidXQg IHVyZ2VudGx5IGFzayB0aGUgb3RoZXIgbWVtYmVycyBvbiB0aGlzIGxpc3QgdG8gcmVzcG9uZCB0 byB0aGUgcXVlc3Rpb246IFNob3VsZCB3ZSByZWNvbnNpZGVyIGV4dGVuZGluZyBFUFAgd2l0aCBh IG5ldyBjb21tYW5kIGFuZCB1c2UgdGhlIG9iamVjdCBvciBwcm90b2NvbCBleHRlbnNpb24gSmFt ZXMgcHJvcG9zZXMgKHNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZXBw ZXh0L2N1cnJlbnQvbXNnMDAyNDEuaHRtbCkgSWYgdGhlcmUgYXJlIG5vIHJlc3BvbnNlcyB0aGUg YXV0aG9ycyBhbmQgdGhlIFdHIGNhbm5vdCBtYWtlIHByb2dyZXNzIG9uIHRoaXMgZG9jdW1lbnQu DQoNCkZvciBpc3N1ZSAzIGFuZCA0OiBXZSB3aWxsIGluY29ycG9yYXRlIHRoZSBjaGFuZ2VzIGlu IHRoZSBuZXh0IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpHciwNClJpaw0KDQoNCg0KRnJvbTog R291bGQsIEphbWVzIFttYWlsdG86SkdvdWxkQHZlcmlzaWduLmNvbTxtYWlsdG86SkdvdWxkQHZl cmlzaWduLmNvbT5dDQpTZW50OiB2cmlqZGFnIDkgamFudWFyaSAyMDE1IDE1OjI5DQpUbzogUmlr IFJpYmJlcnMNCkNjOiBlcHBleHRAaWV0Zi5vcmc8bWFpbHRvOmVwcGV4dEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbZXBwZXh0XSBOZXcgZHJhZnQgZm9yIGtleXJlbGF5IGF2YWlsYWJsZQ0KDQpS aWssDQoNCkJlbG93IGlzIG15IGZlZWRiYWNrIHRvIHRoZSB1cGRhdGVkIGRyYWZ0Og0KDQoNCiAg MS4gIEFzIG5vdGVkIGluIHBhc3QgbWFpbGluZyBsaXN0IGNvbW1lbnRzIGFuZCBpbiBwZXJzb24g ZGlzY3Vzc2lvbnMsIEkgZG9u4oCZdCBhZ3JlZSB3aXRoIHRoZSBtaXhpbmcgb2YgYSBwcm90b2Nv bCBleHRlbnNpb24gZm9yIHRoZSBjb21tYW5kIGFuZCBhbiBvYmplY3QgbWFwcGluZyBmb3IgdGhl IHBvbGwgcmVzcG9uc2UuICBJIGhhdmUgcHJvdmlkZWQgZXhhbXBsZXMgb2YgaW1wbGVtZW50aW5n IHRoaXMgZHJhZnQgdXNpbmcgZWl0aGVyIGFuIG9iamVjdCBtYXBwaW5nIG9yIGEgY29tbWFuZCBy ZXNwb25zZSBleHRlbnNpb24gb2YgZG9tYWluLiAgSW4gaXTigJlzIGN1cnJlbnQgZm9ybSwgSeKA mW0gYXNzdW1pbmcgdGhhdCB0aGUgRVBQIGdyZWV0aW5nIGFuZCBsb2dpbiB3b3VsZCBpbmNsdWRl IHRoZSB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnJlbGF5LTEuMCBVUkkgaW4gYm90aCBhIDxvYmpV Ukk+IGFuZCBhbiA8ZXh0VVJJPiBlbGVtZW50LiAgSSBoaWdobHkgcmVjb21tZW5kIHRoYXQgeW91 IHJlY29uc2lkZXIgdGhpcy4NCiAgMi4gIFlvdSBhcmUgbWFraW5nIGtleXJlbGF5IG1vcmUgZ2Vu ZXJpYyBieSBjcmVhdGluZyBhIG5ldyBleHRlbnNpb24gcG9pbnQgb2YgdGhlIGRhdGEgdG8gcmVs YXksIHdpdGggdGhlIGtleSBkYXRhIGJlaW5nIG9uZSBjb25jcmV0ZSB0eXBlLiAgSSBzdGlsbCBi ZWxpZXZlIHRoYXQgY3JlYXRpbmcgYSBLZXkgUmVsYXkgT2JqZWN0IE1hcHBpbmcgd291bGQgaGF2 ZSBiZWVuIHRoZSBiZXN0IHJvdXRlIHRvIGdvLCBzaW5jZSB0aGUgY3JlYXRpb24gb2YgYSBLZXkg UmVsYXkgb2JqZWN0IHdvdWxkIGFkZCBpdCBpbnRvIHRoZSBwb2xsIHF1ZXVlIGZvciBjb25zdW1w dGlvbiBieSB0aGUgbG9zaW5nIHJlZ2lzdHJhci4gIFRoZSBvbmx5IGNvbW1hbmQgc3VwcG9ydGVk IGJ5IHRoZSBtYXBwaW5nIGlzIGNyZWF0ZSBhbG9uZyB3aXRoIHRoZSBwb2xsIGluZm8gcmVzcG9u c2UuICBUaGUgY3JlYXRlIGlzIGNyZWF0aW5nIGEgdHJhbnNpZW50IG9iamVjdC4gIElmIG90aGVy IHR5cGVzIG9mIGRhdGEgbmVlZCB0byBiZSDigJxyZWxheWVk4oCdLCBhIHNpbWlsYXIgYXBwcm9h Y2ggY291bGQgYmUgdGFrZW4gd2l0aG91dCBoYXZpbmcgdG8gYWRkIGFuIGFkZGl0aW9uYWwgbGF5 ZXIgb2YgZXh0ZW5zaWJpbGl0eS4gIEEgbmV3IEVQUCBvYmplY3QgbWFwcGluZyB3b3VsZCBiZSBk ZWZpbmVkIGZvciB0aGUgbmV3IHR5cGUuICBUaGUga2V5IHJlbGF5IGFsb25nIHdpdGggYW55IG90 aGVyIHJlbGF5IG9iamVjdHMgd2lsbCBiZSBwcm9wZXJseSBleHBvc2VkIGluIHRoZSBFUFAgZ3Jl ZXRpbmcgYW5kIGxvZ2luIDxvYmpVUkk+IGVsZW1lbnRzLg0KICAzLiAgTml0IGluIDMuMS4xLCDi gJxBbiBPUFRJT05BTCA8Y2xUUklEPiAoY2xpZW50IHRyYW5zYWN0aW9uIGlkZW50aWZpZXIpIGVs ZW1lbnQgdGhhdCBNQVkgYmUgdXNlZCB0byB1bmlxdWVseSBpZGVudGlmeSB0aGUgY29tbWFuZCB0 byB0aGUgcmVnaXN0cmFy4oCdLCBzaG91bGQgcmVmZXJlbmNlIGNsaWVudCBpbnN0ZWFkIG9mIHJl Z2lzdHJhci4NCiAgNC4gIFdoYXQgaXMgdGhlIGV4cGVjdGVkIHJlc3BvbnNlIHRvIHRoZSA8cmVs YXk+IGNvbW1hbmQ/ICBJ4oCZbSBhc3N1bWluZyB0aGF0IGl04oCZcyBhcyBFUFAgcmVzcG9uc2Ug YXMgZGVmaW5lZCBpbiBzZWN0aW9uIDIuNiBvZiBSRkMgNTczMCB3aGVyZSB0aGUgPGNsVFJJRD4g dmFsdWUgaXMgc2V0IHdpdGggdGhlIDxyOmNsVFJJRD4gdmFsdWUgYXNzb2NpYXRlZCB3aXRoIHRo ZSBjb21tYW5kIGlmIHN1cHBsaWVkIGJ5IHRoZSBjbGllbnQuDQoNClJlZ2FyZHMsDQoNCg0K4oCU DQoNCg0KDQpKRw0KDQpbY2lkOmltYWdlMDAxLnBuZ0AwMUQwM0M3Ny5DNTE1RjYzMF0NCg0KSmFt ZXMgR291bGQNCkRpc3Rpbmd1aXNoZWQgRW5naW5lZXINCmpnb3VsZEBWZXJpc2lnbi5jb208aHR0 cDovL2pnb3VsZEBWZXJpc2lnbi5jb20+DQoNCjcwMy05NDgtMzI3MTx0ZWw6NzAzLTk0OC0zMjcx Pg0KMTIwNjEgQmx1ZW1vbnQgV2F5DQpSZXN0b24sIFZBIDIwMTkwDQoNClZlcmlzaWduSW5jLmNv bTxodHRwOi8vVmVyaXNpZ25JbmMuY29tPg0KDQpPbiBKYW4gOCwgMjAxNSwgYXQgODo0MSBBTSwg UmlrIFJpYmJlcnMgPHJpay5yaWJiZXJzQHNpZG4ubmw8bWFpbHRvOnJpay5yaWJiZXJzQHNpZG4u bmw+PiB3cm90ZToNCg0KQWxsLA0KDQpBcyB5b3UgKG1heSkgaGF2ZSBub3RpY2VkIHdlIHN1Ym1p dHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBrZXlyZWxheSBkcmFmdC4gSW4gdGhpcyBkcmFmdCB3 ZSB0cmllZCB0byBzb2x2ZSBhbGwgdGhlIG9wZW4gaXNzdWVzLCByZW1hcmtzIGFuZCBmZWVkYmFj ayB3ZSByZWNlaXZlZC4NCg0KVGhlIG1ham9yICBjaGFuZ2VzIGFyZToNCg0KICAxLiAgSW50cm9k dWNpbmcgdGhlIDxyZWxheT4gY29tbWFuZCwgYW5kIHRodXMgc2VwZXJhdGluZyB0aGUgZGF0YSBh bmQNCiAgICAgICB0aGUgY29tbWFuZC4NCg0KICAgMi4gIFVwZGF0ZWQgdGhlIEludHJvZHVjdGlv biwgZGVzY3JpYmluZyB0aGUgZ2VuZXJhbCB1c2Ugb2YgcmVsYXkgdnMNCiAgICAgICB0aGUgaW50 ZW5kZWQgdXNlLWNhc2Ugb2YgcmVsYXlpbmcgRE5TU0VDIGtleSBkYXRhLg0KDQogICAzLiAgUmVz dHJ1Y3R1cmluZyB0aGUgZG9jdW1lbnQgdG8gbWFrZSBpdCBtb3JlIGlubGluZSB3aXRoIGV4aXN0 aW5nDQogICAgICAgRVBQIGV4dGVuc2lvbnMuDQoNCkluIHRoZSBlbmQgaXQgaGFzIGJlY29tZSBh IG1ham9yIHJld3JpdGUgYW5kIGFzIGFsd2F5cyBmZWVkYmFjayBpcyB3ZWxjb21lLg0KDQpLaW5k IHJlZ2FyZHMsDQpSaWsgUmliYmVycw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkVwcEV4dCBtYWlsaW5nIGxpc3QNCkVwcEV4dEBpZXRmLm9yZzxtYWls dG86RXBwRXh0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9lcHBleHQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRXBwRXh0IG1haWxpbmcgbGlzdA0KRXBwRXh0QGlldGYub3JnPG1haWx0bzpFcHBFeHRA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VwcGV4dA0K DQo= --_000_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDEx IDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQg NSAyIDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOk5MO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1 cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzAx NzEwOTE1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYxMjQxMjY2NDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJOTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBVbGxyaWNoLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UsIGl0 IGxvb2tzIGxpa2Ugd2XigJlyZSBnZXR0aW5nIHNvbWV3aGVyZS4gTGlrZSBJIHNhaWQgaW4gSG9u b2x1bHUgSmFtZXMgYW5kIEkgZG9u4oCZdCBhZ3JlZSBidXQgd2UgbmVlZCBvdGhlcnMgdG8gc2hh cmUgdGhlaXINCiB0aG91Z2h0cyBvbiB0aGlzIGFuZCB0aGF0IGlzIHN0YXJ0aW5nIHRvIGhhcHBl bi4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvcGVmdWxseSBtb3JlIHBl b3BsZSBleHByZXNzIHRoZXJlIG9waW5pb24gb24gdGhlIGlzc3VlIGFuZCBnZXQgdGhlIGRyYWZ0 IG1vdmluZyBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+S2luZCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SaWsgUmliYmVyczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRXBwRXh0IFttYWlsdG86ZXBwZXh0LWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlVscmljaCBXaXNzZXI8YnI+DQo8Yj5TZW50Ojwv Yj4gdnJpamRhZyAzMCBqYW51YXJpIDIwMTUgMTA6MTQ8YnI+DQo8Yj5Ubzo8L2I+IGVwcGV4dEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2VwcGV4dF0gTmV3IGRyYWZ0IGZvciBr ZXlyZWxheSBhdmFpbGFibGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IGZpcnN0 IEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhhdCBib3RoIHlvdXJzIGFuZCBKYW1lcyBpZGVh cyBhcmUgbm90IHRoYXQgZmFyIGFwYXJ0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW50cm9kdWN0aW9uIG9mIGEgbmV3IHRlbXBvcmFy eSBvYmplY3Qgd2hpY2ggaXMgc2VuZCBmcm9tIHJlZ2lzdHJhciB0byByZWdpc3RyYXIgdmlhIHRo ZSByZWdpc3RyeS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYXQgd291bGQgb2J2aW91c2x5IG5lZWQgc29tZSBjaGFuZ2VzIHRvIGN1 cnJlbnQgc3lzdGVtcyBhdCB0aGUgcmVnaXN0cnkgYW5kIHJlZ2lzdHJhcnMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgd2Ugc2hv dWxkIGtlZXAgdGhlIG5lZWRlZCBjaGFuZ2VzIGFzIHNtYWxsIGFzIHBvc3NpYmxlLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmVm b3IgSSB0aGluayB0aGF0IEphbWVzIGlkZWEgdG8gdXNlIGV4aXN0aW5nIGNvbW1hbmRzIGlzIHRo ZSB3YXkgdG8gZ28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPktpbmQgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5VbHJpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE1LTAxLTEzIDExOjA5IEdNVCYjNDM7MDE6MDAg UmlrIFJpYmJlcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpyaWsucmliYmVyc0BzaWRuLm5sIiB0YXJn ZXQ9Il9ibGFuayI+cmlrLnJpYmJlcnNAc2lkbi5ubDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFtZXMsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjay4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TXkgZmVlZGJhY2sgb24gaXNz dWUgMSBhbmQgMjoNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBn ZXQgYSBmZWVsaW5nIHdlIGFyZSBydW5uaW5nIGluIGNpcmNsZXMuIEFsbCBhcmd1bWVudHMgaGF2 ZSBiZWVuIG1lbnRpb25lZCBpbiBwcmV2aW91cw0KIHBvc3RzIG9uIHRoaXMgbWFpbGluZ2xpc3Qu IFNvIHdoYXQgaXQgYm9pbHMgZG93biB0byBpcyB3aGF0IHRoZSByZXN0IG9mIHRoZSBXRyB0aGlu a3Mgb2YgdGhpcy4gU28gSSBwb2xpdGVseSAsIGJ1dCAmbmJzcDt1cmdlbnRseSBhc2sgdGhlIG90 aGVyIG1lbWJlcnMgb24gdGhpcyBsaXN0IHRvIHJlc3BvbmQgdG8gdGhlIHF1ZXN0aW9uOiBTaG91 bGQgd2UgcmVjb25zaWRlciBleHRlbmRpbmcgRVBQIHdpdGggYSBuZXcgY29tbWFuZCBhbmQgdXNl IHRoZSBvYmplY3QNCiBvciBwcm90b2NvbCBleHRlbnNpb24gSmFtZXMgcHJvcG9zZXMgKHNlZSA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZXBwZXh0L2N1cnJl bnQvbXNnMDAyNDEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2VwcGV4dC9jdXJyZW50L21zZzAwMjQxLmh0bWw8L2E+KSBJZiB0aGVy ZSBhcmUgbm8gcmVzcG9uc2VzIHRoZSBhdXRob3JzIGFuZCB0aGUgV0cgY2Fubm90IG1ha2UgcHJv Z3Jlc3Mgb24gdGhpcyBkb2N1bWVudC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Rm9yIGlzc3VlIDMgYW5kIDQ6IFdlIHdpbGwgaW5jb3Jwb3JhdGUgdGhlIGNoYW5n ZXMgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Hciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+UmlrICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEdvdWxkLA0KIEphbWVzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OkpHb3VsZEB2ZXJpc2lnbi5jb20iIHRhcmdldD0iX2JsYW5rIj5KR291bGRAdmVyaXNpZ24uY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiB2cmlqZGFnIDkgamFudWFyaSAyMDE1IDE1OjI5PGJy Pg0KPGI+VG86PC9iPiBSaWsgUmliYmVyczxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv OmVwcGV4dEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmVwcGV4dEBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtlcHBleHRdIE5ldyBkcmFmdCBmb3Iga2V5cmVsYXkgYXZh aWxhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlJpaywNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkJlbG93IGlzIG15IGZlZWRiYWNrIHRvIHRoZSB1cGRhdGVkIGRyYWZ0OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkFzIG5vdGVkIGluIHBhc3Qg bWFpbGluZyBsaXN0IGNvbW1lbnRzIGFuZCBpbiBwZXJzb24gZGlzY3Vzc2lvbnMsIEkgZG9u4oCZ dCBhZ3JlZSB3aXRoIHRoZSBtaXhpbmcgb2YgYSBwcm90b2NvbCBleHRlbnNpb24gZm9yIHRoZSBj b21tYW5kIGFuZCBhbiBvYmplY3QgbWFwcGluZyBmb3IgdGhlIHBvbGwgcmVzcG9uc2UuJm5ic3A7 IEkgaGF2ZSBwcm92aWRlZCBleGFtcGxlcyBvZiBpbXBsZW1lbnRpbmcgdGhpcyBkcmFmdCB1c2lu ZyBlaXRoZXIgYW4gb2JqZWN0DQogbWFwcGluZyBvciBhIGNvbW1hbmQgcmVzcG9uc2UgZXh0ZW5z aW9uIG9mIGRvbWFpbi4mbmJzcDsgSW4gaXTigJlzIGN1cnJlbnQgZm9ybSwgSeKAmW0gYXNzdW1p bmcgdGhhdCB0aGUgRVBQIGdyZWV0aW5nIGFuZCBsb2dpbiB3b3VsZCBpbmNsdWRlIHRoZSB1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnJlbGF5LTEuMCBVUkkgaW4gYm90aCBhICZsdDtvYmpVUkkmZ3Q7 IGFuZCBhbiAmbHQ7ZXh0VVJJJmd0OyBlbGVtZW50LiZuYnNwOyBJIGhpZ2hseSByZWNvbW1lbmQg dGhhdCB5b3UgcmVjb25zaWRlcg0KIHRoaXMuICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpZb3UgYXJl IG1ha2luZyBrZXlyZWxheSBtb3JlIGdlbmVyaWMgYnkgY3JlYXRpbmcgYSBuZXcgZXh0ZW5zaW9u IHBvaW50IG9mIHRoZSBkYXRhIHRvIHJlbGF5LCB3aXRoIHRoZSBrZXkgZGF0YSBiZWluZyBvbmUg Y29uY3JldGUgdHlwZS4mbmJzcDsgSSBzdGlsbCBiZWxpZXZlIHRoYXQgY3JlYXRpbmcgYSBLZXkg UmVsYXkgT2JqZWN0IE1hcHBpbmcgd291bGQgaGF2ZSBiZWVuIHRoZSBiZXN0IHJvdXRlIHRvIGdv LCBzaW5jZSB0aGUgY3JlYXRpb24gb2YgYSBLZXkNCiBSZWxheSBvYmplY3Qgd291bGQgYWRkIGl0 IGludG8gdGhlIHBvbGwgcXVldWUgZm9yIGNvbnN1bXB0aW9uIGJ5IHRoZSBsb3NpbmcgcmVnaXN0 cmFyLiZuYnNwOyBUaGUgb25seSBjb21tYW5kIHN1cHBvcnRlZCBieSB0aGUgbWFwcGluZyBpcyBj cmVhdGUgYWxvbmcgd2l0aCB0aGUgcG9sbCBpbmZvIHJlc3BvbnNlLiZuYnNwOyBUaGUgY3JlYXRl IGlzIGNyZWF0aW5nIGEgdHJhbnNpZW50IG9iamVjdC4mbmJzcDsgSWYgb3RoZXIgdHlwZXMgb2Yg ZGF0YSBuZWVkIHRvIGJlIOKAnHJlbGF5ZWTigJ0sDQogYSBzaW1pbGFyIGFwcHJvYWNoIGNvdWxk IGJlIHRha2VuIHdpdGhvdXQgaGF2aW5nIHRvIGFkZCBhbiBhZGRpdGlvbmFsIGxheWVyIG9mIGV4 dGVuc2liaWxpdHkuJm5ic3A7IEEgbmV3IEVQUCBvYmplY3QgbWFwcGluZyB3b3VsZCBiZSBkZWZp bmVkIGZvciB0aGUgbmV3IHR5cGUuJm5ic3A7IFRoZSBrZXkgcmVsYXkgYWxvbmcgd2l0aCBhbnkg b3RoZXIgcmVsYXkgb2JqZWN0cyB3aWxsIGJlIHByb3Blcmx5IGV4cG9zZWQgaW4gdGhlIEVQUCBn cmVldGluZyBhbmQgbG9naW4NCiAmbHQ7b2JqVVJJJmd0OyBlbGVtZW50cy4gJm5ic3A7PG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KTml0IGluIDMuMS4xLCDigJxBbiBPUFRJT05BTCAmbHQ7Y2xUUklEJmd0OyAoY2xpZW50IHRy YW5zYWN0aW9uIGlkZW50aWZpZXIpIGVsZW1lbnQgdGhhdCBNQVkgYmUgdXNlZCB0byB1bmlxdWVs eSBpZGVudGlmeSB0aGUgY29tbWFuZCB0byB0aGUgcmVnaXN0cmFy4oCdLCBzaG91bGQgcmVmZXJl bmNlIGNsaWVudCBpbnN0ZWFkIG9mIHJlZ2lzdHJhci4mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpXaGF0IGlzIHRo ZSBleHBlY3RlZCByZXNwb25zZSB0byB0aGUgJmx0O3JlbGF5Jmd0OyBjb21tYW5kPyZuYnNwOyBJ 4oCZbSBhc3N1bWluZyB0aGF0IGl04oCZcyBhcyBFUFAgcmVzcG9uc2UgYXMgZGVmaW5lZCBpbiBz ZWN0aW9uIDIuNiBvZiBSRkMgNTczMCB3aGVyZSB0aGUgJmx0O2NsVFJJRCZndDsgdmFsdWUgaXMg c2V0IHdpdGggdGhlICZsdDtyOmNsVFJJRCZndDsgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBj b21tYW5kIGlmIHN1cHBsaWVkIGJ5IHRoZSBjbGllbnQuPG86cD48L286cD48L2xpPjwvb2w+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdp bjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPuKAlDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDt3b3JkLXNwYWNpbmc6MHB4Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O3dvcmQtc3BhY2luZzowcHgiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Skc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxicj4NCjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNzMiIGhlaWdodD0i NjQiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iY2lkOmltYWdlMDAxLnBuZ0AwMUQwM0M3Ny5DNTE1 RjYzMCI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJy Pg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90OywmcXVv dDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDZBQUEiPkphbWVzIEdvdWxkPGJyPg0KPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNkI2RDcxIj5EaXN0aW5ndWlz aGVkIEVuZ2luZWVyPGJyPg0KPGEgaHJlZj0iaHR0cDovL2pnb3VsZEBWZXJpc2lnbi5jb20iIHRh cmdldD0iX2JsYW5rIj5qZ291bGRAVmVyaXNpZ24uY29tPC9hPjxicj4NCjxicj4NCjxhIGhyZWY9 InRlbDo3MDMtOTQ4LTMyNzEiIHRhcmdldD0iX2JsYW5rIj43MDMtOTQ4LTMyNzE8L2E+PGJyPg0K MTIwNjEgQmx1ZW1vbnQgV2F5PGJyPg0KUmVzdG9uLCBWQSAyMDE5MDxicj4NCjxicj4NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA2QUFBIj48YSBocmVmPSJo dHRwOi8vVmVyaXNpZ25JbmMuY29tIiB0YXJnZXQ9Il9ibGFuayI+VmVyaXNpZ25JbmMuY29tPC9h Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gSmFu IDgsIDIwMTUsIGF0IDg6NDEgQU0sIFJpayBSaWJiZXJzICZsdDs8YSBocmVmPSJtYWlsdG86cmlr LnJpYmJlcnNAc2lkbi5ubCIgdGFyZ2V0PSJfYmxhbmsiPnJpay5yaWJiZXJzQHNpZG4ubmw8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbGwsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFzIHlvdSAobWF5KSBoYXZlIG5vdGljZWQg d2Ugc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGtleXJlbGF5IGRyYWZ0LiBJbiB0aGlz IGRyYWZ0IHdlIHRyaWVkDQogdG8gc29sdmUgYWxsIHRoZSBvcGVuIGlzc3VlcywgcmVtYXJrcyBh bmQgZmVlZGJhY2sgd2UgcmVjZWl2ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoZSBtYWpvciZuYnNwOyBjaGFuZ2VzIGFyZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IDEuJm5ic3A7IEludHJvZHVjaW5nIHRoZSAm bHQ7cmVsYXkmZ3Q7IGNvbW1hbmQsIGFuZCB0aHVzIHNlcGVyYXRpbmcgdGhlIGRhdGEgYW5kPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGNvbW1hbmQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBVcGRhdGVkIHRoZSBJ bnRyb2R1Y3Rpb24sIGRlc2NyaWJpbmcgdGhlIGdlbmVyYWwgdXNlIG9mIHJlbGF5IHZzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGludGVuZGVkIHVzZS1jYXNlIG9mIHJlbGF5aW5nIERO U1NFQyBrZXkgZGF0YS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFJlc3RydWN0dXJpbmcgdGhlIGRvY3VtZW50IHRvIG1ha2Ug aXQgbW9yZSBpbmxpbmUgd2l0aCBleGlzdGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVQ UCBleHRlbnNpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J biB0aGUgZW5kIGl0IGhhcyBiZWNvbWUgYSBtYWpvciByZXdyaXRlIGFuZCBhcyBhbHdheXMgZmVl ZGJhY2sgaXMgd2VsY29tZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+S2luZCByZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+UmlrIFJpYmJlcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRXBwRXh0IG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpFcHBFeHRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5FcHBFeHRAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZXBwZXh0IiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lcHBleHQ8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkVwcEV4dCBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86RXBwRXh0QGlldGYub3JnIj5FcHBFeHRAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lcHBleHQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VwcGV4 dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 09:30:30 GMT"; modification-date="Fri, 30 Jan 2015 09:30:30 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B928B7BBkambx2SIDNlocal_-- From nobody Fri Jan 30 05:53:38 2015 Return-Path: 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 A92691A037B for ; Fri, 30 Jan 2015 05:53:34 -0800 (PST) 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, 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 8-nj1bZqDOoF for ; Fri, 30 Jan 2015 05:53:31 -0800 (PST) Received: from chip2og112.obsmtp.com (chip2og112.obsmtp.com [64.18.13.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C471A0373 for ; Fri, 30 Jan 2015 05:53:28 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKVMuM1+aXRXigsj/Hu4TDLA0xd4ymDfLN@postini.com; Fri, 30 Jan 2015 05:53:30 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UDrRNG029228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 08:53:27 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 08:53:26 -0500 From: "Gould, James" To: Ulrich Wisser Thread-Topic: [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft Thread-Index: AQHQPGxKLlohz7OT4EqJMOYze6XLQ5zZAzeA Date: Fri, 30 Jan 2015 13:53:26 +0000 Message-ID: <77F1013C-BF41-4982-9845-C1F87F69B5F5@verisign.com> References: <211D0420-18A3-43D7-9A3D-553B34C6DF43@verisign.com> In-Reply-To: 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_77F1013CBF4149829845C1F87F69B5F5verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 13:53:34 -0000 --_004_77F1013CBF4149829845C1F87F69B5F5verisigncom_ Content-Type: multipart/alternative; boundary="_000_77F1013CBF4149829845C1F87F69B5F5verisigncom_" --_000_77F1013CBF4149829845C1F87F69B5F5verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ulrich, Thank you for the review of the draft. My feedback is embedded below. I received private feedback to add an optional caseId element to help captu= re the UDRP, URS, or other case identifier for the change. The optional ca= seId element was added with an enumerated =93type=94 attribute, with the en= umerated values of =93udrp=94, =93urs=94, and =93custom=94, and with an opt= ional =93name=94 attribute for the =93custom=94 type. Are there any additi= onal case types that should be included in the enumerated list? You can se= e the latest updates of the draft using the GitHub project https://github.c= om/james-f-gould/EPP-Change-Poll.git. =97 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 On Jan 30, 2015, at 4:08 AM, Ulrich Wisser > wrote: Hi James and Trung! You two did a nice job on the extension. I would prefer the transform command instead of the info response. That wo= uld eliminate the need for before/after indicator. You mean you want to see the full input transform command in the poll messa= ge? Most of the server-side operations don=92t go through EPP, so it would= be a challenge to attempt to present the input prior to executing the oper= ation using an EPP transform command. Another issue with using a transform= command is representing the server-side logic that is not reflected in the= input parameters like the setting of the expiration date. The client can = see the end result of the operation without having to replicate the transfo= rm operation logic, along with the meta-data about the operation using the = info response. One question for the list is the value in making the before image of the ob= ject available? The after image is required, but the thought is that the b= efore image may be desired. I have some problems with the operators - Why is autoRenew a special operation instead of operation renew with op= =3D"auto=94? I agree that both are associated with renewing the domain; although I view = them as separate first class operations with different characteristics (Wha= t drives the operation, how does the operation function, and what is the ap= plicable grace period for the operation). - What is the difference between delete and delete op=3D"purge=94? Good question. Purge is associated with physically removing the object fro= m the database where the delete could start an RGP lifecycle flow. An imme= diate delete (e.g. delete within the add grace period) is reflected by a = =93delete=94 with the op=3D=93purge=94; otherwise it would be just =93delet= e=94. - Why autoPurge / autoDelete? Another good question. What if for some registries the domain is deleted i= nstead of auto renewed at expiry? That would match the use of the =93autoD= elete=94 operation. Now, the =93autoDelete=94 could include the purging of= the object which would be reflected by setting op=3D=93purge=94. The auto= Purge operation is the server batch that physically purges the object (doma= in) at the end of the pendingDelete period. In this case the domain has be= en deleted, put through the RGP lifecycle flow, and is being purged from th= e database. We wanted to handle both types of registries (auto renew and a= uto delete) as well as be able to identify the event when the object is pur= ged from the database. I hope this makes sense. Kind regards from Stockholm Ulrich 2015-01-20 14:49 GMT+01:00 Gould, James >: The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/ht= ml/draft-gould-change-poll-00 ) has been submitted to the IETF. I co-autho= red this draft with Trung Tran from Neustar to provide a mechanism within E= PP to notify clients of any server-side change, including but not limited t= o regular batch processes, customer support actions, Uniform Domain-Name Di= spute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, c= ourt directed actions, and bulk updates based on customer requests. Sinc= e the client is not directly involved or knowledgable of these operations, = the extension is used along with an EPP object mapping to provide the resul= ting state of the post-operation object, and optionally a pre-operation obj= ect, with the operation meta-data of what, when, who, and why. We would li= ke this draft to be included in a re-charting of the EPPEXT Working Group. Please review the draft and provide any feedback. Thanks, =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com =93This message (including any attachments) is intended only for the use of= the individual or entity to which it is addressed, and may contain informa= tion that is non-public, proprietary, privileged, confidential and exempt f= rom disclosure under applicable law or may be constituted as attorney work = product. If you are not the intended recipient, you are hereby notified tha= t any use, dissemination, distribution, or copying of this communication is= strictly prohibited. If you have received this message in error, notify se= nder immediately and delete this message immediately.=94 _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg _______________________________________________ EppExt mailing list EppExt@ietf.org https://www.ietf.org/mailman/listinfo/eppext --_000_77F1013CBF4149829845C1F87F69B5F5verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <011819F725D84F4DBB3EDA20E3461D85@verisign.com> Content-Transfer-Encoding: quoted-printable Ulrich,

Thank you for the review of the draft.  My feedback is embedded b= elow.  

I received private feedback to add an optional caseId element to help = capture the UDRP, URS, or other case identifier for the change.  The o= ptional caseId element was added with an enumerated =93type=94 attribute, w= ith the enumerated values of =93udrp=94, =93urs=94, and =93custom=94, and with an optional =93name=94 attribute for the =93cus= tom=94 type.  Are there any additional case types that should be inclu= ded in the enumerated list?  You can see the latest updates of the dra= ft using the GitHub project https://github.com/james-f-gould/EPP-Change-Poll.git= .  

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 4:08 AM, Ulrich Wisser <ulrich@wisser.se> wrote:

Hi James and Trung!

You two did a nice job on the extension.  

I  would prefer the transform command instead of the info respons= e. That would eliminate the need for before/after indicator.

You mean you want to see the full input transform command in the poll = message?  Most of the server-side operations don=92t go through EPP, s= o it would be a challenge to attempt to present the input prior to executin= g the operation using an EPP transform command.  Another issue with using a transform command is representin= g the server-side logic that is not reflected in the input parameters like = the setting of the expiration date.  The client can see the end result= of the operation without having to replicate the transform operation logic, along with the meta-data about the operatio= n using the info response.  

One question for the list is the value in making the before image of t= he object available?  The after image is required, but the thought is = that the before image may be desired.


I have some problems with the operators

- Why is autoRenew a special operation instead of operation renew with= op=3D"auto=94?

I agree that both are associated with renewing the domain; although I = view them as separate first class operations with different characteristics= (What drives the operation, how does the operation function, and what is t= he applicable grace period for the operation).   


- What is the difference between delete and delete op=3D"purge=94= ? 

Good question.  Purge is associated with physically removing the = object from the database where the delete could start an RGP lifecycle flow= .  An immediate delete (e.g. delete within the add grace period) is re= flected by a =93delete=94 with the op=3D=93purge=94; otherwise it would be just =93delete=94.  

- Why autoPurge / autoDelete?

Another good question.  What if for some registries the domain is= deleted instead of auto renewed at expiry?  That would match the use = of the =93autoDelete=94 operation.  Now, the =93autoDelete=94 could in= clude the purging of the object which would be reflected by setting op=3D=93purge=94.  The autoPurge operation is the server b= atch that physically purges the object (domain) at the end of the pendingDe= lete period.  In this case the domain has been deleted, put through th= e RGP lifecycle flow, and is being purged from the database.  We wanted to handle both types of registries (auto renew a= nd auto delete) as well as be able to identify the event when the object is= purged from the database.  I hope this makes sense.


Kind regards from Stockholm

Ulrich



2015-01-20 14:49 GMT+01:00 Gould, James <JGould@verisig= n.com>:
The first draft of the Change Poll EPP Extension ( http:= //tools.ietf.org/html/draft-gould-change-poll-00 ) has been submitted t= o the IETF.  I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify client= s of any server-side change, including but not limited to regular batch pro= cesses, customer support actions, Uniform Domain-Name Dispute-Resolution Po= licy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer = requests.    Since the client is not directly involved or knowled= gable of these operations, the extension is used along with an EPP object m= apping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the ope= ration meta-data of what, when, who, and why.  We would like this draf= t to be included in a re-charting of the EPPEXT Working Group.  

Please review the draft and provide any feedback.

Thanks,

=97

JG


<BF09FAA4-32D8-46E0-BED= 0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
jgould@Verisign.c= om

7= 03-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com

=93This message (including any attachments) is int= ended only for the use of the individual or entity to which it is addressed= , and may contain information that is non-public, proprietary, privileged, = confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.=94

_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg


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

--_000_77F1013CBF4149829845C1F87F69B5F5verisigncom_-- --_004_77F1013CBF4149829845C1F87F69B5F5verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 13:53:26 GMT"; modification-date="Fri, 30 Jan 2015 13:53:26 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_77F1013CBF4149829845C1F87F69B5F5verisigncom_-- From nobody Fri Jan 30 06:20:15 2015 Return-Path: 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 A5ACA1A9039 for ; Fri, 30 Jan 2015 06:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ymo-5t_9pAQQ for ; Fri, 30 Jan 2015 06:20:09 -0800 (PST) Received: from chip2og113.obsmtp.com (chip2og113.obsmtp.com [64.18.13.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C001A03AA for ; Fri, 30 Jan 2015 06:20:03 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by chip2ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKVMuTE9PMkpqUdM4BTaI3rbkg6iKgNGQ/@postini.com; Fri, 30 Jan 2015 06:20:08 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UEK2sv010798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 09:20:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 09:20:01 -0500 From: "Hollenbeck, Scott" To: Rik Ribbers , "'Maarten Bosteels'" , Miek Gieben , "Gould, James" , "eppext@ietf.org" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AQHQM8z5sCIQ9FoyhUSL8kWeEFCWPZzHobEAgAFZMYCAD8llcA== Date: Fri, 30 Jan 2015 14:20:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 14:20:12 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFcHBFeHQgW21haWx0bzplcHBl eHQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpayBSaWJiZXJzDQo+IFNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMjAsIDIwMTUgMzowMiBBTQ0KPiBUbzogJ01hYXJ0ZW4gQm9zdGVlbHMn OyBNaWVrIEdpZWJlbjsgR291bGQsIEphbWVzOyBlcHBleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtlcHBleHRdIE5ldyBkcmFmdCBmb3Iga2V5cmVsYXkgYXZhaWxhYmxlDQo+IA0KPiBIZWxs byBNYWFydGVuLA0KPiANCj4gVGh4IGZvciB0aGUgZmVlZGJhY2ssIEkgaG9wZSBtb3JlIHBlb3Bs ZSB3aXRoIGV4cGVyaWVuY2Ugb24gZXh0ZW5kaW5nDQo+IEVQUCB3aWxsIHN0YXRlIHRoZWlyIG9w aW5pb24gb24gdGhlIGxpc3QuDQo+IA0KPiBXZSBoYXZlIGltcGxlbWVudGVkIHRoZSBmdW5jdGlv bmFsaXR5IGluIG91ciByZWdpc3RyYXRpb24gc3lzdGVtLCBidXQNCj4gaXQgaXMgbm90IHZlcnkg YWN0aXZlbHkgdXNlZC4gV2hhdCB3ZSBzZWUgaXMgdGhhdCBtb3N0IHJlZ2lzdHJhcnMgZ28NCj4g aW5zZWN1cmUuIE1vc3Qgb2YgdGhlIHRpbWUgd2Ugc2VlIGEgdHJhbnNmZXIgY29tbWFuZCBmb2xs b3dlZCAoc29tZQ0KPiB0aW1lIGxhdGVyIGluIHRpbWUpIGJ5IGEgZG9tYWluIHVwZGF0ZSB0byBy ZW1vdmUgdGhlIG9sZCBrZXkgbWF0ZXJpYWwNCj4gYW5kIGFkZCBuZXcga2V5IG1hdGVyaWFsLiBU aGVyZSBpcyBldmVuIGEgbG9zaW5nIHJlZ2lzdHJhciB0aGF0IHJlbW92ZXMNCj4gYWxsIEROUyBr ZXkgZGF0YSB3aGVuIGEgcmVnaXN0cmFudCByZXF1ZXN0cyBpdHMgYXV0aG9yaXphdGlvbiB0b2tl bg0KPiBiZWZvcmUgdGhlIGFjdHVhbCB0cmFuc2Zlci4NCg0KT25lIG1vcmUgb3BpbmlvbjoNCg0K QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSBkcmFmdCBhZ2FpbiBJIGJlbGlldmUgSSB3b3VsZCBo YXZlIGRlc2lnbmVkIHRoaXMgZGlmZmVyZW50bHkuIEVQUCBjb21tYW5kcyB0eXBpY2FsbHkgYWN0 IG9uIG9yIHJlYWQgZGF0YSBmcm9tIG9iamVjdHMsIGFuZCBpZiBJJ20gcmVhZGluZyBrZXlyZWxh eSBjb3JyZWN0bHkgdGhlIDxyZWxheT4gY29tbWFuZCBpc24ndCBkb2luZyBlaXRoZXIgb2YgdGhv c2UgdGhpbmdzLiBJdCdzIHB1c2hpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHNlcnZlciB0byBiZSBz dG9yZWQgdGVtcG9yYXJpbHkgKGluIHdoYXQ/KSBzbyB0aGF0IGl0IGNhbiBiZSByZXRyaWV2ZWQg d2l0aCBhIDxwb2xsPiBjb21tYW5kLiBJdCB3b3VsZCBiZSBtb3JlIGFyY2hpdGVjdHVyYWxseSBj b25zaXN0ZW50IHRvIGNyZWF0ZSBhIHRlbXBvcmFyeSByZWxheSBvYmplY3Qgd2l0aCB0aGUgbmVl ZGVkIGluZm9ybWF0aW9uIGFuZCB1c2UgYW4gPGluZm8+IGNvbW1hbmQgdG8gcmV0cmlldmUgdGhl IGRhdGEuIDxwb2xsPiBjYW4gYmUgdXNlZCB0byBub3RpZnkgdGhlIHJlY2VpdmluZyBjbGllbnQg dGhhdCB0aGUgaW5mb3JtYXRpb24gaXMgdGhlcmUgdG8gYmUgcmV0cmlldmVkLiBBbnl3YXksIHRo YXQncyBteSB0d28gY2VudHMuDQoNClJpaydzICJub3QgdmVyeSBhY3RpdmVseSB1c2VkIiBjb21t ZW50IGlzIHRlbGxpbmcuIEROU1NFQyBpc24ndCB3aWRlbHkgc3VwcG9ydGVkIGJ5IHJlZ2lzdHJh cnMsIHNvIGl0IG1ha2VzIHNlbnNlIHRoYXQgd2UncmUgbm90IHNlZWluZyBhIGxvdCBvZiB1c2Uu IEkgZG9uJ3QgaGF2ZSBhbiBpc3N1ZSB3aXRoIGNvbnRpbnVpbmcgd29yayBvbiB0aGlzIGRyYWZ0 IGlmIHRoZSBpbnRlbnRpb24gaXMgdG8gZG9jdW1lbnQgdGhlIGV4aXN0aW5nIHByYWN0aWNlIG9m IG9uZSBvcGVyYXRvciBpbiBhbiBpbmZvcm1hdGlvbmFsIHdheSwgYnV0IEknbSBub3QgY29tZm9y dGFibGUgd2l0aCBwdXJzdWluZyB0aGUgY3VycmVudCBhcHByb2FjaCBvbiB0aGUgc3RhbmRhcmRz IHRyYWNrLiBXZSBzaG91bGQgY29uZmlybSB0aGUgbmVlZCBiZWZvcmUgZG9pbmcgc3RhbmRhcmRz IHRyYWNrIHdvcmsuDQoNClNjb3R0DQo= From nobody Fri Jan 30 06:57:38 2015 Return-Path: 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 83A9B1A0470 for ; Fri, 30 Jan 2015 06:57:36 -0800 (PST) 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, 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 XVBiDzUwGj7h for ; Fri, 30 Jan 2015 06:57:34 -0800 (PST) Received: from chip2og123.obsmtp.com (chip2og123.obsmtp.com [64.18.13.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51121A0072 for ; Fri, 30 Jan 2015 06:57:29 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob123.postini.com ([64.18.5.12]) with SMTP ID DSNKVMub2f2OOYE62jQ3ROzSnI1eDst/1HQT@postini.com; Fri, 30 Jan 2015 06:57:33 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UEvSHO004338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 09:57:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 09:57:27 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwA= Date: Fri, 30 Jan 2015 14:57:27 +0000 Message-ID: <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_46F2F7EA7FD44D47B80DCCC795277512verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 14:57:36 -0000 --_004_46F2F7EA7FD44D47B80DCCC795277512verisigncom_ Content-Type: multipart/alternative; boundary="_000_46F2F7EA7FD44D47B80DCCC795277512verisigncom_" --_000_46F2F7EA7FD44D47B80DCCC795277512verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 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 On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_46F2F7EA7FD44D47B80DCCC795277512verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4D0C82392725DC47918BF9CD0BFFCA00@verisign.com> Content-Transfer-Encoding: quoted-printable Scott,

I believe the intent is to insert the transient object into the poll q= ueue for the target client.  The acknowledgement of the poll message s= hould result in the implicit removal of the transient object from the serve= r.  With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

-----Original Message-----
From: EppExt [mailto:eppext-boun= ces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_46F2F7EA7FD44D47B80DCCC795277512verisigncom_-- --_004_46F2F7EA7FD44D47B80DCCC795277512verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 14:57:26 GMT"; modification-date="Fri, 30 Jan 2015 14:57:26 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_46F2F7EA7FD44D47B80DCCC795277512verisigncom_-- From nobody Fri Jan 30 07:08:55 2015 Return-Path: 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 191C41A9045 for ; Fri, 30 Jan 2015 07:08:50 -0800 (PST) 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, 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 CWOdwvqPoa6Y for ; Fri, 30 Jan 2015 07:08:37 -0800 (PST) Received: from chip2og113.obsmtp.com (chip2og113.obsmtp.com [64.18.13.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FF41A03AA for ; Fri, 30 Jan 2015 07:08:33 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKVMuecCIq+TeX5ackV+qiaKcZ8D3eRvOg@postini.com; Fri, 30 Jan 2015 07:08:36 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UF8WSg005645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 10:08:32 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 10:08:31 -0500 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AQHQM8z5sCIQ9FoyhUSL8kWeEFCWPZzHobEAgAFZMYCAD8llcIAAYhCA//+sxpA= Date: Fri, 30 Jan 2015 15:08:30 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> In-Reply-To: <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> 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_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 15:08:51 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG [cid:image001.png@01D03C73.E02B15D0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



-----Original Message-----
From: EppExt [mailto:eppext-boun= ces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 15:08:30 GMT"; modification-date="Fri, 30 Jan 2015 15:08:30 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F3353EBRN1WNEXMBX01vc_-- From nobody Fri Jan 30 07:32:30 2015 Return-Path: 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 549541A90BF for ; Fri, 30 Jan 2015 07:32:19 -0800 (PST) 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, 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 aQH0Xwp-yDC5 for ; Fri, 30 Jan 2015 07:32:16 -0800 (PST) Received: from chip2og108.obsmtp.com (chip2og108.obsmtp.com [64.18.13.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF48C1A1A3D for ; Fri, 30 Jan 2015 07:32:11 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKVMuj+wiL+QeqjBcE1mcGc+4r7lWmWyOC@postini.com; Fri, 30 Jan 2015 07:32:15 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UFWAls008374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 10:32:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 10:32:09 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OA Date: Fri, 30 Jan 2015 15:32:08 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_ABCBA9303045438CA526B6B824390048verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 15:32:19 -0000 --_004_ABCBA9303045438CA526B6B824390048verisigncom_ Content-Type: multipart/alternative; boundary="_000_ABCBA9303045438CA526B6B824390048verisigncom_" --_000_ABCBA9303045438CA526B6B824390048verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. =97 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 On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_ABCBA9303045438CA526B6B824390048verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Scott,

EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects.   Objects can be created on the server-side without any s= upport for transform by the client.  In this case, the intent is to create a poll queue message object that is con= sumed and automatically deleted when consumed, so the create functions as a= n enqueue and the poll info response functions as a dequeue once acknowledg= ed.  With this, the transient object only needs to support the create transform to insert the message in the po= ll queue and the poll message in the form of an info response to consume th= e message.  There is no need for the implementation to create any form= of a transient object outside the poll queue, since the poll queue is the transient object store for this object = type. 
 

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

= EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc.
=  
= I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which wou= ld be slightly longer-lived, but would be automatically deleted when it exp= ired).
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com=
 
On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <sh= ollenbeck@verisign.com> wrote:


-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On B= ehalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_ABCBA9303045438CA526B6B824390048verisigncom_-- --_004_ABCBA9303045438CA526B6B824390048verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 15:32:08 GMT"; modification-date="Fri, 30 Jan 2015 15:32:08 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_ABCBA9303045438CA526B6B824390048verisigncom_-- From nobody Fri Jan 30 07:35:15 2015 Return-Path: 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 982601A90B3 for ; Fri, 30 Jan 2015 07:35:14 -0800 (PST) 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, 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 74bHFXP0YE2K for ; Fri, 30 Jan 2015 07:35:11 -0800 (PST) Received: from chip2og103.obsmtp.com (chip2og103.obsmtp.com [64.18.13.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8FB1A1A3D for ; Fri, 30 Jan 2015 07:35:06 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by chip2ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKVMukqd/gbdkdiEYuBN8zOl17wF8rAiIe@postini.com; Fri, 30 Jan 2015 07:35:10 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UFZ5qS019783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 10:35:05 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 10:35:04 -0500 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AQHQM8z5sCIQ9FoyhUSL8kWeEFCWPZzHobEAgAFZMYCAD8llcIAAYhCA//+sxpCAAFzrAP//rMyQ Date: Fri, 30 Jan 2015 15:35:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: 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_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 15:35:14 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03C78.67C57400] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= shollenbeck@verisign.com>= ; wrote:



EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:




-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 15:35:03 GMT"; modification-date="Fri, 30 Jan 2015 15:35:03 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F338CEBRN1WNEXMBX01vc_-- From nobody Fri Jan 30 08:40:09 2015 Return-Path: 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 1F7BB1A1B47 for ; Fri, 30 Jan 2015 08:39:55 -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 X6zuqz9e3wzV for ; Fri, 30 Jan 2015 08:39:49 -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 677BE1A1AF0 for ; Fri, 30 Jan 2015 08:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:cc: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=6X6GP+cVPHvBvDTtP+f5GVsdniaolvdjVoQD5gf9xi4=; b=jNNENVRj5L5z7NcSJcjQIMPu/KGGI1VnrJYtlppnXPzxDbUr5RvW61uuAbMRn0hRk/pwZYLjMNb73nWrMZEeuhOVv3zkzydk/xEwwWhQAWFA9KXQzEdqTa8wPP4QAG7s0HR4MImO7mIL1rvaS8TMcsUy5X/5gEdWooRTHtip58k= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0UGdjIp009141-t0UGdjIr009141 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Fri, 30 Jan 2015 17:39:45 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 17:39:40 +0100 From: Rik Ribbers To: "'Hollenbeck, Scott'" , "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwA== Date: Fri, 30 Jan 2015 16:39:40 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 16:39:55 -0000 --_004_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: =D8 I don't have an issue with continuing work on this draft if the intent= ion is to document the existing practice of one operator in an informationa= l way, but I'm not comfortable with pursuing the current approach on the st= andards track. We should confirm the need before doing standards track work= . Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03CAD.0DFD7EB0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Scott,<= /p>

 <= /p>

The intent= ion of the relay command is more of sending a message (with information) th= en the manipulation of objects, but James explained it pretty well.

 = ;

The  = thing that triggered me is the second part of your reply:=

 

=D8  I don't have an issue w= ith continuing work on this draft if the intention is to document the exist= ing practice of one operator in an informational way, but I'm not comfortab= le with pursuing the current approach on the standards track. We should confirm the need before doing standards = track work.

 

Although I= ’m not an IETF expert I assumed that when the document was adapted by= the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be i= nformational or standards track. And as far I understood it is not up to th= e WG to make a document informational, that is something the IESG does. Fee= l free to correct me if I misunderstood things.

 = ;

However th= e real question is: Who can confirm this need?

 = ;

We see the= need for an automated secure transfer of domainnames in our daily operatio= n. As the adoption of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We ch= oose the solution which is described in the draft and believe it is a good = pragmatic solution for a the problem. But  I agree that the need is no= t extremely high at this point, but it will be in the near future. Should we wait for that or act upon what we be= lieve is inevitable?  We choose not to wait.  <= /p>

 = ;

Kind regar= ds,

Rik

 = ;

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Jim, that’s not how I= would have designed it. To each his own.

 

Scott

 

From: Gould, James
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support = new types of objects, and objects can support a different set of commands a= nd responses based on the requirements of those objects.   Objects can= be created on the server-side without any support for transform by the client.  In this case, the intent is to = create a poll queue message object that is consumed and automatically delet= ed when consumed, so the create functions as an enqueue and the poll info r= esponse functions as a dequeue once acknowledged.  With this, the transient object only needs to support the create tra= nsform to insert the message in the poll queue and the poll message in the = form of an info response to consume the message.  There is no need for= the implementation to create any form of a transient object outside the poll queue, since the poll queue is the tra= nsient object store for this object type. 

 

—=

 

JG




James Gould
Distinguished Engine= er
jgould@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, H= ollenbeck, Scott <shollenbec= k@verisign.com> wrote:

=  

EPP has no concept of ̶= 0;objects” in the poll queue. The poll queue manipulates messages. Ob= jects are manipulated by transform commands like create, delete, etc.

 

I was thinking that the sou= rce client would create a relay object, which would result in a message bei= ng queued for the target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and = in the object (which would be slightly longer-lived, but would be automatic= ally deleted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available=

 

Scott,

 

I believe the intent is to inse= rt the transient object into the poll queue for the target client.  Th= e acknowledgement of the poll message should result in the implicit removal= of the transient object from the server.  With what you’re proposing, the source client would create the= transient object that I’m assuming would result in a poll notificati= on containing a signal to the client to submit an info command to get the t= ransient object information?  I’m assuming that the target client would then need to delete the transient object once theyR= 17;re done with processing the message.  I believe it’s simpler = and consistent with the concept of creating a transient poll message to sup= port the create to create the poll message and the info response poll message for the consumption of the transient object. &n= bsp;In this case the poll queue is functioning as the repository for the tr= ansient object with the signal and data being one and the same, and the del= etion of the transient object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engine= er
jgo= uld@Verisign.com

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

VerisignInc.com<= span lang=3D"EN-US">

 

On Jan 30, 2015, at 9:20 AM, Ho= llenbeck, Scott <shollenbeck@verisign.com> wrote:=

=

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 15:51:55 GMT"; modification-date="Fri, 30 Jan 2015 15:51:55 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B928BC13kambx2SIDNlocal_-- From nobody Fri Jan 30 09:02:57 2015 Return-Path: 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 903291A6F14 for ; Fri, 30 Jan 2015 09:02:53 -0800 (PST) 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, 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 09a2Vd-UWhix for ; Fri, 30 Jan 2015 09:02:49 -0800 (PST) Received: from chip2og110.obsmtp.com (chip2og110.obsmtp.com [64.18.13.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665AB1A1B3D for ; Fri, 30 Jan 2015 09:02:43 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVMu5MkTsC7OplmivhrXLepFVWKbDHoew@postini.com; Fri, 30 Jan 2015 09:02:47 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UH2fHL018941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 12:02:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 12:02:40 -0500 From: "Gould, James" To: Rik Ribbers Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAAzVcA Date: Fri, 30 Jan 2015 17:02:40 +0000 Message-ID: <7B0134D9-3D21-4FD0-BC08-5CE63F49E622@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: 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_7B0134D93D214FD0BC085CE63F49E622verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Miek Gieben , "Hollenbeck, Scott" , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 17:02:53 -0000 --_004_7B0134D93D214FD0BC085CE63F49E622verisigncom_ Content-Type: multipart/alternative; boundary="_000_7B0134D93D214FD0BC085CE63F49E622verisigncom_" --_000_7B0134D93D214FD0BC085CE63F49E622verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rik, We have not implemented the extension, but as you point out if the adoption= for DNSSEC grows then so will the need for such an extension. I support t= he idea of creating a standards track extension for this purpose; although = we need to ensure that there is community consensus and there is more than = one implementation of it. There has been some good dialog on the list late= ly, so hopefully it will continue or even better yet pick up. =97 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 On Jan 30, 2015, at 11:39 AM, Rik Ribbers > wrote: Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I=92m not an IETF expert I assumed that when the document was adap= ted by the WG the WG acknowledges the need for a standard. In Honolulu ther= e was a discussion if the documents from the working group should be inform= ational or standards track. And as far I understood it is not up to the WG = to make a document informational, that is something the IESG does. Feel fre= e to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that=92s not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_7B0134D93D214FD0BC085CE63F49E622verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <49FD139DAC1EB04DB3BCFDD7DCE54B40@verisign.com> Content-Transfer-Encoding: quoted-printable Rik,

We have not implemented the extension, but as you point out if the ado= ption for DNSSEC grows then so will the need for such an extension.  I= support the idea of creating a standards track extension for this purpose;= although we need to ensure that there is community consensus and there is more than one implementation of it. &n= bsp;There has been some good dialog on the list lately, so hopefully it wil= l continue or even better yet pick up.  

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 11:39 AM, Rik Ribbers <rik.ribbers@sidn.nl> wrote:

Scott,
 
The intention of the relay command is more = of sending a message (with information) then the manipulation of objects, b= ut James explained it pretty well.
 
The  thing that triggered me is the se= cond part of your reply:
 
=D8  I don't have an issue with continuing work on this draft if the intention is= to document the existing practice of one operator in an informational way,= but I'm not comfortable with pursuing the current approach on the standard= s track. We should confirm the need before doing standards track work.
 
Although I=92m not an IETF expert I assumed= that when the document was adapted by the WG the WG acknowledges the need = for a standard. In Honolulu there was a discussion if the documents from the working group should be information= al or standards track. And as far I understood it is not up to the WG to ma= ke a document informational, that is something the IESG does. Feel free to = correct me if I misunderstood things.
 
However the real question is: Who can confi= rm this need?
 
We see the need for an automated secure tra= nsfer of domainnames in our daily operation. As the adoption of validating = DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  
 
Kind regards,
Rik
 
From: = Hollenbeck, Scott [mailto:shollenbeck@verisign= .com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available
 
Jim, that=92s not how I would have designed it. To each his = own.
 
Scott
 
From: = Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
EPP can be extended to support new types of objects, a= nd objects can support a different set of commands and responses based on t= he requirements of those objects.   Objects can be created on the serv= er-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com<= /span>
 
On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

 

EPP has no concept of =93objects=94 in the poll queue. The p= oll queue manipulates messages. Objects are manipulated by transform comman= ds like create, delete, etc.<= /div>
 
I was thinking that the source client would create a relay o= bject, which would result in a message being queued for the target client. = The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).
 
Scott
 
From:&nbs= p;Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available=
 
Scott,
 
I believe the intent is to insert the transient object= into the poll queue for the target client.  The acknowledgement of th= e poll message should result in the implicit removal of the transient objec= t from the server.  With what you=92re proposing, the source client would create the transient object that I=92m assuming wo= uld result in a poll notification containing a signal to the client to subm= it an info command to get the transient object information?  I=92m ass= uming that the target client would then need to delete the transient object once they=92re done with processing the mes= sage.  I believe it=92s simpler and consistent with the concept of cre= ating a transient poll message to support the create to create the poll mes= sage and the info response poll message for the consumption of the transient object.  In this case the poll queue= is functioning as the repository for the transient object with the signal = and data being one and the same, and the deletion of the transient object h= andled via the standard poll queue mechanism.     
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com
 
On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com<= /span>> wrote:



-----Original Message-----
From: EppExt [mailto:ep= pext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppex= t@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_7B0134D93D214FD0BC085CE63F49E622verisigncom_-- --_004_7B0134D93D214FD0BC085CE63F49E622verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 17:02:40 GMT"; modification-date="Fri, 30 Jan 2015 17:02:40 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_7B0134D93D214FD0BC085CE63F49E622verisigncom_-- From nobody Fri Jan 30 09:27:25 2015 Return-Path: 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 9260C1A9125 for ; Fri, 30 Jan 2015 09:27:20 -0800 (PST) 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, 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 mIsnBNhFzJTM for ; Fri, 30 Jan 2015 09:27:14 -0800 (PST) Received: from chip2og117.obsmtp.com (chip2og117.obsmtp.com [64.18.13.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D2B1A9120 for ; Fri, 30 Jan 2015 09:27:09 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKVMu+7MUxeNwO8PuKnL6eVdNIrYOZlTYS@postini.com; Fri, 30 Jan 2015 09:27:13 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UHR8M3021744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 12:27:08 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 12:27:07 -0500 From: "Hollenbeck, Scott" To: Rik Ribbers , "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwAADPyWA Date: Fri, 30 Jan 2015 17:27:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F33B36@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: 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_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 17:27:21 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > when the document was adapted by the WG the WG acknowledges the need for = a standard No, it means the IETF and the WG decided to work on the document to meet th= e purpose stated in the WG charter. That purpose and the charter can change= if time reveals the need for change. We can propose anything to the IESG f= or consideration if it makes sense to do so, especially if it becomes clear= that we do not have consensus on a particular topic. You said "adapted" - did you mean adopted? "Adapted" would imply "change", = but you've indicated a preference to not change the basic approach. Without= consensus on the approach it's going to be tough to produce a Proposed Sta= ndard. Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: =D8 I don't have an issue with continuing work on this draft if the intent= ion is to document the existing practice of one operator in an informationa= l way, but I'm not comfortable with pursuing the current approach on the st= andards track. We should confirm the need before doing standards track work= . Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03C87.FE10CDB0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> when the document was adapted by the = WG the WG acknowledges the need for a standard

 

No, it means the IETF and the WG decided t= o work on the document to meet the purpose stated in the WG charter. That p= urpose and the charter can change if time reveals the need for change. We can propose anything to the IESG for consideration if it ma= kes sense to do so, especially if it becomes clear that we do not have cons= ensus on a particular topic.

 

You said “adapted” – did= you mean adopted? “Adapted” would imply “change”, = but you’ve indicated a preference to not change the basic approach. W= ithout consensus on the approach it’s going to be tough to produce a Proposed Standard.

 

Scott<= o:p>

 

From: Rik Ribb= ers [mailto:rik.ribbers@sidn.nl]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Scott,

 

The intention of the rela= y command is more of sending a message (with information) then the manipula= tion of objects, but James explained it pretty well.

 <= /p>

The  thing that trig= gered me is the second part of your reply:

 

=D8  I don't have an issue with continuing work o= n this draft if the intention is to document the existing practice of one o= perator in an informational way, but I'm not comfortable with pursuing the = current approach on the standards track. We should confirm the need before doing standards track work.<= /o:p>

 

Although I’m not an= IETF expert I assumed that when the document was adapted by the WG the WG = acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational= or standards track. And as far I understood it is not up to the WG to make= a document informational, that is something the IESG does. Feel free to co= rrect me if I misunderstood things.

 <= /p>

However the real question= is: Who can confirm this need?

 <= /p>

We see the need for an au= tomated secure transfer of domainnames in our daily operation. As the adopt= ion of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  

 <= /p>

Kind regards,<= /span>

Rik

 <= /p>

From: Hollenbe= ck, Scott [mailto:shollenbeck@v= erisign.com]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= shollenbeck@verisign.com>= ; wrote:

 

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:

 

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 17:27:07 GMT"; modification-date="Fri, 30 Jan 2015 17:27:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F33B36BRN1WNEXMBX01vc_-- From nobody Fri Jan 30 10:39:48 2015 Return-Path: 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 E0F581A0370 for ; Fri, 30 Jan 2015 10:39:44 -0800 (PST) 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, 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 AR4W9FHvL3nG for ; Fri, 30 Jan 2015 10:39:39 -0800 (PST) Received: from chip2og111.obsmtp.com (chip2og111.obsmtp.com [64.18.13.71]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99C81A00B9 for ; Fri, 30 Jan 2015 10:39:29 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by chip2ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvP4ZihIDHONTSAO53OFSqStUGotMF2@postini.com; Fri, 30 Jan 2015 10:39:33 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UIdSBH030014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 13:39:28 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 13:39:27 -0500 From: "Hollenbeck, Scott" To: Rik Ribbers , "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwAAF92cA Date: Fri, 30 Jan 2015 18:39:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: 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_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 18:39:45 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: =D8 I don't have an issue with continuing work on this draft if the intent= ion is to document the existing practice of one operator in an informationa= l way, but I'm not comfortable with pursuing the current approach on the st= andards track. We should confirm the need before doing standards track work= . Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03C92.2A19A580] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> The intention of the relay command is= more of sending a message (with information) then the manipulation of obje= cts, but James explained it pretty well.

 

I just thought of something else while re-= reading this sentence. What happens if the exact same command is sent twice= ? Is a second message sent?

 

Scott<= o:p>

 

From: Rik Ribb= ers [mailto:rik.ribbers@sidn.nl]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Scott,

 

The intention of the rela= y command is more of sending a message (with information) then the manipula= tion of objects, but James explained it pretty well.

 <= /p>

The  thing that trig= gered me is the second part of your reply:

 

=D8  I don't have an issue with continuing work o= n this draft if the intention is to document the existing practice of one o= perator in an informational way, but I'm not comfortable with pursuing the = current approach on the standards track. We should confirm the need before doing standards track work.<= /o:p>

 

Although I’m not an= IETF expert I assumed that when the document was adapted by the WG the WG = acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational= or standards track. And as far I understood it is not up to the WG to make= a document informational, that is something the IESG does. Feel free to co= rrect me if I misunderstood things.

 <= /p>

However the real question= is: Who can confirm this need?

 <= /p>

We see the need for an au= tomated secure transfer of domainnames in our daily operation. As the adopt= ion of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  

 <= /p>

Kind regards,<= /span>

Rik

 <= /p>

From: Hollenbe= ck, Scott [mailto:shollenbeck@v= erisign.com]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= shollenbeck@verisign.com>= ; wrote:

 

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:

 

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 18:39:26 GMT"; modification-date="Fri, 30 Jan 2015 18:39:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F33CD7BRN1WNEXMBX01vc_-- From nobody Fri Jan 30 10:49:52 2015 Return-Path: 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 D841E1A001A for ; Fri, 30 Jan 2015 10:49:45 -0800 (PST) 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, 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 kqk7rCT7Lw9q for ; Fri, 30 Jan 2015 10:49:40 -0800 (PST) Received: from chip2og113.obsmtp.com (chip2og113.obsmtp.com [64.18.13.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BD61A039D for ; Fri, 30 Jan 2015 10:49:32 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by chip2ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvSO2/VtLmMw+uK58wFDssBnnZJYc3M@postini.com; Fri, 30 Jan 2015 10:49:35 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UInV0h010203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 13:49:31 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 13:49:30 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQA= Date: Fri, 30 Jan 2015 18:49:30 +0000 Message-ID: <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_9DA4482AEF0F4D66A9419472F16403E3verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 18:49:46 -0000 --_004_9DA4482AEF0F4D66A9419472F16403E3verisigncom_ Content-Type: multipart/alternative; boundary="_000_9DA4482AEF0F4D66A9419472F16403E3verisigncom_" --_000_9DA4482AEF0F4D66A9419472F16403E3verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. =97 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 On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I=92m not an IETF expert I assumed that when the document was adap= ted by the WG the WG acknowledges the need for a standard. In Honolulu ther= e was a discussion if the documents from the working group should be inform= ational or standards track. And as far I understood it is not up to the WG = to make a document informational, that is something the IESG does. Feel fre= e to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that=92s not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_9DA4482AEF0F4D66A9419472F16403E3verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <652A8668A36D444C8C5B377F0EF62AA9@verisign.com> Content-Transfer-Encoding: quoted-printable Yes, each create would result in a new message to get created and enqueued.=  Since the create is for a transient message object, there is no issu= e with creating more then one message with the same data.   

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

> The intention of the relay command is more of sending a message (with= information) then the manipulation of objects, but James explained it pret= ty well.
 
I just thought of something else while re-reading this sentence. What happ= ens if the exact same command is sent twice? Is a second message sent?=
 
Scott
 
From:<= /span> Rik Ribbers [mailto:rik.ribbers@sidn.nl] 
Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available
 
Scott,
 
The intention of the relay command is more of sending a me= ssage (with information) then the manipulation of objects, but James explai= ned it pretty well.
 
The  thing that triggered me is the second part of yo= ur reply:
 
=D8  I don't have an issue with continuing work on this draft if the intention is= to document the existing practice of one operator in an informational way,= but I'm not comfortable with pursuing the current approach on the standard= s track. We should confirm the need before doing standards track work.
 
Although I=92m not an IETF expert I assumed that when the = document was adapted by the WG the WG acknowledges the need for a standard.= In Honolulu there was a discussion if the documents from the working group should be informational or standar= ds track. And as far I understood it is not up to the WG to make a document= informational, that is something the IESG does. Feel free to correct me if= I misunderstood things.
 
However the real question is: Who can confirm this need?
 
We see the need for an automated secure transfer of domain= names in our daily operation. As the adoption of validating DNSSEC resolver= grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solution which = is described in the draft and believe it is a good pragmatic solution for a= the problem. But  I agree that the need is not extremely high at this= point, but it will be in the near future. Should we wait for that or act upon what we believe is inevitable?  W= e choose not to wait.  
 
Kind regards,
Rik
 
From:<= /span> Hollenbeck, Scott [mailto:shollenbeck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available
 
= Jim, that=92s not how I would have designed it. To each his own.=
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects.   Objects can be created on the server-side without any s= upport for transform by the client.  In this case, the intent is to create a poll queue message object that is con= sumed and automatically deleted when consumed, so the create functions as a= n enqueue and the poll info response functions as a dequeue once acknowledg= ed.  With this, the transient object only needs to support the create transform to insert the message in the po= ll queue and the poll message in the form of an info response to consume th= e message.  There is no need for the implementation to create any form= of a transient object outside the poll queue, since the poll queue is the transient object store for this object = type. 
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com=
 
On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <s= hollenbeck@verisign.com> wrote:

 

= EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc.
=  
= I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which wou= ld be slightly longer-lived, but would be automatically deleted when it exp= ired).
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:=

 

-----Original Message-----
From: EppExt [mailto:ep= pext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppex= t@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_9DA4482AEF0F4D66A9419472F16403E3verisigncom_-- --_004_9DA4482AEF0F4D66A9419472F16403E3verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 18:49:30 GMT"; modification-date="Fri, 30 Jan 2015 18:49:30 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_9DA4482AEF0F4D66A9419472F16403E3verisigncom_-- From nobody Fri Jan 30 11:08:12 2015 Return-Path: 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 A5DAF1A0368 for ; Fri, 30 Jan 2015 11:08:09 -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 q-afa4p4-6ZM for ; Fri, 30 Jan 2015 11:08:04 -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 7B3471A0358 for ; Fri, 30 Jan 2015 11:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:cc: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=0rjLPkEJ562FYdzVbnALEF8LuBg/ha6B2fxA+86/gkk=; b=e1Ptp0k/iW2ziVTYs7ZOTuIg+lSPzUUXlXN+wkaD7/EyaPgNBUqpRCtQM79XS01sFvpnqAYfBoNow5VQYnC8792iokmkog/DL9Wg8vP/LfAKl1yR7JkPdvjmMrjUQxzVof7f4dlbLkh+RmLK5MI61eKpIBvt9NOV7lMq/GdLhWY= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0UJ81JY014215-t0UJ81Ja014215 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Fri, 30 Jan 2015 20:08:01 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 20:07:58 +0100 From: Rik Ribbers To: "'Hollenbeck, Scott'" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwAADPyWAAAJDmZA= Date: Fri, 30 Jan 2015 19:07:58 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33B36@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33B36@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 19:08:09 -0000 --_004_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Scott, Thanks for the clarification and I did mean adopted. =D8 but you've indicated a preference to not change the basic approach. That is indeed our preference but as two people (Ulrich Wisser and Maarten = Bosteels) this week clearly stated that they think the proposal of James is= the way to go we might have to reconsider as standard track is also our pr= eference. But than again the majority of the working group members do not a= ctively participate in this discussion. So are 2 (Ok 3, as you are someone = in the EPP community ;-)) people enough to reconsider? I got no clue on how= big the WG actually is (anybody?), but I'm still hoping that more people = (especially the ones that hummed in Honolulu) state on the issue. If the ma= jority of the WG thinks we've done it wrong who are we not to reconsider th= ings and go for the proposal of James, the concept of relaying DNSSEC data = doesn't change only the XML will and in the end the concept is the most im= portant part. So again I call upon the members of this working group to review the draft = and see what the problem is (http://www.ietf.org/mail-archive/web/eppext/cu= rrent/msg00241.html) and state their opinion on this mailing list. Even if = you don't care or have no objection let it know then at least we know where= we are standing and can decide on how to proceed. Kind regards, Rik Ribbers From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 18:27 To: Rik Ribbers; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available > when the document was adapted by the WG the WG acknowledges the need for = a standard No, it means the IETF and the WG decided to work on the document to meet th= e purpose stated in the WG charter. That purpose and the charter can change= if time reveals the need for change. We can propose anything to the IESG f= or consideration if it makes sense to do so, especially if it becomes clear= that we do not have consensus on a particular topic. You said "adapted" - did you mean adopted? "Adapted" would imply "change", = but you've indicated a preference to not change the basic approach. Without= consensus on the approach it's going to be tough to produce a Proposed Sta= ndard. Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: =D8 I don't have an issue with continuing work on this draft if the intent= ion is to document the existing practice of one operator in an informationa= l way, but I'm not comfortable with pursuing the current approach on the st= andards track. We should confirm the need before doing standards track work= . Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03CC3.2FECED10] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Scott,<= /p>

 <= /p>

Thanks for= the clarification and I did mean adopted.

 = ;

=D8<= span style=3D"font:7.0pt "Times New Roman"">  but you’ve in= dicated a preference to not change the basic approach.

 = ;

That is in= deed our preference but as two people (Ulrich Wisser and Maarten Bosteels) = this week clearly stated that they think the proposal of James is the way to go we might have to reconsider as standard track is also our= preference. But than again the majority of the working group members do no= t actively participate in this discussion. So are 2 (Ok 3, as you are someo= ne in the EPP community ;-)) people enough to reconsider? I got no clue on how big the WG actually is (anybody= ?), but  I’m still hoping that more people (especially the ones = that hummed in Honolulu) state on the issue. If the majority of the WG thin= ks we’ve done it wrong who are we not to reconsider things and go for the proposal of James, the concept of relaying DNSSEC da= ta doesn’t change only the XML will  and in the end the concept = is the most important part.

 = ;

So again I= call upon the members of this working group to review the draft and see wh= at the problem is (http= ://www.ietf.org/mail-archive/web/eppext/current/msg00241.html) and state their opinion on this mailing list. Even if you don’t care= or have no objection let it know then at least we know where we are standi= ng and can decide on how to proceed.

 = ;

Kind regar= ds,

Rik Ribber= s

 = ;

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: vrijdag 30 januari 2015 18:27
To: Rik Ribbers; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

> when the document was = adapted by the WG the WG acknowledges the need for a standard

 

No, it means the IETF and t= he WG decided to work on the document to meet the purpose stated in the WG = charter. That purpose and the charter can change if time reveals the need for change. We can propose anything to the IESG for consideration= if it makes sense to do so, especially if it becomes clear that we do not = have consensus on a particular topic.

 

You said “adaptedR= 21; – did you mean adopted? “Adapted” would imply “= change”, but you’ve indicated a preference to not change the ba= sic approach. Without consensus on the approach it’s going to be tough to produce a Proposed Standar= d.

 

Scott

 

From: Rik Ribbers [m= ailto:rik.ribbers@sidn.nl]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Scott,<= /p>

 <= /p>

The intent= ion of the relay command is more of sending a message (with information) th= en the manipulation of objects, but James explained it pretty well.

 = ;

The  = thing that triggered me is the second part of your reply:=

 

=D8  I don't have an issue w= ith continuing work on this draft if the intention is to document the exist= ing practice of one operator in an informational way, but I'm not comfortab= le with pursuing the current approach on the standards track. We should confirm the need before doing standards = track work.

 

Although I= ’m not an IETF expert I assumed that when the document was adapted by= the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be i= nformational or standards track. And as far I understood it is not up to th= e WG to make a document informational, that is something the IESG does. Fee= l free to correct me if I misunderstood things.

 = ;

However th= e real question is: Who can confirm this need?

 = ;

We see the= need for an automated secure transfer of domainnames in our daily operatio= n. As the adoption of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We ch= oose the solution which is described in the draft and believe it is a good = pragmatic solution for a the problem. But  I agree that the need is no= t extremely high at this point, but it will be in the near future. Should we wait for that or act upon what we be= lieve is inevitable?  We choose not to wait.  <= /p>

 = ;

Kind regar= ds,

Rik

 = ;

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Jim, that’s not how I= would have designed it. To each his own.

 

Scott

 

From: Gould, James
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support = new types of objects, and objects can support a different set of commands a= nd responses based on the requirements of those objects.   Objects can= be created on the server-side without any support for transform by the client.  In this case, the intent is to = create a poll queue message object that is consumed and automatically delet= ed when consumed, so the create functions as an enqueue and the poll info r= esponse functions as a dequeue once acknowledged.  With this, the transient object only needs to support the create tra= nsform to insert the message in the poll queue and the poll message in the = form of an info response to consume the message.  There is no need for= the implementation to create any form of a transient object outside the poll queue, since the poll queue is the tra= nsient object store for this object type. 

 

—=

 

JG




James Gould
Distinguished Engine= er
jgould@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, H= ollenbeck, Scott <shollenbec= k@verisign.com> wrote:

=  

EPP has no concept of ̶= 0;objects” in the poll queue. The poll queue manipulates messages. Ob= jects are manipulated by transform commands like create, delete, etc.

 

I was thinking that the sou= rce client would create a relay object, which would result in a message bei= ng queued for the target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and = in the object (which would be slightly longer-lived, but would be automatic= ally deleted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available=

 

Scott,

 

I believe the intent is to inse= rt the transient object into the poll queue for the target client.  Th= e acknowledgement of the poll message should result in the implicit removal= of the transient object from the server.  With what you’re proposing, the source client would create the= transient object that I’m assuming would result in a poll notificati= on containing a signal to the client to submit an info command to get the t= ransient object information?  I’m assuming that the target client would then need to delete the transient object once theyR= 17;re done with processing the message.  I believe it’s simpler = and consistent with the concept of creating a transient poll message to sup= port the create to create the poll message and the info response poll message for the consumption of the transient object. &n= bsp;In this case the poll queue is functioning as the repository for the tr= ansient object with the signal and data being one and the same, and the del= etion of the transient object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engine= er
jgo= uld@Verisign.com

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

VerisignInc.com<= span lang=3D"EN-US">

 

On Jan 30, 2015, at 9:20 AM, Ho= llenbeck, Scott <shollenbeck@verisign.com> wrote:=

=  

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 18:30:20 GMT"; modification-date="Fri, 30 Jan 2015 18:30:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B928BE7Bkambx2SIDNlocal_-- From nobody Fri Jan 30 11:11:28 2015 Return-Path: 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 AC9611A039D for ; Fri, 30 Jan 2015 11:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 xi6Aab8PAAHU for ; Fri, 30 Jan 2015 11:11:20 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC831A0358 for ; Fri, 30 Jan 2015 11:11:09 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvXTRRQbxRydkSUtAAAKJtZcct84rNc@postini.com; Fri, 30 Jan 2015 11:11:17 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UJB8m8012785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 14:11:08 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 14:11:07 -0500 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwAAF92cAAAre/AAACf8AMA== Date: Fri, 30 Jan 2015 19:11:07 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> In-Reply-To: <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> 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_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 19:11:26 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved? Scott From: Gould, James Sent: Friday, January 30, 2015 1:50 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. - JG [cid:image001.png@01D03C96.2929A360] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> Since the create is for a transient m= essage object, there is no issue with creating more then one message with t= he same data.

 

If two or more messages end up being enque= ued, what is the client supposed to assume about any repeats after retrievi= ng and acting on the first message? How is idempotency preserved?

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 1:50 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Yes, each create would result in a new message to ge= t created and enqueued.  Since the create is for a transient message o= bject, there is no issue with creating more then one message with the same = data.   

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



> The intention of the relay command is= more of sending a message (with information) then the manipulation of obje= cts, but James explained it pretty well.

 

I just thought of something else while re-= reading this sentence. What happens if the exact same command is sent twice= ? Is a second message sent?

 

Scott

 

From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] 
Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Scott,=

 =

The intention of the rela= y command is more of sending a message (with information) then the manipula= tion of objects, but James explained it pretty well.

 <= /p>

The  thing that trig= gered me is the second part of your reply:

 

=D8  I don't have an issue with c= ontinuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not= comfortable with pursuing the current approach on the standards track. We = should confirm the need before doing standards track work.

 

Although I’m not an= IETF expert I assumed that when the document was adapted by the WG the WG = acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational= or standards track. And as far I understood it is not up to the WG to make= a document informational, that is something the IESG does. Feel free to co= rrect me if I misunderstood things.

 <= /p>

However the real question= is: Who can confirm this need?

 <= /p>

We see the need for an au= tomated secure transfer of domainnames in our daily operation. As the adopt= ion of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  

 <= /p>

Kind regards,=

Rik

 <= /p>

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= sh= ollenbeck@verisign.com> wrote:

 

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:

 

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 19:11:07 GMT"; modification-date="Fri, 30 Jan 2015 19:11:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F33D6DBRN1WNEXMBX01vc_-- From nobody Fri Jan 30 11:12:51 2015 Return-Path: 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 C04E21A1A38 for ; Fri, 30 Jan 2015 11:12:40 -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 3e4hX_DTOGZB for ; Fri, 30 Jan 2015 11:12:34 -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 A9C701A19F0 for ; Fri, 30 Jan 2015 11:12:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:cc: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=QpkaT0Q/Ln/JKagTofjOtZX6ABCf9/c6/5K2c0rdlGg=; b=HrdipP/XJCvWV7nu97TWAvzpTcein5KfH3qkxBfhTaWcQNtrAsx32EGqGXAzX+63coFxBvQmeXoF1RXpos8ZQSDyDEPbF8CFWutlRpkKHO3Tf1LWJdejPxMb/K6BTzEB6Vn5lDxqm7rkh0AJOUj0LCsR+e5DXELEVkAyE84oeo4= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by arn2-kamx.sidn.nl with ESMTP id t0UJCP1J014473-t0UJCP1L014473 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Fri, 30 Jan 2015 20:12:25 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 20:12:21 +0100 From: Rik Ribbers To: "'Hollenbeck, Scott'" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEZqysAAANycgAALHHTMAIC1EKAAAFOroAAAGLLAAAA000AAAAaFIAAAobIwAAF92cAAAEOs/A= Date: Fri, 30 Jan 2015 19:12:21 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/related; boundary="_004_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 19:12:41 -0000 --_004_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_ Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_" --_000_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes for every relay command a message is sent. We've taken some measures in our system for not flooding the system. In the= draft we've written some security considerations regarding this as one co= uld flood the registrars poll queue. Kind regards Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 19:39 To: Rik Ribbers; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: =D8 I don't have an issue with continuing work on this draft if the intent= ion is to document the existing practice of one operator in an informationa= l way, but I'm not comfortable with pursuing the current approach on the st= andards track. We should confirm the need before doing standards track work= . Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG [cid:image001.png@01D03CC9.0E1CB5C0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes for ev= ery relay command a message is sent.  

 = ;

We’v= e taken some measures in our system for not flooding the system. In the dra= ft we’ve written some security considerations regarding this  as one could flood the registrars poll queue.

 = ;

Kind regar= ds

Rik

 = ;

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: vrijdag 30 januari 2015 19:39
To: Rik Ribbers; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

> The intention of the r= elay command is more of sending a message (with information) then the manip= ulation of objects, but James explained it pretty well.

 

I just thought of something= else while re-reading this sentence. What happens if the exact same comman= d is sent twice? Is a second message sent?

 

Scott

 

From: Rik Ribbers [mailto:rik.ribbers@sidn.nl]
Sent: Friday, January 30, 2015 11:40 AM
To: Hollenbeck, Scott; Gould, James
Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Scott,<= /p>

 <= /p>

The intent= ion of the relay command is more of sending a message (with information) th= en the manipulation of objects, but James explained it pretty well.

 = ;

The  = thing that triggered me is the second part of your reply:=

 

=D8  I don't have an issue w= ith continuing work on this draft if the intention is to document the exist= ing practice of one operator in an informational way, but I'm not comfortab= le with pursuing the current approach on the standards track. We should confirm the need before doing standards = track work.

 

Although I= ’m not an IETF expert I assumed that when the document was adapted by= the WG the WG acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be i= nformational or standards track. And as far I understood it is not up to th= e WG to make a document informational, that is something the IESG does. Fee= l free to correct me if I misunderstood things.

 = ;

However th= e real question is: Who can confirm this need?

 = ;

We see the= need for an automated secure transfer of domainnames in our daily operatio= n. As the adoption of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We ch= oose the solution which is described in the draft and believe it is a good = pragmatic solution for a the problem. But  I agree that the need is no= t extremely high at this point, but it will be in the near future. Should we wait for that or act upon what we be= lieve is inevitable?  We choose not to wait.  <= /p>

 = ;

Kind regar= ds,

Rik

 = ;

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]
Sent: vrijdag 30 januari 2015 16:35
To: Gould, James
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: RE: [eppext] New draft for keyrelay available

 

Jim, that’s not how I= would have designed it. To each his own.

 

Scott

 

From: Gould, James
Sent: Friday, January 30, 2015 10:32 AM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support = new types of objects, and objects can support a different set of commands a= nd responses based on the requirements of those objects.   Objects can= be created on the server-side without any support for transform by the client.  In this case, the intent is to = create a poll queue message object that is consumed and automatically delet= ed when consumed, so the create functions as an enqueue and the poll info r= esponse functions as a dequeue once acknowledged.  With this, the transient object only needs to support the create tra= nsform to insert the message in the poll queue and the poll message in the = form of an info response to consume the message.  There is no need for= the implementation to create any form of a transient object outside the poll queue, since the poll queue is the tra= nsient object store for this object type. 

 

—=

 

JG




James Gould
Distinguished Engine= er
jgould@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, H= ollenbeck, Scott <shollenbec= k@verisign.com> wrote:

=  

EPP has no concept of ̶= 0;objects” in the poll queue. The poll queue manipulates messages. Ob= jects are manipulated by transform commands like create, delete, etc.

 

I was thinking that the sou= rce client would create a relay object, which would result in a message bei= ng queued for the target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and = in the object (which would be slightly longer-lived, but would be automatic= ally deleted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available=

 

Scott,

 

I believe the intent is to inse= rt the transient object into the poll queue for the target client.  Th= e acknowledgement of the poll message should result in the implicit removal= of the transient object from the server.  With what you’re proposing, the source client would create the= transient object that I’m assuming would result in a poll notificati= on containing a signal to the client to submit an info command to get the t= ransient object information?  I’m assuming that the target client would then need to delete the transient object once theyR= 17;re done with processing the message.  I believe it’s simpler = and consistent with the concept of creating a transient poll message to sup= port the create to create the poll message and the info response poll message for the consumption of the transient object. &n= bsp;In this case the poll queue is functioning as the repository for the tr= ansient object with the signal and data being one and the same, and the del= etion of the transient object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engine= er
jgo= uld@Verisign.com

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

VerisignInc.com<= span lang=3D"EN-US">

 

On Jan 30, 2015, at 9:20 AM, Ho= llenbeck, Scott <shollenbeck@verisign.com> wrote:=

=  

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_-- --_004_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 19:12:20 GMT"; modification-date="Fri, 30 Jan 2015 19:12:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_C80127C588F8F2409E2B535AF968B768B928BE8Akambx2SIDNlocal_-- From nobody Fri Jan 30 12:03:06 2015 Return-Path: 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 CB10D1A1BF8 for ; Fri, 30 Jan 2015 12:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 kYGLprmssr7n for ; Fri, 30 Jan 2015 12:02:59 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0371A1BBB for ; Fri, 30 Jan 2015 12:02:54 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvjbhcCcNUWSFRWcvqbCheGB22GM5/j@postini.com; Fri, 30 Jan 2015 12:02:58 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UK2rMm007378 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 15:02:53 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 15:02:52 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiA Date: Fri, 30 Jan 2015 20:02:52 +0000 Message-ID: <6BA91560-5425-4BAC-A17A-25D13EF88A8F@verisign.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_6BA9156054254BACA17A25D13EF88A8Fverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 20:03:04 -0000 --_004_6BA9156054254BACA17A25D13EF88A8Fverisigncom_ Content-Type: multipart/alternative; boundary="_000_6BA9156054254BACA17A25D13EF88A8Fverisigncom_" --_000_6BA9156054254BACA17A25D13EF88A8Fverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, There is a level of indirection here, where the goal of the extension is to= create a message to be sent to another party. There is no idempotency iss= ue with the creation of the message itself since it=92s transient and immut= able. Creating a duplicate message with the same data creates another imm= utable, transient object. The consuming client will handle the idempotency= aspects by ensuring that receipt of a duplicate message does not change th= e result. For example, consumption of the relay of the same key should not= result in the key getting duplicated in the resulting zone. This is the r= esponsibility of the consuming client and not of the server. =97 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 On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott > wrote: > Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved? Scott From: Gould, James Sent: Friday, January 30, 2015 1:50 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I=92m not an IETF expert I assumed that when the document was adap= ted by the WG the WG acknowledges the need for a standard. In Honolulu ther= e was a discussion if the documents from the working group should be inform= ational or standards track. And as far I understood it is not up to the WG = to make a document informational, that is something the IESG does. Feel fre= e to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that=92s not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_6BA9156054254BACA17A25D13EF88A8Fverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <29CB78F93B6CCE4AB7C4A0730C89C10D@verisign.com> Content-Transfer-Encoding: quoted-printable Scott,

There is a level of indirection here, where the goal of the extension = is to create a message to be sent to another party.  There is no idemp= otency issue with the creation of the message itself since it=92s transient= and immutable.  Creating a duplicate message  with the same data creates another immutable, transient object. &nbs= p;The consuming client will handle the idempotency aspects by ensuring that= receipt of a duplicate message does not change the result.  For examp= le, consumption of the relay of the same key should not result in the key getting duplicated in the resulting zone.  This= is the responsibility of the consuming client and not of the server.  = ;

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

= > Since the create is for a transient message object, there is no issue = with creating more then one message with the same data.
=  
= If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved?
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 1:50 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Yes, each create would result in a new message to get created and enqueued.=  Since the create is for a transient message object, there is no issu= e with creating more then one message with the same data.   =
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com=
 
On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <sh= ollenbeck@verisign.com> wrote:


> The intention of the relay command is more of sending a message (with= information) then the manipulation of objects, but James explained it pret= ty well.
 
I just thought of something else while re-reading this sentence. What happ= ens if the exact same command is sent twice? Is a second message sent?
 
Scott
 
From:<= /span> Rik Ribbers [mailto:rik.ribber= s@sidn.nl]  Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available
 
Scott,
 
The intention of the relay command is more of sending a me= ssage (with information) then the manipulation of objects, but James explai= ned it pretty well.
 
The  thing that triggered me is the second part of yo= ur reply:
 
=D8  I do= n't have an issue with continuing work on this draft if the intention is to= document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current ap= proach on the standards track. We should confirm the need before doing stan= dards track work.
 
Although I=92m not an IETF expert I assumed that when the = document was adapted by the WG the WG acknowledges the need for a standard.= In Honolulu there was a discussion if the documents from the working group should be informational or standar= ds track. And as far I understood it is not up to the WG to make a document= informational, that is something the IESG does. Feel free to correct me if= I misunderstood things.
 
However the real question is: Who can confirm this need?
 
We see the need for an automated secure transfer of domain= names in our daily operation. As the adoption of validating DNSSEC resolver= grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solution which = is described in the draft and believe it is a good pragmatic solution for a= the problem. But  I agree that the need is not extremely high at this= point, but it will be in the near future. Should we wait for that or act upon what we believe is inevitable?  W= e choose not to wait.  
 
Kind regards,
Rik
 
From:<= /span> Hollenbeck, Scott [mailto:shollen= beck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: RE: [eppe= xt] New draft for keyrelay available
 
= Jim, that=92s not how I would have designed it. To each his own.
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects.   Objects can be created on the server-side without any s= upport for transform by the client.  In this case, the intent is to create a poll queue message object that is con= sumed and automatically deleted when consumed, so the create functions as a= n enqueue and the poll info response functions as a dequeue once acknowledg= ed.  With this, the transient object only needs to support the create transform to insert the message in the po= ll queue and the poll message in the form of an info response to consume th= e message.  There is no need for the implementation to create any form= of a transient object outside the poll queue, since the poll queue is the transient object store for this object = type. 
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <<= span style=3D"color: purple;">shollenbeck@verisign.com> wrote= :

 

= EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc.
=  
= I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which wou= ld be slightly longer-lived, but would be automatically deleted when it exp= ired).
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:=

 

-----Original Message-----
From: EppExt [mailto:ep= pext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppex= t@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_6BA9156054254BACA17A25D13EF88A8Fverisigncom_-- --_004_6BA9156054254BACA17A25D13EF88A8Fverisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 20:02:52 GMT"; modification-date="Fri, 30 Jan 2015 20:02:52 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_6BA9156054254BACA17A25D13EF88A8Fverisigncom_-- From nobody Fri Jan 30 12:18:24 2015 Return-Path: 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 AF57E1A6F96 for ; Fri, 30 Jan 2015 12:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 JEjj-8EseBbH for ; Fri, 30 Jan 2015 12:18:09 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E451A6F7C for ; Fri, 30 Jan 2015 12:18:03 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvm+8Yf5y6gvFYaquk4NWUvBcs1nPOv@postini.com; Fri, 30 Jan 2015 12:18:08 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id t0UKI2PH009080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 15:18:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 15:18:01 -0500 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhA= Date: Fri, 30 Jan 2015 20:18:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-5425-4BAC-A17A-25D13EF88A8F@verisign.com> In-Reply-To: <6BA91560-5425-4BAC-A17A-25D13EF88A8F@verisign.com> 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_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 20:18:19 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > This is the responsibility of the consuming client and not of the server EPP commands are supposed to be idempotent *without* the client needing to = assume responsibility for any special actions. We can do better. Scott From: Gould, James Sent: Friday, January 30, 2015 3:03 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, There is a level of indirection here, where the goal of the extension is to= create a message to be sent to another party. There is no idempotency iss= ue with the creation of the message itself since it's transient and immutab= le. Creating a duplicate message with the same data creates another immut= able, transient object. The consuming client will handle the idempotency a= spects by ensuring that receipt of a duplicate message does not change the = result. For example, consumption of the relay of the same key should not r= esult in the key getting duplicated in the resulting zone. This is the res= ponsibility of the consuming client and not of the server. - JG [cid:image001.png@01D03C9E.E80538A0] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott > wrote: > Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved? Scott From: Gould, James Sent: Friday, January 30, 2015 1:50 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> This is the responsibility of the con= suming client and not of the server

 

EPP commands are supposed to be idempotent= *without* the client needing to assume responsibility for any speci= al actions. We can do better.

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 3:03 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

There is a level of indirection here, where the goal= of the extension is to create a message to be sent to another party.  = ;There is no idempotency issue with the creation of the message itself sinc= e it’s transient and immutable.  Creating a duplicate message  with the same data creates another immutable, tr= ansient object.  The consuming client will handle the idempotency aspe= cts by ensuring that receipt of a duplicate message does not change the res= ult.  For example, consumption of the relay of the same key should not result in the key getting duplicated in the res= ulting zone.  This is the responsibility of the consuming client and n= ot of the server.  

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



> Since the create is for a transient m= essage object, there is no issue with creating more then one message with t= he same data.

 

If two or more messages end up being enque= ued, what is the client supposed to assume about any repeats after retrievi= ng and acting on the first message? How is idempotency preserved?

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 1:50 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Yes, each create would result in a new message to ge= t created and enqueued.  Since the create is for a transient message o= bject, there is no issue with creating more then one message with the same = data.   

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:




> The intention of the relay command is= more of sending a message (with information) then the manipulation of obje= cts, but James explained it pretty well.

 

I just thought of something else while re-= reading this sentence. What happens if the exact same command is sent twice= ? Is a second message sent?

 

Scott

 

From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] 
Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Scott,=

 =

The intention of the rela= y command is more of sending a message (with information) then the manipula= tion of objects, but James explained it pretty well.

 <= /p>

The  thing that trig= gered me is the second part of your reply:

 

=D8  I don't have an issue with c= ontinuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not= comfortable with pursuing the current approach on the standards track. We = should confirm the need before doing standards track work.

 

Although I’m not an= IETF expert I assumed that when the document was adapted by the WG the WG = acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational= or standards track. And as far I understood it is not up to the WG to make= a document informational, that is something the IESG does. Feel free to co= rrect me if I misunderstood things.

 <= /p>

However the real question= is: Who can confirm this need?

 <= /p>

We see the need for an au= tomated secure transfer of domainnames in our daily operation. As the adopt= ion of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  

 <= /p>

Kind regards,=

Rik

 <= /p>

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= sh= ollenbeck@verisign.com> wrote:

 

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:

 

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 20:18:01 GMT"; modification-date="Fri, 30 Jan 2015 20:18:01 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F33F4CBRN1WNEXMBX01vc_-- From nobody Fri Jan 30 12:34:56 2015 Return-Path: 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 CF9711A7004 for ; Fri, 30 Jan 2015 12:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ga9EH7YdB-y3 for ; Fri, 30 Jan 2015 12:34:50 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF2C1A6FF0 for ; Fri, 30 Jan 2015 12:34:45 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvq5YThsm+C5sXcVGf65seJbE0pRq2I@postini.com; Fri, 30 Jan 2015 12:34:50 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UKYibh022530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 15:34:44 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 15:34:43 -0500 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhD//7ZaAA== Date: Fri, 30 Jan 2015 20:34:42 +0000 Message-ID: References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-5425-4BAC-A17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 20:34:55 -0000 --_004_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_ Content-Type: multipart/alternative; boundary="_000_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_" --_000_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Scott, There are three parties here which include the producing client, the server= , and the consuming client. What you=92re referring to in the EPP command = is the producing client and server, which does not have any idempotent issu= e since the message is transient and immutable. To address your idempotenc= y concern end-to-end, maybe the producing client should add a unique relay = identifier that the relaying consumer ensures to process only once. Messag= es with a duplicate relay identifier must be processed a single time by the= relaying consumer. Does that work? =97 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 On Jan 30, 2015, at 3:18 PM, Hollenbeck, Scott > wrote: > This is the responsibility of the consuming client and not of the server EPP commands are supposed to be idempotent *without* the client needing to = assume responsibility for any special actions. We can do better. Scott From: Gould, James Sent: Friday, January 30, 2015 3:03 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, There is a level of indirection here, where the goal of the extension is to= create a message to be sent to another party. There is no idempotency iss= ue with the creation of the message itself since it=92s transient and immut= able. Creating a duplicate message with the same data creates another imm= utable, transient object. The consuming client will handle the idempotency= aspects by ensuring that receipt of a duplicate message does not change th= e result. For example, consumption of the relay of the same key should not= result in the key getting duplicated in the resulting zone. This is the r= esponsibility of the consuming client and not of the server. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott > wrote: > Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved? Scott From: Gould, James Sent: Friday, January 30, 2015 1:50 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I=92m not an IETF expert I assumed that when the document was adap= ted by the WG the WG acknowledges the need for a standard. In Honolulu ther= e was a discussion if the documents from the working group should be inform= ational or standards track. And as far I understood it is not up to the WG = to make a document informational, that is something the IESG does. Feel fre= e to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that=92s not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you=92re proposing, the source client would create the transient object= that I=92m assuming would result in a poll notification containing a signa= l to the client to submit an info command to get the transient object infor= mation? I=92m assuming that the target client would then need to delete th= e transient object once they=92re done with processing the message. I beli= eve it=92s simpler and consistent with the concept of creating a transient = poll message to support the create to create the poll message and the info = response poll message for the consumption of the transient object. In this= case the poll queue is functioning as the repository for the transient obj= ect with the signal and data being one and the same, and the deletion of th= e transient object handled via the standard poll queue mechanism. =97 JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <478E702356D97F44B07C6B8782952DCF@verisign.com> Content-Transfer-Encoding: quoted-printable Scott,

There are three parties here which include the producing client, the s= erver, and the consuming client.  What you=92re referring to in the EP= P command is the producing client and server, which does not have any idemp= otent issue since the message is transient and immutable.  To address your idempotency concern end-to-= end, maybe the producing client should add a unique relay identifier that t= he relaying consumer ensures to process only once.  Messages with a du= plicate relay identifier must be processed a single time by the relaying consumer.  Does that work?

=97

<= span style=3D"font-size: 11pt;">

<= span style=3D"font-size: 11pt;">JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignI= nc.com

On Jan 30, 2015, at 3:18 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

= > This is the responsibility of the consuming client and not of the serv= er
=  
= EPP commands are supposed to be idempotent *without* the client need= ing to assume responsibility for any special actions. We can do better.
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 3:03 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
There is a level of indirection here, where the goal of the extension is to= create a message to be sent to another party.  There is no idempotenc= y issue with the creation of the message itself since it=92s transient and = immutable.  Creating a duplicate message  with the same data creates another immutable, transient object. &nbs= p;The consuming client will handle the idempotency aspects by ensuring that= receipt of a duplicate message does not change the result.  For examp= le, consumption of the relay of the same key should not result in the key getting duplicated in the resulting zone.  This= is the responsibility of the consuming client and not of the server.  = ;
 
=97=
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

VerisignInc.com=
 
On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott <sh= ollenbeck@verisign.com> wrote:


= > Since the create is for a transient message object, there is no issue = with creating more then one message with the same data.
=  
= If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved?
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 1:50 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Yes, each create would result in a new message to get created and enqueued.=  Since the create is for a transient message object, there is no issu= e with creating more then one message with the same data.   =
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:=



> The intention of the relay command is more of sending a message (with= information) then the manipulation of objects, but James explained it pret= ty well.
 
I just thought of something else while re-reading this sentence. What happ= ens if the exact same command is sent twice? Is a second message sent?
 
Scott
 
From:<= /span> Rik Ribbers [mailto:rik.ribber= s@sidn.nl]  Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available
 
Scott,
 
The intention of the relay command is more of sending a me= ssage (with information) then the manipulation of objects, but James explai= ned it pretty well.
 
The  thing that triggered me is the second part of yo= ur reply:
 
=D8  I do= n't have an issue with continuing work on this draft if the intention is to= document the existing practice of one operator in an informational way, but I'm not comfortable with pursuing the current ap= proach on the standards track. We should confirm the need before doing stan= dards track work.
 
Although I=92m not an IETF expert I assumed that when the = document was adapted by the WG the WG acknowledges the need for a standard.= In Honolulu there was a discussion if the documents from the working group should be informational or standar= ds track. And as far I understood it is not up to the WG to make a document= informational, that is something the IESG does. Feel free to correct me if= I misunderstood things.
 
However the real question is: Who can confirm this need?
 
We see the need for an automated secure transfer of domain= names in our daily operation. As the adoption of validating DNSSEC resolver= grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solution which = is described in the draft and believe it is a good pragmatic solution for a= the problem. But  I agree that the need is not extremely high at this= point, but it will be in the near future. Should we wait for that or act upon what we believe is inevitable?  W= e choose not to wait.  
 
Kind regards,
Rik
 
From:<= /span> Hollenbeck, Scott [mailto:shollen= beck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: RE: [eppe= xt] New draft for keyrelay available
 
= Jim, that=92s not how I would have designed it. To each his own.
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects.   Objects can be created on the server-side without any s= upport for transform by the client.  In this case, the intent is to create a poll queue message object that is con= sumed and automatically deleted when consumed, so the create functions as a= n enqueue and the poll info response functions as a dequeue once acknowledg= ed.  With this, the transient object only needs to support the create transform to insert the message in the po= ll queue and the poll message in the form of an info response to consume th= e message.  There is no need for the implementation to create any form= of a transient object outside the poll queue, since the poll queue is the transient object store for this object = type. 
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <<= span style=3D"color: purple;">shollenbeck@verisign.com> wrote= :

 

= EPP has no concept of =93objects=94 in the poll queue. The poll queue manip= ulates messages. Objects are manipulated by transform commands like create,= delete, etc.
=  
= I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once dequeued), and in the object (which wou= ld be slightly longer-lived, but would be automatically deleted when it exp= ired).
=  
Scott
=  
From:<= /span> Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext@ietf.org=
Subject: Re: [eppe= xt] New draft for keyrelay available
 
Scott,
 
I believe the intent is to insert the transient object into the poll queue = for the target client.  The acknowledgement of the poll message should= result in the implicit removal of the transient object from the server. &n= bsp;With what you=92re proposing, the source client would create the transient object that I=92m assuming would result = in a poll notification containing a signal to the client to submit an info = command to get the transient object information?  I=92m assuming that = the target client would then need to delete the transient object once they=92re done with processing the message. &nbs= p;I believe it=92s simpler and consistent with the concept of creating a tr= ansient poll message to support the create to create the poll message and t= he info response poll message for the consumption of the transient object.  In this case the poll queue is functioning = as the repository for the transient object with the signal and data being o= ne and the same, and the deletion of the transient object handled via the s= tandard poll queue mechanism.     
 
=97
 

JG


<image001.png>

James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com
 
On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:=

 

-----Original Message-----
From: EppExt [mailto:ep= pext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppex= t@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.

One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

--_000_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_-- --_004_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_ Content-Type: image/png; name="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png" Content-Description: BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png Content-Disposition: inline; filename="BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png"; size=4109; creation-date="Fri, 30 Jan 2015 20:34:42 GMT"; modification-date="Fri, 30 Jan 2015 20:34:42 GMT" Content-ID: <77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_BF69A00EEBD5435A8BF51C77A44E4545verisigncom_-- From nobody Fri Jan 30 12:36:33 2015 Return-Path: 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 0BDB01A700D for ; Fri, 30 Jan 2015 12:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 UUJA0s16mXyS for ; Fri, 30 Jan 2015 12:36:25 -0800 (PST) Received: from MBX1.impetus.co.in (mail.impetus.co.in [103.250.168.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC271A6FF0 for ; Fri, 30 Jan 2015 12:36:17 -0800 (PST) Received: from MBX1.impetus.co.in (192.168.100.123) by MBX1.impetus.co.in (192.168.100.123) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sat, 31 Jan 2015 02:06:08 +0530 Received: from MBX1.impetus.co.in ([fe80::d489:82f:caa0:3c23]) by MBX1.impetus.co.in ([fe80::d489:82f:caa0:3c23%19]) with mapi id 15.00.0913.011; Sat, 31 Jan 2015 02:06:08 +0530 From: Santosh Kalsangrah To: Rik Ribbers , "eppext@ietf.org" Thread-Topic: New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwRfVugQ Date: Fri, 30 Jan 2015 20:36:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.100.161] Content-Type: multipart/alternative; boundary="_000_cc9301a8806f4f0e979d0cef96c09719MBX1impetuscoin_" MIME-Version: 1.0 Archived-At: Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 20:36:30 -0000 --_000_cc9301a8806f4f0e979d0cef96c09719MBX1impetuscoin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rik, Here is my feedback, (actually questions:)) 1. It seems it's assumed that all EPP messaging between registrar 1<-= >registry<->registrar 2 proposed in this draft is over secure transport. Is= that ok if either or both registrar(s) connects to registry over non-secur= e transport? 2. How is key information validated by receiving registrar that it is= what was sent by the other registrar. Or how is sender assured that key i= nformation would be sent as is to other end? Or this is not important? 3. How would gaining registrar be notified back that key info it has = sent is acknowledged/read by losing registrar. Or is it that gaining regist= rar need not to know? 4. In case if losing registrar does not support extension in this dra= ft, what will happen to key info? Thanks, Santosh K From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Thursday, January 08, 2015 7:12 PM To: eppext@ietf.org Subject: [eppext] New draft for keyrelay available All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers ________________________________ NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_cc9301a8806f4f0e979d0cef96c09719MBX1impetuscoin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rik, =

=  

Here = is my feedback, (actually questionsJ)

=  

1.       It seems it’s assumed that all EPP messaging between registrar 1&l= t;->registry<->registrar 2 proposed in this draft is over secure t= ransport. Is that ok if either or both registrar(s) connects to registry over non-secure transport?

2.       How is key information validated by receiving registrar that it is what = was sent by the  other registrar. Or how is sender assured that key in= formation would be sent as is to other end? Or this is not important?

3.       How would gaining registrar be notified back that key info it has sent i= s acknowledged/read by losing registrar. Or is it that gaining registrar ne= ed not to know?

4.       In case if losing registrar does not support extension in this draft, wh= at will happen to key info?

=  

Thanks,

Santosh K

=  

From: EppExt [mail= to:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Thursday, January 08, 2015 7:12 PM
To: eppext@ietf.org
Subject: [eppext] New draft for keyrelay available

 

All,

 

As you (may) have noticed= we submitted a new version of the keyrelay draft. In this draft we tried t= o solve all the open issues, remarks and feedback we received.

 

The major  changes a= re:

 

  1.  Introduci= ng the <relay> command, and thus seperating the data and

    &= nbsp;  the command.

 

   2.  Upd= ated the Introduction, describing the general use of relay vs

    &= nbsp;  the intended use-case of relaying DNSSEC key data.

 

   3.  Res= tructuring the document to make it more inline with existing

    &= nbsp;  EPP extensions.

 

In the end it has become = a major rewrite and as always feedback is welcome.

 

Kind regards,<= /p>

Rik Ribbers








NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference.
 --_000_cc9301a8806f4f0e979d0cef96c09719MBX1impetuscoin_-- From nobody Fri Jan 30 13:02:44 2015 Return-Path: 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 6270D1A872B for ; Fri, 30 Jan 2015 13:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 0KIwBnYTna2U for ; Fri, 30 Jan 2015 13:02:35 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501371A870B for ; Fri, 30 Jan 2015 13:02:30 -0800 (PST) Received: from brn1lxmailout01.verisign.com ([72.13.63.41]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKVMvxZVxhA7D4szUTUwb0HxdRYxNNsOjy@postini.com; Fri, 30 Jan 2015 13:02:34 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id t0UL2S1l025787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Jan 2015 16:02:29 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 16:02:28 -0500 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [eppext] New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwA+eoEAALUP4qAAEcW9gAEmPdEAAANycwAAKyYUgAIEIAGAAAFOhwAAAGLyAAAA03OAAAAZ7YAAAkG4AAAELswAAABaAQAAAMFFgAABzoiAAApRdhD//7ZaAIAATNuw Date: Fri, 30 Jan 2015 21:02:27 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-5425-4BAC-A17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: 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_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Cc: Rik Ribbers , Miek Gieben , Maarten Bosteels , "eppext@ietf.org" Subject: Re: [eppext] New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 21:02:42 -0000 --_004_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_ Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_" --_000_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Messages with a duplicate relay identifier must be processed a single tim= e by the relaying consumer. Does that work? I'm not a fan of this approach so I'd rather not try to fix it, but anythin= g that reduces the risk of a repeated action would be an improvement. I thi= nk it would be better to consider an alternative that carries no risk of du= plication. Scott From: Gould, James Sent: Friday, January 30, 2015 3:35 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, There are three parties here which include the producing client, the server= , and the consuming client. What you're referring to in the EPP command is= the producing client and server, which does not have any idempotent issue = since the message is transient and immutable. To address your idempotency = concern end-to-end, maybe the producing client should add a unique relay id= entifier that the relaying consumer ensures to process only once. Messages= with a duplicate relay identifier must be processed a single time by the r= elaying consumer. Does that work? - JG [cid:image001.png@01D03CA6.247B6A50] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 3:18 PM, Hollenbeck, Scott > wrote: > This is the responsibility of the consuming client and not of the server EPP commands are supposed to be idempotent *without* the client needing to = assume responsibility for any special actions. We can do better. Scott From: Gould, James Sent: Friday, January 30, 2015 3:03 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, There is a level of indirection here, where the goal of the extension is to= create a message to be sent to another party. There is no idempotency iss= ue with the creation of the message itself since it's transient and immutab= le. Creating a duplicate message with the same data creates another immut= able, transient object. The consuming client will handle the idempotency a= spects by ensuring that receipt of a duplicate message does not change the = result. For example, consumption of the relay of the same key should not r= esult in the key getting duplicated in the resulting zone. This is the res= ponsibility of the consuming client and not of the server. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott > wrote: > Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. If two or more messages end up being enqueued, what is the client supposed = to assume about any repeats after retrieving and acting on the first messag= e? How is idempotency preserved? Scott From: Gould, James Sent: Friday, January 30, 2015 1:50 PM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Yes, each create would result in a new message to get created and enqueued.= Since the create is for a transient message object, there is no issue wit= h creating more then one message with the same data. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott > wrote: > The intention of the relay command is more of sending a message (with inf= ormation) then the manipulation of objects, but James explained it pretty w= ell. I just thought of something else while re-reading this sentence. What happe= ns if the exact same command is sent twice? Is a second message sent? Scott From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] Sent: Friday, January 30, 2015 11:40 AM To: Hollenbeck, Scott; Gould, James Cc: Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Scott, The intention of the relay command is more of sending a message (with infor= mation) then the manipulation of objects, but James explained it pretty wel= l. The thing that triggered me is the second part of your reply: > I don't have an issue with continuing work on this draft if the intentio= n is to document the existing practice of one operator in an informational = way, but I'm not comfortable with pursuing the current approach on the stan= dards track. We should confirm the need before doing standards track work. Although I'm not an IETF expert I assumed that when the document was adapte= d by the WG the WG acknowledges the need for a standard. In Honolulu there = was a discussion if the documents from the working group should be informat= ional or standards track. And as far I understood it is not up to the WG to= make a document informational, that is something the IESG does. Feel free = to correct me if I misunderstood things. However the real question is: Who can confirm this need? We see the need for an automated secure transfer of domainnames in our dail= y operation. As the adoption of validating DNSSEC resolver grows it becomes= more and more a problem that domainnames cannot be resolved. We choose the= solution which is described in the draft and believe it is a good pragmati= c solution for a the problem. But I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for th= at or act upon what we believe is inevitable? We choose not to wait. Kind regards, Rik From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: vrijdag 30 januari 2015 16:35 To: Gould, James Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: RE: [eppext] New draft for keyrelay available Jim, that's not how I would have designed it. To each his own. Scott From: Gould, James Sent: Friday, January 30, 2015 10:32 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, EPP can be extended to support new types of objects, and objects can suppor= t a different set of commands and responses based on the requirements of th= ose objects. Objects can be created on the server-side without any suppor= t for transform by the client. In this case, the intent is to create a pol= l queue message object that is consumed and automatically deleted when cons= umed, so the create functions as an enqueue and the poll info response func= tions as a dequeue once acknowledged. With this, the transient object only= needs to support the create transform to insert the message in the poll qu= eue and the poll message in the form of an info response to consume the mes= sage. There is no need for the implementation to create any form of a tran= sient object outside the poll queue, since the poll queue is the transient = object store for this object type. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott > wrote: EPP has no concept of "objects" in the poll queue. The poll queue manipulat= es messages. Objects are manipulated by transform commands like create, del= ete, etc. I was thinking that the source client would create a relay object, which wo= uld result in a message being queued for the target client. The info could = exist in both the poll message (which would be short-lived and lost once de= queued), and in the object (which would be slightly longer-lived, but would= be automatically deleted when it expired). Scott From: Gould, James Sent: Friday, January 30, 2015 9:57 AM To: Hollenbeck, Scott Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Scott, I believe the intent is to insert the transient object into the poll queue = for the target client. The acknowledgement of the poll message should resu= lt in the implicit removal of the transient object from the server. With w= hat you're proposing, the source client would create the transient object t= hat I'm assuming would result in a poll notification containing a signal to= the client to submit an info command to get the transient object informati= on? I'm assuming that the target client would then need to delete the tran= sient object once they're done with processing the message. I believe it's= simpler and consistent with the concept of creating a transient poll messa= ge to support the create to create the poll message and the info response p= oll message for the consumption of the transient object. In this case the = poll queue is functioning as the repository for the transient object with t= he signal and data being one and the same, and the deletion of the transien= t object handled via the standard poll queue mechanism. - JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott > wrote: -----Original Message----- From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Tuesday, January 20, 2015 3:02 AM To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org Subject: Re: [eppext] New draft for keyrelay available Hello Maarten, Thx for the feedback, I hope more people with experience on extending EPP will state their opinion on the list. We have implemented the functionality in our registration system, but it is not very actively used. What we see is that most registrars go insecure. Most of the time we see a transfer command followed (some time later in time) by a domain update to remove the old key material and add new key material. There is even a losing registrar that removes all DNS key data when a registrant requests its authorization token before the actual transfer. One more opinion: After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the command isn't doing either of = those things. It's pushing information to the server to be stored temporari= ly (in what?) so that it can be retrieved with a command. It would b= e more architecturally consistent to create a temporary relay object with t= he needed information and use an command to retrieve the data. can be used to notify the receiving client that the information is there = to be retrieved. Anyway, that's my two cents. Rik's "not very actively used" comment is telling. DNSSEC isn't widely supp= orted by registrars, so it makes sense that we're not seeing a lot of use. = I don't have an issue with continuing work on this draft if the intention i= s to document the existing practice of one operator in an informational way= , but I'm not comfortable with pursuing the current approach on the standar= ds track. We should confirm the need before doing standards track work. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> Messages with a duplicate relay ident= ifier must be processed a single time by the relaying consumer.  Does = that work?

 

I’m not a fan of this approach so I&= #8217;d rather not try to fix it, but anything that reduces the risk of a r= epeated action would be an improvement. I think it would be better to consider an alternative that carries no risk of duplication.

 

Scott<= o:p>

 

From: Gould, J= ames
Sent: Friday, January 30, 2015 3:35 PM
To: Hollenbeck, Scott
Cc: Rik Ribbers; Maarten Bosteels; Miek Gieben; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

 

Scott,

 

There are three parties here which include the produ= cing client, the server, and the consuming client.  What you’re = referring to in the EPP command is the producing client and server, which d= oes not have any idempotent issue since the message is transient and immutable.  To address your idempotency co= ncern end-to-end, maybe the producing client should add a unique relay iden= tifier that the relaying consumer ensures to process only once.  Messa= ges with a duplicate relay identifier must be processed a single time by the relaying consumer.  Does that work?

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

On Jan 30, 2015, at 3:18 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">shollenbeck@verisign.com>= wrote:



> This is the responsibility of the con= suming client and not of the server

 

EPP commands are supposed to be idempotent= *without* the client needing to assume responsibility for any speci= al actions. We can do better.

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 3:03 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

There is a level of indirection here, where the goal= of the extension is to create a message to be sent to another party.  = ;There is no idempotency issue with the creation of the message itself sinc= e it’s transient and immutable.  Creating a duplicate message  with the same data creates another immutable, tr= ansient object.  The consuming client will handle the idempotency aspe= cts by ensuring that receipt of a duplicate message does not change the res= ult.  For example, consumption of the relay of the same key should not result in the key getting duplicated in the res= ulting zone.  This is the responsibility of the consuming client and n= ot of the server.  

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 2:11 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:




> Since the create is for a transient m= essage object, there is no issue with creating more then one message with t= he same data.

 

If two or more messages end up being enque= ued, what is the client supposed to assume about any repeats after retrievi= ng and acting on the first message? How is idempotency preserved?

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 1:50 PM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Yes, each create would result in a new message to ge= t created and enqueued.  Since the create is for a transient message o= bject, there is no issue with creating more then one message with the same = data.   

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 1:39 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:





> The intention of the relay command is= more of sending a message (with information) then the manipulation of obje= cts, but James explained it pretty well.

 

I just thought of something else while re-= reading this sentence. What happens if the exact same command is sent twice= ? Is a second message sent?

 

Scott

 

From: Rik Ribbers [mailto:rik.ribbers@sidn.nl] 
Sent: Friday, Janu= ary 30, 2015 11:40 AM
To: Hollenbeck, Sc= ott; Gould, James
Cc: Maarten Bostee= ls; Miek Gieben; eppext@ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Scott,=

 =

The intention of the rela= y command is more of sending a message (with information) then the manipula= tion of objects, but James explained it pretty well.

 <= /p>

The  thing that trig= gered me is the second part of your reply:

 

=D8  I don't have an issue with c= ontinuing work on this draft if the intention is to document the existing practice of one operator in an informational way, but I'm not= comfortable with pursuing the current approach on the standards track. We = should confirm the need before doing standards track work.

 

Although I’m not an= IETF expert I assumed that when the document was adapted by the WG the WG = acknowledges the need for a standard. In Honolulu there was a discussion if the documents from the working group should be informational= or standards track. And as far I understood it is not up to the WG to make= a document informational, that is something the IESG does. Feel free to co= rrect me if I misunderstood things.

 <= /p>

However the real question= is: Who can confirm this need?

 <= /p>

We see the need for an au= tomated secure transfer of domainnames in our daily operation. As the adopt= ion of validating DNSSEC resolver grows it becomes more and more a problem that domainnames cannot be resolved. We choose the solu= tion which is described in the draft and believe it is a good pragmatic sol= ution for a the problem. But  I agree that the need is not extremely h= igh at this point, but it will be in the near future. Should we wait for that or act upon what we believe is in= evitable?  We choose not to wait.  

 <= /p>

Kind regards,=

Rik

 <= /p>

From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] 
Sent: vrijdag 30 j= anuari 2015 16:35
To: Gould, James Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: RE: [eppe= xt] New draft for keyrelay available

 

Jim, that’s not how I would have des= igned it. To each his own.

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 10:32 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

EPP can be extended to support new types of objects,= and objects can support a different set of commands and responses based on= the requirements of those objects.   Objects can be created on the se= rver-side without any support for transform by the client.  In this case, the intent is to create a poll queue me= ssage object that is consumed and automatically deleted when consumed, so t= he create functions as an enqueue and the poll info response functions as a= dequeue once acknowledged.  With this, the transient object only needs to support the create transform to insert = the message in the poll queue and the poll message in the form of an info r= esponse to consume the message.  There is no need for the implementati= on to create any form of a transient object outside the poll queue, since the poll queue is the transient objec= t store for this object type. 

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 10:08 AM, Hollenbeck, Scott <= sh= ollenbeck@verisign.com> wrote:

 

EPP has no concept of “objects”= ; in the poll queue. The poll queue manipulates messages. Objects are manip= ulated by transform commands like create, delete, etc.

 

I was thinking that the source client woul= d create a relay object, which would result in a message being queued for t= he target client. The info could exist in both the poll message (which would be short-lived and lost once dequeued), and in the ob= ject (which would be slightly longer-lived, but would be automatically dele= ted when it expired).

 

Scott

 

From: Gould, James 
Sent: Friday, Janu= ary 30, 2015 9:57 AM
To: Hollenbeck, Sc= ott
Cc: Rik Ribbers; M= aarten Bosteels; Miek Gieben; eppext= @ietf.org
Subject: Re: [eppe= xt] New draft for keyrelay available

 

Scott,

 

I believe the intent is to insert the transient obje= ct into the poll queue for the target client.  The acknowledgement of = the poll message should result in the implicit removal of the transient obj= ect from the server.  With what you’re proposing, the source client would create the transient object that I̵= 7;m assuming would result in a poll notification containing a signal to the= client to submit an info command to get the transient object information? =  I’m assuming that the target client would then need to delete the transient object once they’re done with proc= essing the message.  I believe it’s simpler and consistent with = the concept of creating a transient poll message to support the create to c= reate the poll message and the info response poll message for the consumption of the transient object.  In this case th= e poll queue is functioning as the repository for the transient object with= the signal and data being one and the same, and the deletion of the transi= ent object handled via the standard poll queue mechanism.     

 

—

 

JG


<image001.png>

James Gould
Distinguished Engineer
jgo= uld@Verisign.com

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

VerisignInc.com

 

On Jan 30, 2015, at 9:20 AM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com">sho= llenbeck@verisign.com> wrote:

 

-----Original Message-----
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribb= ers
Sent: Tuesday, January 20, 2015 3:02 AM
To: 'Maarten Bosteels'; Miek Gieben; Gould, James; eppext@ietf.org
Subject: Re: [eppext] New draft for keyrelay available

Hello Maarten,

Thx for the feedback, I hope more people with experience on extending
EPP will state their opinion on the list.

We have implemented the functionality in our registration system, but
it is not very actively used. What we see is that most registrars go
insecure. Most of the time we see a transfer command followed (some
time later in time) by a domain update to remove the old key material
and add new key material. There is even a losing registrar that removes
all DNS key data when a registrant requests its authorization token
before the actual transfer.


One more opinion:

After reading through the draft again I believe I would have designed this = differently. EPP commands typically act on or read data from objects, and i= f I'm reading keyrelay correctly the <relay> command isn't doing eith= er of those things. It's pushing information to the server to be stored temporarily (in what?) so that it can be retrie= ved with a <poll> command. It would be more architecturally consisten= t to create a temporary relay object with the needed information and use an= <info> command to retrieve the data. <poll> can be used to notify the receiving client that the informati= on is there to be retrieved. Anyway, that's my two cents.

Rik's "not very actively used" comment is telling. DNSSEC isn't w= idely supported by registrars, so it makes sense that we're not seeing a lo= t of use. I don't have an issue with continuing work on this draft if the i= ntention is to document the existing practice of one operator in an informational way, but I'm not comfortable with purs= uing the current approach on the standards track. We should confirm the nee= d before doing standards track work.

Scott

 

--_000_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_-- --_004_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Fri, 30 Jan 2015 21:02:27 GMT"; modification-date="Fri, 30 Jan 2015 21:02:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_831693C2CDA2E849A7D7A712B24E257F49F34147BRN1WNEXMBX01vc_-- From nobody Fri Jan 30 13:30:57 2015 Return-Path: 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 6CA181A700F for ; Fri, 30 Jan 2015 13:30:55 -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 lqkVjVAXxJSt for ; Fri, 30 Jan 2015 13:30:52 -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 9FD081A1A59 for ; Fri, 30 Jan 2015 13:30:51 -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-originating-ip:content-type:mime-version; bh=BjBt2oAYURDpN3QpaoZoniM+hrBdpbriZAjiH3sgZWU=; b=qXEtxCdmETJdGv254WA0PuSSmXOK6zMELOU9A/JgzKQi2ILw/S1jPzJ/LgNscb2AiSTUup/uD4qpvdo4VVEn7Imlyzf9iYvIfILp2ZFUpLwFuSWW29A9+P1VzWZqHY3fLELFsdTI/t3qodJrNimhwH9U4tQQeC2w8HyG3kPMJxo= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id t0ULUoLj019090-t0ULUoLl019090 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL) for ; Fri, 30 Jan 2015 22:30:50 +0100 Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0174.001; Fri, 30 Jan 2015 22:30:46 +0100 From: Rik Ribbers To: "eppext@ietf.org" Thread-Topic: New draft for keyrelay available Thread-Index: AdArSKQ+n3FmCyCWSq6l2+OWlzutMwRfVugQAAJJBTAAATSlQA== Date: Fri, 30 Jan 2015 21:30:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.153] Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768B928C0A3kambx2SIDNlocal_" MIME-Version: 1.0 Archived-At: Subject: [eppext] FW: New draft for keyrelay available X-BeenThere: eppext@ietf.org 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: Fri, 30 Jan 2015 21:30:55 -0000 --_000_C80127C588F8F2409E2B535AF968B768B928C0A3kambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forgot to include the list.... sorry From: Rik Ribbers Sent: vrijdag 30 januari 2015 22:30 To: 'Santosh Kalsangrah' Subject: RE: New draft for keyrelay available Hello Santosh, Thx for the feedback. Here are my answers: 1) This draft uses the validated trusted EPP channel. According to RFC= 5734, section 8 this must be a TCP/TLS connection. The idea is here that a = registrar doesn't always know how or to whom the DNSSEC key material must b= e send. By using the registry EPP interface there is a secure and trusted p= ath. 2) In the draft we state that depending on the use case a server must = determine what elements of the data must be used for 1) validating the requ= est and 2) determining the registrar to relay the data to. For the keyrelay= usecase this is the authInfo element for 1) and for 2) the domainname is = used. 3) This is actually out-of scope for this specific draft. The mechanis= m is to send the command and if the server approves (return EPP code 1000)= the gaining registrar must assume the message is on the poll queue of the = losing registrar. There is a different draft which describes the process of= a secure domain transfer which describes the complete process (https://too= ls.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 ) 4) This depends on the policy of the registry. For us a registrar must= acknowledge the poll message what happens afterwards it out of our hands a= nd depends on the registrars. There are several issues (e.g. the registrar = is not always the DNS-operator) that are involved with the secure transfer = of a domainname that are not covered here. This draft focusses on relaying = the keymaterial from registrar 1 and 2. Again see the draft https://tools.= ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 for more informati= on. Kind regards, Rik From: Santosh Kalsangrah [mailto:santosh.kalsangrah@impetus.co.in] Sent: vrijdag 30 januari 2015 21:36 To: Rik Ribbers; eppext@ietf.org Subject: RE: New draft for keyrelay available Rik, Here is my feedback, (actually questions:)) 1. It seems it's assumed that all EPP messaging between registrar 1<-= >registry<->registrar 2 proposed in this draft is over secure transport. Is= that ok if either or both registrar(s) connects to registry over non-secur= e transport? 2. How is key information validated by receiving registrar that it is= what was sent by the other registrar. Or how is sender assured that key i= nformation would be sent as is to other end? Or this is not important? 3. How would gaining registrar be notified back that key info it has = sent is acknowledged/read by losing registrar. Or is it that gaining regist= rar need not to know? 4. In case if losing registrar does not support extension in this dra= ft, what will happen to key info? Thanks, Santosh K From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers Sent: Thursday, January 08, 2015 7:12 PM To: eppext@ietf.org Subject: [eppext] New draft for keyrelay available All, As you (may) have noticed we submitted a new version of the keyrelay draft.= In this draft we tried to solve all the open issues, remarks and feedback = we received. The major changes are: 1. Introducing the command, and thus seperating the data and the command. 2. Updated the Introduction, describing the general use of relay vs the intended use-case of relaying DNSSEC key data. 3. Restructuring the document to make it more inline with existing EPP extensions. In the end it has become a major rewrite and as always feedback is welcome. Kind regards, Rik Ribbers ________________________________ NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_C80127C588F8F2409E2B535AF968B768B928C0A3kambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Forgot = to include the list…. sorry

&n= bsp;

From: Rik Ribbers
Sent: vrijdag 30 januari 2015 22:30
To: 'Santosh Kalsangrah'
Subject: RE: New draft for keyrelay available

 

Hello Santosh,

 

Thx for= the feedback. Here are my answers:

&n= bsp;

= 1)      This draft uses the validated trusted EPP channel. According to RFC5734, s= ection 8 this must be a TCP/TLS connection. The idea is here that a registr= ar doesn’t always know how or to whom the DNSSEC key material must be send. By using the registry EPP interface = there is a secure and trusted path.

= 2)      In the draft we state that depending on the use case a server must determi= ne what elements of the data must be used for 1) validating the request and= 2) determining the registrar to relay the data to. For the keyrelay usecase this is  the authInfo element f= or 1) and for 2) the domainname is used.

= 3)      This is actually out-of scope for this specific draft. The mechanism is &n= bsp;to send the command and if the server approves (return EPP code 1000) t= he gaining registrar must assume the message is on the poll queue of the losing registrar. There is a different draft w= hich describes the process of a secure domain transfer which describes the = complete process (https://tools.ietf.org/html/draft-koch-dnsop-dnss= ec-operator-change-06 )

= 4)      This depends on the policy of the registry. For us a registrar must acknow= ledge the poll message what happens afterwards it out of our hands and depe= nds on the registrars. There are several issues (e.g. the registrar is not always the DNS-operator) that are involv= ed with the secure transfer of a domainname that are not covered here. This= draft focusses on relaying  the keymaterial from registrar 1 and 2. A= gain see the draft https://tools.ietf.org/html/draft-koch-dnsop-dnssec-operator-change-06 = for more information.

&n= bsp;

Kind re= gards,

Rik

 

From: Santosh Kalsangrah [mailto:santosh.kalsangrah@impetus.co.in]
Sent: vrijdag 30 januari 2015 21:36
To: Rik Ribbers; eppext@ietf.org<= /a>
Subject: RE: New draft for keyrelay available

 

Rik,

 

Here is my feedback, (actually questionsJ<= span lang=3D"EN-US" style=3D"font-size:10.5pt;color:#1F497D">)

 

1.       It see= ms it’s assumed that all EPP messaging between registrar 1<->re= gistry<->registrar 2 proposed in this draft is over secure transport.= Is that ok if either or both registrar(s) connects to registry over non-secure transport?

2.       How is= key information validated by receiving registrar that it is what was sent = by the  other registrar. Or how is sender assured that key information= would be sent as is to other end? Or this is not important?

3.       How wo= uld gaining registrar be notified back that key info it has sent is acknowl= edged/read by losing registrar. Or is it that gaining registrar need not to= know?

4.       In cas= e if losing registrar does not support extension in this draft, what will h= appen to key info?

 

Thanks,

Santosh K

 

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Rik Ribbers
Sent: Thursday, January 08, 2015 7:12 PM
To: eppext@ietf.org
Subject: [eppext] New draft for keyrelay available=

 

Al= l,

 

As= you (may) have noticed we submitted a new version of the keyrelay draft. I= n this draft we tried to solve all the open issues, remarks and feedback we= received.

 

Th= e major  changes are:

 

&n= bsp; 1.  Introducing the <relay> command, and thus seperating th= e data and

&n= bsp;      the command.

 

&n= bsp;  2.  Updated the Introduction, describing the general use of= relay vs

&n= bsp;      the intended use-case of relaying DNSSEC= key data.

 

&n= bsp;  3.  Restructuring the document to make it more inline with = existing

&n= bsp;      EPP extensions.

 

In= the end it has become a major rewrite and as always feedback is welcome.

 

Ki= nd regards,

Ri= k Ribbers

 







NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference.

--_000_C80127C588F8F2409E2B535AF968B768B928C0A3kambx2SIDNlocal_--

James,

 = ;

I’m = not an expert on the sunrise and claims requirements, but the wording seems= correct according the RPM requirements.

 = ;

Gr,

Rik

 <= /p>

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Gould, James
Sent: dinsdag 6 januari 2015 0:18
To: eppext@ietf.org
Subject: [eppext] draft-ietf-eppext-launchphase Support for a "= Claims Service" post the Claims Phase

 

All,

 

There was an issue raised privately in supporting cl= aims as a Claims Service post the Claims Phase.   According to section= 2.4.3 of the RPM Requirements, “...releases for Allocation or regist= ration such reserved domain name at any time following the start date of the Claims Period, such domain MUST be subject= to the Claims Services (as described in Section 3) for a period of ninety = (90) calendar days following the date Registry Operator releases such domai= n name for registration…”.  This means that support for the Claims Check Form needs to be revised to indica= te whether or not the Claims Create Form is needed for the domain name and = the use of the Claims Create Form should be supported in phases other than = “claims”.  There are no XML schema changes required to support this.  Please review and provide feedback= to the proposed revised language in the draft below to include in the next= version of the draft that will also include the Implementation Status sect= ion discussed at the IETF-91 EPPEXT meeting. 

 

Change 3.1.1 "Claims Check Form&quo= t; as follows:

 

   The Claims Check Form define=
s a new command called the Claims Check
   Command that is used to dete=
rmine whether or not there are any
   matching trademarks, in the =
specified launch phase, for each domain
   name passed in the command, that requires the use of the "Claims Create Form" 
   on a Domain Create Comman=
d.

 

   Instead of returning whether=
 the domain name is available, the Claims
   Check Command will return wh=
ether or not at least one matching
   trademark exists for the dom=
ain name, that requires the use of the 
   "Claims Create Form&=
quot; on a Domain Create Command. 

 

   <launch:name>  Co=
ntains the fully qualified name of the queried
       =
;    domain name.  This element MUST contain an "e=
xists" attribute
       =
;    whose value indicates if a matching trademark exists fo=
r the
       =
;    domain name that requires the use of the "Claim=
s Create Form" on a Domain Create Command.  
       =
;    A value of "1" (or "true") means th=
at a
       =
;    matching trademark does exist and that the "Cla=
ims Create Form" is required on 
       =
;    a Domain Create Command.  A

       =
;    value of "0" (or "false") means tha=
t a matching trademark


       =
;    does not exist or that the "Claims Create Form&=
quot; is NOT required on a Domain Create Command.

 

 

Change 3.3.2 "Claims Create Form&qu= ot; as follows:

 

<launch:phase>  SHOULD =
contain the value of "claims" to indicate the
       clai=
ms launch phase.  A value other than "claims" MAY be used=
 to 
pass the claims notice for domain name=
s outside of the claims phase. 

 

 

Based on the above revised language the following ma= y be done:

 

  1. During claims phase with a claims check command
    1. If domain has matching trademark 
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse
  1. During post claims phase with a claims check command
    1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark
      1. return exists=3Dtrue 
    1. else 
      1. return exists=3Dfalse 

 

  1. During claims phase with a create command 
    1. If domain has matching trademark 
      1. claims notice is required 
    1. else 
      1. claims notice is NOT required
  1. During post claims phase with a create command 
    2. <= /ol>
      1. If domain was released post claims phase start and is within 90 days of rel= ease and has matching trademark return 
        1. claims notice is required 
      1. else 
        1. claims notice is NOT required 

 

 

Thanks,

 

R= 12;

 

JG




James Gould
Distinguished Engineer
jgould@Verisign.com

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

Veri= signInc.com

 

“This message (including any attachmen= ts) is intended only for the use of the individual or entity to which it is= addressed, and may contain information that is non-public, proprietary, pr= ivileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If yo= u are not the intended recipient, you are hereby notified that any use, dis= semination, distribution, or copying of this communication is strictly proh= ibited. If you have received this message in error, notify sender immediately and delete this message immedi= ately.”