From rep.dot.nop@gmail.com Thu Sep 5 01:26:48 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAF021E8089 for ; Thu, 5 Sep 2013 01:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOg8Rm3sidPx for ; Thu, 5 Sep 2013 01:26:47 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8921F968B for ; Thu, 5 Sep 2013 01:26:47 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so1361513lbh.5 for ; Thu, 05 Sep 2013 01:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IKtcRJAfUsyn0Lpv7xYT+MyNyIdFJ4tHA2NC+7Q8tWo=; b=F08W9g6t+kMqK14bRdjhudx7pCbjnRNgG6pHNS3cvaNQypFgHvuSam00JZFE3s6pq0 rPr29lRU8X3apDF/xdBKPnatALo2MhMCEC5a3hUuZ3ojkLBL7jmxlhcgMgm0CqaDjdZ/ UCTJQYhEG1JZ9bqCdRHALCsoRraVrJQPZUy6nX4CNd9A7mY04bt8KgnSGhReWwqk13jt /YA7PzEJRanVNCziuSP0pnFairmi7Dy8qTlhXGo92KdhUwlk6brZVgbhV0602kRL+Zoz LofbeRDhabrsplnWkDSkP4EikCl3NtFrXwVQzeyGQ2DXKukaqBZTKWK6yk7U3BdKDC5u SUKg== MIME-Version: 1.0 X-Received: by 10.112.146.33 with SMTP id sz1mr6095045lbb.14.1378369606354; Thu, 05 Sep 2013 01:26:46 -0700 (PDT) Received: by 10.114.23.39 with HTTP; Thu, 5 Sep 2013 01:26:46 -0700 (PDT) In-Reply-To: <19F54F2956911544A32543B8A9BDE0750A23308F@NICS-EXCH2.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE0750A23308F@NICS-EXCH2.sbg.nic.at> Date: Thu, 5 Sep 2013 10:26:46 +0200 Message-ID: From: Bernhard Reutner-Fischer To: gustavo.lozano@icann.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alexander Mayrhofer , "tmch-tech@icann.org" , "provreg@ietf.org" Subject: Re: [provreg] Review of draft-lozano-tmch-func-spec-05 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 08:26:48 -0000 Hi, in http://tools.ietf.org/html/draft-lozano-tmch-func-spec-07#section-5.3.4 please s/TNC/TCN/g Thanks, On 23 April 2013 13:54, Alexander Mayrhofer wr= ote: > Hi, > > i've reviewed draft-lozano-tmch-func-spec, here are my comments: > > - Abstract: The text contains "Domain Name Registry" as well as "domain n= ame Registry" - is this intentional? > > - Introduction: Why is "Data Formats" capitalized? > > - 5.2.1 / 5.2.2 (Sunrise domain registration): I understand that "registr= ation" in the sense of executing a sunrise "create" command could either be= direct "Allocation", or the creation of an "Application". Some text that c= larifies these options would be good, because "registration" could be mis-i= nterpreted as "direct, immediate allocation". > > - page 27 (5.2.3): Theres a broken literal "xref" in bullet 4. > > - 6.1 (DNL List): I understand that the DNL is always a "full" list, cont= aining all DNLs that match a PRM? Clarifying text would be appreciated here= . > > - 6.2 (SMD revocation): I do assume it would always include all revoked S= MDs. Also "Version 1 MUST always be present" could maybe be changed to "MU= ST be set to '1' for this version of the specification".. Same in Section 6= .3 and Section 6.3.1 > > - 6.3 (LORDN file): should a LORDN file contain only domains effectively = allocated since the last accepted LORDN file, or should it always contain t= he domains of the current day, or should it contain all domains allocated s= ince the start of the Sunrise period? I suppose either the second option -= some text clarifying this would be good (unless i've missed it?). > > - 6.3: : mention that the A-Label is to be used, eg. "The = domain name that was allocated in A-Label representation". > > - Section 6.3.1: The "first line" specification of the LORDN log file has= a missing comma between and >LORDN file crea= tion datetime>. > > - 6.3.1.1: I understand that a single "err" class outcome in the LORDN lo= gfile indicates that the whole file was rejected, and the Registry shall re= peat with a corrected file? Clarification would be good here as well.. > > > - 6.3.1.1: I understand that since "ROID notified earlier" is just a warn= ing, a LORDN file can effectively contain domain names that have been repor= ted earlier wihout processing to fail... > > tia, > > Alex > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From jay@nzrs.net.nz Thu Sep 5 15:16:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7521E80E6 for ; Thu, 5 Sep 2013 15:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbJ4YUyhtZzP for ; Thu, 5 Sep 2013 15:16:13 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 666D521E80BD for ; Thu, 5 Sep 2013 15:16:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 925544B77CD for ; Fri, 6 Sep 2013 10:16:08 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5QRebfZ-udl for ; Fri, 6 Sep 2013 10:16:00 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 2C7684B7779 for ; Fri, 6 Sep 2013 10:14:47 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4FD402E2-947C-40BC-BC36-73A20EBBF370@nzrs.net.nz> Date: Fri, 6 Sep 2013 10:14:49 +1200 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [provreg] dnsxml - A standard XML representation of DNS data X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:16:18 -0000 Apologies if you've seen and ignored this on other lists, but it's not = getting any feedback on dnsop or dnsext, which I suspect is because few = people there understand dns-schema well enough to comment. So this is a draft of a standard XML representation of DNS data. It = does not attempt to replicate the DNS protocol, just the RRs, and is as = comprehensive as possible. I think the registry community is likely to = find this useful. Jay A new version of I-D, draft-daley-dnsxml-00.txt has been successfully submitted by Jay Daley and posted to the IETF repository. Filename: draft-daley-dnsxml Revision: 00 Title: dnsxml - A standard XML representation of DNS data Creation date: 2013-07-31 Group: Individual Submission Number of pages: 54 URL: = http://www.ietf.org/internet-drafts/draft-daley-dnsxml-00.txt Status: http://datatracker.ietf.org/doc/draft-daley-dnsxml Htmlized: http://tools.ietf.org/html/draft-daley-dnsxml-00 Abstract: This memo describes a syntax for encoding DNS Resource Records in XML, and a schema to define that syntax written in XML Schema. It can be used to represent all DNS RDATA. This can be used by diverse applications as a common format. DNS Resource Records are represented as XML elements with the name of the element taken from the mnemonic used to represent the DNS Resource Record in presentation format. The RDATA is represented as XML attributes or content of the element. The attribute names are taken from the RDATA field names specified in the normative RFC. --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From shollenbeck@verisign.com Mon Sep 9 04:33:44 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2119D21F8F97 for ; Mon, 9 Sep 2013 04:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRhpOq-2L4bd for ; Mon, 9 Sep 2013 04:33:31 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0236221F8DE3 for ; Mon, 9 Sep 2013 04:33:27 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUi2yB/I/JuAeji15P7JhFnXpP4+pvXzw@postini.com; Mon, 09 Sep 2013 04:33:31 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r89BXRcH007840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 07:33:27 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 9 Sep 2013 07:33:26 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: EPP Extensions Stuff: Current Status Thread-Index: Ac6tUGXKr0I/r3jlSHel/WdzPkwrGA== Date: Mon, 9 Sep 2013 11:33:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4925C891@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [provreg] EPP Extensions Stuff: Current Status X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:33:44 -0000 I wrote a draft working group charter and shared it with Pete recently. As = soon as he confirms that he's OK with the general direction (new document t= o define policy and procedures for an extensions registry plus work on a sm= all number of existing extension drafts) I'll share it with this list for r= eview and refinement. Note that me sending it to Pete is not an attempt to = get approval of anything. I just want to be sure that he's comfortable with= the approach before we all put in the effort to come up with something mor= e formal for him to review. Scott From jay@nzrs.net.nz Thu Sep 12 16:37:28 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D030011E8244 for ; Thu, 12 Sep 2013 16:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so1xwiNDcX+O for ; Thu, 12 Sep 2013 16:37:23 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9089611E80EE for ; Thu, 12 Sep 2013 16:37:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5FADD4B7B54 for ; Fri, 13 Sep 2013 11:36:50 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Id-a4ThNySho for ; Fri, 13 Sep 2013 11:36:42 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A6E894B7651 for ; Fri, 13 Sep 2013 11:36:42 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> Date: Fri, 13 Sep 2013 11:36:48 +1200 To: "provreg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 23:37:28 -0000 I have some questions for you.=20 I'm aware of two separate approaches to registry locking 1. Two-factor authentication of change requests, where the registrant = is expected to hold one factor and the registrar pass it through. Using = something like SecureID. 2. Intervention, where the registry is expected to verify a change = request out-of-band (or the registrar pre-empts this with a out-of-band = unlock request). My questions are: Q1: Does anyone have an EPP extension for handling 1 above that they = would be willing to put forward for wider use? Q2: Is there any role for EPP in 2 above? thanks in advance for anyone taking the time to reply! cheers Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From shollenbeck@verisign.com Fri Sep 13 04:35:21 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DFC11E80F7 for ; Fri, 13 Sep 2013 04:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVZc4K4ZbaJ4 for ; Fri, 13 Sep 2013 04:35:16 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0133711E8162 for ; Fri, 13 Sep 2013 04:35:08 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUjL4a49ueVnAfbE6/sINCpbl0tCuoSDM@postini.com; Fri, 13 Sep 2013 04:35:13 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8DBZ4vr017262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Sep 2013 07:35:04 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Sep 2013 07:34:37 -0400 From: "Hollenbeck, Scott" To: Jay Daley , "provreg@ietf.org" Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOsBD/ayJ8KeHrk0OZqDKGxO/VqJnDiWTw Date: Fri, 13 Sep 2013 11:35:03 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49261C9B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> In-Reply-To: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 11:35:22 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Jay Daley > Sent: Thursday, September 12, 2013 7:37 PM > To: provreg@ietf.org > Subject: [provreg] Registry lock - two-factor or intervention >=20 > I have some questions for you. >=20 > I'm aware of two separate approaches to registry locking >=20 > 1. Two-factor authentication of change requests, where the registrant > is expected to hold one factor and the registrar pass it through. > Using something like SecureID. >=20 > 2. Intervention, where the registry is expected to verify a change > request out-of-band (or the registrar pre-empts this with a out-of-band > unlock request). >=20 > My questions are: >=20 > Q1: Does anyone have an EPP extension for handling 1 above that they > would be willing to put forward for wider use? > Q2: Is there any role for EPP in 2 above? I'm not aware of an extension for 1 or an EPP role for 2, Jay. Scott From provreg@contact.dotandco.com Fri Sep 13 06:06:51 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DBE11E81F0 for ; Fri, 13 Sep 2013 06:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRbOa6vlOHAS for ; Fri, 13 Sep 2013 06:06:47 -0700 (PDT) Received: from mail.dotandco.com (triglav.dotandco.com [194.242.114.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFAD11E81ED for ; Fri, 13 Sep 2013 06:06:46 -0700 (PDT) Received: from triglav.dotandco.com (localhost.localdomain [127.0.0.1]) by mail.dotandco.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r8DD4goC016002; Fri, 13 Sep 2013 15:04:42 +0200 Received: (from patrick@localhost) by triglav.dotandco.com (8.14.3/8.14.3/Submit) id r8DD4fBo016000; Fri, 13 Sep 2013 15:04:41 +0200 X-Authentication-Warning: triglav.dotandco.com: patrick set sender to provreg@contact.dotandco.com using -f Date: Fri, 13 Sep 2013 15:04:40 +0200 From: Patrick Mevzek To: "provreg@ietf.org" Message-ID: <20130913130440.GA11402@home.patoche.org> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> Organization: Dot And Co User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.dotandco.com [127.0.0.1]); Fri, 13 Sep 2013 15:04:42 +0200 (CEST) Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2013 13:06:51 -0000 Jay Daley 2013-09-13 01:38 > 1. Two-factor authentication of change requests, where the registrant is expected to hold one factor and the registrar pass it through. Using something like SecureID. > > 2. Intervention, where the registry is expected to verify a change request out-of-band (or the registrar pre-empts this with a out-of-band unlock request). > > My questions are: > > Q1: Does anyone have an EPP extension for handling 1 above that they would be willing to put forward for wider use? FWIW I've implemented a VeriSign "Two Factor Auth" extension that unfortunately I do not find now anymore on http://www.verisigninc.com/en_US/products-and-services/domain-name-services/registry-products/epp-sdk/index.xhtml so you have the source instead: https://metacpan.org/source/PMEVZEK/Net-DRI-0.96_05/lib/Net/DRI/Protocol/EPP/Extensions/VeriSign/TwoFactorAuth.pm It covers two-factor auth, but maybe more for registrar two-factor auth instead of registrant two-factor auth. This seems however to be covered by a patent: http://www.faqs.org/patents/app/20120174198 HTH, -- Patrick Mevzek From zhoulinlin@cnnic.cn Mon Sep 16 22:30:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC64311E8300 for ; Mon, 16 Sep 2013 22:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol5V-J0ZCPVy for ; Mon, 16 Sep 2013 22:30:23 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 6D9B911E8214 for ; Mon, 16 Sep 2013 22:30:22 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 17 Sep 2013 13:30:05 +0800 From: "Linlin Zhou" To: "'Hollenbeck, Scott'" , References: <831693C2CDA2E849A7D7A712B24E257F4925C891@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4925C891@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 17 Sep 2013 13:30:02 +0800 Message-ID: <018d01ceb366$f710c2f0$e53248d0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6tUGXKr0I/r3jlSHel/WdzPkwrGAGFnCAg Content-Language: zh-cn Subject: Re: [provreg] EPP Extensions Stuff: Current Status X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 05:30:28 -0000 +1 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf > Of Hollenbeck, Scott > Sent: Monday, September 09, 2013 7:33 PM > To: provreg@ietf.org > Subject: [provreg] EPP Extensions Stuff: Current Status > > I wrote a draft working group charter and shared it with Pete recently. As soon > as he confirms that he's OK with the general direction (new document to define > policy and procedures for an extensions registry plus work on a small number of > existing extension drafts) I'll share it with this list for review and refinement. > Note that me sending it to Pete is not an attempt to get approval of anything. I > just want to be sure that he's comfortable with the approach before we all put > in the effort to come up with something more formal for him to review. > > Scott > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From shollenbeck@verisign.com Wed Sep 18 04:21:29 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D2711E822B for ; Wed, 18 Sep 2013 04:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkcCoL+5X44o for ; Wed, 18 Sep 2013 04:21:24 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 983DA11E8230 for ; Wed, 18 Sep 2013 04:21:02 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUjmMl1hExasoJFrTobhJKR68t8veAugG@postini.com; Wed, 18 Sep 2013 04:21:05 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8IBKqLK017714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Sep 2013 07:20:55 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 07:20:24 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: Ac60YSDD3AqH2WpnRAOeb5Tvgs6iew== Date: Wed, 18 Sep 2013 11:20:51 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 11:21:29 -0000 I recently closed a conversation with Applications Area Director Pete Resni= ck to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conc= ept in principal. I'm including the text of the proposed charter that I sha= red with Pete and I'd like to ask others to review it and share feedback as= appropriate. If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting. I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I = don't think this will be a difficult task because cloning an existing regis= try is a perfectly reasonable approach, but someone needs to do the work. I= 'm willing to co-chair (if you all will have me) if we form a working group= , and thus it would be best if we find other volunteers to write documents. Scott ---------- Proposed Charter for EPP Extensions (eppext) Working Group The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May = 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) i= n August 2009. It is the standard domain name provisioning protocol for gen= eric top-level domain name registries that operate under the auspices of th= e Internet Corporation for Assigned Names and Numbers (ICANN). It is also u= sed by a number of country code top-level domain registries. Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size fits = all" provisioning protocol, so the provreg working group made a conscious d= ecision to focus on a minimal set of common functionality. EPP was designed= to be extensible to allow additional features to be specified on an "as ne= eded" basis. Guidelines for extending EPP were published as Informational R= FC 3735 in March 2004. The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community = found itself facing a situation in which multiple extensions were being dev= eloped by different registries to solve the same basic problems, such as re= gistering internationalized domain name variants. ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of = non-standard extension duplication is only expected to become worse. The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps: 1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process. 2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding: draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp= -keyrelay/) draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/= ) draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-la= unchphase/) draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-s= md/) draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md. When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group. Milestones: TBD Extensions registry document to IESG TBD draft-gieben-epp-keyrelay to IESG TBD draft-obispo-epp-idn to IESG TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG From michael@mwyoung.ca Wed Sep 18 05:01:53 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA5311E8243 for ; Wed, 18 Sep 2013 05:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeRzlQSx6ZYU for ; Wed, 18 Sep 2013 05:01:47 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2769311E8253 for ; Wed, 18 Sep 2013 05:01:41 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so5605046lab.12 for ; Wed, 18 Sep 2013 05:01:40 -0700 (PDT) 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:cc:content-type; bh=ZjhfBGLDh30j0UB1q0pgM8dkfGKVy8NqbWZHiohNxb8=; b=WeMXa7fduRjyheX3RR5Zo3gLkNouPlm+7r1+bxmgJjgqbGBO1fVoIUX0GSSlCYCYIG RdR0nEDOtDLElfCgb/4sysQc/Qe73qEL7ayYI4cXMQfr+Q+XsgkrLyWS+NSd3cRiOsKj r5ZvDo8FqxwOXt77mcdsYOrHnCxvsPNYZ2XdWIi0fyq4V6NdY+bDHf7+5ronamwrIGXj WcsnuZOE5RW1eJbAMNFVdygD6VsZ4/If79gozgqlJlYvYhPmJ4wrbs9vAx8wuCN7OL6C 8ApAiujRCsMowXfEZ0gHH+4WWIbJ6qPufcWkfzoUXpYF39cWB0QbQD136qEm/CpWrsSa 2I2Q== X-Gm-Message-State: ALoCoQkJQ5t4zx45WqMPET5IhBM39xhCSIr8kJCazB7VBRC8OYU+SQgUeBNnK6e2D/z52WnPQbty MIME-Version: 1.0 X-Received: by 10.152.10.99 with SMTP id h3mr35003811lab.13.1379505700149; Wed, 18 Sep 2013 05:01:40 -0700 (PDT) Received: by 10.114.78.196 with HTTP; Wed, 18 Sep 2013 05:01:40 -0700 (PDT) Received: by 10.114.78.196 with HTTP; Wed, 18 Sep 2013 05:01:40 -0700 (PDT) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Sep 2013 08:01:40 -0400 Message-ID: From: Michael Young To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a1132f26a392c5f04e6a733ad Cc: provreg@ietf.org Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:01:53 -0000 --001a1132f26a392c5f04e6a733ad Content-Type: text/plain; charset=ISO-8859-1 Scott I'm willing to participate and help write, Michael Young On 2013-09-18 7:21 AM, "Hollenbeck, Scott" wrote: > I recently closed a conversation with Applications Area Director Pete > Resnick to see what he thought about a narrowly-focused charter for a > working group to develop a registry for EPP extensions. Pete has agreed > with the concept in principal. I'm including the text of the proposed > charter that I shared with Pete and I'd like to ask others to review it and > share feedback as appropriate. > > If we have enough support for a proposed charter Pete is willing to > entertain a chartering request. If there's more to discuss we can ask about > scheduling a BOF during the Vancouver meeting. > > I've got one specific question: are people able and willing to write a > draft (or drafts) that describe(s) the registry and registration > procedures? I don't think this will be a difficult task because cloning an > existing registry is a perfectly reasonable approach, but someone needs to > do the work. I'm willing to co-chair (if you all will have me) if we form a > working group, and thus it would be best if we find other volunteers to > write documents. > > Scott > ---------- > Proposed Charter for EPP Extensions (eppext) Working Group > > The Extensible Provisioning Protocol (EPP) was a work product of the IETF > Provisioning Registry Protocol (provreg) working group. EPP was published > as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March > 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in > May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and > 5734) in August 2009. It is the standard domain name provisioning protocol > for generic top-level domain name registries that operate under the > auspices of the Internet Corporation for Assigned Names and Numbers > (ICANN). It is also used by a number of country code top-level domain > registries. > > Domain name registries implement a variety of business models. The > difference in these models made it very difficult to come up with a "one > size fits all" provisioning protocol, so the provreg working group made a > conscious decision to focus on a minimal set of common functionality. EPP > was designed to be extensible to allow additional features to be specified > on an "as needed" basis. Guidelines for extending EPP were published as > Informational RFC 3735 in March 2004. > > The provreg working group was chartered to develop EPP, but not these > additional extensions. The working group was closed in 2004 after producing > a number of Proposed Standard specifications. As registries began to > implement and deploy EPP the need for extensions became real, and the user > community found itself facing a situation in which multiple extensions were > being developed by different registries to solve the same basic problems, > such as registering internationalized domain name variants. > > ICANN is now well into a program to delegate a large number of new generic > top-level domains. EPP will be used to provision those domains, and new > registry operators are expected to develop additional protocol extensions. > With no way to coordinate the development of these extensions, the problem > of non-standard extension duplication is only expected to become worse. > > The goal of the EPP Extensions (eppext) working group is to develop an > IANA registry of EPP extensions and procedures to review specifications for > inclusion in the registry. It will accomplish this goal in two steps: > > 1. Develop a Proposed Standard specification for the registration and > review of EPP extensions. There is no current Internet Draft that describes > this process. > > 2. Test the extension registration process by developing a small number of > standards track extensions that currently exist in Internet Draft form, > including: > > draft-gieben-epp-keyrelay ( > http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) > > draft-obispo-epp-idn ( > http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) > > draft-tan-epp-launchphase ( > http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) > draft-lozano-tmch-smd ( > https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) > draft-tan-epp-launchphase has a normative dependency on > draft-lozano-tmch-smd. > > When these milestones have been completed the working group will consider > rechartering to explore the issue of ongoing extension development and > standardization. Modifications to EPP itself are explicitly out of scope > for this working group. > > Milestones: > > TBD Extensions registry document to IESG > > TBD draft-gieben-epp-keyrelay to IESG > > TBD draft-obispo-epp-idn to IESG > > TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > --001a1132f26a392c5f04e6a733ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Scott I'm willing to participate and help write,

Michael Young

On 2013-09-18 7:21 AM, "Hollenbeck, Scott&q= uot; <shollenbeck@verisign.c= om> wrote:
I recently closed a conversation with Applications Area Director Pete Resni= ck to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conc= ept in principal. I'm including the text of the proposed charter that I= shared with Pete and I'd like to ask others to review it and share fee= dback as appropriate.

If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about sc= heduling a BOF during the Vancouver meeting.

I've got one specific question: are people able and willing to write a = draft (or drafts) that describe(s) the registry and registration procedures= ? I don't think this will be a difficult task because cloning an existi= ng registry is a perfectly reasonable approach, but someone needs to do the= work. I'm willing to co-chair (if you all will have me) if we form a w= orking group, and thus it would be best if we find other volunteers to writ= e documents.

Scott
----------
Proposed Charter for EPP Extensions (eppext) Working Group

The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May = 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) i= n August 2009. It is the standard domain name provisioning protocol for gen= eric top-level domain name registries that operate under the auspices of th= e Internet Corporation for Assigned Names and Numbers (ICANN). It is also u= sed by a number of country code top-level domain registries.

Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size = fits all" provisioning protocol, so the provreg working group made a c= onscious decision to focus on a minimal set of common functionality. EPP wa= s designed to be extensible to allow additional features to be specified on= an "as needed" basis. Guidelines for extending EPP were publishe= d as Informational RFC 3735 in March 2004.

The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community = found itself facing a situation in which multiple extensions were being dev= eloped by different registries to solve the same basic problems, such as re= gistering internationalized domain name variants.

ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of = non-standard extension duplication is only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps:

1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process.

2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding:

draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/dr= aft-gieben-epp-keyrelay/)

draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo= -epp-idn/)

draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/dr= aft-tan-epp-launchphase/)
draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lo= zano-tmch-smd/)
draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md.

When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group.

Milestones:

TBD Extensions registry document to IESG

TBD draft-gieben-epp-keyrelay to IESG

TBD draft-obispo-epp-idn to IESG

TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg
--001a1132f26a392c5f04e6a733ad-- From JGould@verisign.com Wed Sep 18 05:17:37 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F21C11E8277 for ; Wed, 18 Sep 2013 05:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvk1NSTHkJ4e for ; Wed, 18 Sep 2013 05:17:33 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 1733D11E8268 for ; Wed, 18 Sep 2013 05:17:26 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUjmZ1Ly0sNwfP99LXRywTZiTn3J99iKl@postini.com; Wed, 18 Sep 2013 05:17:28 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8ICHLaq013956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 08:17:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 08:16:53 -0400 From: "Gould, James" To: Michael Young , "Hollenbeck, Scott" Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOtGjpiOvLq7nihUW0B3qiq1srzQ== Date: Wed, 18 Sep 2013 12:17:20 +0000 Message-ID: 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.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CE5F11C44DDFBjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:17:37 -0000 --_004_CE5F11C44DDFBjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CE5F11C44DDFBjgouldverisigncom_" --_000_CE5F11C44DDFBjgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, I too am willing to participate and help write, so +1. -- JG [cid:71449A38-A6AD-4166-B08F-196836E09509] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Michael Young > Date: Wednesday, September 18, 2013 8:01 AM To: "Hollenbeck, Scott" > Cc: EPP Provreg > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working= Group Scott I'm willing to participate and help write, Michael Young On 2013-09-18 7:21 AM, "Hollenbeck, Scott" > wrote: I recently closed a conversation with Applications Area Director Pete Resni= ck to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conc= ept in principal. I'm including the text of the proposed charter that I sha= red with Pete and I'd like to ask others to review it and share feedback as= appropriate. If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting. I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I = don't think this will be a difficult task because cloning an existing regis= try is a perfectly reasonable approach, but someone needs to do the work. I= 'm willing to co-chair (if you all will have me) if we form a working group= , and thus it would be best if we find other volunteers to write documents. Scott ---------- Proposed Charter for EPP Extensions (eppext) Working Group The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May = 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) i= n August 2009. It is the standard domain name provisioning protocol for gen= eric top-level domain name registries that operate under the auspices of th= e Internet Corporation for Assigned Names and Numbers (ICANN). It is also u= sed by a number of country code top-level domain registries. Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size fits = all" provisioning protocol, so the provreg working group made a conscious d= ecision to focus on a minimal set of common functionality. EPP was designed= to be extensible to allow additional features to be specified on an "as ne= eded" basis. Guidelines for extending EPP were published as Informational R= FC 3735 in March 2004. The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community = found itself facing a situation in which multiple extensions were being dev= eloped by different registries to solve the same basic problems, such as re= gistering internationalized domain name variants. ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of = non-standard extension duplication is only expected to become worse. The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps: 1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process. 2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding: draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp= -keyrelay/) draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/= ) draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-la= unchphase/) draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-s= md/) draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md. When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group. Milestones: TBD Extensions registry document to IESG TBD draft-gieben-epp-keyrelay to IESG TBD draft-obispo-epp-idn to IESG TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_CE5F11C44DDFBjgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1E2AA2979151D24994D2A614DD4971E8@verisign.com> Content-Transfer-Encoding: quoted-printable
Scott,

I too am willing to participate and help write, so +1.  

-- 

 

JG

 

 

= James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

= VerisignInc.com


From: Michael Young <michael@mwyoung.ca>
Date: Wednesday, September 18, 2013= 8:01 AM
To: "Hollenbeck, Scott" &= lt;shollenbeck@verisign.com= >
Cc: EPP Provreg <provreg@ietf.org>
Subject: Re: [provreg] Proposed Cha= rter for EPP Extensions (eppext) Working Group

Scott I'm willing to participate and help write,

Michael Young

On 2013-09-18 7:21 AM, "Hollenbeck, Scott&q= uot; <shollenbeck@verisign.c= om> wrote:
I recently closed a conversation with Applications Area Director Pete Resni= ck to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conc= ept in principal. I'm including the text of the proposed charter that I shared with Pete and I'd like to a= sk others to review it and share feedback as appropriate.

If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting.

I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I = don't think this will be a difficult task because cloning an existing regis= try is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will= have me) if we form a working group, and thus it would be best if we find = other volunteers to write documents.

Scott
----------
Proposed Charter for EPP Extensions (eppext) Working Group

The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69= ; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard= domain name provisioning protocol for generic top-level domain name regist= ries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is = also used by a number of country code top-level domain registries.

Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size = fits all" provisioning protocol, so the provreg working group made a c= onscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additi= onal features to be specified on an "as needed" basis. Guidelines= for extending EPP were published as Informational RFC 3735 in March 2004.<= br>
The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community found itself facing a situation in whi= ch multiple extensions were being developed by different registries to solv= e the same basic problems, such as registering internationalized domain nam= e variants.

ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of non-standard extension duplication is = only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps:

1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process.

2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding:

draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/dr= aft-gieben-epp-keyrelay/)

draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo= -epp-idn/)

draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/dr= aft-tan-epp-launchphase/)
draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lo= zano-tmch-smd/)
draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md.

When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group.

Milestones:

TBD Extensions registry document to IESG

TBD draft-gieben-epp-keyrelay to IESG

TBD draft-obispo-epp-idn to IESG

TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG


_______________________________________________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg
 --_000_CE5F11C44DDFBjgouldverisigncom_-- --_004_CE5F11C44DDFBjgouldverisigncom_ Content-Type: image/png; name="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74.png" Content-Description: 3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74.png Content-Disposition: inline; filename="3CA91A0B-A6C1-43A5-AC92-8E23C9AD1B74.png"; size=4109; creation-date="Wed, 18 Sep 2013 12:17:20 GMT"; modification-date="Wed, 18 Sep 2013 12:17:20 GMT" Content-ID: <71449A38-A6AD-4166-B08F-196836E09509> 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_CE5F11C44DDFBjgouldverisigncom_-- From alexander.mayrhofer@nic.at Wed Sep 18 05:19:38 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6FD11E8238 for ; Wed, 18 Sep 2013 05:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVdsrHLrSe1S for ; Wed, 18 Sep 2013 05:19:34 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9D60A11E827B for ; Wed, 18 Sep 2013 05:19:06 -0700 (PDT) Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.49 ; Wed, 18 Sep 2013 14:19:04 +0200 Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0158.001; Wed, 18 Sep 2013 14:19:03 +0200 From: Alexander Mayrhofer To: "Gould, James" , Michael Young , "Hollenbeck, Scott" Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOtGkfjI5bbWPtuUelqj7DKznbQ5nLaZ8A Date: Wed, 18 Sep 2013 12:19:02 +0000 Message-ID: <19F54F2956911544A32543B8A9BDE0750A319E9A@NICS-EXCH2.sbg.nic.at> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.10.0.163] Content-Type: multipart/related; boundary="_004_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_"; type="multipart/alternative" MIME-Version: 1.0 X-XWALL-BCKS: auto Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:19:38 -0000 --_004_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_ Content-Type: multipart/alternative; boundary="_000_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_" --_000_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same for me. I'm willing to write and review. Alex Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftrag = von Gould, James Gesendet: Mittwoch, 18. September 2013 14:17 An: Michael Young; Hollenbeck, Scott Cc: provreg@ietf.org Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working= Group Scott, I too am willing to participate and help write, so +1. -- JG [cid:image001.png@01CEB47A.05F27A70] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Michael Young > Date: Wednesday, September 18, 2013 8:01 AM To: "Hollenbeck, Scott" > Cc: EPP Provreg > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working= Group Scott I'm willing to participate and help write, Michael Young On 2013-09-18 7:21 AM, "Hollenbeck, Scott" > wrote: I recently closed a conversation with Applications Area Director Pete Resni= ck to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conc= ept in principal. I'm including the text of the proposed charter that I sha= red with Pete and I'd like to ask others to review it and share feedback as= appropriate. If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting. I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I = don't think this will be a difficult task because cloning an existing regis= try is a perfectly reasonable approach, but someone needs to do the work. I= 'm willing to co-chair (if you all will have me) if we form a working group= , and thus it would be best if we find other volunteers to write documents. Scott ---------- Proposed Charter for EPP Extensions (eppext) Working Group The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May = 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) i= n August 2009. It is the standard domain name provisioning protocol for gen= eric top-level domain name registries that operate under the auspices of th= e Internet Corporation for Assigned Names and Numbers (ICANN). It is also u= sed by a number of country code top-level domain registries. Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size fits = all" provisioning protocol, so the provreg working group made a conscious d= ecision to focus on a minimal set of common functionality. EPP was designed= to be extensible to allow additional features to be specified on an "as ne= eded" basis. Guidelines for extending EPP were published as Informational R= FC 3735 in March 2004. The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community = found itself facing a situation in which multiple extensions were being dev= eloped by different registries to solve the same basic problems, such as re= gistering internationalized domain name variants. ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of = non-standard extension duplication is only expected to become worse. The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps: 1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process. 2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding: draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp= -keyrelay/) draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/= ) draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-la= unchphase/) draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-s= md/) draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md. When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group. Milestones: TBD Extensions registry document to IESG TBD draft-gieben-epp-keyrelay to IESG TBD draft-obispo-epp-idn to IESG TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Same for m= e. I’m willing to write and review.

 = ;

Alex<= /o:p>

 = ;

 = ;

Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftrag von Gould, James
Gesendet: Mittwoch, 18. September 2013 14:17
An: Michael Young; Hollenbeck, Scott
Cc: provreg@ietf.org
Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) = Working Group

 

Scott,

 

I too am willing to partici= pate and help write, so +1.  

 

-- 

 

JG

 

 

James Gould

Principal Software Engineer=

jgo= uld@verisign.com

 

703-948-3271 (Office)=

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

 

From: Michael Young <michael@mwyoung.ca>
Date: Wednesday, September 18, 2013 8:01 AM
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: EPP Provreg <provreg@ietf= .org>
Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) = Working Group

 

Scott I'm willing to participate and help write= ,

Michael Young

On 2013-09-18 7:21 AM, &quo= t;Hollenbeck, Scott" <s= hollenbeck@verisign.com> wrote:

I recently closed a convers= ation with Applications Area Director Pete Resnick to see what he thought a= bout a narrowly-focused charter for a working group to develop a registry for EPP extensions. Pete has agreed with the concept in princip= al. I'm including the text of the proposed charter that I shared with Pete = and I'd like to ask others to review it and share feedback as appropriate.<= br>
If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting.

I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I = don't think this will be a difficult task because cloning an existing regis= try is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will= have me) if we form a working group, and thus it would be best if we find = other volunteers to write documents.

Scott
----------
Proposed Charter for EPP Extensions (eppext) Working Group

The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69= ; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard= domain name provisioning protocol for generic top-level domain name regist= ries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is = also used by a number of country code top-level domain registries.

Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size = fits all" provisioning protocol, so the provreg working group made a c= onscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additi= onal features to be specified on an "as needed" basis. Guidelines= for extending EPP were published as Informational RFC 3735 in March 2004.<= br>
The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community found itself facing a situation in whi= ch multiple extensions were being developed by different registries to solv= e the same basic problems, such as registering internationalized domain nam= e variants.

ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. Wit= h no way to coordinate the development of these extensions, the problem of non-standard extension duplication is = only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps:

1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process.

2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, inc= luding:

draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/dr= aft-gieben-epp-keyrelay/)

draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo= -epp-idn/)

draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/dr= aft-tan-epp-launchphase/)
draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lo= zano-tmch-smd/)
draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md.

When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group.

Milestones:

TBD Extensions registry document to IESG

TBD draft-gieben-epp-keyrelay to IESG

TBD draft-obispo-epp-idn to IESG

TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG


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

--_000_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_-- --_004_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Wed, 18 Sep 2013 12:19:02 GMT"; modification-date="Wed, 18 Sep 2013 12:19: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_19F54F2956911544A32543B8A9BDE0750A319E9ANICSEXCH2sbgnic_-- From lem@isc.org Wed Sep 18 05:40:26 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ADA11E826C for ; Wed, 18 Sep 2013 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhF2q8CxSA4i for ; Wed, 18 Sep 2013 05:40:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0E011E8264 for ; Wed, 18 Sep 2013 05:40:25 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id AAFBEC94AC; Wed, 18 Sep 2013 12:40:14 +0000 (UTC) (envelope-from lem@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379508025; bh=HS9cLJLwg9ryY5whJUHERfKeCq5T6OrCo6qoL/SklDQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FupDf44TsInDis6E523UIcPD5Zj1GJ08FRCKugaTLI65qfqpt3g5Ya2bu90ahi45h nh/xDNntTB2qC9YhPyZXixW2uzgtH4cIb1Ce+m3U9qoN1m7nHEBlsk7HWKrN++rShA +oo3KQXmvkksAsrp7TkNse0leLQkPG8wuFbR5LCY= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 12:40:14 +0000 (UTC) (envelope-from lem@isc.org) Received: from lembook.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 42AE2216C25; Wed, 18 Sep 2013 12:40:14 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Sep 2013 08:40:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D359B6C-71E2-43B1-AE8F-21FA1B6F9E72@isc.org> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1283) X-DCC--Metrics: post.isc.org; whitelist Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:40:26 -0000 I'm willing to participate, specially writing. Best regards -lem On Sep 18, 2013, at 7:20 AM, Hollenbeck, Scott wrote: > I recently closed a conversation with Applications Area Director Pete = Resnick to see what he thought about a narrowly-focused charter for a = working group to develop a registry for EPP extensions. Pete has agreed = with the concept in principal. I'm including the text of the proposed = charter that I shared with Pete and I'd like to ask others to review it = and share feedback as appropriate. >=20 > If we have enough support for a proposed charter Pete is willing to = entertain a chartering request. If there's more to discuss we can ask = about scheduling a BOF during the Vancouver meeting. >=20 > I've got one specific question: are people able and willing to write a = draft (or drafts) that describe(s) the registry and registration = procedures? I don't think this will be a difficult task because cloning = an existing registry is a perfectly reasonable approach, but someone = needs to do the work. I'm willing to co-chair (if you all will have me) = if we form a working group, and thus it would be best if we find other = volunteers to write documents. >=20 > Scott > ---------- > Proposed Charter for EPP Extensions (eppext) Working Group >=20 > The Extensible Provisioning Protocol (EPP) was a work product of the = IETF Provisioning Registry Protocol (provreg) working group. EPP was = published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) = in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, = and 4934) in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, = 5732, 5733, and 5734) in August 2009. It is the standard domain name = provisioning protocol for generic top-level domain name registries that = operate under the auspices of the Internet Corporation for Assigned = Names and Numbers (ICANN). It is also used by a number of country code = top-level domain registries. >=20 > Domain name registries implement a variety of business models. The = difference in these models made it very difficult to come up with a "one = size fits all" provisioning protocol, so the provreg working group made = a conscious decision to focus on a minimal set of common functionality. = EPP was designed to be extensible to allow additional features to be = specified on an "as needed" basis. Guidelines for extending EPP were = published as Informational RFC 3735 in March 2004. >=20 > The provreg working group was chartered to develop EPP, but not these = additional extensions. The working group was closed in 2004 after = producing a number of Proposed Standard specifications. As registries = began to implement and deploy EPP the need for extensions became real, = and the user community found itself facing a situation in which multiple = extensions were being developed by different registries to solve the = same basic problems, such as registering internationalized domain name = variants. >=20 > ICANN is now well into a program to delegate a large number of new = generic top-level domains. EPP will be used to provision those domains, = and new registry operators are expected to develop additional protocol = extensions. With no way to coordinate the development of these = extensions, the problem of non-standard extension duplication is only = expected to become worse. >=20 > The goal of the EPP Extensions (eppext) working group is to develop an = IANA registry of EPP extensions and procedures to review specifications = for inclusion in the registry. It will accomplish this goal in two = steps: >=20 > 1. Develop a Proposed Standard specification for the registration and = review of EPP extensions. There is no current Internet Draft that = describes this process. >=20 > 2. Test the extension registration process by developing a small = number of standards track extensions that currently exist in Internet = Draft form, including: >=20 > draft-gieben-epp-keyrelay = (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) >=20 > draft-obispo-epp-idn = (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) >=20 > draft-tan-epp-launchphase = (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) > draft-lozano-tmch-smd = (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) > draft-tan-epp-launchphase has a normative dependency on = draft-lozano-tmch-smd. >=20 > When these milestones have been completed the working group will = consider rechartering to explore the issue of ongoing extension = development and standardization. Modifications to EPP itself are = explicitly out of scope for this working group. >=20 > Milestones: >=20 > TBD Extensions registry document to IESG >=20 > TBD draft-gieben-epp-keyrelay to IESG >=20 > TBD draft-obispo-epp-idn to IESG >=20 > TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From fobispo@isc.org Wed Sep 18 05:48:01 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C346E11E828B for ; Wed, 18 Sep 2013 05:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbWk2ATZdHZu for ; Wed, 18 Sep 2013 05:48:01 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1688811E828A for ; Wed, 18 Sep 2013 05:48:01 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id CD732C9480; Wed, 18 Sep 2013 12:47:46 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379508479; bh=1aZ72hYP7GjRtObwVgLoWyfVOj59pBoi07/RemQ5aZs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Y4A5YNVpOWhD7cBgr1DoXMySp/CW9cuWl0ZZILhYwpx97WTao+z0clTFKRIDID92+ y/NcuBy1P6ZzM3+VOP2AvWVjo2QmQHNopODEVD2kfMUGhFk9M2v+cF+IRn3rg5l2pP tVhRm+mDw+pERIOJkuYhpUYTSIasjR50bVx4Udnc= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 12:47:46 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [10.245.53.97] (unknown [64.94.58.75]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6227D216C1E; Wed, 18 Sep 2013 12:47:46 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Francisco Obispo In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Sep 2013 07:47:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91256B7C-822F-400C-83D7-3389DC83388A@isc.org> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1510) X-DCC--Metrics: post.isc.org; whitelist Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:48:01 -0000 Hi Scott, We will be happy to participate in the wg. best regards, On Sep 18, 2013, at 6:20 AM, "Hollenbeck, Scott" = wrote: > I've got one specific question: are people able and willing to write a = draft (or drafts) that describe(s) the registry and registration = procedures? I don't think this will be a difficult task because cloning = an existing registry is a perfectly reasonable approach, but someone = needs to do the work. I'm willing to co-chair (if you all will have me) = if we form a working group, and thus it would be best if we find other = volunteers to write documents. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From jothan@gmail.com Wed Sep 18 09:42:23 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88DD11E80ED for ; Wed, 18 Sep 2013 09:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR958x0Wrozg for ; Wed, 18 Sep 2013 09:42:23 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4787411E8228 for ; Wed, 18 Sep 2013 09:42:20 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jy13so5780975veb.33 for ; Wed, 18 Sep 2013 09:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/lagE9K+YOFWMhKNuaGgKtHTU4gWKSewsYHT+hANk54=; b=QIUTQMrxjtS1VvhCtXzZhqCiDj0KSYpGCZm7tBFV5FgW2MTL8kMoRX6pJ5iLhK6amj 7tVwReU1vf93hB49HTU9KPagRix/oFydl2JXZwA3L3nJPizePwUBJSyLLdKWp6QHSOT3 mMHS0INuaYSB5qHsMrgelDuBOM+ul7xj4y8bWUiUk+efHcCPV/H67W0ZiL99Ex1V4RQm 9ep29jGhHvhOQMuRBzfZbzvwqTb35I2oNbC2PBigt8YM6/aBGMtuqNErmrwWx+nhDKO1 wxkZsyvGyy4uVXui8pRFWJv1+eDLZwLpctR+ZSdk3vrvP8/G5GosRH3zbHQh3JQmPE1B Ze5g== X-Received: by 10.220.84.65 with SMTP id i1mr36460vcl.51.1379522538317; Wed, 18 Sep 2013 09:42:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.108.166 with HTTP; Wed, 18 Sep 2013 09:41:38 -0700 (PDT) In-Reply-To: <91256B7C-822F-400C-83D7-3389DC83388A@isc.org> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <91256B7C-822F-400C-83D7-3389DC83388A@isc.org> From: Jothan Frakes Date: Wed, 18 Sep 2013 09:41:38 -0700 Message-ID: To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=089e0160d2f4db2e0304e6ab1e86 Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 16:42:23 -0000 --089e0160d2f4db2e0304e6ab1e86 Content-Type: text/plain; charset=UTF-8 I would like to also participate and contribute to this important effort. -Jothan Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax On Wed, Sep 18, 2013 at 5:47 AM, Francisco Obispo wrote: > Hi Scott, > > We will be happy to participate in the wg. > > best regards, > > On Sep 18, 2013, at 6:20 AM, "Hollenbeck, Scott" > wrote: > > > I've got one specific question: are people able and willing to write a > draft (or drafts) that describe(s) the registry and registration > procedures? I don't think this will be a difficult task because cloning an > existing registry is a perfectly reasonable approach, but someone needs to > do the work. I'm willing to co-chair (if you all will have me) if we form a > working group, and thus it would be best if we find other volunteers to > write documents. > > Francisco Obispo > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID = B38DB1BE > > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > --089e0160d2f4db2e0304e6ab1e86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to also participate = and contribute to this important effort.

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206= -201-6881 fax


On Wed, Sep 18, 2013 at 5:47 AM, Francis= co Obispo <fobispo@isc.org> wrote:
Hi Scott,

We will be happy to participate in the wg.

best regards,

On Sep 18, 2013, at 6:20 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

> I've got one specific question: are people able and willing to wri= te a draft (or drafts) that describe(s) the registry and registration proce= dures? I don't think this will be a difficult task because cloning an e= xisting registry is a perfectly reasonable approach, but someone needs to d= o the work. I'm willing to co-chair (if you all will have me) if we for= m a working group, and thus it would be best if we find other volunteers to= write documents.

Francisco Obispo
email: fobispo@isc.org
Phone: +1 65= 0 423 1374 || INOC-DBA *3557* NOC
PGP KeyID =3D B38DB1BE




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

--089e0160d2f4db2e0304e6ab1e86-- From york@isoc.org Wed Sep 18 10:21:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C502611E8284 for ; Wed, 18 Sep 2013 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CftvmYFZ54Ku for ; Wed, 18 Sep 2013 10:21:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9B711E829D for ; Wed, 18 Sep 2013 10:21:30 -0700 (PDT) Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 18 Sep 2013 17:21:28 +0000 Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.71]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.165]) with mapi id 15.00.0775.005; Wed, 18 Sep 2013 17:21:28 +0000 From: Dan York To: "Hollenbeck, Scott" , "provreg@ietf.org" Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: Ac60YSDD3AqH2WpnRAOeb5Tvgs6iewAENi2A Date: Wed, 18 Sep 2013 17:21:27 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.101.4] x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(51704005)(189002)(199002)(81686001)(77982001)(54316002)(56776001)(74876001)(19580405001)(76796001)(59766001)(54356001)(79102001)(15975445006)(74706001)(77096001)(76786001)(83322001)(65816001)(74366001)(80976001)(76176001)(19580395003)(81816001)(76482001)(80022001)(56816003)(69226001)(63696002)(47736001)(50986001)(15202345003)(4396001)(49866001)(51856001)(47446002)(53806001)(74502001)(81342001)(83072001)(36756003)(47976001)(81542001)(31966008)(15395725003)(74662001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <6ECAD3CABA16414F8C48C10DBFF1E6A7@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:21:34 -0000 Scott, I would be willing to participate and review documents. I'll note that my specific interest is in accelerating DNSSEC deployment and I see this registrar/registry communication as one of the areas that needs improvement/automation. In discussing DNSSEC deployment challenges, we've also received feedback from registrars that they are frustrated with having many different ways of communicating with different registries. While I agree that the variety of business models means there will continue to be multiple extensions for EPP, I do see value in trying to do whatever is possible to try to limit the proliferation of a zillion new EPP extensions by documenting existing extensions and helping new registries find out about those extensions before inventing their own. As I don't work with EPP on a regular basis, I don't feel I have the background to help with the actual writing, but I would be glad to participate in reviewing. Dan P.S. And I do realize that EPP extensions are about far more than DNSSEC - I was just stating the context for where I personally am coming from. -- Dan York Senior Content Strategist, Internet Society york@isoc.org +1-802-735-1624 Jabber: york@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/deploy360/ On 9/18/13 7:20 AM, "Hollenbeck, Scott" wrote: >I recently closed a conversation with Applications Area Director Pete >Resnick to see what he thought about a narrowly-focused charter for a >working group to develop a registry for EPP extensions. Pete has agreed >with the concept in principal. I'm including the text of the proposed >charter that I shared with Pete and I'd like to ask others to review it >and share feedback as appropriate. > >If we have enough support for a proposed charter Pete is willing to >entertain a chartering request. If there's more to discuss we can ask >about scheduling a BOF during the Vancouver meeting. > >I've got one specific question: are people able and willing to write a >draft (or drafts) that describe(s) the registry and registration >procedures? I don't think this will be a difficult task because cloning >an existing registry is a perfectly reasonable approach, but someone >needs to do the work. I'm willing to co-chair (if you all will have me) >if we form a working group, and thus it would be best if we find other >volunteers to write documents. > >Scott >---------- >Proposed Charter for EPP Extensions (eppext) Working Group > >The Extensible Provisioning Protocol (EPP) was a work product of the IETF >Provisioning Registry Protocol (provreg) working group. EPP was published >as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March >2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) >in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, >and 5734) in August 2009. It is the standard domain name provisioning >protocol for generic top-level domain name registries that operate under >the auspices of the Internet Corporation for Assigned Names and Numbers >(ICANN). It is also used by a number of country code top-level domain >registries. > >Domain name registries implement a variety of business models. The >difference in these models made it very difficult to come up with a "one >size fits all" provisioning protocol, so the provreg working group made a >conscious decision to focus on a minimal set of common functionality. EPP >was designed to be extensible to allow additional features to be >specified on an "as needed" basis. Guidelines for extending EPP were >published as Informational RFC 3735 in March 2004. > >The provreg working group was chartered to develop EPP, but not these >additional extensions. The working group was closed in 2004 after >producing a number of Proposed Standard specifications. As registries >began to implement and deploy EPP the need for extensions became real, >and the user community found itself facing a situation in which multiple >extensions were being developed by different registries to solve the same >basic problems, such as registering internationalized domain name >variants. > >ICANN is now well into a program to delegate a large number of new >generic top-level domains. EPP will be used to provision those domains, >and new registry operators are expected to develop additional protocol >extensions. With no way to coordinate the development of these >extensions, the problem of non-standard extension duplication is only >expected to become worse. > >The goal of the EPP Extensions (eppext) working group is to develop an >IANA registry of EPP extensions and procedures to review specifications >for inclusion in the registry. It will accomplish this goal in two steps: > >1. Develop a Proposed Standard specification for the registration and >review of EPP extensions. There is no current Internet Draft that >describes this process. > >2. Test the extension registration process by developing a small number >of standards track extensions that currently exist in Internet Draft >form, including: > >draft-gieben-epp-keyrelay >(http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) > >draft-obispo-epp-idn >(http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) > >draft-tan-epp-launchphase >(http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) >draft-lozano-tmch-smd >(https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) >draft-tan-epp-launchphase has a normative dependency on >draft-lozano-tmch-smd. > >When these milestones have been completed the working group will consider >rechartering to explore the issue of ongoing extension development and >standardization. Modifications to EPP itself are explicitly out of scope >for this working group. > >Milestones: > >TBD Extensions registry document to IESG > >TBD draft-gieben-epp-keyrelay to IESG > >TBD draft-obispo-epp-idn to IESG > >TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG > > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From jacques.latour@cira.ca Wed Sep 18 10:28:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D630D11E8291 for ; Wed, 18 Sep 2013 10:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2LS+8T4IL-t for ; Wed, 18 Sep 2013 10:28:41 -0700 (PDT) Received: from mail02.prd.cira.ca (mail02.tor.cira.ca [192.228.26.136]) by ietfa.amsl.com (Postfix) with ESMTP id AAB3511E811A for ; Wed, 18 Sep 2013 10:28:41 -0700 (PDT) Received: from crp-spam-01.crp-dmz.cira.ca ([10.2.36.116]) by mail02.prd.cira.ca (8.13.8/8.13.1) with SMTP id r8IHSffV009146 for ; Wed, 18 Sep 2013 13:28:41 -0400 Received: from crp-spam-01.crp-dmz.cira.ca (localhost [127.0.0.1]) by crp-spam-01.crp-dmz.cira.ca (Postfix) with ESMTP id 07C90ACE8E for ; Wed, 18 Sep 2013 13:28:41 -0400 (EDT) X-Virus-Scanned: by SpamTitan at corp.cira.ca; Received: from mx1.cira.ca (unknown [10.2.36.1]) by crp-spam-01.crp-dmz.cira.ca (Postfix) with ESMTP id C6823ACD6B for ; Wed, 18 Sep 2013 13:28:39 -0400 (EDT) Received: from EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c]) by EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50%19]) with mapi id 14.01.0438.000; Wed, 18 Sep 2013 13:28:39 -0400 From: Jacques Latour To: "provreg@ietf.org" , Stuart Olmstead-Wilcox Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOsBEQlfOvQDINcEe9nT42BBojD5nDnkeg Date: Wed, 18 Sep 2013 17:28:38 +0000 Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> In-Reply-To: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:28:46 -0000 Hi Jay, This is timely, we're also looking at doing registry lock. We're looking a= t different mechanisms to setup the lock and also to procure the lock (the = $$$) possibly via EPP, but it should be a generic interface usable for any = additional value add services that we might offer in the future, not just h= ard coded for registry lock. {I think} We would be interested in working with you to build something. Also, this in an introduction of Stu, our development manager here at CIRA. Should we have an industry standard way of doing registry lock? { registran= t <--> registrar <--> registry } Jack > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behal= f > Of Jay Daley > Sent: September-12-13 7:37 PM > To: provreg@ietf.org > Subject: [provreg] Registry lock - two-factor or intervention >=20 > I have some questions for you. >=20 > I'm aware of two separate approaches to registry locking >=20 > 1. Two-factor authentication of change requests, where the registrant is > expected to hold one factor and the registrar pass it through. Using som= ething > like SecureID. >=20 > 2. Intervention, where the registry is expected to verify a change reque= st out- > of-band (or the registrar pre-empts this with a out-of-band unlock reques= t). >=20 > My questions are: >=20 > Q1: Does anyone have an EPP extension for handling 1 above that they wou= ld > be willing to put forward for wider use? No > Q2: Is there any role for EPP in 2 above? Yes, for locking the domain and also the financial aspect. >=20 > thanks in advance for anyone taking the time to reply! >=20 > cheers > Jay >=20 > -- > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 > linkedin: www.linkedin.com/in/jaydaley >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From shollenbeck@verisign.com Wed Sep 18 10:57:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A8811E80A2 for ; Wed, 18 Sep 2013 10:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2whN0bXX81J for ; Wed, 18 Sep 2013 10:57:21 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0F84C11E80E4 for ; Wed, 18 Sep 2013 10:56:51 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUjnpXcLtukTUFVEKlZzOcqoZrKCunZXT@postini.com; Wed, 18 Sep 2013 10:56:51 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8IHughg025316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 13:56:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 13:56:14 -0400 From: "Hollenbeck, Scott" To: Jacques Latour , "provreg@ietf.org" , Stuart Olmstead-Wilcox Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOsBEQlfOvQDINcEe9nT42BBojD5nDnkeggAgrraA= Date: Wed, 18 Sep 2013 17:56:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49267359@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 17:57:27 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Jacques Latour > Sent: Wednesday, September 18, 2013 1:29 PM > To: provreg@ietf.org; Stuart Olmstead-Wilcox > Subject: Re: [provreg] Registry lock - two-factor or intervention [snip] > Should we have an industry standard way of doing registry lock? { > registrant <--> registrar <--> registry } I'm more than a little concerned that something that flows through the regi= strar can be called a *registry* lock. Locks that flow through and can be s= et or unset by the registrar more appropriately affect the client*Prohibite= d status values. Scott From michele@blacknight.com Wed Sep 18 11:03:52 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A83E21F8613 for ; Wed, 18 Sep 2013 11:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGxkk0xdHAOG for ; Wed, 18 Sep 2013 11:03:47 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4A86311E810B for ; Wed, 18 Sep 2013 11:03:47 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::b89b:6394:5849:df5c]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 19:03:46 +0100 From: Michele Neylon - Blacknight To: "Hollenbeck, Scott" Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOsBEQlfOvQDINcEe9nT42BBojD5nDnkeggAgrraD///f6AA== Date: Wed, 18 Sep 2013 18:03:44 +0000 Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> In-Reply-To: <20130918175531.485BF5A4010@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="utf-8" Content-ID: <5B6267357576CE4DB98982D8FA0729B5@blacknight.local> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Stuart Olmstead-Wilcox , "provreg@ietf.org" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:03:52 -0000 DQpPbiAxOCBTZXAgMjAxMywgYXQgMTg6NTYsICJIb2xsZW5iZWNrLCBTY290dCIgPHNob2xsZW5i ZWNrQHZlcmlzaWduLmNvbT4NCiB3cm90ZToNCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IHByb3ZyZWctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnByb3ZyZWctYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4+IEJlaGFsZiBPZiBKYWNxdWVzIExhdG91cg0KPj4gU2VudDog V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTMgMToyOSBQTQ0KPj4gVG86IHByb3ZyZWdAaWV0 Zi5vcmc7IFN0dWFydCBPbG1zdGVhZC1XaWxjb3gNCj4+IFN1YmplY3Q6IFJlOiBbcHJvdnJlZ10g UmVnaXN0cnkgbG9jayAtIHR3by1mYWN0b3Igb3IgaW50ZXJ2ZW50aW9uDQo+IA0KPiBbc25pcF0N Cj4gDQo+PiBTaG91bGQgd2UgaGF2ZSBhbiBpbmR1c3RyeSBzdGFuZGFyZCB3YXkgb2YgZG9pbmcg cmVnaXN0cnkgbG9jaz8gew0KPj4gcmVnaXN0cmFudCA8LS0+IHJlZ2lzdHJhciA8LS0+IHJlZ2lz dHJ5IH0NCj4gDQo+IEknbSBtb3JlIHRoYW4gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgc29tZXRo aW5nIHRoYXQgZmxvd3MgdGhyb3VnaCB0aGUgcmVnaXN0cmFyIGNhbiBiZSBjYWxsZWQgYSAqcmVn aXN0cnkqIGxvY2suIExvY2tzIHRoYXQgZmxvdyB0aHJvdWdoIGFuZCBjYW4gYmUgc2V0IG9yIHVu c2V0IGJ5IHRoZSByZWdpc3RyYXIgbW9yZSBhcHByb3ByaWF0ZWx5IGFmZmVjdCB0aGUgY2xpZW50 KlByb2hpYml0ZWQgc3RhdHVzIHZhbHVlcy4NCg0KU2NvdHQNCg0KSXQgZGVwZW5kcyBvbiBob3cg aXQncyBpbXBsZW1lbnRlZCBzdXJlbHk/DQoNCkFzIGEgcmVnaXN0cmFyIEkgKm1pZ2h0KiBsaWtl IHRoZSBpZGVhIG9mIGJlaW5nIGFibGUgdG8gImZsYWciIHdpdGggdGhlIHJlZ2lzdHJ5IHRoYXQg d2Ugd2FudCB0byBhZGQgb3IgcmVtb3ZlIGEgcmVnaXN0cnkgbG9jaw0KDQpCdXQgSSdkIGJlIHdh cnkgb2YgbXkgRVBQIGNvbW1hbmRzIC8gY29ubmVjdGlvbiBiZWluZyBhYmxlIHRvIHNldCBvciB1 bnNldCBpdCwgYXMgSSdkIHNlZSB0aGF0IGFzIHVuZGVybWluaW5nIHRoZSB2ZXJ5IG5hdHVyZSBv ZiBhIGhpZ2hseSBzZWN1cmUgcmVnaXN0cnkgbG9jay4gDQoNCk15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlICJyZWdpc3RyeSBsb2NrIiBzZXJ2aWNlcyBiZWluZyBvZmZlcmVkIGJ5IHNldmVyYWwgcmVn aXN0cmllcyBhbmQgYmVpbmcgcmVxdWVzdGVkIGJ5IHJlZ2lzdHJhbnRzIChzZWUgdGhlIHRocmVh ZCBmcm9tIGxhdGUgbGFzdCB5ZWFyIGZyb20gV2FycmVuKSBpcyB0aGF0IHRoZSAiYXR0cmFjdGlv biIgb3IgInNlbGxpbmcgcG9pbnQiIGlzIHRoYXQgdGhlIGxvY2sgc3RhdHVzIGhhcyB0byBiZSBz ZXQgKGFuZCByZW1vdmVkKSB1c2luZyAib3V0IG9mIGJvdW5kcyIgbWV0aG9kcy4NCg0KT2YgY291 cnNlIEkgY291bGQgYmUgY29tcGxldGVseSBtaXN1bmRlcnN0YW5kaW5nLg0KDQpSZWdhcmRzDQoN Ck1pY2hlbGUNCg0KDQpNciBNaWNoZWxlIE5leWxvbg0KQmxhY2tuaWdodCBTb2x1dGlvbnMg4pme DQpIb3N0aW5nICYgRG9tYWlucw0KSUNBTk4gQWNjcmVkaXRlZCBSZWdpc3RyYXINCmh0dHA6Ly93 d3cuYmxhY2tuaWdodC5jbw0KaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20vDQpJbnRsLiArMzUz ICgwKSA1OSAgOTE4MzA3Mg0KVVM6IDIxMy0yMzMtMTYxMiANCkxvY2FsbDogMTg1MCA5MjkgOTI5 DQpEaXJlY3QgRGlhbDogKzM1MyAoMCk1OSA5MTgzMDkwDQpGYWNlYm9vazogaHR0cDovL2ZiLm1l L2JsYWNrbmlnaHQNClR3aXR0ZXI6IGh0dHA6Ly90d2l0dGVyLmNvbS9tbmV5bG9uDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCbGFja25pZ2h0IEludGVybmV0IFNvbHV0aW9ucyBM dGQsIFVuaXQgMTJBLEJhcnJvd3NpZGUgQnVzaW5lc3MgUGFyayxTbGVhdHkNClJvYWQsR3JhaWd1 ZWN1bGxlbixDYXJsb3csSXJlbGFuZCAgQ29tcGFueSBOby46IDM3MDg0NQ0KDQo= From shollenbeck@verisign.com Wed Sep 18 11:21:58 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28811E810B for ; Wed, 18 Sep 2013 11:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbjJQ1dJRr8p for ; Wed, 18 Sep 2013 11:21:52 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8765A11E80F6 for ; Wed, 18 Sep 2013 11:21:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUjnvO3xR5FpbLOmc8lIWYeNtPoSmkKFn@postini.com; Wed, 18 Sep 2013 11:21:52 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8IILlFD030044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Sep 2013 14:21:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Sep 2013 14:20:58 -0400 From: "Hollenbeck, Scott" To: Michele Neylon - Blacknight Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOsBEQlfOvQDINcEe9nT42BBojD5nDnkeggAgrraD///f6AIAAEZ1g Date: Wed, 18 Sep 2013 18:21:46 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> 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 Cc: Stuart Olmstead-Wilcox , "provreg@ietf.org" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:21:58 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNoZWxlIE5leWxvbiAtIEJs YWNrbmlnaHQgW21haWx0bzptaWNoZWxlQGJsYWNrbmlnaHQuY29tXQ0KPiBTZW50OiBXZWRuZXNk YXksIFNlcHRlbWJlciAxOCwgMjAxMyAyOjA0IFBNDQo+IFRvOiBIb2xsZW5iZWNrLCBTY290dA0K PiBDYzogSmFjcXVlcyBMYXRvdXI7IHByb3ZyZWdAaWV0Zi5vcmc7IFN0dWFydCBPbG1zdGVhZC1X aWxjb3gNCj4gU3ViamVjdDogUmU6IFtwcm92cmVnXSBSZWdpc3RyeSBsb2NrIC0gdHdvLWZhY3Rv ciBvciBpbnRlcnZlbnRpb24NCj4gDQo+IA0KPiBPbiAxOCBTZXAgMjAxMywgYXQgMTg6NTYsICJI b2xsZW5iZWNrLCBTY290dCINCj4gPHNob2xsZW5iZWNrQHZlcmlzaWduLmNvbT4NCj4gIHdyb3Rl Og0KPiANCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogcHJvdnJl Zy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHJvdnJlZy1ib3VuY2VzQGlldGYub3JnXSBPbg0K PiA+PiBCZWhhbGYgT2YgSmFjcXVlcyBMYXRvdXINCj4gPj4gU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMTgsIDIwMTMgMToyOSBQTQ0KPiA+PiBUbzogcHJvdnJlZ0BpZXRmLm9yZzsgU3R1YXJ0 IE9sbXN0ZWFkLVdpbGNveA0KPiA+PiBTdWJqZWN0OiBSZTogW3Byb3ZyZWddIFJlZ2lzdHJ5IGxv Y2sgLSB0d28tZmFjdG9yIG9yIGludGVydmVudGlvbg0KPiA+DQo+ID4gW3NuaXBdDQo+ID4NCj4g Pj4gU2hvdWxkIHdlIGhhdmUgYW4gaW5kdXN0cnkgc3RhbmRhcmQgd2F5IG9mIGRvaW5nIHJlZ2lz dHJ5IGxvY2s/IHsNCj4gPj4gcmVnaXN0cmFudCA8LS0+IHJlZ2lzdHJhciA8LS0+IHJlZ2lzdHJ5 IH0NCj4gPg0KPiA+IEknbSBtb3JlIHRoYW4gYSBsaXR0bGUgY29uY2VybmVkIHRoYXQgc29tZXRo aW5nIHRoYXQgZmxvd3MgdGhyb3VnaA0KPiB0aGUgcmVnaXN0cmFyIGNhbiBiZSBjYWxsZWQgYSAq cmVnaXN0cnkqIGxvY2suIExvY2tzIHRoYXQgZmxvdyB0aHJvdWdoDQo+IGFuZCBjYW4gYmUgc2V0 IG9yIHVuc2V0IGJ5IHRoZSByZWdpc3RyYXIgbW9yZSBhcHByb3ByaWF0ZWx5IGFmZmVjdCB0aGUN Cj4gY2xpZW50KlByb2hpYml0ZWQgc3RhdHVzIHZhbHVlcy4NCj4gDQo+IFNjb3R0DQo+IA0KPiBJ dCBkZXBlbmRzIG9uIGhvdyBpdCdzIGltcGxlbWVudGVkIHN1cmVseT8NCj4gDQo+IEFzIGEgcmVn aXN0cmFyIEkgKm1pZ2h0KiBsaWtlIHRoZSBpZGVhIG9mIGJlaW5nIGFibGUgdG8gImZsYWciIHdp dGggdGhlDQo+IHJlZ2lzdHJ5IHRoYXQgd2Ugd2FudCB0byBhZGQgb3IgcmVtb3ZlIGEgcmVnaXN0 cnkgbG9jaw0KPiANCj4gQnV0IEknZCBiZSB3YXJ5IG9mIG15IEVQUCBjb21tYW5kcyAvIGNvbm5l Y3Rpb24gYmVpbmcgYWJsZSB0byBzZXQgb3INCj4gdW5zZXQgaXQsIGFzIEknZCBzZWUgdGhhdCBh cyB1bmRlcm1pbmluZyB0aGUgdmVyeSBuYXR1cmUgb2YgYSBoaWdobHkNCj4gc2VjdXJlIHJlZ2lz dHJ5IGxvY2suDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSAicmVnaXN0cnkgbG9jayIg c2VydmljZXMgYmVpbmcgb2ZmZXJlZCBieQ0KPiBzZXZlcmFsIHJlZ2lzdHJpZXMgYW5kIGJlaW5n IHJlcXVlc3RlZCBieSByZWdpc3RyYW50cyAoc2VlIHRoZSB0aHJlYWQNCj4gZnJvbSBsYXRlIGxh c3QgeWVhciBmcm9tIFdhcnJlbikgaXMgdGhhdCB0aGUgImF0dHJhY3Rpb24iIG9yICJzZWxsaW5n DQo+IHBvaW50IiBpcyB0aGF0IHRoZSBsb2NrIHN0YXR1cyBoYXMgdG8gYmUgc2V0IChhbmQgcmVt b3ZlZCkgdXNpbmcgIm91dA0KPiBvZiBib3VuZHMiIG1ldGhvZHMuDQoNCk15IG9yaWdpbmFsIGlu dGVudGlvbiBmb3IgdGhlIHNlcnZlcipQcm9oaWJpdGVkIHN0YXR1cyB2YWx1ZXMgd2FzIGZvY3Vz ZWQgbW9yZSBvbiByZWdpc3RyeS1pbml0aWF0ZWQgYWN0aW9ucyBsaWtlIGRlYWxpbmcgd2l0aCBh IGNvdXJ0IG9yZGVyIHRoYXQgZGlkbid0IHJlcXVpcmUgaW5pdGlhdGlvbiBieSBhIHJlZ2lzdHJh ci4gVGhlaXIgdXNlIGluIGltcGxlbWVudGluZyBhbiBvbi1kZW1hbmQgbG9jayBzZXJ2aWNlIHdh cyBhIHNlcmVuZGlwaXRvdXMgc2lkZSBlZmZlY3QuDQoNCkFueXdheSwgeWVzLCBpZiB0aGUgaWRl YSBpcyB0byBjb21tdW5pY2F0ZSBzb21lIHNvcnQgb2YgcmVxdWVzdCB0byB0aGUgcmVnaXN0cnkg dG8gcGVyZm9ybSBhbiBvdXQtb2YtYmFuZCBsb2NraW5nIGFjdGlvbiBpdCBjb3VsZCBiZSBkb25l IHZpYSBFUFAuIEFzIHlvdSBub3RlZCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGFuIGFkZGl0aW9u YWwgb3V0LW9mLWJhbmQgbWVjaGFuaXNtIGluIHBsYWNlIHRvIHZhbGlkYXRlIHRoZSByZXF1ZXN0 Lg0KDQpTY290dA0K From fobispo@isc.org Wed Sep 18 14:34:04 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAE611E810B for ; Wed, 18 Sep 2013 14:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id konk6Ak0Foco for ; Wed, 18 Sep 2013 14:34:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4B611E810A for ; Wed, 18 Sep 2013 14:34:03 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 6BDFEC94D0; Wed, 18 Sep 2013 21:33:50 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379540042; bh=Er8F/8WqLDR7aYCf+iGkICdpFvjitVeqJFKwIhWZB6o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ZOkow9Ka3UqRzzQLFV8O+00dWembTpysdXhbTlEms+McUa243qhsr5u1yTr3Lcuu5 gcS5v2TXD/TbeOQIRFSZjeru/s7YaLwF1vOf3KdE2EHoWWzbAkLgoXPuBXCcMoNg/M y0ibH1bG9BS9xBAmpBsPG+T3OQ8KjYB0dADY6nHg= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 21:33:50 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.10.19] (unknown [74.222.88.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 00F56216C1E; Wed, 18 Sep 2013 21:33:36 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Francisco Obispo In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Sep 2013 16:33:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1510) X-DCC--Metrics: post.isc.org; whitelist Cc: Stuart Olmstead-Wilcox , "provreg@ietf.org" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:34:04 -0000 The only reason why I would use an extension to implement a registrar = lock, is to: 1) Collect real registrant information so it can be used to authenticate = a request to activate at the registry using an out-of-band method. This = include response/challenges, mobile number, etc so that multi-factor = authentication can be used. This is specially useful when privacy = services are used. 2) Signal the registrar that a registry lock is in effect, which could = be much more than the standard server* statuses. On Sep 18, 2013, at 1:21 PM, "Hollenbeck, Scott" = wrote: > Anyway, yes, if the idea is to communicate some sort of request to the = registry to perform an out-of-band locking action it could be done via = EPP. As you noted there would need to be an additional out-of-band = mechanism in place to validate the request. >=20 > Scott Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From jay@nzrs.net.nz Wed Sep 18 14:46:44 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD6B11E81B9 for ; Wed, 18 Sep 2013 14:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSJp-0aQGWCx for ; Wed, 18 Sep 2013 14:46:40 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 09D4211E81BC for ; Wed, 18 Sep 2013 14:46:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 31F734B6650; Thu, 19 Sep 2013 09:46:37 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yhMwik8yNZR; Thu, 19 Sep 2013 09:46:29 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A5CFE4B665F; Thu, 19 Sep 2013 09:46:29 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: Date: Thu, 19 Sep 2013 09:46:30 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <5997A84D-7DE3-4F00-902D-B05C8A0C0293@nzrs.net.nz> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> To: Jacques Latour X-Mailer: Apple Mail (2.1510) Cc: Stuart Olmstead-Wilcox , "provreg@ietf.org" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:46:44 -0000 Hi Jacques=20 We've been floating the idea with registrars and the overwhelming = feedback is for the registry to offer the full service with as little = development as necessary for the registrars. Not only that but they = also favour a manual service to begin, which can help establish demand = and the need for future development. So putting the two together it looks something like: 1. registrars send a lock request (presumably an extension to EPP, = unless anyone has a better idea).=20 2. when a change request comes in we queue it and seek manual = confirmation that it should be processed. Still not sure if 1. should be the billable transaction or each = occurrence of 2. how does that seem? Jay On 19/09/2013, at 5:28 AM, Jacques Latour = wrote: > Hi Jay, >=20 > This is timely, we're also looking at doing registry lock. We're = looking at different mechanisms to setup the lock and also to procure = the lock (the $$$) possibly via EPP, but it should be a generic = interface usable for any additional value add services that we might = offer in the future, not just hard coded for registry lock. {I think} >=20 > We would be interested in working with you to build something. >=20 > Also, this in an introduction of Stu, our development manager here at = CIRA. >=20 > Should we have an industry standard way of doing registry lock? { = registrant <--> registrar <--> registry } >=20 > Jack >=20 >> -----Original Message----- >> From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf >> Of Jay Daley >> Sent: September-12-13 7:37 PM >> To: provreg@ietf.org >> Subject: [provreg] Registry lock - two-factor or intervention >>=20 >> I have some questions for you. >>=20 >> I'm aware of two separate approaches to registry locking >>=20 >> 1. Two-factor authentication of change requests, where the = registrant is >> expected to hold one factor and the registrar pass it through. Using = something >> like SecureID. >>=20 >> 2. Intervention, where the registry is expected to verify a change = request out- >> of-band (or the registrar pre-empts this with a out-of-band unlock = request). >>=20 >> My questions are: >>=20 >> Q1: Does anyone have an EPP extension for handling 1 above that they = would >> be willing to put forward for wider use? >=20 > No >=20 >> Q2: Is there any role for EPP in 2 above? >=20 > Yes, for locking the domain and also the financial aspect. >=20 >>=20 >> thanks in advance for anyone taking the time to reply! >>=20 >> cheers >> Jay >>=20 >> -- >> Jay Daley >> Chief Executive >> .nz Registry Services (New Zealand Domain Name Registry Limited) >> desk: +64 4 931 6977 >> mobile: +64 21 678840 >> linkedin: www.linkedin.com/in/jaydaley >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From jay@nzrs.net.nz Wed Sep 18 14:56:35 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44D11E8265 for ; Wed, 18 Sep 2013 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPvCNXgE+etH for ; Wed, 18 Sep 2013 14:56:31 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8862B11E8263 for ; Wed, 18 Sep 2013 14:56:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 902804B6643; Thu, 19 Sep 2013 09:56:29 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXC4N2WZ-RRV; Thu, 19 Sep 2013 09:56:22 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 936B64B665D; Thu, 19 Sep 2013 09:56:21 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: Date: Thu, 19 Sep 2013 09:56:22 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: Francisco Obispo X-Mailer: Apple Mail (2.1510) Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 21:56:35 -0000 On 19/09/2013, at 9:33 AM, Francisco Obispo wrote: > The only reason why I would use an extension to implement a registrar = lock, is to: >=20 > 1) Collect real registrant information so it can be used to = authenticate a request to activate at the registry using an out-of-band = method. This include response/challenges, mobile number, etc so that = multi-factor authentication can be used. This is specially useful when = privacy services are used. We came to the conclusion that a manual verification (or possibly = another out-of-band verification) does not need to be to the registrant = but works perfectly well to the registrar. That of course is much = better for those of us that need to maintain the = registry->registrar->registrant model and not introduce a = registry->registrant component. An example: The registrar locks via EPP. The registrar is hacked and a change = request is sent. At the registry the change request goes into a = verification queue. Then either a) the registry phones the registrar (ok for us with only 80 registrars) = and checks the change request is valid; or b) the registrar must enter a secure token, generated by something like = SecureID/Google Authenticator on the registry web site; or Of course we could just expect the token to come with the unlock, as = Jacques was describing. But in none of the above does the registrant = have to hold the token, it is fine for the registrar to hold it so long = as it is sufficiently compartmentalised from the registrar provisioning = system. I have yet to hear of a registrar hack that has included = breaking into the registrar offices and physically accessing equipment. cheers Jay >=20 > 2) Signal the registrar that a registry lock is in effect, which could = be much more than the standard server* statuses. >=20 >=20 >=20 >=20 > On Sep 18, 2013, at 1:21 PM, "Hollenbeck, Scott" = wrote: >=20 >> Anyway, yes, if the idea is to communicate some sort of request to = the registry to perform an out-of-band locking action it could be done = via EPP. As you noted there would need to be an additional out-of-band = mechanism in place to validate the request. >>=20 >> Scott >=20 > Francisco Obispo=20 > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 >=20 >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From fobispo@isc.org Wed Sep 18 15:41:51 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F62E11E81B7 for ; Wed, 18 Sep 2013 15:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDHL7jWPFCXv for ; Wed, 18 Sep 2013 15:41:50 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 764B311E81A1 for ; Wed, 18 Sep 2013 15:41:50 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id ED614C9484; Wed, 18 Sep 2013 22:41:36 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379544110; bh=Yt0/wrzBlFwhy0ru8S4IlwSrX92TvDZWonxBjApBTEM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=PfxcHYPmSYFZidilyJuP/CGXPt4nuAe0ar/ulrS+d7Vo5Nu1fYiLzSsnoLag0owvr Km8I/2DD+SIMIqMgtRxz/h7TumOQ97qyjNNYanCLBoilCQsXprzzWT4Vq+/5M+6MMq wCb29IpMQi255SIZRGBbk7C9+9c4F5hlI6obDM+M= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 22:41:36 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.10.19] (unknown [74.222.88.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C7484216C25; Wed, 18 Sep 2013 22:41:23 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Francisco Obispo In-Reply-To: Date: Wed, 18 Sep 2013 17:41:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: Jay Daley X-Mailer: Apple Mail (2.1510) X-DCC--Metrics: post.isc.org; whitelist Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:41:51 -0000 Hi Jay, Let me give you another example, A registrar mistakenly changes a record (even authorizes a change), = without its client knowing about it, the domain name goes offline, or = even worse, gets hijacked.=20 My idea of a registry lock is to have a direct relationship with the = registrant/name holder, so it can decide wether the domain name is = allowed to be changed by the registrar. Verisign offers a registry lock, so perhaps they can share a little bit = on how they do it, and how they authenticate the request in cases where = contact privacy is enabled. On Sep 18, 2013, at 4:56 PM, Jay Daley wrote: > We came to the conclusion that a manual verification (or possibly = another out-of-band verification) does not need to be to the registrant = but works perfectly well to the registrar. That of course is much = better for those of us that need to maintain the = registry->registrar->registrant model and not introduce a = registry->registrant component. Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From mje@posix.co.za Wed Sep 18 15:56:15 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FC911E82D3 for ; Wed, 18 Sep 2013 15:56:15 -0700 (PDT) X-Quarantine-ID: <7l8HL61lr3f1> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -0.741 X-Spam-Level: X-Spam-Status: No, score=-0.741 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l8HL61lr3f1 for ; Wed, 18 Sep 2013 15:56:14 -0700 (PDT) Received: from mje99.posix.co.za (mje99.posix.co.za [IPv6:2001:42a0:1000:48::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0C11E825E for ; Wed, 18 Sep 2013 15:56:11 -0700 (PDT) Received: from [2001:42a0:1000:48:1912:bdae:a048:63b6] by mje99.posix.co.za with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80.1) (envelope-from ) id 1VMQMh-0007nW-7L for provreg@ietf.org; Thu, 19 Sep 2013 00:37:09 +0200 From: Mark Elkins To: provreg In-Reply-To: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-+6b26UK+r6gFfs9Vfjt5" Organization: Posix Systems Date: Thu, 19 Sep 2013 00:36:54 +0200 Message-ID: <1379543814.7206.220.camel@mjelap.posix.co.za> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mje@posix.co.za List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:56:15 -0000 --=-+6b26UK+r6gFfs9Vfjt5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have the pleasure of being both involved with the Registry and Registrar side of the business. As a Registrar - I would see an extension similar to the existing "EPP Prohibit Actions" the way to set such a lock and then when unlocking such a lock, the need for the Registrar to use one of those key generators that some Banks provide customers with for Internet Banking (OTP - One Time Password generators). Its an out of band (OOB) collaboration that the correct party is asking for a change - and these OTP devices are not (MUST NOT be) physically connected to the Registrar EPP systems. Not sure if one can do "replay" type scenarios with these OTP devices - or how predictable they become. Anyway - the primary expense is one OTP device per Registry/Registrar relationship... so the extra security can be added for basically nothing (cost-wise) and with no extra work for the Registry per unlock. There would be some additional (minor) software development. Physical management of the OTP devices, distribution etc - would have to be done too. Was wondering about scalability - Locked domains should usually stay locked? Perhaps big batched changes (ie jobs like the same Nameserver change for multiple domains) could be validated with one OOB OTP? Just my rambling thoughts on the subject. On Thu, 2013-09-19 at 09:56 +1200, Jay Daley wrote: > On 19/09/2013, at 9:33 AM, Francisco Obispo wrote: >=20 > > The only reason why I would use an extension to implement a registrar l= ock, is to: > >=20 > > 1) Collect real registrant information so it can be used to authenticat= e a request to activate at the registry using an out-of-band method. This i= nclude response/challenges, mobile number, etc so that multi-factor authent= ication can be used. This is specially useful when privacy services are use= d. >=20 > We came to the conclusion that a manual verification (or possibly another= out-of-band verification) does not need to be to the registrant but works = perfectly well to the registrar. That of course is much better for those o= f us that need to maintain the registry->registrar->registrant model and no= t introduce a registry->registrant component. >=20 > An example: >=20 > The registrar locks via EPP. The registrar is hacked and a change reque= st is sent. At the registry the change request goes into a verification qu= eue. Then either >=20 > a) the registry phones the registrar (ok for us with only 80 registrars) = and checks the change request is valid; or > b) the registrar must enter a secure token, generated by something like S= ecureID/Google Authenticator on the registry web site; or >=20 >=20 > Of course we could just expect the token to come with the unlock, as Jacq= ues was describing. But in none of the above does the registrant have to h= old the token, it is fine for the registrar to hold it so long as it is suf= ficiently compartmentalised from the registrar provisioning system. I have= yet to hear of a registrar hack that has included breaking into the regist= rar offices and physically accessing equipment. >=20 > cheers > Jay >=20 >=20 > >=20 > > 2) Signal the registrar that a registry lock is in effect, which could = be much more than the standard server* statuses. > >=20 > >=20 > >=20 > >=20 > > On Sep 18, 2013, at 1:21 PM, "Hollenbeck, Scott" wrote: > >=20 > >> Anyway, yes, if the idea is to communicate some sort of request to the= registry to perform an out-of-band locking action it could be done via EPP= . As you noted there would need to be an additional out-of-band mechanism i= n place to validate the request. > >>=20 > >> Scott > >=20 > > Francisco Obispo=20 > > email: fobispo@isc.org > > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > > PGP KeyID =3D B38DB1BE > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > provreg mailing list > > provreg@ietf.org > > https://www.ietf.org/mailman/listinfo/provreg >=20 >=20 --=20 . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje@posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 --=-+6b26UK+r6gFfs9Vfjt5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUVjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHCzCCBfOg AwIBAgIDBRX+MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIxMDEwMTQwNzA5WhcNMTMxMDEyMTI0MzMwWjBVMRkwFwYDVQQNExBNdjlyUDJVMXJxUjBKY1V5 MRgwFgYDVQQDDA9tamVAcG9zaXguY28uemExHjAcBgkqhkiG9w0BCQEWD21qZUBwb3NpeC5jby56 YTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxQ9nxQ08Sc7gryudzm/DSWaRg8CKSd 1jksu8qShkcM2WbByGlV3dAjIwbN1IOcNWDO+A7L2aDf3/T0DWI74y1ZHCqP2ke4JQaIvj8FblRl 3ypA2YVCk+8mZ5kXeJMxmPPlfBUehMnN61niYhE2uWz0EGEVN9pInDH7f6HTYtkYe1gKxaoK5vJv HlNR57yNZZKGtSpszWmIM1/cUc246vB0gvgn1OfSzxN7mObIYJeccceFvUsXgM077J8oBlSZdHaQ 85OqYwmV/Mk8dfZyDwioavI3M+SQPjJJMqMjG1/Apxo5UG/zrObBH2bWAHvXVLPER78Myq5pp51a bXM4OCcCAwEAAaOCA6owggOmMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUV7JIQzT5T8CJp2mpg2Z6zHl4HS8wHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGgYDVR0RBBMwEYEPbWplQHBvc2l4LmNvLnphMIICIQYD VR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wu Y29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3Jk aW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENv bSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNv bXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCB jzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5k IHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlv bnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUH MAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEF BQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOC AQEAdSWC8C1Zriz+8ajsOeZOAv5U9UD0HXJLVLa7g/Y3B7jivLgDvV1t0qtJe47O2mt5NDLocsTA hpWZg7QkHtyPpyzmigfbP9SBwpEZfX/eF5xJFUDQsnB9SrX/YkbV2lgsjKSfxJW8R2JN8N7CsfJz r9cVQ705hgqDdnct6SL2qaWbkSSEk7S5D9nCwL/8j3oNnraBFadjLJmjI5CSu+AE386Dy986NpGG bTUPDGpYLHAVHqpPK7B/yC09r/PRpH8Bx4UpUP5z0ELLvXf0dYCzRWU228BEHJp0pQlpjVMD/W18 1NkKs83XtBCGDa0lKbcynnPqV5RO4XVTfXuPtplVgzCCBwswggXzoAMCAQICAwUV/jANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMTAxMDE0MDcwOVoXDTEz MTAxMjEyNDMzMFowVTEZMBcGA1UEDRMQTXY5clAyVTFycVIwSmNVeTEYMBYGA1UEAwwPbWplQHBv c2l4LmNvLnphMR4wHAYJKoZIhvcNAQkBFg9tamVAcG9zaXguY28uemEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCsUPZ8UNPEnO4K8rnc5vw0lmkYPAikndY5LLvKkoZHDNlmwchpVd3Q IyMGzdSDnDVgzvgOy9mg39/09A1iO+MtWRwqj9pHuCUGiL4/BW5UZd8qQNmFQpPvJmeZF3iTMZjz 5XwVHoTJzetZ4mIRNrls9BBhFTfaSJwx+3+h02LZGHtYCsWqCubybx5TUee8jWWShrUqbM1piDNf 3FHNuOrwdIL4J9Tn0s8Te5jmyGCXnHHHhb1LF4DNO+yfKAZUmXR2kPOTqmMJlfzJPHX2cg8IqGry NzPkkD4ySTKjIxtfwKcaOVBv86zmwR9m1gB711SzxEe/DMquaaedWm1zODgnAgMBAAGjggOqMIID pjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQw HQYDVR0OBBYEFFeySEM0+U/AiadpqYNmesx5eB0vMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMBoGA1UdEQQTMBGBD21qZUBwb3NpeC5jby56YTCCAiEGA1UdIASCAhgwggIUMIICEAYL KwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3Mg MSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxp YW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBs aW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEu c3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhho dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAHUlgvAtWa4s/vGo7Dnm TgL+VPVA9B1yS1S2u4P2Nwe44ry4A71dbdKrSXuOztpreTQy6HLEwIaVmYO0JB7cj6cs5ooH2z/U gcKRGX1/3hecSRVA0LJwfUq1/2JG1dpYLIykn8SVvEdiTfDewrHyc6/XFUO9OYYKg3Z3Leki9qml m5EkhJO0uQ/ZwsC//I96DZ62gRWnYyyZoyOQkrvgBN/Og8vfOjaRhm01DwxqWCxwFR6qTyuwf8gt Pa/z0aR/AceFKVD+c9BCy7139HWAs0VlNtvARByadKUJaY1TA/1tfNTZCrPN17QQhg2tJSm3Mp5z 6leUTuF1U317j7aZVYMxggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMFFf4wCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTMwOTE4MjIzNjU0WjAjBgkqhkiG9w0BCQQxFgQUT2G1E68In7CN9oZHfc92RAJAv8ww gaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFFf4wgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUV/jANBgkq hkiG9w0BAQEFAASCAQBxfsV2oQsF+B/RvAR8waHu/2ejrHI5mFjuCC3e/SggyJ2Tlp+/Dg+Yu4Qb bIfic0nsJc8sOHLMwQa/mLGXF0BvepV79zQt1Yibqm2U/lVPww6KoPe2AgdczCQkDOFPMgkwgJUp G9km6/AWVoxsfQTbb9Zzth/AuYy0FHde7Ta5FldM5urNZK+MXKwdBL62k2WyjAk+dUVoieEEcBjG sqd/nafp7FZMbIGfEYfhmpcDF3Vh3kiCCkqpio4qIQsjjnNd1k6rUFUMbawW8v7qOKAAy8rhq5X6 v+095O/j0qMRvvRyuDpwoIAlH/pH/Lzkrvizm4iLXQcFp89vy8by+styAAAAAAAA --=-+6b26UK+r6gFfs9Vfjt5-- From lem@isc.org Wed Sep 18 15:59:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1807311E825E for ; Wed, 18 Sep 2013 15:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxT26oDrjzhj for ; Wed, 18 Sep 2013 15:59:26 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 4649111E80D9 for ; Wed, 18 Sep 2013 15:59:23 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 54085C94EE; Wed, 18 Sep 2013 22:59:16 +0000 (UTC) (envelope-from lem@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379545163; bh=091HiWYKl+6Hx43W0rG8TdVVQoNmNQ15SXqwxUJ+3DM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dW4N8VO8VvmhQT+3vYnjkiSwH+Fyozxn8yioHukJBoC+x/vuYMY1WUcg/epnsegIf Bdey6LuEiH9YYzrfvJTXTYokaiPUvlQWQ0dqF300C/fUeKPdJP3Y6tsTQuDlvRVa7j RTscLYro0wxruFV7yaF36IPtEqkI6zwttubUS/YE= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 22:59:16 +0000 (UTC) (envelope-from lem@isc.org) Received: from lembook.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CE4A2216C25; Wed, 18 Sep 2013 22:59:15 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Wed, 18 Sep 2013 18:59:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9E62BABA-6A8F-45DF-BAF2-ACF360AFDB9D@isc.org> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: Jay Daley X-Mailer: Apple Mail (2.1283) X-DCC--Metrics: post.isc.org; whitelist Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:59:27 -0000 On Sep 18, 2013, at 5:56 PM, Jay Daley wrote: > We came to the conclusion that a manual verification (or possibly = another out-of-band verification) does not need to be to the registrant = but works perfectly well to the registrar. That of course is much = better for those of us that need to maintain the = registry->registrar->registrant model and not introduce a = registry->registrant component. I think a Registry <-> Registrant component is unavoidable for this type = of service. The Registrant likely wants assurances that the Domain won't = be changed in any way without her consent. Best regards -lem From jay@nzrs.net.nz Wed Sep 18 16:29:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F16E11E815B for ; Wed, 18 Sep 2013 16:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_05=-1.11, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PajH31whaJxd for ; Wed, 18 Sep 2013 16:29:40 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 48A2311E80AD for ; Wed, 18 Sep 2013 16:29:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 2F8864B66C7; Thu, 19 Sep 2013 11:29:37 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0h08OkHxHVp; Thu, 19 Sep 2013 11:29:29 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id C90F44B6280; Thu, 19 Sep 2013 11:29:29 +1200 (NZST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> Date: Thu, 19 Sep 2013 11:29:30 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> To: Francisco Obispo X-Mailer: Apple Mail (2.1510) Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:29:45 -0000 Hi Francisco On 19/09/2013, at 10:41 AM, Francisco Obispo wrote: > Hi Jay, >=20 > Let me give you another example, >=20 > A registrar mistakenly changes a record (even authorizes a change), = without its client knowing about it, the domain name goes offline, or = even worse, gets hijacked.=20 How exactly do you think a registrar can mistakenly authorise a change = via an OOB mechanism? =20 In my view, the threats and realistic likelihood of those threats, are: 1. The registrar is hacked and the miscreant sends a change request = using the registrar credentials. [Likelihood =3D Possible] 2. The registrar mistakenly requests a change. [Likelihood =3D = Unlikely] 3. The registrar mistakenly requests a change and then also mistakenly = authorises the OOB challenge. [Likelihood =3D Very Rare] I would also suggest that the likelihood of 3 is exactly the same as the = two following: 4. The registrar mistakenly requests a change and then the *registrant* = mistakenly authorises the OOB challenge. [Likelihood =3D Very Rare] 5. The *registrant* mistakenly requests a change and then also = mistakenly authorises the OOB challenge. [Likelihood =3D Very Rare] >=20 > My idea of a registry lock is to have a direct relationship with the = registrant/name holder, so it can decide wether the domain name is = allowed to be changed by the registrar. The implications of that are significant. Both for the registry and = registrar. Those implications include: - how does the registry authenticate the registrant (compare delivering = one secure token to each registrar with delivering one to each = registrant)? - the risk that the registry will use the relationship for something = they shouldn't=20 - potentially (depending on how it is set up) the need for the registry = to have a customer support team and what happens if the registrant gets = poor customer service from the registry? I would be very careful at rushing into the idea that the registry must = have a direct relationship with the registrar if I were you. Doing it = via the registrar is the path of least resistance and less risk. > Verisign offers a registry lock, so perhaps they can share a little = bit on how they do it, and how they authenticate the request in cases = where contact privacy is enabled. There are a number of registries that do it who are part of CENTR and = gave presentations on it recently: .dk =95 registrants have direct contact with registry =95 VID Service (Very Important Domain) - only 1000 VID out of = 1.2 million active domains =95 uses a snail mail approach to enact changes. very robust, = but slow which dies frustrate some people =95 charge 50 krona per annumn (5 pds Sterling) .cz =95 registrant asks registry for change. Can lock two things =95 just transfer =95 lock all changes =95 done via letter which can be downloaded from website =95 offered as a free service =95 have about 5,000 out of 1 million =95 registrars have all locked their own domains .nl =95 service called .nl control =95 lock all data, but not name servers =95 it is a manual process =95 sold for 50 Euros per annum =95 numbers sold are very low Jay >=20 >=20 >=20 > On Sep 18, 2013, at 4:56 PM, Jay Daley wrote: >=20 >> We came to the conclusion that a manual verification (or possibly = another out-of-band verification) does not need to be to the registrant = but works perfectly well to the registrar. That of course is much = better for those of us that need to maintain the = registry->registrar->registrant model and not introduce a = registry->registrant component. >=20 > Francisco Obispo=20 > email: fobispo@isc.org > Phone: +1 650 423 1374 || INOC-DBA *3557* NOC > PGP KeyID =3D B38DB1BE >=20 >=20 >=20 >=20 --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From michele@blacknight.com Wed Sep 18 16:32:35 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D76411E8166 for ; Wed, 18 Sep 2013 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVuofhkTEn5x for ; Wed, 18 Sep 2013 16:32:31 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3911E80AD for ; Wed, 18 Sep 2013 16:32:30 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::b89b:6394:5849:df5c]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0342.003; Thu, 19 Sep 2013 00:32:30 +0100 From: Michele Neylon - Blacknight To: =?iso-8859-1?Q?Luis_Mu=F1oz?= Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOtMKxlfOvQDINcEe9nT42BBojD5nMFGYA Date: Wed, 18 Sep 2013 23:32:29 +0000 Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> In-Reply-To: <20130918225728.140C65A400F@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:32:35 -0000 On 18 Sep 2013, at 23:59, Luis Mu=F1oz wrote: >=20 > On Sep 18, 2013, at 5:56 PM, Jay Daley wrote: >=20 >> We came to the conclusion that a manual verification (or possibly anothe= r out-of-band verification) does not need to be to the registrant but works= perfectly well to the registrar. That of course is much better for those = of us that need to maintain the registry->registrar->registrant model and n= ot introduce a registry->registrant component. >=20 > I think a Registry <-> Registrant component is unavoidable for this type = of service. The Registrant likely wants assurances that the Domain won't be= changed in any way without her consent. Luis The registry has no contractual relationship with the registrant The registrant has a contractual relationship with the registrar The registrar has a contractual relationship with the registry So - no. Regards Michele >=20 > Best regards >=20 > -lem >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation http://www.blacknight.co/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From lem@isc.org Wed Sep 18 16:37:35 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BBB11E8104 for ; Wed, 18 Sep 2013 16:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK6Kgma2xhS1 for ; Wed, 18 Sep 2013 16:37:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D200411E80AD for ; Wed, 18 Sep 2013 16:37:34 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B3ED7C9425; Wed, 18 Sep 2013 23:37:27 +0000 (UTC) (envelope-from lem@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1379547454; bh=uzKy5eyYyDt8jSGPJjTkEp+bjPPgYfE/cE2KgoQkbt4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=PqQnVhqC1uY9OY6JKv+Gfo2hpbgvM2Xl8QxwTleiG09/3G3dyz76tAJ5qJcMSV8pP uSTFO5bGznPbSjUdfW9c/A7+buFXEXmNgsj1Mjw3Fz+dsbtFqmU00GoZs4hVxe1Vi6 +cvhQoAAyoCJ9eQoYgazI9EBZCvJIj8Gnu+Ajv4g= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 18 Sep 2013 23:37:27 +0000 (UTC) (envelope-from lem@isc.org) Received: from lembook.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 302FE216C1E; Wed, 18 Sep 2013 23:37:27 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Wed, 18 Sep 2013 19:37:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C67CBC5-44D3-49F5-BB3E-4F63991A4D75@isc.org> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> To: Michele Neylon - Blacknight X-Mailer: Apple Mail (2.1283) X-DCC--Metrics: post.isc.org; whitelist Cc: "" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:37:35 -0000 On Sep 18, 2013, at 7:32 PM, Michele Neylon - Blacknight wrote: > The registry has no contractual relationship with the registrant >=20 > The registrant has a contractual relationship with the registrar >=20 > The registrar has a contractual relationship with the registry >=20 > So - no. Your description of the status quo is consistent with mine. That only = means that the status quo is suboptimal to address a specific market = need. If you look at Jay's example, it's clear that 2 out of 3 examples show = an explicit relationship between the registrant and the registry. In the = .nl case it's not clear whether such relationship exists or not. Best regards -lem From jay@nzrs.net.nz Wed Sep 18 16:54:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3566B11E8104 for ; Wed, 18 Sep 2013 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dGDyb3YDfqs for ; Wed, 18 Sep 2013 16:54:13 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id AC18411E80D3 for ; Wed, 18 Sep 2013 16:54:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 8873D4B66D6; Thu, 19 Sep 2013 11:54:12 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YF5Pdgm4rCT; Thu, 19 Sep 2013 11:54:05 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 257694B66D5; Thu, 19 Sep 2013 11:54:05 +1200 (NZST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 19 Sep 2013 11:54:06 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <844A4BFA-2923-4E0A-B2B3-3B67E747A59B@nzrs.net.nz> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 23:54:18 -0000 Good news, thanks Scott and thanks for offering to co-chair. I'll make = the time to review. Jay On 18/09/2013, at 11:20 PM, "Hollenbeck, Scott" = wrote: > I recently closed a conversation with Applications Area Director Pete = Resnick to see what he thought about a narrowly-focused charter for a = working group to develop a registry for EPP extensions. Pete has agreed = with the concept in principal. I'm including the text of the proposed = charter that I shared with Pete and I'd like to ask others to review it = and share feedback as appropriate. >=20 > If we have enough support for a proposed charter Pete is willing to = entertain a chartering request. If there's more to discuss we can ask = about scheduling a BOF during the Vancouver meeting. >=20 > I've got one specific question: are people able and willing to write a = draft (or drafts) that describe(s) the registry and registration = procedures? I don't think this will be a difficult task because cloning = an existing registry is a perfectly reasonable approach, but someone = needs to do the work. I'm willing to co-chair (if you all will have me) = if we form a working group, and thus it would be best if we find other = volunteers to write documents. >=20 > Scott > ---------- --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From michele@blacknight.com Wed Sep 18 17:05:30 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1293F11E814D for ; Wed, 18 Sep 2013 17:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjRw6Px-h1Zy for ; Wed, 18 Sep 2013 17:05:26 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0BE11E80D3 for ; Wed, 18 Sep 2013 17:05:25 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::b89b:6394:5849:df5c]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0342.003; Thu, 19 Sep 2013 01:05:23 +0100 From: Michele Neylon - Blacknight To: =?iso-8859-1?Q?Luis_Mu=F1oz?= Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOtMKxlfOvQDINcEe9nT42BBojD5nMFGYAgAABX4CAABfxCQ== Date: Thu, 19 Sep 2013 00:05:23 +0000 Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> , <20130918233540.9598A5A4010@merlin.blacknight.ie> In-Reply-To: <20130918233540.9598A5A4010@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 00:05:30 -0000 Luis=0A= =0A= Jay's examples are from ccTLDs where there is tripartite contractual relati= onship in many cases.=0A= =0A= In the gTLD space that does not exist and is highly unlikely to ever exist.= =0A= =0A= Regards=0A= =0A= Michele=0A= =0A= --=0A= Mr Michele Neylon=0A= Blacknight Solutions=0A= Hosting & Colocation, Domains=0A= http://www.blacknight.co/=0A= http://blog.blacknight.com/=0A= http://mneylon.tel/=0A= Intl. +353 (0) 59 9183072=0A= Locall: 1850 929 929=0A= Direct Dial: +353 (0)59 9183090=0A= Fax. +353 (0) 1 4811 763=0A= Twitter: http://twitter.com/mneylon=0A= -------------------------------=0A= Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty= =0A= Road,Graiguecullen,Carlow,Ireland Company No.: 370845=0A= =0A= ________________________________________=0A= From: Luis Mu=F1oz [lem@isc.org]=0A= Sent: 19 September 2013 00:37=0A= To: Michele Neylon - Blacknight=0A= Cc: Jay Daley; =0A= Subject: Re: [provreg] Registry lock - two-factor or intervention=0A= =0A= On Sep 18, 2013, at 7:32 PM, Michele Neylon - Blacknight wrote:=0A= =0A= > The registry has no contractual relationship with the registrant=0A= >=0A= > The registrant has a contractual relationship with the registrar=0A= >=0A= > The registrar has a contractual relationship with the registry=0A= >=0A= > So - no.=0A= =0A= Your description of the status quo is consistent with mine. That only means= that the status quo is suboptimal to address a specific market need.=0A= =0A= If you look at Jay's example, it's clear that 2 out of 3 examples show an e= xplicit relationship between the registrant and the registry. In the .nl ca= se it's not clear whether such relationship exists or not.=0A= =0A= Best regards=0A= =0A= -lem=0A= =0A= From jarle@uninett.no Wed Sep 18 23:37:07 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B97B21F9BB5 for ; Wed, 18 Sep 2013 23:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJONuNsPushA for ; Wed, 18 Sep 2013 23:37:01 -0700 (PDT) Received: from festningen.uninett.no (festningen.uninett.no [IPv6:2001:700:1:60:290:27ff:fe54:ae62]) by ietfa.amsl.com (Postfix) with ESMTP id 551D221F9B9F for ; Wed, 18 Sep 2013 23:37:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by festningen.uninett.no (Postfix) with ESMTP id A435080AC6; Thu, 19 Sep 2013 08:36:57 +0200 (CEST) Date: Thu, 19 Sep 2013 08:36:57 +0200 (CEST) Message-Id: <20130919.083657.435222138.jarle@uninett.no> To: jay@nzrs.net.nz From: Jarle Greipsland In-Reply-To: References: <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> X-Mailer: Mew version 6.5 on Emacs 24.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 06:37:07 -0000 Jay Daley writes: [ ... ] > How exactly do you think a registrar can mistakenly authorise a change via an OOB mechanism? > > In my view, the threats and realistic likelihood of those threats, are: > > 1. The registrar is hacked and the miscreant sends a change request using the registrar credentials. [Likelihood = Possible] > > 2. The registrar mistakenly requests a change. [Likelihood = Unlikely] > > 3. The registrar mistakenly requests a change and then also mistakenly authorises the OOB challenge. [Likelihood = Very Rare] 3b. The registrar deliberately, as a result of e.g. social engineering or blackmail, requests a change and then also deliberately authorises the OOB challenge. [Likelihood = ??] -jarle From Antoin.Verschuren@sidn.nl Thu Sep 19 00:31:39 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD221F960E for ; Thu, 19 Sep 2013 00:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gczXuLeLx9B6 for ; Thu, 19 Sep 2013 00:31:35 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id CCC5721F93E1 for ; Thu, 19 Sep 2013 00:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=wTqhbcukP8cYBqDAbKYOkcZVB8D+T04i7amtohR2l1E=; b=yzHtYhCCLSvxFv/dOW7GcoVenwrlJn7B3N0++bAGDO3oFnTzwgSlz0Deh6fM6wiHgNFbrbNL673aUWcm46337ClFZUKPy2vC044E1Tc7u8mny4/O5UK830gQA+XYPm5N4t2w2HXtcufstLhLbnUmcvp9SQCpJXm/sQcKYygHOag= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r8J7VX1B017714-r8J7VX1D017714 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Sep 2013 09:31:33 +0200 Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 09:31:32 +0200 Message-ID: <523AA854.1070009@sidn.nl> Date: Thu, 19 Sep 2013 09:31:32 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 07:31:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Scott, I feel a conflict of interest writing on the registration procedures, but I'm happy to review and participate in the wg. Op 18-09-13 13:20, Hollenbeck, Scott schreef: > I've got one specific question: are people able and willing to > write a draft (or drafts) that describe(s) the registry and > registration procedures? I don't think this will be a difficult > task because cloning an existing registry is a perfectly reasonable > approach, but someone needs to do the work. I'm willing to co-chair > (if you all will have me) if we form a working group, and thus it > would be best if we find other volunteers to write documents. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSOqhPAAoJEDqHrM883AgnfCIH/2a46fQL9ZLZQ1DDK9YETflv PihNrEX8lf1XH/Lixyi3BZSiqA0KhVzpoKrNhxqQmCWd3V5QJXXV57KvYBbGL17z WM9UZOdElX9Vl5PRoIeRUNqMt4JrnEmhMFNrZbVOmvGf5GAS9m9idhT5f80HpJ9j PQYRZso+OcNagvv4mnc00w8YVxlw2dCo+NqOF5fJDLT5T2jU0tlH8pHnI0ewTWbF eWThUTPnnFAmCu0lHaXM6xuoXKj0oZ9nOWX3CHgN3Bsr76zKDS+4nnDy3umk6vqJ rp4uP4hIqeqoTSxWS23d8kn0HXZX7EP+FAOi3ba+LtioYf0qoeoddH9o+ppEfic= =V8KU -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Thu Sep 19 01:35:16 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B718421F99F3 for ; Thu, 19 Sep 2013 01:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65GP7wK3xe0c for ; Thu, 19 Sep 2013 01:35:12 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id F330621F99EF for ; Thu, 19 Sep 2013 01:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=7QCE7bPUgEFjTSyBFjbAL27nWsS6E0Uhq+3t7dVTxWg=; b=Cq5d0QJ/H74PhmN2MWut6iCZMF5MdU2gUerIWRZfktK9IQI82Br++YJUqceAUeMS1YzixGLdodXWdbxLZ2FVT3w5KSYdPZ4oGJXEymnAuK8V/kFjvMb2y+7q9u1Yg64jcI+holIW0bA0kwlAvI4MIa/J4jCAwHisWnQYp2Ug98w= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r8J8Z3rK020440-r8J8Z3rM020440 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Sep 2013 10:35:03 +0200 Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 10:35:03 +0200 Message-ID: <523AB737.9090503@sidn.nl> Date: Thu, 19 Sep 2013 10:35:03 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:35:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 19-09-13 01:32, Michele Neylon - Blacknight schreef: > The registry has no contractual relationship with the registrant > > The registrant has a contractual relationship with the registrar > > The registrar has a contractual relationship with the registry Michele, This is not the general case, so your statement is biased. In .nl, there is a contractual relationship between registrant and registry. The role of the registrar is to offload administrative burden of the registry, the registrar acts as an administrative agent for the registrant. But technically there is always the parent-child relationship between registry and registrar in the form of a DNS delegation, so legally (at least in our jurisdiction) it cannot be denied that a registry is offering a service to a registrant. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSOrc3AAoJEDqHrM883AgnIdkIAKAz9IEtbUBm4sJS7TC2fgig bbf6nXfsyRhhhA32I3NHBMeRTegjC32US/VD6jpLPS+kP87Zus0EGQdVX8yEZqWM D8w6Dnlz2xfH+XtVtj8u8QuBCw1HVkVRsgAogpUF875PKSZNB8i38ILqBaM4D8kR Ev45LDMFXA2g4O0dyOSWDIBvbfoaqLHy28cCKnTnyBLQUbwgd2gEeuQW31XrbRI6 VFPN64N+oLZO3XKrOuGvMdRqHZbFlN84GzGDk5nu2Xzg0dwgn1shZpBUajwWpMNQ zfcDyTxGfMfiKvQyDMasNzu3VbLW7BQ9RmZMS5zcSfp2FE/ZxiZOT7cc2jvHyxE= =87Hl -----END PGP SIGNATURE----- From Marco.Davids@sidn.nl Thu Sep 19 01:35:23 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC5A21F99FD for ; Thu, 19 Sep 2013 01:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTi65gQiSNN8 for ; Thu, 19 Sep 2013 01:35:19 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 1001C21F99F4 for ; Thu, 19 Sep 2013 01:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:openpgp:content-type:x-originating-ip; bh=o6TzovSmBFawiaYYOwXwi4VVeCh7zufoIuYMSbn1EeI=; b=f0b78+amfVtSqQOG0WGEEfmANVaN2p+BTgvIeA1hPcJZVOs7YQVgbrPzNecBwQycVnKXWPtxtpiof+r8tNFgAVRqlcoMb8PFhlXuQQdVomOrdSZtLjK1RrdgBCPr9RblEaO6mxhZUk9k3B30r0ZXYgWYc/bkJbQzyVf0hroy9ic= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r8J8ZILR020479-r8J8ZILT020479 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Sep 2013 10:35:18 +0200 Received: from [94.198.152.217] (94.198.152.217) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 10:35:17 +0200 Message-ID: <523AB745.5020706@sidn.nl> Date: Thu, 19 Sep 2013 10:35:17 +0200 From: "Marco Davids (SIDN)" Organization: SIDN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=9F781B52 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060905020001010505010301" X-Originating-IP: [94.198.152.217] Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:35:23 -0000 --------------ms060905020001010505010301 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/19/13 01:29, Jay Daley wrote: > In my view, the threats and realistic likelihood of those threats, are= : >=20 > 1. The registrar is hacked and the miscreant sends a change request us= ing the registrar credentials. [Likelihood =3D Possible] That's an understatement. Sooner or later this will happen to some registrar(s) We've had that experience with some of our registrars, so have others (most of us probably remember the New York Times incident). http://blog.fox-it.com/2013/08/05/dns-takeover-redirects-thousands-of-web= sites-to-malware/ > .nl > =95 service called .nl control > =95 lock all data, but not name servers Locking of (in zone) name servers will be possible in due time with 'nl-Control'. After the incident above, we have speeded up the development of that feature. > =95 it is a manual process > =95 sold for 50 Euros per annum That's is probably a retail price. Wholesale prices are considerably lower (but upon request of our registrars we refrain from publishing wholesale prices). > =95 numbers sold are very low Surprisingly low, given the risks involved. -- Marco SIDN --------------ms060905020001010505010301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMZjCC BiowggUSoAMCAQICAwa6NTANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTEzMDUzMTExMDk0MloXDTE0MDYwMjAzMjc1NFowRDEdMBsGA1UE AwwUbWFyY28uZGF2aWRzQHNpZG4ubmwxIzAhBgkqhkiG9w0BCQEWFG1hcmNvLmRhdmlkc0Bz aWRuLm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyajTCa3uBAPAiQrrqCDe mzW5wvxaovW3h1/dCzfEuR/OZRYlgQg0dRsrGPMs+Wg2wwqPvvjsF/YQ2AeXxpzAIQVHywI5 zgZwptg0+Lv4UvFZFwHw5xdB2STvVIXFG7fuTyk5D0MkhhsO/MHjOmSucDzkH6CW/TgiBxkJ bSXIc+YOKZlI1E1q9V10rR2NW4VD27/AO71Va6sfA33qbY2MGvjR9UPB9bBjwsczeCulpNhE rIU7K4tWhgcd1DTUgz8P6pHw5bqRMzxfIQW3yHg5SnXjugCxLIfKBxIN7uXrqVmf0+haU3K/ tc6Wjl9JYjzXsdhempN1eRI3clyl6jS8YQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADALBgNV HQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRn3ugN 5hkGkJ5A8hb1D6n4GcsppTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HREEGDAWgRRtYXJjby5kYXZpZHNAc2lkbi5ubDCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYB BAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xp Y3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0 aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21w bGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcB AQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNz MS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBALqkjS+NnMxn/trjz71UHJEeiNJ7rbgNxk1+ RdhMw2TKiGocYa2Ql7TfCjgknCaakk7m54Spmr7AdbSVKVffmxQFzUaq5Or5HAMtqRfWJLh1 A94gOMPaRErdoRF0PLGPrwJPbxMAH4lTOIwpRqSVnUepG4pJKEBYFMXRWBW6nSs4/RJSscAP 70qoyX/MOPWFZjuxRU9d/gqQt4rNjf3Ojq+j3omI3oS/LgVUAyCdEsg7M0SEC5eG/kxLTCH9 bzY7A98/g55OENAsVQlP43GNr+hojOva9VDyeYQTktt0AtYheb29Za/Grw7cP9UAFzOdlsDA 5uL4TzfzDsk2BIwt2ZEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5 IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zP f1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG /FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSy rrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIB qTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssB XHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUH AQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYB BQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCeg JaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBm MC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqG SIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95 CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A +hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcL N5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/ O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI27 0g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z 77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/Q vVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8 BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZAgEBMIGU MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwa6NTAJBgUrDgMCGgUAoIIC HTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5MTkwODM1 MTdaMCMGCSqGSIb3DQEJBDEWBBTi0zpDhOLUziP9evGE5Z+pV1JvPjBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3 EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBro1MIGnBgsq hkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMG ujUwDQYJKoZIhvcNAQEBBQAEggEAO2t/LfV9h+zLrQyMMC9sNQ+UCASihOZ4OlHoEWzWXSXb 5FeqxKDSGQlFMPV02mD1+dcosVMsVBuG8TPN8Z/XSqGihheI454oESc/dc7JNIlwl0Er7mfl cC/QUCP8lnDpttCqqfyU/4fG7si0sKeEJzAcYZZWlgJj+uPNc/qIoiCzgO74vnkNIsDD0D0G AN+9FX8AzAxq6aqHZs5d/4W/LOIzH6Eabypo0s9nMJ7DWpOm81hbI3yCMpG1S6MnOnP+zjdj QTS+MnXgmDJ88CWXVOmrHMNuxKfWIX1mKYT7K9aeSIZR+RneZy/ABfWEnxcF2qY2yL/VMVFK TQiLmQ8g4gAAAAAAAA== --------------ms060905020001010505010301-- From Antoin.Verschuren@sidn.nl Thu Sep 19 01:41:08 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AB521F99EF for ; Thu, 19 Sep 2013 01:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkLUSfIQdFEg for ; Thu, 19 Sep 2013 01:41:04 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 487E421F91C9 for ; Thu, 19 Sep 2013 01:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=stPQoZD988c9gim/LosaBsaT9n0bU/pYae+j6j0sBEU=; b=H77UJIwV/BMzX7uJ7Us2oiH7vAHaGQrmfWKJuEOl+bHUQrfLHnaMypV2LFCMXaBc3hkmoTQz26jtyvTEOjT18kLCjeSYC4K2N5IHQiuhL4/jDJRGXFIVkgry8guScgiMKBSMG5IpohegdkHyov6cJi+7NNyWz0PN9RbszpjklE8= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r8J8f3SR020595-r8J8f3ST020595 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Sep 2013 10:41:03 +0200 Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 10:41:03 +0200 Message-ID: <523AB89E.9070304@sidn.nl> Date: Thu, 19 Sep 2013 10:41:02 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <24E5E7F7-B61C-4DD8-859E-69584234F1E8@isc.org> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:41:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 19-09-13 01:29, Jay Daley schreef: > .nl • service called .nl control • lock all data, but not name > servers • it is a manual process • sold for 50 Euros per annum • > numbers sold are very low To clarify, we are currently redesigning our .nl control service to include name server changes, and possibly DNSSEC parameter changes. We are also aiming to automate the service when we reach about 250 .nl control domains. We would like to implement a common standard, so I'm interested in this discussion. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSOrieAAoJEDqHrM883AgnS+4H/10vsgvfwVIEYQi1/NZtF247 Q0l61e+xvQSLVKPraaztgIloqH1mqLy5MPvXdLmEbQp7fU8Hg1GKaeISny1A7TGJ cb6Y/v1N3UnJ775mxsL3FZiKgKwLMC/M+jW7HhzyXxtl36KSGJMGq/CDVOX/jNBt ydrNGYPAzPNtuq8+DB6kjll3soOxtK0VeGtkO3JgAYeX5M/eooPwZlUwDORg6jUt /fhaRZd0k7TcWa7qENoD7AAJRBfU3/iOgcGcOrPIl4z8Lc980WmCYeXUaWZQcblF +zuT8Yhp3oAf3hStkNjG/STUTxuM7j1kK+jvCpG7NRyNznUU2T6MEKfKe2y6a28= =lB2b -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Thu Sep 19 01:45:28 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C353321F99EF for ; Thu, 19 Sep 2013 01:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWN3P1Suz3-H for ; Thu, 19 Sep 2013 01:45:23 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 7856921F944C for ; Thu, 19 Sep 2013 01:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=u6yafwHmcF4VwBQFahFbOvA/LCQeUCvI4yE3eZUKDy0=; b=iOo7Bn4lWYSJzOTAsgzQXD614BenBS/12bwKQhCI43XIcfM2u2ThASDJnlitlFj0OMYHSXJVSZbeuQuEcneBUxjrPmwnPMJfzTaKFRZ2JL21uXE+erTZQKFwvIVBdZEh5S+zuYnrByOVDmHlMxDy6CUOUa10IMWkqqg2eMJkzwY= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r8J8jMRA020711-r8J8jMRC020711 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Thu, 19 Sep 2013 10:45:22 +0200 Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 10:45:22 +0200 Message-ID: <523AB9A2.8030309@sidn.nl> Date: Thu, 19 Sep 2013 10:45:22 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> <523AB737.9090503@sidn.nl> In-Reply-To: <523AB737.9090503@sidn.nl> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:45:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 19-09-13 10:35, Antoin Verschuren schreef: > Op 19-09-13 01:32, Michele Neylon - Blacknight schreef: > >> The registry has no contractual relationship with the registrant > >> The registrant has a contractual relationship with the registrar > >> The registrar has a contractual relationship with the registry > > Michele, > > This is not the general case, so your statement is biased. In .nl, > there is a contractual relationship between registrant and > registry. The role of the registrar is to offload administrative > burden of the registry, the registrar acts as an administrative > agent for the registrant. But technically there is always the > parent-child relationship between registry and registrar in the > form of a DNS Oops, this is a typo, I meant between registry and registrant. > delegation, so legally (at least in our jurisdiction) it cannot be > denied that a registry is offering a service to a registrant. > > _______________________________________________ provreg mailing > list provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSOrmiAAoJEDqHrM883AgnL/QIALAZVIeGaL1e/oyXGwaaNCc4 7W7UZpshQq2sl6EbS0AQBJ1e7nH28+rZleSgufcM9pHOhO6JRdXwd1mXlMlPm3jc UhdyQWmLjiNdv8HbxS7rbHA0FJKYzuZoo7GNMuigapjkukvUVaw5LBehe2vvmXuJ higyscmWhrEjSyETAwXz+YQywBEa1apQ8n62YAcIOB+igkSZ0bmi3iRaO6pNJKYA If6JG4mZ9GWSwXhyZjI2b0VRXgpwXANLcj/7gSj85DIpcUea4XeruhC7HU4OZ3oW Qn6b04ihQEgcxcAzE0SgcMHX0+iytkdSRQ8nQX49MDWSXm4PwDRxINwxu8jTqH4= =Cpy+ -----END PGP SIGNATURE----- From michele@blacknight.com Thu Sep 19 02:22:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9321F99E1 for ; Thu, 19 Sep 2013 02:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjHAAHaCRasK for ; Thu, 19 Sep 2013 02:22:41 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4FB21F9339 for ; Thu, 19 Sep 2013 02:22:40 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::b89b:6394:5849:df5c]) by bkexchhubcas01.blacknight.local ([fe80::994e:1bb8:df56:f591%15]) with mapi id 14.02.0342.003; Thu, 19 Sep 2013 10:22:36 +0100 From: Michele Neylon - Blacknight To: Antoin Verschuren Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOtMKxlfOvQDINcEe9nT42BBojD5nMFGYAgACXloCAAA1JAA== Date: Thu, 19 Sep 2013 09:22:36 +0000 Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> In-Reply-To: <20130919083317.977495A400F@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.17.243.251] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 09:22:45 -0000 DQpPbiAxOSBTZXAgMjAxMywgYXQgMDk6MzUsIEFudG9pbiBWZXJzY2h1cmVuIDxBbnRvaW4uVmVy c2NodXJlbkBzaWRuLm5sPiB3cm90ZToNCg0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FH RS0tLS0tDQo+IEhhc2g6IFNIQTENCj4gDQo+IE9wIDE5LTA5LTEzIDAxOjMyLCBNaWNoZWxlIE5l eWxvbiAtIEJsYWNrbmlnaHQgc2NocmVlZjoNCj4gDQo+PiBUaGUgcmVnaXN0cnkgaGFzIG5vIGNv bnRyYWN0dWFsIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSByZWdpc3RyYW50DQo+PiANCj4+IFRoZSBy ZWdpc3RyYW50IGhhcyBhIGNvbnRyYWN0dWFsIHJlbGF0aW9uc2hpcCB3aXRoIHRoZSByZWdpc3Ry YXINCj4+IA0KPj4gVGhlIHJlZ2lzdHJhciBoYXMgYSBjb250cmFjdHVhbCByZWxhdGlvbnNoaXAg d2l0aCB0aGUgcmVnaXN0cnkNCj4gDQo+IE1pY2hlbGUsDQo+IA0KPiBUaGlzIGlzIG5vdCB0aGUg Z2VuZXJhbCBjYXNlLCBzbyB5b3VyIHN0YXRlbWVudCBpcyBiaWFzZWQuDQoNClNvIGlzIHlvdXIg cmVhY3Rpb24NCjopDQoNCg0KDQo+IEluIC5ubCwgdGhlcmUgaXMgYSBjb250cmFjdHVhbCByZWxh dGlvbnNoaXAgYmV0d2VlbiByZWdpc3RyYW50IGFuZA0KPiByZWdpc3RyeS4NCg0KDQpZZXMsIGJ1 dCB0aGVyZSBpcyBub3JtYWxseSBubyBjb250cmFjdHVhbCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGUgcmVnaXN0cnkgYW5kIGEgcmVnaXN0cmFudCBpbiBnVExEcywgd2hpY2ggaXMgd2hhdCBJIHdh cyB0aGlua2luZyBhYm91dC4NCg0KPiBUaGUgcm9sZSBvZiB0aGUgcmVnaXN0cmFyIGlzIHRvIG9m ZmxvYWQgYWRtaW5pc3RyYXRpdmUgYnVyZGVuIG9mIHRoZQ0KPiByZWdpc3RyeSwgdGhlIHJlZ2lz dHJhciBhY3RzIGFzIGFuIGFkbWluaXN0cmF0aXZlIGFnZW50IGZvciB0aGUNCj4gcmVnaXN0cmFu dC4NCg0KV293ISBUaGF0J3MgYWN0dWFsbHkgaW5jcmVkaWJseSBvZmZlbnNpdmUgdG8gcmVnaXN0 cmFycy4NCg0KU28gYW55IHRpbWUgdGhlcmUgYXJlICphbnkqIGlzc3VlcyB3aXRoICphbnkqIGRv bWFpbnMgb2YgYW55IGtpbmQgSSBjYW4ganVzdCBzZW5kIGFsbCB0aGUgcmVnaXN0cmFudHMsIHVz ZXJzIGFuZCAkcmFuZG9tIDNyZCBwYXJ0aWVzIGRpcmVjdGx5IHRvIHRoZSByZWdpc3RyeT8NCg0K R3JlYXQuDQoNCkknbGwgYmUgYWJsZSB0byBsYXkgb2ZmIG1vc3Qgb2YgbXkgc3RhZmYNCg0KUmVn YXJkcw0KDQpNaWNoZWxlDQoNCg0KPiBCdXQgdGVjaG5pY2FsbHkgdGhlcmUgaXMgYWx3YXlzIHRo ZSBwYXJlbnQtY2hpbGQNCj4gcmVsYXRpb25zaGlwIGJldHdlZW4gcmVnaXN0cnkgYW5kIHJlZ2lz dHJhciBpbiB0aGUgZm9ybSBvZiBhIEROUw0KPiBkZWxlZ2F0aW9uLCBzbyBsZWdhbGx5IChhdCBs ZWFzdCBpbiBvdXIganVyaXNkaWN0aW9uKSBpdCBjYW5ub3QgYmUNCj4gZGVuaWVkIHRoYXQgYSBy ZWdpc3RyeSBpcyBvZmZlcmluZyBhIHNlcnZpY2UgdG8gYSByZWdpc3RyYW50Lg0KPiANCj4gLSAt LSANCj4gQW50b2luIFZlcnNjaHVyZW4NCj4gDQo+IFRlY2huaWNhbCBQb2xpY3kgQWR2aXNvciBT SURODQo+IE1lYW5kZXIgNTAxLCBQTyBCb3ggNTAyMiwgNjgwMiBFQSBBcm5oZW0sIFRoZSBOZXRo ZXJsYW5kcw0KPiANCj4gUDogKzMxIDI2IDM1MjU1MDAgIE06ICszMSA2IDIzMzY4OTcwDQo+IE1h aWx0bzogYW50b2luLnZlcnNjaHVyZW5Ac2lkbi5ubA0KPiBYTVBQOiBhbnRvaW4udmVyc2NodXJl bkBqYWJiZXIuc2lkbi5ubA0KPiBIVFRQOi8vd3d3LnNpZG4ubmwvDQo+IC0tLS0tQkVHSU4gUEdQ IFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHIHYxLjQuMTEgKEdOVS9MaW51eCkNCj4g DQo+IGlRRWNCQUVCQWdBR0JRSlNPcmMzQUFvSkVEcUhyTTg4M0Fnbklka0lBS0F6OUlFdGJVQm00 c0pTN1RDMmZnaWcNCj4gYmJmNm5YZnN5UmhoaEEzMkkzTkhCTWVSVGVnakMzMlVTL1ZENmpwTFBT K2tQODdadXMwRUdRZFZYOHlFWnFXTQ0KPiBEOHc2RG5sejJ4ZkgrWHRWdGo4dThRdUJDdzFIVmtW UnNnQW9ncFVGODc1UEtTWk5COGkzOElMcUJhTTREOGtSDQo+IEV2NDVMRE1GWEEyZzRPMGR5T1NX RElCdmJmb2FxTEh5MjhjQ0tuVG55QkxRVWJ3Z2QyZ0VldVFXMzFYcmJSSTYNCj4gVkZQTjY0Titv TFpPM1hLck91R3ZNZFJxSFpiRmxOODRHekdEazVudTJYemcwZHdnbjFzaFpwQlVhandXcE1OUQ0K PiB6ZmNEeVR4R2ZNZmlLdlF5RE1hc056dTNWYkxXN0JROVJtWk1TNXpjU2ZwMkZFL1p4aVpPVDdj YzJqdkh5eEU9DQo+ID04N0hsDQo+IC0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwcm92cmVnIG1h aWxpbmcgbGlzdA0KPiBwcm92cmVnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcHJvdnJlZw0KDQpNciBNaWNoZWxlIE5leWxvbg0KQmxhY2tuaWdodCBT b2x1dGlvbnMg4pmeDQpIb3N0aW5nICYgRG9tYWlucw0KSUNBTk4gQWNjcmVkaXRlZCBSZWdpc3Ry YXINCmh0dHA6Ly93d3cuYmxhY2tuaWdodC5jbw0KaHR0cDovL2Jsb2cuYmxhY2tuaWdodC5jb20v DQpJbnRsLiArMzUzICgwKSA1OSAgOTE4MzA3Mg0KVVM6IDIxMy0yMzMtMTYxMiANCkxvY2FsbDog MTg1MCA5MjkgOTI5DQpEaXJlY3QgRGlhbDogKzM1MyAoMCk1OSA5MTgzMDkwDQpGYWNlYm9vazog aHR0cDovL2ZiLm1lL2JsYWNrbmlnaHQNClR3aXR0ZXI6IGh0dHA6Ly90d2l0dGVyLmNvbS9tbmV5 bG9uDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpCbGFja25pZ2h0IEludGVybmV0 IFNvbHV0aW9ucyBMdGQsIFVuaXQgMTJBLEJhcnJvd3NpZGUgQnVzaW5lc3MgUGFyayxTbGVhdHkN ClJvYWQsR3JhaWd1ZWN1bGxlbixDYXJsb3csSXJlbGFuZCAgQ29tcGFueSBOby46IDM3MDg0NQ0K DQo= From Antoin.Verschuren@sidn.nl Thu Sep 19 05:35:11 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048BF21F925A for ; Thu, 19 Sep 2013 05:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.285 X-Spam-Level: X-Spam-Status: No, score=0.285 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4vPYCU8rxOk for ; Thu, 19 Sep 2013 05:35:06 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 4E34B21F979E for ; Thu, 19 Sep 2013 05:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=CQM40ijuaTl/RWu/5Pg/Rd2K+7DhDYSRu6oJIkAq3PU=; b=wtSFMwkxbS/GGWJ6C8/44aJ15IhMU+deKU8a/dTlJHVh4lfuSSiqtcH49sZBXb9bE6FuqenKkimvNzNHYtL87m8EfXcjM8123NhTO0FrPqxGulC9QoLH5Co6U5HhmxWKMz1T9F/Sn9wNpdV1s76DttaWtqEn7mNuxo2N4PUY6rc= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r8JCYtH0031075-r8JCYtH2031075 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Thu, 19 Sep 2013 14:34:55 +0200 Received: from [94.198.152.218] (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 19 Sep 2013 14:34:55 +0200 Message-ID: <523AEF6F.1080201@sidn.nl> Date: Thu, 19 Sep 2013 14:34:55 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michele Neylon - Blacknight References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.218] Cc: "" Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 12:35:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 19-09-13 11:22, Michele Neylon - Blacknight schreef: > This is not the general case, so your statement is biased. > >> So is your reaction :) Touche. :-). Just wanted to state that ICANN gTLD's are not the only norm. This is an IETF mailinglist. The IETF create standards, not ICANN contracts. > The role of the registrar is to offload administrative burden of > the registry, the registrar acts as an administrative agent for > the registrant. > >> Wow! That's actually incredibly offensive to registrars. Perhaps I'm just not a native speaker, and did not find a better term than burden, where I meant distribute administrative tasks to market players that are far better in communicating with end-customers. >> So any time there are *any* issues with *any* domains of any kind >> I can just send all the registrants, users and $random 3rd >> parties directly to the registry? I think it's the misunderstanding of the term "registrar" that has led and still leads to these strong statements. There are indeed a lot of entities that act as registrar in one of their roles that do a lot more than just that. They also act as dns-operator as a service to their customer, offer legal services, do website hosting, are a CA, or offer much more service to their customer, and do that well. But these extra services are not part of the pure registrar role in the model, as there are entities that act as registrar that do not offer these services, and it's important to clearly separate these roles when we need to come up with a clear model to base assumptions on. These entities are service providers, and one of their roles is acting as a registrar for those of their customers that are registrants. (They may have other customers that are not registrants). Registrar refers to the role, not to the entity. By administrative agent, I mean a registrar is responsible for all administrative, legal and financial communication and transactions between registrant and registry regarding the registration of a domain. The registrar represents the registry towards the registrant, and represents the registrant towards the registry. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJSOu9vAAoJEDqHrM883AgneqcH/3L3prtNQxfn1YwPb4pCCUs0 2v57k6bOlhvZKEPk0wDN6YzG/DkyAH8y6E5yqGuUp6esi2r3PH/hitdJ1HnxdDo7 0CKCUci9QFnGu3cwn/tBivm9e2VJ9ExOD0TwNGuVLEhNKmjX+IyN4viE17m6obzw rz0c/1fIYZYmoKfCSrVd1FchG0aWb9c49lY3VKQMItdkRBjogjz5U9SAezpVyCsU BcD0HXwGlwqrnlGi6JGUHzz3PH3LXXSXVxf7gLWHOL7yF5ocK6p5XRH0gCS01ipB +8z3ombUQ7qoF4ymjAQDLSITrSHlRtXObxMkFE9xbsue/tzBzPidA9bhjvIq+Rw= =X4fI -----END PGP SIGNATURE----- From gustavo.lozano@icann.org Thu Sep 19 08:45:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5935421F9399 for ; Thu, 19 Sep 2013 08:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.161 X-Spam-Level: X-Spam-Status: No, score=-5.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UPFlBieHhTF for ; Thu, 19 Sep 2013 08:45:29 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2E21F958A for ; Thu, 19 Sep 2013 08:45:29 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 19 Sep 2013 08:45:29 -0700 From: Gustavo Lozano To: "provreg@ietf.org" Date: Thu, 19 Sep 2013 08:45:27 -0700 Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: Ac61T0RxTWBMZBAATrCxt0+F2EW/0Q== Message-ID: In-Reply-To: <19F54F2956911544A32543B8A9BDE0750A319E9A@NICS-EXCH2.sbg.nic.at> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3462425127_19875140" MIME-Version: 1.0 Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 15:45:34 -0000 --B_3462425127_19875140 Content-type: multipart/mixed; boundary="B_3462425127_19914307" --B_3462425127_19914307 Content-type: multipart/alternative; boundary="B_3462425127_19870307" --B_3462425127_19870307 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable +1 Gustavo From: Alexander Mayrhofer Date: Wednesday, September 18, 2013 5:19 AM To: "Gould, James" , Michael Young , "Hollenbeck, Scott" Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Workin= g Group > Same for me. I=B9m willing to write and review. > =20 > Alex > =20 > =20 >=20 > Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftra= g von > Gould, James > Gesendet: Mittwoch, 18. September 2013 14:17 > An: Michael Young; Hollenbeck, Scott > Cc: provreg@ietf.org > Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Worki= ng > Group > =20 >=20 > Scott, >=20 > =20 >=20 > I too am willing to participate and help write, so +1. >=20 > =20 >=20 > --=20 > =20 > JG > =20 > =20 > James Gould > Principal Software Engineer > jgould@verisign.com > =20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com >=20 > =20 >=20 > From: Michael Young > Date: Wednesday, September 18, 2013 8:01 AM > To: "Hollenbeck, Scott" > Cc: EPP Provreg > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Worki= ng > Group >=20 > =20 >>=20 >> Scott I'm willing to participate and help write, >>=20 >> Michael Young >>=20 >> On 2013-09-18 7:21 AM, "Hollenbeck, Scott" wr= ote: >> I recently closed a conversation with Applications Area Director Pete Re= snick >> to see what he thought about a narrowly-focused charter for a working gr= oup >> to develop a registry for EPP extensions. Pete has agreed with the conce= pt in >> principal. I'm including the text of the proposed charter that I shared = with >> Pete and I'd like to ask others to review it and share feedback as >> appropriate. >>=20 >> If we have enough support for a proposed charter Pete is willing to ente= rtain >> a chartering request. If there's more to discuss we can ask about schedu= ling >> a BOF during the Vancouver meeting. >>=20 >> I've got one specific question: are people able and willing to write a d= raft >> (or drafts) that describe(s) the registry and registration procedures? I >> don't think this will be a difficult task because cloning an existing >> registry is a perfectly reasonable approach, but someone needs to do the >> work. I'm willing to co-chair (if you all will have me) if we form a wor= king >> group, and thus it would be best if we find other volunteers to write >> documents. >>=20 >> Scott >> ---------- >> Proposed Charter for EPP Extensions (eppext) Working Group >>=20 >> The Extensible Provisioning Protocol (EPP) was a work product of the IET= F >> Provisioning Registry Protocol (provreg) working group. EPP was publishe= d as >> a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 200= 4. It >> became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2= 007, >> and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in A= ugust >> 2009. It is the standard domain name provisioning protocol for generic >> top-level domain name registries that operate under the auspices of the >> Internet Corporation for Assigned Names and Numbers (ICANN). It is also = used >> by a number of country code top-level domain registries. >>=20 >> Domain name registries implement a variety of business models. The diffe= rence >> in these models made it very difficult to come up with a "one size fits = all" >> provisioning protocol, so the provreg working group made a conscious dec= ision >> to focus on a minimal set of common functionality. EPP was designed to b= e >> extensible to allow additional features to be specified on an "as needed= " >> basis. Guidelines for extending EPP were published as Informational RFC = 3735 >> in March 2004. >>=20 >> The provreg working group was chartered to develop EPP, but not these >> additional extensions. The working group was closed in 2004 after produc= ing a >> number of Proposed Standard specifications. As registries began to imple= ment >> and deploy EPP the need for extensions became real, and the user communi= ty >> found itself facing a situation in which multiple extensions were being >> developed by different registries to solve the same basic problems, such= as >> registering internationalized domain name variants. >>=20 >> ICANN is now well into a program to delegate a large number of new gener= ic >> top-level domains. EPP will be used to provision those domains, and new >> registry operators are expected to develop additional protocol extension= s. >> With no way to coordinate the development of these extensions, the probl= em of >> non-standard extension duplication is only expected to become worse. >>=20 >> The goal of the EPP Extensions (eppext) working group is to develop an I= ANA >> registry of EPP extensions and procedures to review specifications for >> inclusion in the registry. It will accomplish this goal in two steps: >>=20 >> 1. Develop a Proposed Standard specification for the registration and re= view >> of EPP extensions. There is no current Internet Draft that describes thi= s >> process. >>=20 >> 2. Test the extension registration process by developing a small number = of >> standards track extensions that currently exist in Internet Draft form, >> including: >>=20 >> draft-gieben-epp-keyrelay >> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) >>=20 >> draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-i= dn/) >>=20 >> draft-tan-epp-launchphase >> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) >> draft-lozano-tmch-smd >> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) >> draft-tan-epp-launchphase has a normative dependency on >> draft-lozano-tmch-smd. >>=20 >> When these milestones have been completed the working group will conside= r >> rechartering to explore the issue of ongoing extension development and >> standardization. Modifications to EPP itself are explicitly out of scope= for >> this working group. >>=20 >> Milestones: >>=20 >> TBD Extensions registry document to IESG >>=20 >> TBD draft-gieben-epp-keyrelay to IESG >>=20 >> TBD draft-obispo-epp-idn to IESG >>=20 >> TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG >>=20 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg --B_3462425127_19870307 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
+1

= Gustavo

From: Alexan= der Mayrhofer <alexander.mayr= hofer@nic.at>
Date: Wednesd= ay, September 18, 2013 5:19 AM
To: = "Gould, James" <JGould@verisign.com= >, Michael Young <michael@mwyo= ung.ca>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc:= "provreg@ietf.org" <provreg@ietf.org>
Subject: Re: [provreg] Proposed Charter for EPP Extension= s (eppext) Working Group

 

Alex

=

 

 

Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftrag von Gould, James
Gesendet: Mittwoch, 18. Septem= ber 2013 14:17
An: Michael Young; Hollenbeck, Scott
Cc: = provreg@ietf.org
Betreff: Re= : [provreg] Proposed Charter for EPP Extensions (eppext) Working Group<= /o:p>

 

<= div>

Scott,

 

I too am willing to participate and help write, so +1.  

 

-- 

 

<= /o:p>

 

James Gould

jgould@verisign.com

 = =

703-948-3271 (Office)

Reston, VA 20190

VerisignInc.com

 

From: Michael Young <michae= l@mwyoung.ca>
Date: Wednesday, September 18, 2013 8:01 AMTo: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: EPP Provreg <provreg@ietf.org>
Subject: Re: [pro= vreg] Proposed Charter for EPP Extensions (eppext) Working Group<= /span>

 

=

Scott I'm willing to participate and = help write,

Michael Young

On 2013-09-18 7:21 AM, "Hollenbeck, Scott" = <shollenbeck@verisign.com&g= t; wrote:

I recently closed = a conversation with Applications Area Director Pete Resnick to see what he t= hought about a narrowly-focused charter for a working group to develop a registry for EPP extensions. Pete has agreed with the concept in princip= al. I'm including the text of the proposed charter that I shared with Pete a= nd I'd like to ask others to review it and share feedback as appropriate.
If we have enough support for a proposed charter Pete is willing to enterta= in a chartering request. If there's more to discuss we can ask about schedul= ing a BOF during the Vancouver meeting.

I've got one specific question: are people able and willing to write a draf= t (or drafts) that describe(s) the registry and registration procedures? I d= on't think this will be a difficult task because cloning an existing registr= y is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will= have me) if we form a working group, and thus it would be best if we find o= ther volunteers to write documents.

Scott
----------
Proposed Charter for EPP Extensions (eppext) Working Group

The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as = a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. I= t became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69= ; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard = domain name provisioning protocol for generic top-level domain name registri= es that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is = also used by a number of country code top-level domain registries.

Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size fits a= ll" provisioning protocol, so the provreg working group made a conscious dec= ision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additi= onal features to be specified on an "as needed" basis. Guidelines for extend= ing EPP were published as Informational RFC 3735 in March 2004.

The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a num= ber of Proposed Standard specifications. As registries began to implement an= d deploy EPP the need for extensions became real, and the user community found itself facing a situation in whi= ch multiple extensions were being developed by different registries to solve= the same basic problems, such as registering internationalized domain name = variants.

ICANN is now well into a program to delegate a large number of new generic = top-level domains. EPP will be used to provision those domains, and new regi= stry operators are expected to develop additional protocol extensions. With = no way to coordinate the development of these extensions, the problem of non-standard extension duplication is = only expected to become worse.

The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for incl= usion in the registry. It will accomplish this goal in two steps:

1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this = process.

2. Test the extension registration process by developing a small number of = standards track extensions that currently exist in Internet Draft form, incl= uding:

draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-g= ieben-epp-keyrelay/)

draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-= idn/)

draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-t= an-epp-launchphase/)
draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-= tmch-smd/)
draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-s= md.

When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and standa= rdization. Modifications to EPP itself are explicitly out of scope for this = working group.

Milestones:

TBD Extensions registry document to IESG

TBD draft-gieben-epp-keyrelay to IESG

TBD draft-obispo-epp-idn to IESG

TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG


= _______________________________________________
provreg mailing list
provreg@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/provreg

--B_3462425127_19870307-- --B_3462425127_19914307 Content-type: image/png; name="image001.png"; x-mac-type="504E4766" Content-ID: Content-disposition: attachment; filename="image001.png" Content-transfer-encoding: base64 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= --B_3462425127_19914307-- --B_3462425127_19875140 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITsQYJKoZIhvcNAQcCoIITojCCE54CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EX0wggb4MIIF4KADAgECAhAMNMzaaOCLlcX5TdjpURhNMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzA1MDgwMDAw MDBaFw0xNjA1MDgxMjAwMDBaMIGiMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczERMA8GA1UECxMIUmVnaXN0cnkxFzAV BgNVBAMTDkd1c3Rhdm8gTG96YW5vMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 3w18r+IUAk+jj+kX9oTY/E3q0GyAzR+0x8YvIlksG3cKpkVBqjAKnpZL+GaN98aXYqsIDo8g gctjo1fAx8QxgPkGeZ56EP5uaaN65I1guFa/mVTzSGg2WyXVMRjJmcLBBt//k9APKpvl4Qj4 o+ItgJAKcEA9mtErJB1UE6FtX6ubRd7l/t2BlYHaJLEmdtA4hXfE9TYiVSo4J8652aQ1ba7I g/Qzse32X4A6gm2w6EbEt7m8UVcH0pbxOXpi8Vvz1l6qG3+kxdtJUclg3os4mm0/Iz5glFzM a7OvDyGDbRZbL8ewlnsx3+mjNqDy2S5xNSYFKmdo65xJL1HItfJcSQIDAQABo4IDZzCCA2Mw HwYDVR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFDejkLO4b/vTq4z4 /ln0RuaCGgvuMCMGA1UdEQQcMBqBGGd1c3Rhdm8ubG96YW5vQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2 oDSGMmh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3Js MDigNqA0hjJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0x LmNybDCCAcUGA1UdIASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEW Lmh0dHA6Ly93d3cuZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggr BgEFBQcCAjCCAVYeggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIA dABpAGYAaQBjAGEAdABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQA YQBuAGMAZQAgAG8AZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMA IABhAG4AZAAgAHQAaABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUA ZQBtAGUAbgB0ACAAdwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkA IABhAG4AZAAgAGEAcgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkA bgAgAGIAeQAgAHIAZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNl cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQC MAAwDQYJKoZIhvcNAQEFBQADggEBAGaf7RGm6z5gi7JPp8yiw4JQc1rNztSU2JyQfjy3XtFU rrkK3UhhhYKXVoTRL4bSEx2OTc7ejQ2uMNNKU0ew/hPWhx1jU3AMvf6f3FHFt8X/dAcse+TU QyHT822Kup802tVILAijiq+3SnpNoT2VbI1aw1M4lJpIUezERhbDSRkPXMdIK/nRl57KCXc/ PyM2AD4HvdT1OqXQ1j1baeooPcvofWewjD/WyHkpdVbQ+RJ7F1a9ndagERt4D1kTp1yiZwVH 8gKthT5JXVvA1yTOg8Z8nDl2c12SrVQcP/pIAz8VsTNFlIrcO22XGFfyIfj+WFeLkDJeMccK B1IlFAPPKO0wggbCMIIFqqADAgECAhAKBN8hdF1NK4zqM3IFAFDpMA0GCSqGSIb3DQEBBQUA MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5k aWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0w NjExMTAwMDAwMDBaFw0yMTExMTAwMDAwMDBaMGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxE aWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lD ZXJ0IEFzc3VyZWQgSUQgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOiC LZn5ysJClaWAc0Bw0p5WVFypxNJBBo/JM/xNRZFcgZ/tLJz4FlnfnrUkFcKYubR3SdyJxAra r8tea+2tsHEx6886QAxGTZPsi3o2CAOrDDT+GEmC/sfHMUiAfB6iD5IOUMnGh+s2P9gww/+m 9/uizW9zI/6sVgWQ8DIhFonGcIj5BZd9o8dD3QLoOz3tsUGj7T++25VIxO4es/K8DCuZ0MZd EkKB4YNugnM/JksUkK5ZZgrEjb7SzgaurYRvSISbT0C58Uzyr5j79s5AXVz2qPEvr+yJIvJr GGWxwXOt1/HYzx4KdFxCuGh+t9V3CidWfA9ipD8yFGCV/QcEogkCAwEAAaOCA28wggNrMA4G A1UdDwEB/wQEAwIBhjA7BgNVHSUENDAyBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMD BggrBgEFBQcDBAYIKwYBBQUHAwgwggHGBgNVHSAEggG9MIIBuTCCAbUGC2CGSAGG/WwBAwAE MIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBv c2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAg AHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABl AHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQBy AHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABs AGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0 AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAPBgNVHRMB Af8EBTADAQH/MH0GCCsGAQUFBwEBBHEwbzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGln aWNlcnQuY29tMEcGCCsGAQUFBzAChjtodHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DQUNlcnRz L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDov L2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0 aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDAd BgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGL p6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAIRhTkEeuHYEKrW274/yVYW5XVb+Cpjm5L1l in1AKdP8sV1F/Tq4KlszSyRczbm05HOtYV12rXQzimbVI69MH3JuRdl1QLuiO8+NSS/AQbDi KaNROENQmRSsMwY1Yol9d6lSB+VsIFe2gbpvvLPClO12AoDZfM6FqBzsx0NKS7FXz3LO3/Ul PMsiT/2fUtE3ywi7OD7g1T5veQmtW3wxs3c1w+Rj+WgKmAfnRjh3hNI+l7wKoKisJU9EbpHh 0lqva+8wHI2jREKzEIsj+tfmNXQ3rM/rq1gfyYgj/zbUB+o0akfqnZVsnilPU+3jK5UgTirP lmB6+CyA8JVSzimWgWIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3 DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBD QTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYD VQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMT G0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK 3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lY GDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3La nmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0i rj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNj MGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuC MS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3 DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+Df wWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3 +owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMN FG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB /DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1cmVkIElEIENB LTECEAw0zNpo4IuVxflN2OlRGE0wCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTiaJ77 ME+lOW9xDl6G0D7yVW6KrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMzA5MTkxNTQ1MjdaMA0GCSqGSIb3DQEBAQUABIIBAMwC671G5tuesVwF8AyRU2vy 2nZMxQ9QLOeRBnmJnAXHXq/rzs3UKNP0JCoDLu/WymZYWWn9YO2eTiKNKo+XOkOZi17/GHOU JlRS0I1nEmFjZrbHJSAOvT2tySFgpgnY/dkD6DFZmYqsKHoytZH+eJ8kVk3F9xcgBd4DFXHP TAS+AYmMmUHacUMh61WnrqhTU9PCgjuVVLwac+CKIjEwu4a+EYr9aPjXkx6EmLEPAZoxF+3G e2+n8IGofKpeMi/Swm0viHaRBA3EnH41Pm5kKsW3ZdJ5LEWwstDP/9F3zN8B/Wv88Jj7rSDE /LEySZZk50F5tpc+GuobAAL/764IBQ0= --B_3462425127_19875140-- From brunner@nic-naa.net Thu Sep 19 09:17:32 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778121F997D for ; Thu, 19 Sep 2013 09:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0vr5M0VeCkV for ; Thu, 19 Sep 2013 09:17:26 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5A73A21F99CD for ; Thu, 19 Sep 2013 09:17:26 -0700 (PDT) Received: from abalone.local ([67.42.198.93]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r8JGHOfR060554 for ; Thu, 19 Sep 2013 12:17:24 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <523B2394.7060407@nic-naa.net> Date: Thu, 19 Sep 2013 09:17:24 -0700 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: provreg@ietf.org References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:17:32 -0000 On 9/18/13 11:21 AM, Hollenbeck, Scott wrote: > My original intention for the server*Prohibited status values was focused more on registry-initiated actions like dealing with a court order that didn't require initiation by a registrar. Their use in implementing an on-demand lock service was a serendipitous side effect. > > Anyway, yes, if the idea is to communicate some sort of request to the registry to perform an out-of-band locking action it could be done via EPP. As you noted there would need to be an additional out-of-band mechanism in place to validate the request. Having only the poll method, how can the registrar discover the change of state caused by an out-of-band (court to registry) communication? Eric From brunner@nic-naa.net Thu Sep 19 09:24:58 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55E021F8F61 for ; Thu, 19 Sep 2013 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e+Wd9K4QBKV for ; Thu, 19 Sep 2013 09:24:37 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 64CE421F935A for ; Thu, 19 Sep 2013 09:24:24 -0700 (PDT) Received: from abalone.local ([67.42.198.93]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r8JGOMjD060581 for ; Thu, 19 Sep 2013 12:24:23 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <523B2536.8020408@nic-naa.net> Date: Thu, 19 Sep 2013 09:24:22 -0700 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: provreg@ietf.org References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> , <20130918233540.9598A5A4010@merlin.blacknight.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:24:59 -0000 On 9/18/13 5:05 PM, Michele Neylon - Blacknight wrote: > Jay's examples are from ccTLDs where there is tripartite contractual relationship in many cases. > > In the gTLD space that does not exist and is highly unlikely to ever exist. Agree. Additionally, a court order (in what territorial jurisdiction?) creates an enforceable third-party right (in what territorial jurisdiction?) sufficient to modify without notice to the existing parties (in what territorial jurisdiction?) the pre-existing contractual relationship? Eric From shollenbeck@verisign.com Thu Sep 19 09:25:10 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0729221F960E for ; Thu, 19 Sep 2013 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k9lZhFc2bO3 for ; Thu, 19 Sep 2013 09:25:04 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id 221CD21F935A for ; Thu, 19 Sep 2013 09:25:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUjslUm0S+yRfUgx4Yd7E2NyajNChLUOv@postini.com; Thu, 19 Sep 2013 09:25:01 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8JGOkLk015528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 12:24:47 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 19 Sep 2013 12:24:43 -0400 From: "Hollenbeck, Scott" To: "ebw@abenaki.wabanaki.net" , "provreg@ietf.org" Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: AQHOtVOhp9JxXNgo/kWtZRQplIrYMJnNPfAg Date: Thu, 19 Sep 2013 16:24:42 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49268BD8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <523B2394.7060407@nic-naa.net> In-Reply-To: <523B2394.7060407@nic-naa.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:25:10 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Eric Brunner-Williams > Sent: Thursday, September 19, 2013 12:17 PM > To: provreg@ietf.org > Subject: Re: [provreg] Registry lock - two-factor or intervention >=20 > On 9/18/13 11:21 AM, Hollenbeck, Scott wrote: > > My original intention for the server*Prohibited status values was > focused more on registry-initiated actions like dealing with a court > order that didn't require initiation by a registrar. Their use in > implementing an on-demand lock service was a serendipitous side effect. > > > > Anyway, yes, if the idea is to communicate some sort of request to > the registry to perform an out-of-band locking action it could be done > via EPP. As you noted there would need to be an additional out-of-band > mechanism in place to validate the request. >=20 > Having only the poll method, how can the registrar discover the change > of state caused by an out-of-band (court to registry) communication? A polled message is the primary feedback mechanism, but out-of-band channel= s like email and telephone can also be used. Scott From brunner@nic-naa.net Thu Sep 19 10:17:11 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512F821F9425 for ; Thu, 19 Sep 2013 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+9IkhdHmned for ; Thu, 19 Sep 2013 10:17:05 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5E86121F940D for ; Thu, 19 Sep 2013 10:17:04 -0700 (PDT) Received: from abalone.local ([67.42.198.93]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r8JHH1G3060704 for ; Thu, 19 Sep 2013 13:17:01 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <523B318D.8080106@nic-naa.net> Date: Thu, 19 Sep 2013 10:17:01 -0700 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: provreg@ietf.org References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> In-Reply-To: <523AEF6F.1080201@sidn.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 17:17:11 -0000 On 9/19/13 5:34 AM, Antoin Verschuren wrote: > Just wanted to state that ICANN gTLD's are not the only norm. This is > an IETF mailinglist. The IETF create standards, not ICANN contracts. As one of the original cabal, I believe you are mistaken. The contributors to the pre-IETF effort sought to create, without liability under U.S. law (Sherman Act, anti-trust/competition policy generally) So, evaluating your lines quoted above: 1. The design constraints of the contributors to the specification published as the work product(s) of the PROVREG Working Group did not include registries other than those usually described as "generic" or "sponsored". I think most of those involved in provisioning and the consequences of provisioning (see for example Dan York's note on DNSSEC uptake) share a view that a single provisioning mechanism that is indifferent to whether a registry is associated with a direct delegation from the IANA root, or pre-exists the PROVREG WG work product, or even used a "shared access" model (whether the "shared access" is implemented in the "registrar" function or the "registry" function) is preferable, absent extenuating circumstances, to two or more substantively distinct specifications. If there is a "norm" it is tolerance. 2. The provreg@ietf.org is the continued-as-a-convenience vehicle for communication of the implementers of the specifications published by the concluded PROVREG Working Group, archived and possibly subject to the same, and/or subsequent NOTE WELL conditions, of the mailing list prior to the conclusion of the PROVREG Working Group. The beneficiaries of the mailing list are not limited to the contributors to the PROVREG Working Group work product. Others are free to adopt, with or without modification, our specifications. 3. The purpose of the original contributors who formed the PROVREG Working Group and who's work product has been repeatedly published by the IETF, was to create a specification to be made manditory-to-implement by parties entering into registry or registrar contracts with ICANN, without incurring liabilities (supra). Recall, at the period, the IETF formed part of the Protocol Supporting Organization (PSO), an ICANN ByLaws entity. Note also, use by competitors of "standards bodies" to publish specifications without incurring liabilities under competition policy laws is a broadly established practice. I repeat, tolerance is useful, and as Michale pointed out, some hundreds (eventually thousands) of EPP (client, or server, or both) operators appear to lack, for the moment, a means to provide third parties with {write|lock} access to the underlying data. The problem is not likely to be solved, IMHO, by assertion that it does not exist. Eric From brunner@nic-naa.net Thu Sep 19 10:28:03 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF58721F9951 for ; Thu, 19 Sep 2013 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.926 X-Spam-Level: X-Spam-Status: No, score=0.926 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO62nO42JprZ for ; Thu, 19 Sep 2013 10:27:58 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id BC9BE21F994A for ; Thu, 19 Sep 2013 10:27:57 -0700 (PDT) Received: from abalone.local ([67.42.198.93]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r8JHRl9r060727 for ; Thu, 19 Sep 2013 13:27:48 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <523B3413.2000009@nic-naa.net> Date: Thu, 19 Sep 2013 10:27:47 -0700 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: provreg@ietf.org References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918175531.485BF5A4010@merlin.blacknight.ie> <831693C2CDA2E849A7D7A712B24E257F49267449@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <523B318D.8080106@nic-naa.net> In-Reply-To: <523B318D.8080106@nic-naa.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 17:28:03 -0000 On 9/19/13 10:17 AM, Eric Brunner-Williams wrote: > The contributors to the pre-IETF effort sought to create, without > liability under U.S. law (Sherman Act, anti-trust/competition policy > generally) > Sigh. ... "specifications." Eric From mcanix@gmail.com Thu Sep 19 11:19:48 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6DC21F9123 for ; Thu, 19 Sep 2013 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T14g7OS-ceIt for ; Thu, 19 Sep 2013 11:19:47 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id CB9B821F90CC for ; Thu, 19 Sep 2013 11:19:46 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so8463773wid.3 for ; Thu, 19 Sep 2013 11:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=V4WhSMG8gyhX2C9uLr4L9xyaj3/gyb45pMssdW0MBQA=; b=xPlZBzqnWOINo6cuDDekRlYO2ej+K+tq928Nx3nTHkmDS91ZXaDjsVRqjSyRW98Dz2 JpXWLn9i/t2LjqzUqrnJe0fURITjQ2ytQoQtdAUF2J1HyVU42MqPnw7NAshbQa1T7E2u 67B+56qQ2MVkdvaLFITNsoTsDYeZNC2DfLicrM4hkeEjIbbhsVuQALaJlAIqpNNoL/Ti ySmbmVBQvI+sL9U6H5F9CpK7cpgHcziJRORd5dLLHFwJ4TgKMwFHV9ocfKgWJKYFXxTd JKu5LeNxVUeFFc3E9nJxrrHtQHRKSsQbpg9bC5b466BRpFbMBq1vBVG0as/XSQcbHlCb pz1Q== X-Received: by 10.180.20.77 with SMTP id l13mr2443247wie.40.1379614785890; Thu, 19 Sep 2013 11:19:45 -0700 (PDT) Received: from [192.168.192.18] (41-135-0-116.dsl.mweb.co.za. [41.135.0.116]) by mx.google.com with ESMTPSA id jf2sm11737078wic.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 11:19:44 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7A5BD739-F884-4430-945B-EA86A3827183 Content-Transfer-Encoding: 7bit Message-Id: <1E12FA0A-6354-4FE8-80E6-DEAC6E0F0460@gmail.com> X-Mailer: iPad Mail (10B329) From: Mike O'Connell Date: Thu, 19 Sep 2013 20:19:39 +0200 To: Gustavo Lozano Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 18:19:48 -0000 --Apple-Mail-7A5BD739-F884-4430-945B-EA86A3827183 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Likewise +1 On 19 Sep 2013, at 17:45, Gustavo Lozano wrote: > +1 >=20 > Gustavo >=20 > From: Alexander Mayrhofer > Date: Wednesday, September 18, 2013 5:19 AM > To: "Gould, James" , Michael Young , "Hollenbeck, Scott" > Cc: "provreg@ietf.org" > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Workin= g Group >=20 > Same for me. I=E2=80=99m willing to write and review. > =20 > Alex > =20 > =20 > Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftrag= von Gould, James > Gesendet: Mittwoch, 18. September 2013 14:17 > An: Michael Young; Hollenbeck, Scott > Cc: provreg@ietf.org > Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Workin= g Group > =20 > Scott, > =20 > I too am willing to participate and help write, so +1. =20 > =20 > --=20 > =20 > JG > =20 > > =20 > James Gould > Principal Software Engineer > jgould@verisign.com > =20 > 703-948-3271 (Office) > 12061 Bluemont Way > Reston, VA 20190 > VerisignInc.com > =20 > From: Michael Young > Date: Wednesday, September 18, 2013 8:01 AM > To: "Hollenbeck, Scott" > Cc: EPP Provreg > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Workin= g Group > =20 > Scott I'm willing to participate and help write, >=20 > Michael Young >=20 > On 2013-09-18 7:21 AM, "Hollenbeck, Scott" wrot= e: > I recently closed a conversation with Applications Area Director Pete Resn= ick to see what he thought about a narrowly-focused charter for a working gr= oup to develop a registry for EPP extensions. Pete has agreed with the conce= pt in principal. I'm including the text of the proposed charter that I share= d with Pete and I'd like to ask others to review it and share feedback as ap= propriate. >=20 > If we have enough support for a proposed charter Pete is willing to entert= ain a chartering request. If there's more to discuss we can ask about schedu= ling a BOF during the Vancouver meeting. >=20 > I've got one specific question: are people able and willing to write a dra= ft (or drafts) that describe(s) the registry and registration procedures? I d= on't think this will be a difficult task because cloning an existing registr= y is a perfectly reasonable approach, but someone needs to do the work. I'm w= illing to co-chair (if you all will have me) if we form a working group, and= thus it would be best if we find other volunteers to write documents. >=20 > Scott > ---------- > Proposed Charter for EPP Extensions (eppext) Working Group >=20 > The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as a= Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It= became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007= , and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in Aug= ust 2009. It is the standard domain name provisioning protocol for generic t= op-level domain name registries that operate under the auspices of the Inter= net Corporation for Assigned Names and Numbers (ICANN). It is also used by a= number of country code top-level domain registries. >=20 > Domain name registries implement a variety of business models. The differe= nce in these models made it very difficult to come up with a "one size fits a= ll" provisioning protocol, so the provreg working group made a conscious dec= ision to focus on a minimal set of common functionality. EPP was designed to= be extensible to allow additional features to be specified on an "as needed= " basis. Guidelines for extending EPP were published as Informational RFC 37= 35 in March 2004. >=20 > The provreg working group was chartered to develop EPP, but not these addi= tional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement a= nd deploy EPP the need for extensions became real, and the user community fo= und itself facing a situation in which multiple extensions were being develo= ped by different registries to solve the same basic problems, such as regist= ering internationalized domain name variants. >=20 > ICANN is now well into a program to delegate a large number of new generic= top-level domains. EPP will be used to provision those domains, and new reg= istry operators are expected to develop additional protocol extensions. With= no way to coordinate the development of these extensions, the problem of no= n-standard extension duplication is only expected to become worse. >=20 > The goal of the EPP Extensions (eppext) working group is to develop an IAN= A registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps: >=20 > 1. Develop a Proposed Standard specification for the registration and revi= ew of EPP extensions. There is no current Internet Draft that describes this= process. >=20 > 2. Test the extension registration process by developing a small number of= standards track extensions that currently exist in Internet Draft form, inc= luding: >=20 > draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-ep= p-keyrelay/) >=20 > draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn= /) >=20 > draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-l= aunchphase/) > draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-= smd/) > draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-= smd. >=20 > When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and standa= rdization. Modifications to EPP itself are explicitly out of scope for this w= orking group. >=20 > Milestones: >=20 > TBD Extensions registry document to IESG >=20 > TBD draft-gieben-epp-keyrelay to IESG >=20 > TBD draft-obispo-epp-idn to IESG >=20 > TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --Apple-Mail-7A5BD739-F884-4430-945B-EA86A3827183 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Likewise +1

On 19 Se= p 2013, at 17:45, Gustavo Lozano <gustavo.lozano@icann.org> wrote:

+1

Gustavo

From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>Date: Wednesday, September 18, 201= 3 5:19 AM
To: "Gould, James" <= ;JGould@verisign.com>, Michael= Young <michael@mwyoung.ca>,= "Hollenbeck, Scott" <shollen= beck@verisign.com>
Cc: "<= a href=3D"mailto:provreg@ietf.org">provreg@ietf.org" <provreg@ietf.org>
Subject: Re: [provreg] Proposed Charter for EPP Extensions (ep= pext) Working Group

Same for me. I=E2=80=99m willing to write and review.

&= nbsp;

Alex

 

 

Von: = provreg-bounces@ietf.org [ma= ilto:provreg-bounces@ietf.org] Im Auftrag von Gould, James
Gesendet: Mittwoch, 18. Septemb= er 2013 14:17
An: Michael Young; Hollenbeck, Scott
Cc: <= a href=3D"mailto:provreg@ietf.org">provreg@ietf.org
Betreff: R= e: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group=

 

Scott,

 

I too am willing to participate and help write, so= +1.  

<= o:p> 

-- 

 

JG

=  

<image001.png>

=  

James Gould

= P= rincipal Software Engineer

jgould@verisign.com

 

703-948-3271 (Office)<= /p>

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

 

From: Michael Young <mic= hael@mwyoung.ca>
Date: Wednesday, September 18, 2013 8:01 A= M
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: EPP Provreg <provreg@ietf.org>
Subject: R= e: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group=

 =

Scott I'm willing to p= articipate and help write,

Michael Young

On 2013-09-18 7:21 AM,= "Hollenbeck, Scott" <shollen= beck@verisign.com> wrote:

I recently closed a conversation with Applications Area Director Pet= e Resnick to see what he thought about a narrowly-focused charter for a work= ing group to develop a registry for EPP extensions. Pete has agreed with the concept in principa= l. I'm including the text of the proposed charter that I shared with Pete an= d I'd like to ask others to review it and share feedback as appropriate.
=
If we have enough support for a proposed charter Pete is willing to entertai= n a chartering request. If there's more to discuss we can ask about scheduli= ng a BOF during the Vancouver meeting.

I've got one specific question: are people able and willing to write a draft= (or drafts) that describe(s) the registry and registration procedures? I do= n't think this will be a difficult task because cloning an existing registry= is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will h= ave me) if we form a working group, and thus it would be best if we find oth= er volunteers to write documents.

Scott
----------
Proposed Charter for EPP Extensions (eppext) Working Group

The Extensible Provisioning Protocol (EPP) was a work product of the IETF Pr= ovisioning Registry Protocol (provreg) working group. EPP was published as a= Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It= became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69;= RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard d= omain name provisioning protocol for generic top-level domain name registrie= s that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is a= lso used by a number of country code top-level domain registries.

Domain name registries implement a variety of business models. The differenc= e in these models made it very difficult to come up with a "one size fits al= l" provisioning protocol, so the provreg working group made a conscious deci= sion to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additio= nal features to be specified on an "as needed" basis. Guidelines for extendi= ng EPP were published as Informational RFC 3735 in March 2004.

The provreg working group was chartered to develop EPP, but not these additi= onal extensions. The working group was closed in 2004 after producing a numb= er of Proposed Standard specifications. As registries began to implement and= deploy EPP the need for extensions became real, and the user community found itself facing a situation in whic= h multiple extensions were being developed by different registries to solve t= he same basic problems, such as registering internationalized domain name va= riants.

ICANN is now well into a program to delegate a large number of new generic t= op-level domains. EPP will be used to provision those domains, and new regis= try operators are expected to develop additional protocol extensions. With n= o way to coordinate the development of these extensions, the problem of non-standard extension duplication is o= nly expected to become worse.

The goal of the EPP Extensions (eppext) working group is to develop an IANA r= egistry of EPP extensions and procedures to review specifications for inclus= ion in the registry. It will accomplish this goal in two steps:

1. Develop a Proposed Standard specification for the registration and review= of EPP extensions. There is no current Internet Draft that describes this p= rocess.

2. Test the extension registration process by developing a small number of s= tandards track extensions that currently exist in Internet Draft form, inclu= ding:

draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draf= t-gieben-epp-keyrelay/)

draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-e= pp-idn/)

draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draf= t-tan-epp-launchphase/)
draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-loza= no-tmch-smd/)
draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-sm= d.

When these milestones have been completed the working group will consider re= chartering to explore the issue of ongoing extension development and standar= dization. Modifications to EPP itself are explicitly out of scope for this w= orking group.

Milestones:

TBD Extensions registry document to IESG

TBD draft-gieben-epp-keyrelay to IESG

TBD draft-obispo-epp-idn to IESG

TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG


_______________________________________________
provreg mailing list
provreg@ietf.org=
https://www.ietf.org/mailman/listinfo/provreg<= /p>

<image001.png>
=
__________________________= _____________________
provreg mailing list
<= a href=3D"mailto:provreg@ietf.org">provreg@ietf.org
https://www.ietf.org/m= ailman/listinfo/provreg
= --Apple-Mail-7A5BD739-F884-4430-945B-EA86A3827183-- From JGould@verisign.com Thu Sep 19 12:37:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA99B21F8F9A for ; Thu, 19 Sep 2013 12:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.891 X-Spam-Level: X-Spam-Status: No, score=-4.891 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s8bwJWvz-SG for ; Thu, 19 Sep 2013 12:37:21 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECDD21F88A9 for ; Thu, 19 Sep 2013 12:37:21 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUjtSXDQIBpG4Fyc0W/V24W7PJHk2kQKF@postini.com; Thu, 19 Sep 2013 12:37:21 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8JJavrQ010583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 15:36:59 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 19 Sep 2013 15:24:18 -0400 From: "Gould, James" To: EPP Provreg , "tmch-tech@icann.org" Thread-Topic: Verisign EPP SDK 1.1.0.4 and Launch EPP SDK 2.3.0.0 Thread-Index: AQHOtW22YeV5fejkFUiOQ9TLt6wwow== Date: Thu, 19 Sep 2013 19:24:17 +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.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_004_CE60B0D54DF91jgouldverisigncom_" MIME-Version: 1.0 Subject: [provreg] Verisign EPP SDK 1.1.0.4 and Launch EPP SDK 2.3.0.0 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 19:37:28 -0000 --_004_CE60B0D54DF91jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CE60B0D54DF91jgouldverisigncom_" --_000_CE60B0D54DF91jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Verisign has released the fifth release of the Launch EPP SDK, named Launch= EPP SDK 2.3.0.0. This SDK fully implements draft-tan-epp-launchphase-11 (= http://tools.ietf.org/html/draft-tan-epp-launchphase-11 ) and draft-lozano= -tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), refer= red to simply as 11/02, and includes the following features that can be of = use to multiple stakeholders: 1. Packet encoder / decoder (CODEC) that will encode the XML from object= s and decode the objects from XML. 2. Creation and validation code for signed marks (SMD) using an XML sign= ed mark or a base64 encoded signed mark that complies with draft-lozano-tmc= h-smd-02. 3. Support for SMD certificate chain validation, Certificate Revocation = List (CRL) validation, and SMD revocation validation. 4. Sample of poll messaging compliant with draft-tan-epp-launchphase-11 = in the EPP Stub Server. 5. A client API that utilizes the packet encoder / decoder (CODEC) along= with other code (e.g. transport, configuration, XML parsing pooling) to in= terface with an EPP server. 6. An EPP Stub Server that includes pre-defined responses to support the= client tests. The EPP Stub Server behavior can be easily customized to su= ite your testing needs. 7. Loading and validating the ICANN sample SMD's. 8. Support of use of the ICANN sample SMD's in the EPP Stub Server. The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 5734, 3= 915, and 5910. The Launch EPP SDK is open source, requires Java 6 or higher, and below are= the distributions and documents: * Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/asset= s/epp-sdk/2_3_0_0/epp-launch-bundle-2.3.0.0-bin.tar.gz * Unix Source Distribution (.tag.gz) - http://www.verisigninc.com/asset= s/epp-sdk/2_3_0_0/epp-launch-bundle-2.3.0.0-src.tar.gz * Windows Binary Distribution (.zip) - http://www.verisigninc.com/asset= s/epp-sdk/2_3_0_0/epp-launch-bundle-2.3.0.0-bin.zip * Windows Source Distribution (.zip) - http://www.verisigninc.com/asset= s/epp-sdk/2_3_0_0/epp-launch-bundle-2.3.0.0-src.zip * Readme File - http://www.verisigninc.com/assets/epp-sdk/2_3_0_0/epp-l= aunch.README * Install Instructions - http://www.verisigninc.com/assets/epp-sdk/2_3_= 0_0/epp-launch.INSTALL * Change Log - http://www.verisigninc.com/assets/epp-sdk/2_3_0_0/change= log.txt The Verisign EPP SDK 1.1.0.4 includes all that is in the Launch EPP SDK 2.3= .0.0 plus it adds all of the Verisign custom EPP mappings and extensions. = Below are the distributions and documents: * Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/asset= s/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-bin.tar.gz * Unix Source Distribution (.tag.gz) - http://www.verisigninc.com/asset= s/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-src.tar.gz * Windows Binary Distribution (.zip) - http://www.verisigninc.com/asset= s/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-bin.zip * Windows Source Distribution (.zip) - http://www.verisigninc.com/asset= s/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-src.zip * Programmer's Guide - http://www.verisigninc.com/assets/epp-sdk/1_1_0_= 4/Verisign-EPP-SDK-Prog-Guide.pdf * Change Log - http://www.verisigninc.com/assets/epp-sdk/1_1_0_4/change= log.txt The full set of EPP specifications, tools, and SDK's can be found at http:/= /www.verisigninc.com/en_US/products-and-services/domain-name-services/regis= try-products/epp-sdk/index.xhtml?loc=3Den_US. Thanks, -- JG [cid:922F2D86-FC79-472E-A0CF-F88984FFA29E] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 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_CE60B0D54DF91jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4BBEAEC614EB7742BDA14069C5CBB99C@verisign.com> Content-Transfer-Encoding: quoted-printable
Verisign has released the fifth release of the Launch EPP SDK, named L= aunch EPP SDK 2.3.0.0.  This SDK fully implements draft-tan-epp-launch= phase-11 ( http://tools.ietf.org/html/draft-tan-epp-launchphase-11 )=  and draft-lozano-tmch-smd-02 ( http://tools.ietf.org/html/draft-lozano-tmch-smd-02 ), referred to simply as 11/02, and includes the following fea= tures that can be of use to multiple stakeholders:
  1. Packet encoder / decoder (CODEC) that will encode the XML from objects = and decode the objects from XML.    
  2. Creation and validat= ion code for signed marks (SMD) using an XML signed mark or a base64 encode= d signed mark that complies with draft-lozano-tmch-smd-02.
  3. Support = for SMD certificate chain validation, Certificate Revocation List (CRL) val= idation, and SMD revocation validation.  
  4. Sample of poll messa= ging compliant with draft-tan-epp-launchphase-11 in the EPP Stub Serve= r.
  5. A client API that utilizes the packet encoder / decoder (CODEC) = along with other code (e.g. transport, configuration, XML parsing pooling) = to interface with an EPP server.  
  6. An EPP Stub Server that inc= ludes pre-defined responses to support the client tests.  The EPP Stub= Server behavior can be easily customized to suite your testing needs. &nbs= p;
  7. Loading and validating the ICANN sample SMD's.  
  8. Su= pport of use of the ICANN sample SMD's in the EPP Stub Server.  
    9. <= /ol>
    The Launch EPP SDK includes support for RFC 5730, 5731, 5732, 5733, 57= 34, 3915, and 5910.  

The Launch EPP SDK is open source, requires Java 6 or higher, and belo= w are the distributions and documents:
The Verisign EPP SDK 1.1.0.4 includes all that is in the Launch EPP SD= K 2.3.0.0 plus it adds all of the Verisign custom EPP mappings and extensio= ns.  Below are the distributions and documents:
  • Unix Binary Distribution (.tar.gz) - http://www.verisigninc.com/as= sets/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-bin.tar.gz
  • Unix Source Di= stribution (.tag.gz) - http://www.verisigninc.com/assets/epp-sdk/1_1_0= _4/epp-verisign-1.1.0.4-src.tar.gz
  • Windows Binary Distribution (.zi= p) - http://www.verisigninc.com/assets/epp-sdk/1_1_0_4/epp-verisign-1.= 1.0.4-bin.zip
  • Windows Source Distribution (.zip) - http://www.= verisigninc.com/assets/epp-sdk/1_1_0_4/epp-verisign-1.1.0.4-src.zip
    • Programmer's Guide - http://www.verisigninc.com/assets/epp-sdk/1_1_0_= 4/Verisign-EPP-SDK-Prog-Guide.pdf
  • Change Log - http://www.ver= isigninc.com/assets/epp-sdk/1_1_0_4/changelog.txt


Thanks,


-- 

 

JG

 

 

Jame= s Gould

Princ= ipal Software Engineer

jgould@verisign.com

 = ;

703-9= 48-3271 (Office)

12061= Bluemont Way

Resto= n, VA 20190

Veri= signInc.com

“This 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.”
--_000_CE60B0D54DF91jgouldverisigncom_-- --_004_CE60B0D54DF91jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png Content-Disposition: attachment; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[21].png"; size=4109; creation-date="Thu, 19 Sep 2013 19:24:17 GMT"; modification-date="Thu, 19 Sep 2013 19:24:17 GMT" Content-ID: <922F2D86-FC79-472E-A0CF-F88984FFA29E> 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_CE60B0D54DF91jgouldverisigncom_-- From jan@irial.com Fri Sep 20 00:21:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6A621F8C7C for ; Fri, 20 Sep 2013 00:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hovvNT+eUWwR for ; Fri, 20 Sep 2013 00:21:40 -0700 (PDT) Received: from ns1.knots.net (mail.oa5.net [89.187.75.200]) by ietfa.amsl.com (Postfix) with ESMTP id A4DB921F84B7 for ; Fri, 20 Sep 2013 00:21:36 -0700 (PDT) Received: from [10.10.20.63] (ns1.knots.net [89.187.75.200]) jan (authenticated bits=0) by ns1.knots.net (8.14.2/8.12.11) with ESMTP id r8K7JNJu025965 sender jan@irial.com for ; Fri, 20 Sep 2013 08:20:50 +0100 Received: from [10.10.20.63] ([79.136.100.43] helo=[10.10.20.63]) by mail.oa5.com; 20 Sep 2013 07:19:23 +0000 Message-ID: <523BF67C.4060003@irial.com> Date: Fri, 20 Sep 2013 09:17:16 +0200 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: provreg@ietf.org References: <1E12FA0A-6354-4FE8-80E6-DEAC6E0F0460@gmail.com> In-Reply-To: <1E12FA0A-6354-4FE8-80E6-DEAC6E0F0460@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Whitelisted: Yes X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 07:21:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 here. ALso willing to write and review Best regards jan On 09/19/2013 08:19 PM, Mike O'Connell wrote: > Likewise +1 > > On 19 Sep 2013, at 17:45, Gustavo Lozano > wrote: > >> +1 >> >> Gustavo >> >> From: Alexander Mayrhofer > > >> Date: Wednesday, September 18, 2013 5:19 AM >> To: "Gould, James" >, >> Michael Young >, >> "Hollenbeck, Scott" > > >> Cc: "provreg@ietf.org " > > >> Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) >> Working Group >> >> Same for me. I’m willing to write and review. >> >> >> >> Alex >> >> >> >> >> >> *Von:*provreg-bounces@ietf.org >> [mailto:provreg-bounces@ietf.org] *Im Auftrag von *Gould, James >> *Gesendet:* Mittwoch, 18. September 2013 14:17 >> *An:* Michael Young; Hollenbeck, Scott >> *Cc:* provreg@ietf.org >> *Betreff:* Re: [provreg] Proposed Charter for EPP Extensions >> (eppext) Working Group >> >> >> >> Scott, >> >> >> >> I too am willing to participate and help write, so +1. >> >> >> >> -- >> >> >> >> JG >> >> >> >> >> >> >> >> James Gould >> >> Principal Software Engineer >> >> jgould@verisign.com >> >> >> >> 703-948-3271 (Office) >> >> 12061 Bluemont Way >> >> Reston, VA 20190 >> >> VerisignInc.com >> >> >> >> *From: *Michael Young > >> *Date: *Wednesday, September 18, 2013 8:01 AM >> *To: *"Hollenbeck, Scott" > > >> *Cc: *EPP Provreg > >> *Subject: *Re: [provreg] Proposed Charter for EPP Extensions >> (eppext) Working Group >> >> >> >> Scott I'm willing to participate and help write, >> >> Michael Young >> >> On 2013-09-18 7:21 AM, "Hollenbeck, Scott" >> > >> wrote: >> >> I recently closed a conversation with Applications Area >> Director Pete Resnick to see what he thought about a >> narrowly-focused charter for a working group to develop a >> registry for EPP extensions. Pete has agreed with the concept >> in principal. I'm including the text of the proposed charter >> that I shared with Pete and I'd like to ask others to review >> it and share feedback as appropriate. >> >> If we have enough support for a proposed charter Pete is >> willing to entertain a chartering request. If there's more to >> discuss we can ask about scheduling a BOF during the Vancouver >> meeting. >> >> I've got one specific question: are people able and willing to >> write a draft (or drafts) that describe(s) the registry and >> registration procedures? I don't think this will be a >> difficult task because cloning an existing registry is a >> perfectly reasonable approach, but someone needs to do the >> work. I'm willing to co-chair (if you all will have me) if we >> form a working group, and thus it would be best if we find >> other volunteers to write documents. >> >> Scott >> ---------- >> Proposed Charter for EPP Extensions (eppext) Working Group >> >> The Extensible Provisioning Protocol (EPP) was a work product >> of the IETF Provisioning Registry Protocol (provreg) working >> group. EPP was published as a Proposed Standard (RFCs 3730, >> 3731, 3732, 3733, and 3734) in March 2004. It became a Draft >> Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, >> and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and >> 5734) in August 2009. It is the standard domain name >> provisioning protocol for generic top-level domain name >> registries that operate under the auspices of the Internet >> Corporation for Assigned Names and Numbers (ICANN). It is also >> used by a number of country code top-level domain registries. >> >> Domain name registries implement a variety of business models. >> The difference in these models made it very difficult to come >> up with a "one size fits all" provisioning protocol, so the >> provreg working group made a conscious decision to focus on a >> minimal set of common functionality. EPP was designed to be >> extensible to allow additional features to be specified on an >> "as needed" basis. Guidelines for extending EPP were published >> as Informational RFC 3735 in March 2004. >> >> The provreg working group was chartered to develop EPP, but >> not these additional extensions. The working group was closed >> in 2004 after producing a number of Proposed Standard >> specifications. As registries began to implement and deploy >> EPP the need for extensions became real, and the user >> community found itself facing a situation in which multiple >> extensions were being developed by different registries to >> solve the same basic problems, such as registering >> internationalized domain name variants. >> >> ICANN is now well into a program to delegate a large number of >> new generic top-level domains. EPP will be used to provision >> those domains, and new registry operators are expected to >> develop additional protocol extensions. With no way to >> coordinate the development of these extensions, the problem of >> non-standard extension duplication is only expected to become >> worse. >> >> The goal of the EPP Extensions (eppext) working group is to >> develop an IANA registry of EPP extensions and procedures to >> review specifications for inclusion in the registry. It will >> accomplish this goal in two steps: >> >> 1. Develop a Proposed Standard specification for the >> registration and review of EPP extensions. There is no current >> Internet Draft that describes this process. >> >> 2. Test the extension registration process by developing a >> small number of standards track extensions that currently >> exist in Internet Draft form, including: >> >> draft-gieben-epp-keyrelay >> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) >> >> draft-obispo-epp-idn >> (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) >> >> draft-tan-epp-launchphase >> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) >> draft-lozano-tmch-smd >> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) >> draft-tan-epp-launchphase has a normative dependency on >> draft-lozano-tmch-smd. >> >> When these milestones have been completed the working group >> will consider rechartering to explore the issue of ongoing >> extension development and standardization. Modifications to >> EPP itself are explicitly out of scope for this working group. >> >> Milestones: >> >> TBD Extensions registry document to IESG >> >> TBD draft-gieben-epp-keyrelay to IESG >> >> TBD draft-obispo-epp-idn to IESG >> >> TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG >> >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >> >> >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI79nwACgkQQEpdoflEoIt/tQCeNaU93OxBekmNO9KDSo6CT7NA 2mwAn3nOpUdLPt7IP46kZpt7l/9hAIFK =r2rI -----END PGP SIGNATURE----- From maarten.bosteels@dns.be Fri Sep 20 00:41:40 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A6921F8B4E for ; Fri, 20 Sep 2013 00:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RAND_1=2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWAsTuBAqC51 for ; Fri, 20 Sep 2013 00:41:36 -0700 (PDT) Received: from nug.nucleus.be (old.nug.nucleus.be [77.73.97.156]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0621F8AF4 for ; Fri, 20 Sep 2013 00:41:35 -0700 (PDT) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 72290CBD800D for ; Fri, 20 Sep 2013 09:41:33 +0200 (CEST) Received: from nug.nucleus.be (localhost.localdomain [127.0.0.1]) by nug.nucleus.be (Postfix) with ESMTP id 63EAACBD800A for ; Fri, 20 Sep 2013 09:41:33 +0200 (CEST) Date: Fri, 20 Sep 2013 09:41:33 +0200 (CEST) From: Maarten Bosteels To: provreg Message-ID: <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> In-Reply-To: <523AEF6F.1080201@sidn.nl> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1855490_754247027.1379662893231" X-Originating-IP: [77.67.63.234] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - GC29 (Linux)/8.0.4_GA_5737) Thread-Topic: Registry lock - two-factor or intervention Thread-Index: a9OabIVQOEtnIMV+Ut7HahRmAokp1Q== X-Mailman-Approved-At: Fri, 20 Sep 2013 02:37:54 -0700 Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 09:28:19 -0000 ------=_Part_1855490_754247027.1379662893231 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, At DNS Belgium we are also planning to implement a Registry Lock for .be, so I am definitely interested in developing a common standard. Given the limited interest (by registrants and/or registrars ?) seen at other registries, we plan to start with a mechamism that requires little development for the registry and little to no development effort for the registrars. We recently discussed several options with our Registrar Forum and this is what we came up with for an initial version: * a registry lock on a domain name can only be requested by the sponsoring registrar and only via the web interface and will not be visible nor updatable via EPP * the adminsitrative part (signing agreements, passing around contact details, etc) will be handled manually (exact procedures are still work-in-progress) * the registrant chooses who should be contacted when registrar requests to unlock the domain name => IMO this offers the most flexibility: a registrant can choose to let his registrar handle the whole process or he can choose to be involved in the unlocking process himself * once the administrative part is handled, someone at the registry flags the registration as 'registry locked' => no updates possible to linked registrant nor to the host attributes (NS and A records) of the domain name nor to the DS records (to be investigated if we would allow emergency key roll-overs) * the registrar requests (via the web interface) to unlock a domain name => the registry seeks confirmation using the previously specified contact details. Upon confirmation: registry unlocks the domain name (TBD: indefinitely or for a limited time) * price: to be decided We don't foresee a two-factor authentication mechanism, although one could consider the pre-specified phonenumber as something you have. (We do however plan to add two-factor authentication to the registrar extranet, covering all possible transaction types not just those related to registry lock.) A further simplification (to speed up the roll-out) could be to handle lock and unlock requests entirely via the customer support system (and not via the registrar extranet). In a later phase (when the feature has enough success) we will consider to facilitate lock and unlock requests via EPP and to send EPP poll messages to notify the registrar when the lock or unlock has been approved. All of this of course preferably using a standardized EPP extension. Best regards, Maarten Bosteels Head of Development DNS Belgium +32 16 28 49 70 www.dnsbelgium.be ----- Original Message ----- | From: "Antoin Verschuren" | To: "Michele Neylon - Blacknight" | Cc: "" | Sent: Thursday, 19 September, 2013 2:34:55 PM | Subject: Re: [provreg] Registry lock - two-factor or intervention | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | Op 19-09-13 11:22, Michele Neylon - Blacknight schreef: | > This is not the general case, so your statement is biased. | > | >> So is your reaction :) | Touche. :-). | Just wanted to state that ICANN gTLD's are not the only norm. This is | an IETF mailinglist. The IETF create standards, not ICANN contracts. | > The role of the registrar is to offload administrative burden of | > the registry, the registrar acts as an administrative agent for | > the registrant. | > | >> Wow! That's actually incredibly offensive to registrars. | Perhaps I'm just not a native speaker, and did not find a better term | than burden, where I meant distribute administrative tasks to market | players that are far better in communicating with end-customers. | >> So any time there are *any* issues with *any* domains of any kind | >> I can just send all the registrants, users and $random 3rd | >> parties directly to the registry? | I think it's the misunderstanding of the term "registrar" that has led | and still leads to these strong statements. | There are indeed a lot of entities that act as registrar in one of | their roles that do a lot more than just that. They also act as | dns-operator as a service to their customer, offer legal services, do | website hosting, are a CA, or offer much more service to their | customer, and do that well. | But these extra services are not part of the pure registrar role in | the model, as there are entities that act as registrar that do not | offer these services, and it's important to clearly separate these | roles when we need to come up with a clear model to base assumptions on. | These entities are service providers, and one of their roles is acting | as a registrar for those of their customers that are registrants. | (They may have other customers that are not registrants). Registrar | refers to the role, not to the entity. | By administrative agent, I mean a registrar is responsible for all | administrative, legal and financial communication and transactions | between registrant and registry regarding the registration of a | domain. The registrar represents the registry towards the registrant, | and represents the registrant towards the registry. | - -- | Antoin Verschuren | Technical Policy Advisor SIDN | Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands | P: +31 26 3525500 M: +31 6 23368970 | Mailto: antoin.verschuren@sidn.nl | XMPP: antoin.verschuren@jabber.sidn.nl | HTTP://www.sidn.nl/ | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v1.4.11 (GNU/Linux) | iQEcBAEBAgAGBQJSOu9vAAoJEDqHrM883AgneqcH/3L3prtNQxfn1YwPb4pCCUs0 | 2v57k6bOlhvZKEPk0wDN6YzG/DkyAH8y6E5yqGuUp6esi2r3PH/hitdJ1HnxdDo7 | 0CKCUci9QFnGu3cwn/tBivm9e2VJ9ExOD0TwNGuVLEhNKmjX+IyN4viE17m6obzw | rz0c/1fIYZYmoKfCSrVd1FchG0aWb9c49lY3VKQMItdkRBjogjz5U9SAezpVyCsU | BcD0HXwGlwqrnlGi6JGUHzz3PH3LXXSXVxf7gLWHOL7yF5ocK6p5XRH0gCS01ipB | +8z3ombUQ7qoF4ymjAQDLSITrSHlRtXObxMkFE9xbsue/tzBzPidA9bhjvIq+Rw= | =X4fI | -----END PGP SIGNATURE----- | _______________________________________________ | provreg mailing list | provreg@ietf.org | https://www.ietf.org/mailman/listinfo/provreg ------=_Part_1855490_754247027.1379662893231 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

At DNS Belgium we are also planning to implement a Registry Lock for .= be, so I am definitely interested in developing a common standard.

=
Given the limited interest (by registrants and/or registrars ?) seen a= t other registries, we plan to start with a mechamism that requires little = development for the registry and 
little to no development e= ffort for the registrars.

=
We recently discussed several optio= ns with our Registrar Forum and this is what we came up with for an initial= version:

* a registry lock on a domain name can only be requested = by the sponsoring registrar and only via the web interface and will not be = visible nor updatable via EPP
* the = adminsitrative part (signing agreements, passing around contact details, et= c) will be handled manually  (exact procedures are still work-in-progr= ess)
* the registrant chooses w= ho should be contacted when registrar requests to unlock the domain name
  =3D> IMO this offers the most flexibility:  a r= egistrant can choose to let his registrar handle the whole process or he ca= n choose to be involved in the unlocking process himself
* once the administrative part is handled, someo= ne at the registry flags the registration as 'registry locked'
  =3D> no updates possible to linke= d registrant nor to the host attributes (NS and A records) of the domain na= me nor to the DS records (to be investigated if we would allow emergency ke= y roll-overs)
* the registrar reques= ts (via the web interface) to unlock a domain name 
   =3D> the registry seeks confirmation u= sing the previously specified contact details.  Upon confirmation: &nb= sp;registry unlocks the domain name (TBD:  indefinitely or for a limit= ed time)
* price:  to be decide= d

We don't foresee a two-factor authentication mechanism, although = one could consider the pre-specified phonenumber as something you have.
(We do= however plan to add two-factor authentication to the registrar extranet, covering all= possible transaction types not just those related to registry lock.)

A further simplification (to speed up the roll-out) could be to h= andle lock and unlock requests entirely via the customer support system (an= d not via the registrar extranet).
<= br>
In a later phase (when the featu= re has enough success) we will consider to facilitate lock and unlock reque= sts via EPP and to send EPP poll messages to notify the registrar when the = lock or unlock has been approved. All of this of course preferably using a = standardized EPP extension.

Best regards,

Maarten Bosteels<= /div>
Head of Development
DNS Belgium
= +32 16 28 49 70=
<= span class=3D"Object" id=3D"OBJ_PREFIX_DWT6268_com_zimbra_url" style=3D"col= or: #336699; cursor: pointer;" data-mce-style=3D"color: #336699; cursor: po= inter;">www.dnsbelgium.be

<= hr id=3D"zwchr">
= From: "Antoin Verschuren" <antoin.verschuren@sidn.nl>
To= : "Michele Neylon - Blacknight" <michele@blacknight.com>
Cc= : "<provreg@ietf.org>" <provreg@ietf.org>
Sent: T= hursday, 19 September, 2013 2:34:55 PM
Subject: Re: [provreg] Reg= istry lock - two-factor or intervention

-----BEGIN PGP SI= GNED MESSAGE-----
Hash: SHA1

Op 19-09-13 11:22, Michel= e Neylon - Blacknight schreef:

> This is not the gener= al case, so your statement is biased.
>
>> So is your react= ion :)

Touche. :-).
Just wanted to state that ICANN gT= LD's are not the only norm. This is
an IETF mailinglist. The IETF create= standards, not ICANN contracts.

> The role of the reg= istrar is to offload administrative burden of
> the registry, the reg= istrar acts as an administrative agent for
> the registrant.
> =
>> Wow! That's actually incredibly offensive to registrars.

Perhaps I'm just not a native speaker, and did not find a bett= er term
than burden, where I meant distribute administrative tasks to ma= rket
players that are far better in communicating with end-customers.

>> So any time there are *any* issues with *any* doma= ins of any kind
>> I can just send all the registrants, users and = $random 3rd
>> parties directly to the registry?

I think it's the misunderstanding of the term "registrar" that has led
= and still leads to these strong statements.
There are indeed a lot of en= tities that act as registrar in one of
their roles that do a lot more th= an just that. They also act as
dns-operator as a service to their custom= er, offer legal services, do
website hosting, are a CA, or offer much mo= re service to their
customer, and do that well.
But these extra servi= ces are not part of the pure registrar role in
the model, as there are e= ntities that act as registrar that do not
offer these services, and it's= important to clearly separate these
roles when we need to come up with = a clear model to base assumptions on.
These entities are service provide= rs, and one of their roles is acting
as a registrar for those of their c= ustomers that are registrants.
(They may have other customers that are n= ot registrants). Registrar
refers to the role, not to the entity.
By = administrative agent, I mean a registrar is responsible for all
administ= rative, legal and financial communication and transactions
between regis= trant and registry regarding the registration of a
domain. The registrar= represents the registry towards the registrant,
and represents the regi= strant towards the registry.


- --
Antoin Verschur= en

Technical Policy Advisor SIDN
Meander 501, PO Box 5= 022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500 &n= bsp;M: +31 6 23368970
Mailto: antoin.verschuren@sidn.nl
XMPP: antoin.= verschuren@jabber.sidn.nl
HTTP://www.sidn.nl/
-----BEGIN PGP SIGNATUR= E-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAG= BQJSOu9vAAoJEDqHrM883AgneqcH/3L3prtNQxfn1YwPb4pCCUs0
2v57k6bOlhvZKEPk0wD= N6YzG/DkyAH8y6E5yqGuUp6esi2r3PH/hitdJ1HnxdDo7
0CKCUci9QFnGu3cwn/tBivm9e2= VJ9ExOD0TwNGuVLEhNKmjX+IyN4viE17m6obzw
rz0c/1fIYZYmoKfCSrVd1FchG0aWb9c49= lY3VKQMItdkRBjogjz5U9SAezpVyCsU
BcD0HXwGlwqrnlGi6JGUHzz3PH3LXXSXVxf7gLWH= OL7yF5ocK6p5XRH0gCS01ipB
+8z3ombUQ7qoF4ymjAQDLSITrSHlRtXObxMkFE9xbsue/tz= BzPidA9bhjvIq+Rw=3D
=3DX4fI
-----END PGP SIGNATURE-----
__________= _____________________________________
provreg mailing list
provreg@ie= tf.org
https://www.ietf.org/mailman/listinfo/provreg

------=_Part_1855490_754247027.1379662893231-- From paf@frobbit.se Fri Sep 20 02:47:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760921F8FF8 for ; Fri, 20 Sep 2013 02:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38C0AvzLhGhT for ; Fri, 20 Sep 2013 02:47:44 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02421F8FE5 for ; Fri, 20 Sep 2013 02:47:44 -0700 (PDT) Received: from junior.frobbit.se (unknown [192.165.72.12]) by mail.frobbit.se (Postfix) with ESMTPA id 66DAB21CBA; Fri, 20 Sep 2013 11:47:43 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_0B329903-DBB8-440E-B966-C99C17188C95"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> Date: Fri, 20 Sep 2013 11:47:41 +0200 Message-Id: <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> To: Maarten Bosteels X-Mailer: Apple Mail (2.1510) Cc: provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 09:47:45 -0000 --Apple-Mail=_0B329903-DBB8-440E-B966-C99C17188C95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 sep 2013, at 09:41, Maarten Bosteels = wrote: > We recently discussed several options with our Registrar Forum and = this is what we came up with for an initial version:=20 >=20 > * a registry lock on a domain name can only be requested by the = sponsoring registrar and only via the web interface and will not be = visible nor updatable via EPP=20 Do separate "turn on" and "turn off" the lock which are in turn = separated from making changes while the lock is in place. I see no problems what so ever to "turn on" via epp, and think that is = what should be done. > * the adminsitrative part (signing agreements, passing around contact = details, etc) will be handled manually (exact procedures are still = work-in-progress)=20 Administrative part of turning on or off or making changes while the = lock is set? > * the registrant chooses who should be contacted when registrar = requests to unlock the domain name=20 > =3D> IMO this offers the most flexibility: a registrant can choose to = let his registrar handle the whole process or he can choose to be = involved in the unlocking process himself=20 It is important that we have clear terminology here. You say "registrant = chooses" but above you say (which I think is correct) that the registrar = is turning things on. I think what you say is that "registrant chooses, and this choice is = sent from the registrar to the registry when the lock is turned on". Is = that correct understanding of what you wrote? > * once the administrative part is handled, someone at the registry = flags the registration as 'registry locked'=20 > =3D> no updates possible to linked registrant nor to the host = attributes (NS and A records) of the domain name nor to the DS records = (to be investigated if we would allow emergency key roll-overs)=20 > * the registrar requests (via the web interface) to unlock a domain = name=20 > =3D> the registry seeks confirmation using the previously specified = contact details. Upon confirmation: registry unlocks the domain name = (TBD: indefinitely or for a limited time)=20 See above. > * price: to be decided=20 >=20 > We don't foresee a two-factor authentication mechanism, although one = could consider the pre-specified phonenumber as something you have.=20 > (We do however plan to add two-factor authentication to the registrar = extranet, covering all possible transaction types not just those related = to registry lock.)=20 >=20 > A further simplification (to speed up the roll-out) could be to handle = lock and unlock requests entirely via the customer support system (and = not via the registrar extranet).=20 I think you absolutely must have a two-factor authentication in the form = of two phone numbers, physical surface post or whatever. Something that = is extremely hard to socially engineer. Require two persons to be = involved or whatever. > In a later phase (when the feature has enough success) we will = consider to facilitate lock and unlock requests via EPP and to send EPP = poll messages to notify the registrar when the lock or unlock has been = approved. All of this of course preferably using a standardized EPP = extension.=20 Patrik --Apple-Mail=_0B329903-DBB8-440E-B966-C99C17188C95 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlI8Gb0ACgkQrMabGguI1828DACghPeiCehA24Zd1kvyCx3EDEnR RdYAn0RXBLL71wugGGuoruz0Xvpw1EkL =7hEP -----END PGP SIGNATURE----- --Apple-Mail=_0B329903-DBB8-440E-B966-C99C17188C95-- From shollenbeck@verisign.com Fri Sep 20 04:29:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5010821F9302 for ; Fri, 20 Sep 2013 04:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW2fRpLzcHhT for ; Fri, 20 Sep 2013 04:29:40 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6121F8E70 for ; Fri, 20 Sep 2013 04:29:40 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUjwxo5sTpfMGy81GcIaAwBYWyePsaU0e@postini.com; Fri, 20 Sep 2013 04:29:40 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8KBTacY000523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Sep 2013 07:29:39 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 20 Sep 2013 07:29:36 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOtdITNQjvNUokl0WyGgA5AD8N/JnOeAEg Date: Fri, 20 Sep 2013 11:29:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49276ED6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <1E12FA0A-6354-4FE8-80E6-DEAC6E0F0460@gmail.com> <523BF67C.4060003@irial.com> In-Reply-To: <523BF67C.4060003@irial.com> 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 Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 11:29:45 -0000 QSBudW1iZXIgb2YgcGVvcGxlIGhhdmUgZXhwcmVzc2VkIHdpbGxpbmduZXNzIHRvIHBhcnRpY2lw YXRlIGFuZC9vciB3cml0ZSBkb2N1bWVudHMuIEl0IHdvdWxkIGJlIHJlYWxseSwgcmVhbGx5IGhl bHBmdWwgaWYgb25lIG9yIG1vcmUgb2YgeW91IGNvdWxkIHdyaXRlIGEgZHJhZnQgb3IgdHdvIGRl c2NyaWJpbmcgcHJvcG9zYWxzIGZvciBhbiBleHRlbnNpb25zIHJlZ2lzdHJ5LiBIYXZpbmcgYSBj b3VwbGUgb2YgZG9jdW1lbnRzIHRvIGNob29zZSBmcm9tIG1pZ2h0IG1ha2UgdGhlIGNoYXJ0ZXJp bmcgcHJvY2VzcyBhIGxpdHRsZSBlYXNpZXIuIFNvbWV0aGluZyBsaWtlIFJGQyA1Nzk3IChodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1Nzk3KSBjb3VsZCBwcm92aWRlIGEgdXNlZnVsIHRl bXBsYXRlLg0KDQpUaGVyZSBhcmUgc29tZSB0aG91Z2h0cyBvbiByZWdpc3RyeSBjb250ZW50cyBp biB0aGlzIHRocmVhZDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3By b3ZyZWcvY3VycmVudC9tc2cwNzQyOS5odG1sDQoNClNjb3R0DQoNCg== From michael@mwyoung.ca Fri Sep 20 05:59:50 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967D421F9642 for ; Fri, 20 Sep 2013 05:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8WYmygdQFwp for ; Fri, 20 Sep 2013 05:59:44 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8793321F960E for ; Fri, 20 Sep 2013 05:59:44 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id tp5so694351ieb.40 for ; Fri, 20 Sep 2013 05:59:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=AW1XupSoC9z0gTlAvNjiZl13DhpPo6SoYEoRGP3AjyU=; b=Af2cV2n5wgtObrcaJsQ8mZlxU772NCZhM4+jrG7B7aePJBP9Bo03FPZBF+IRn4pa2Z Cm1pYz4R7D3nw1rOATFPd97CnkgE0lDnoodE/9JCrIdNp3hRFAr6SLTOJ8Gzzkf4Fs8K WtKH2/+ol8u5HABK65pNg5JeXdrXc9UO1FcsRlGyMqpzrthDtQ7KVgwrCrhxS1a951Y/ cNQPPvv1xcjTzsMOr6GKuB+C5mIvlSrbEhkFzr3iAePUvAuTY8mWmHMlj6T7Etu5Yt4+ qUwI/oDuKnQhsW/+KGk7udCksXJuTRBqiUaFNIZEUl0gmrT50e1AwupMd6kez4yiNon/ qGeQ== X-Gm-Message-State: ALoCoQkqPMWKsGe7wtOKZ/8vBuywzjwjb0cRl6zc3GOk0POjPu6ZRRHqM8M/XRkTalD1/k9qSJFR X-Received: by 10.50.109.132 with SMTP id hs4mr2457266igb.34.1379681982751; Fri, 20 Sep 2013 05:59:42 -0700 (PDT) Received: from [172.16.1.44] (CPE74d02b4255c8-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.3.13]) by mx.google.com with ESMTPSA id ir7sm2730396igb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 05:59:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0F6C5FF6-E467-4BC8-AE0B-B9DBE3064D77" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> Date: Fri, 20 Sep 2013 08:59:40 -0400 Message-Id: <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1508) Cc: Maarten Bosteels , provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:59:50 -0000 --Apple-Mail=_0F6C5FF6-E467-4BC8-AE0B-B9DBE3064D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Patrik Some thoughts below: > I see no problems what so ever to "turn on" via epp, and think that is = what should be done. The original use case for the "Registry Lock" service offering, at least = at the gTLDs was to provide some backup restrictions in the event a = registrar's credentials/systems were compromised. Registrars can = already "lock" a domain through Client prohibited statuses. Early = Registry Lock service offering required the Registrar to authenticate in = an out of band mechanism from the EPP server, this typically meant = calling into the Registry support desk and providing a personal = authentication code/password/token, etc at which time the Registry staff = would apply the lock. Later some Registries talked about provided an = out of band API separate from the Registry system to automate the same = concept. If this is still the business justification (protection against a = compromised Registrar), then there is a problem with facilitating = turning on the Registry Lock via the EPP server. Although a separate = system, with separate credentials that happens to use an EPP API would = be fine. Personally I think one should only use an EPP API where = necessary, it's easier to use Restful API over xml or json for non-core = registry requests.=20 > I think you absolutely must have a two-factor authentication in the = form of two phone numbers, physical surface post or whatever. Something = that is extremely hard to socially engineer. Require two persons to be = involved or whatever. Exactly the point to requiring them to contact customer service as past = of the Registry Lock process, no actual direct machine interface method = to apply or remove the lock and multiple steps. You now need to have = the personal credentials of an authorized Registrar employee versus the = main login credentials for the registrar. Of course, as always, the = greatest exposure is the Registrar's and Registry's own staff. MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_0F6C5FF6-E467-4BC8-AE0B-B9DBE3064D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I see no = problems what so ever to "turn on" via epp, and think that is what = should be done.

The original = use case for the "Registry Lock" service offering, at least at the gTLDs = was to provide some backup restrictions in the event a registrar's = credentials/systems were compromised.  Registrars can already = "lock" a domain through Client prohibited statuses.  Early Registry = Lock service offering required the Registrar to authenticate in an out = of band mechanism from the EPP server, this typically meant calling into = the Registry support desk and providing a personal authentication = code/password/token, etc at which time the Registry staff would apply = the lock.  Later some Registries talked about provided an out of = band API separate from the Registry system to automate the same = concept.

If this is still the business = justification (protection against a compromised Registrar), then there = is a problem with facilitating turning on the Registry Lock via the EPP = server.  Although a separate system, with separate credentials that = happens to use an EPP API would be fine.  Personally I think one = should only use an EPP API where necessary, it's easier to use =  Restful API over xml or json for non-core registry = requests. 


I think you absolutely must have a two-factor = authentication in the form of two phone numbers, physical surface post = or whatever. Something that is extremely hard to socially engineer. = Require two persons to be involved or = whatever.

Exactly the point to requiring = them to contact customer service as past of the Registry Lock process, = no actual direct machine interface method to apply or remove the lock = and multiple steps.  You now need to have the personal credentials = of an authorized Registrar employee versus the main login credentials = for the registrar.  Of course, as always, the greatest exposure is = the Registrar's and Registry's own staff.
michael@mwyoung.ca




= --Apple-Mail=_0F6C5FF6-E467-4BC8-AE0B-B9DBE3064D77-- From paf@frobbit.se Fri Sep 20 06:52:38 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3059921F99F3 for ; Fri, 20 Sep 2013 06:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrcOXS9MSCqB for ; Fri, 20 Sep 2013 06:52:37 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 1954121F99CE for ; Fri, 20 Sep 2013 06:52:34 -0700 (PDT) Received: from junior.frobbit.se (unknown [192.165.72.12]) by mail.frobbit.se (Postfix) with ESMTPA id 13D6C21DFE; Fri, 20 Sep 2013 15:52:33 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_780616A1-6D9F-4951-97E7-A6EE31C9B80D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> Date: Fri, 20 Sep 2013 15:52:30 +0200 Message-Id: <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> To: MICHAEL YOUNG X-Mailer: Apple Mail (2.1510) Cc: Maarten Bosteels , provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 13:52:38 -0000 --Apple-Mail=_780616A1-6D9F-4951-97E7-A6EE31C9B80D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 sep 2013, at 14:59, MICHAEL YOUNG wrote: > Some thoughts below: >=20 >> I see no problems what so ever to "turn on" via epp, and think that = is what should be done. >=20 >=20 > The original use case for the "Registry Lock" service offering, at = least at the gTLDs was to provide some backup restrictions in the event = a registrar's credentials/systems were compromised. ...which I think is still a good goal. > Registrars can already "lock" a domain through Client prohibited = statuses. Not in all TLDs. Don't just talk about gTLDs... ;-) > Early Registry Lock service offering required the Registrar to = authenticate in an out of band mechanism from the EPP server, this = typically meant calling into the Registry support desk and providing a = personal authentication code/password/token, etc at which time the = Registry staff would apply the lock. Later some Registries talked about = provided an out of band API separate from the Registry system to = automate the same concept. >=20 > If this is still the business justification (protection against a = compromised Registrar), then there is a problem with facilitating = turning on the Registry Lock via the EPP server. Well, I see that as a potential denial of service attack. But my only = point was that we should see the "Turn ON", "Turn OFF", "Make changes" = as separate operations as they MIGHT require different mechanisms. > Although a separate system, with separate credentials that happens to = use an EPP API would be fine. Personally I think one should only use an = EPP API where necessary, it's easier to use Restful API over xml or = json for non-core registry requests.=20 If you have an automated system, why implementing something else than = EPP? >> I think you absolutely must have a two-factor authentication in the = form of two phone numbers, physical surface post or whatever. Something = that is extremely hard to socially engineer. Require two persons to be = involved or whatever. >=20 > Exactly the point to requiring them to contact customer service as = past of the Registry Lock process, no actual direct machine interface = method to apply or remove the lock and multiple steps. You now need to = have the personal credentials of an authorized Registrar employee versus = the main login credentials for the registrar. Of course, as always, the = greatest exposure is the Registrar's and Registry's own staff. Correct. And that is why it is so important to look in detail on each = operation and define what can be done to secure it. I would say that we need two different communication mechanisms where at = least one, if not two, humans are involved to do some changes that have = to do with these locks. Patrik --Apple-Mail=_780616A1-6D9F-4951-97E7-A6EE31C9B80D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlI8Ux8ACgkQrMabGguI182ZrQCfeigSBkJY4HNT5aWxIjsn8Z9r 348AoIaTE2Q0SE481DoU4EoFDEMPSSpl =x9ku -----END PGP SIGNATURE----- --Apple-Mail=_780616A1-6D9F-4951-97E7-A6EE31C9B80D-- From michael@mwyoung.ca Fri Sep 20 08:28:09 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B65321F9B7E for ; Fri, 20 Sep 2013 08:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEVa0RVBOB05 for ; Fri, 20 Sep 2013 08:28:03 -0700 (PDT) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 21F4A21F9AE3 for ; Fri, 20 Sep 2013 08:28:02 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id z20so201494yhz.13 for ; Fri, 20 Sep 2013 08:28:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nj94V757wzOszkZlxWlxERWCYvkU6eKFC49HL8QfgiM=; b=UlPkjuVhmDbswC8HbthcztobmBgH6HH5237iZmLjHA4P4Q3x36c25k7Caj/8s8msDB 4BG7SZJgBRP5J3Agl4ZqnjVhKiYfHaci4QU0fl4nqsYq85p6yU5cRzn0F4nHT09M3NGs iZBYHVLaho2tJ+x92VzJuYBR6CvIu8GrWQjTqkOO9B5Xusi6evuKO7Gwq2A15v02p9+h FHKys38tLBCUk0SsHaFEDPX7McD5NhYHzpoLBNE4UhE6VhtIsJKt9THcxWBfBYqonnYR LIXRlkLlrUOx4qUMcPBUm+SD+eZynPgX65QPwI93otnXXZZAFcZntk2eR0qnqFPYZP3K f+EQ== X-Gm-Message-State: ALoCoQn5m5dGSvS4NC4p+L8HMLQvfiwuInxu0LJdp1X5cdHNovA9kz66h5oVaO3SoOxnnro6j6KE X-Received: by 10.236.15.162 with SMTP id f22mr7254612yhf.23.1379690882421; Fri, 20 Sep 2013 08:28:02 -0700 (PDT) Received: from [192.168.43.59] ([184.151.190.26]) by mx.google.com with ESMTPSA id v96sm18786815yhp.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 08:28:01 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EE0DF258-AB9A-4726-B48E-3036CA05CF70" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> Date: Fri, 20 Sep 2013 11:27:59 -0400 Message-Id: <49E89DC0-2DAE-43C4-8BEA-E97A64380DC5@mwyoung.ca> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1508) Cc: Maarten Bosteels , provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:28:09 -0000 --Apple-Mail=_EE0DF258-AB9A-4726-B48E-3036CA05CF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > If you have an automated system, why implementing something else than = EPP? Different reasons in different use cases, but really non EPP APIs (I = think anyways) come into play when you are dealing with arm's length = associated actions or decisions that in turn trigger a core EPP call. For one example, some registries are heading towards stronger identity = verification, where the registrant must be examined by a third party (to = both the registry and registrar) before a registration is allowed to be = finalized. I use the word finalized carefully, because while that = verification occurs, one could using a pending create or one could also = combine a typical registration with all the server prohibited statuses = applied. When the verification process is successfully done, a core EPP = command then results in the registration going to a "regular" state - = whatever that happens to be for that particular registry. Registry Lock really is a product that happens to entail more than just = firing a core EPP command, there are elements of identity verification, = two party involvement, etc, all of which really happen outside the = registry. The final result of all that activity is that a core EPP = command is triggered to apply Server prohibited statuses or to remove = them. During most of the lead up process, I have no real need or desire = to talk with an EPP server, just at the end of the decision making. The actual functionality of an EPP Server is relatively = straight-forward, when you think of comparative large systems, which a = really good thing in an infrastructure system. I think if we are to = hope to successfully standardize extensions, we should be critical of = which elements of proposed extension use cases really need to involve an = EPP server, and which are better served as an external system. That said, don't get me wrong, I'm all for standardization whenever we = can achieve it. MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_EE0DF258-AB9A-4726-B48E-3036CA05CF70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If you have an automated system, why = implementing something else than EPP?

Different reasons in = different use cases, but really non EPP APIs (I think anyways) come into = play when you are dealing with arm's length associated actions or = decisions that in turn trigger a core EPP = call.

For one example, some registries are = heading towards stronger identity verification, where the registrant = must be examined by a third party (to both the registry and registrar) = before a registration is allowed to be finalized.  I use the word = finalized carefully, because while that verification occurs, one could = using a pending create or one could also combine a typical registration = with all the server prohibited statuses applied.  When the = verification process is successfully done, a core EPP command then = results in the registration going to a "regular" state - whatever that = happens to be for that particular = registry.

Registry Lock really is a product = that happens to entail more than just firing a core EPP command, there = are elements of identity verification, two party involvement, etc, all = of which really happen outside the registry.  The final result of = all that activity is that a core EPP command is triggered to apply = Server prohibited statuses or to remove them.  During most of the = lead up process, I have no real need or desire to talk with an EPP = server, just at the end of the decision = making.

The actual functionality of an EPP = Server is relatively straight-forward, when you think of comparative = large systems, which a really good thing in an infrastructure system. =  I think if we are to hope to successfully standardize extensions, = we should be critical of which elements of proposed extension use cases = really need to involve an EPP server, and which are better served as an = external system.

That said, don't get me wrong, = I'm all for standardization whenever we can achieve = it.


MICHAEL YOUNG




= --Apple-Mail=_EE0DF258-AB9A-4726-B48E-3036CA05CF70-- From stuart.olmstead-wilcox@cira.ca Fri Sep 20 12:41:51 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF03A21F9D65 for ; Fri, 20 Sep 2013 12:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.854 X-Spam-Level: X-Spam-Status: No, score=-9.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxlv7sqBffz6 for ; Fri, 20 Sep 2013 12:41:46 -0700 (PDT) Received: from office-mx.cira.ca (office-smtp.cira.ca [192.228.22.119]) by ietfa.amsl.com (Postfix) with ESMTP id A850821F9D3A for ; Fri, 20 Sep 2013 12:41:45 -0700 (PDT) Received: from office-mx0 (office-mx0 [127.0.0.1]) by office-mx.cira.ca (Postfix) with SMTP id CAD6813FB04 for ; Fri, 20 Sep 2013 15:41:40 -0400 (EDT) Received: from mbxhub.cira.ca (mbxhub.cira.ca [192.228.22.115]) by office-mx.cira.ca (Postfix) with ESMTP id 38C2313FB04 for ; Fri, 20 Sep 2013 15:41:40 -0400 (EDT) Received: from MBX01.cira1.cira.ca ([10.2.16.30]) by exch-hub.cira1.cira.ca ([10.2.16.28]) with mapi; Fri, 20 Sep 2013 15:41:39 -0400 From: Stuart Olmstead-Wilcox To: provreg Date: Fri, 20 Sep 2013 15:41:38 -0400 Thread-Topic: [provreg] Registry lock - two-factor or intervention Thread-Index: Ac62Fgr9wn1COc/BTSeDwX1k9q63SwAIJh3w Message-ID: References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> <49E89DC0-2DAE-43C4-8BEA-E97A64380DC5@mwyoung.ca> In-Reply-To: <49E89DC0-2DAE-43C4-8BEA-E97A64380DC5@mwyoung.ca> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA Content-Type: multipart/alternative; boundary="_000_CF3C66A5DB184445AE42748BFA64AAA1013BCB3B58E0MBX01cira1c_" MIME-Version: 1.0 X-VAMS: NONE Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:41:52 -0000 --_000_CF3C66A5DB184445AE42748BFA64AAA1013BCB3B58E0MBX01cira1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, At CIRA we are also currently developing our business requirements and init= ial design of a Registry Lock service for .CA. The question and discussion= of a common epp extension / implementation approach not only for Registry = Lock, but for the exposure of value-add or additional services per domain i= s something we are very interested in as well. >From where we currently are in our analysis, I am also in agreement that is= seems logical to leverage epp for the setting of the lock itself. There does, however, look to be an intrinsic requirement for a separately a= uthenticated step prior to the rar being allowed to set the server flags vi= a epp - and also prior to removal of the flags to allow for domain modifica= tion. The question of whether these separately authenticated steps should be auto= mated (epp or other) or manual (person to person) is something we are quite= focused on at the moment and would definitely invite feedback or real-worl= d experience on either approach. As I mentioned above, we are also looking at how best to generally expose s= ervices that can be applied / added onto domains - to rar's. These service= s could be Registry Lock, or any other value added service. If there any = extensions out there that someone has put together for this purpose I would= be very interested to learn more about them as well. In either case, we are interested in participating in the discussion and de= velopment of standardized approaches as well. Thanks, Stu STU OLMSTEAD-WILCOX. Development Manager Canadian Internet Registration Authority (CIRA) (613) 237-5335 x265 From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of MICHAEL YOUNG Sent: September-20-13 11:28 AM To: Patrik F=E4ltstr=F6m Cc: Maarten Bosteels; provreg Subject: Re: [provreg] Registry lock - two-factor or intervention If you have an automated system, why implementing something else than EPP? Different reasons in different use cases, but really non EPP APIs (I think = anyways) come into play when you are dealing with arm's length associated a= ctions or decisions that in turn trigger a core EPP call. For one example, some registries are heading towards stronger identity veri= fication, where the registrant must be examined by a third party (to both t= he registry and registrar) before a registration is allowed to be finalized= . I use the word finalized carefully, because while that verification occu= rs, one could using a pending create or one could also combine a typical re= gistration with all the server prohibited statuses applied. When the verif= ication process is successfully done, a core EPP command then results in th= e registration going to a "regular" state - whatever that happens to be for= that particular registry. Registry Lock really is a product that happens to entail more than just fir= ing a core EPP command, there are elements of identity verification, two pa= rty involvement, etc, all of which really happen outside the registry. The= final result of all that activity is that a core EPP command is triggered = to apply Server prohibited statuses or to remove them. During most of the = lead up process, I have no real need or desire to talk with an EPP server, = just at the end of the decision making. The actual functionality of an EPP Server is relatively straight-forward, w= hen you think of comparative large systems, which a really good thing in an= infrastructure system. I think if we are to hope to successfully standard= ize extensions, we should be critical of which elements of proposed extensi= on use cases really need to involve an EPP server, and which are better ser= ved as an external system. That said, don't get me wrong, I'm all for standardization whenever we can = achieve it. MICHAEL YOUNG michael@mwyoung.ca --_000_CF3C66A5DB184445AE42748BFA64AAA1013BCB3B58E0MBX01cira1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

At CIRA we are also currently developing our busin= ess requirements and initial design of a Registry Lock service for .CA.=A0 = The question and discussion of a common epp extension / implementation appr= oach not only for Registry Lock, but for the exposure of value-add or addit= ional services per domain is something we are very interested in as well.

 

From where we currently are in our analysis, I= am also in agreement that is seems logical to leverage epp for the setting= of the lock itself. =A0

<= o:p> 

There does, however,= look to be an intrinsic requirement for a separately authenticated step pr= ior to the rar being allowed to set the server flags via epp – and al= so prior to removal of the flags to allow for domain modification.=A0 =

 

The question of whether these separately authenti= cated steps should be automated (epp or other) or manual (person to person)= is something we are quite focused on at the moment and would definitely in= vite feedback or real-world experience on either approach.

 

As I mentioned above, we are also looking at how best to gene= rally expose services that can be applied / added onto domains - to rarR= 17;s.=A0 These services could be Registry Lock, or any other value added se= rvice. =A0=A0If there any extensions out there that someone has put togethe= r for this purpose I would be very interested to learn more about them as w= ell.

 

In either case, we are interested in par= ticipating in the discussion and development of standardized approaches as = well.

 

Thanks,

Stu

 

STU = OLMSTEAD-WILCOX. Development Manager

Canadian Internet Re= gistration Authority (CIRA)

(613) 237-5335 x265

 

From:= provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org]= On Behalf Of MICHAEL YOUNG
Sent: September-20-13 11:28 AM=
To: Patrik F=E4ltstr=F6m
Cc: Maarten Bosteels; provreg=
Subject: Re: [provreg] Registry lock - two-factor or interventio= n

 

If you have an automated system, why implementing something else tha= n EPP?

 

Different reasons in= different use cases, but really non EPP APIs (I think anyways) come into p= lay when you are dealing with arm's length associated actions or decisions = that in turn trigger a core EPP call.

 

For one example, some registries are heading towards stronge= r identity verification, where the registrant must be examined by a third p= arty (to both the registry and registrar) before a registration is allowed = to be finalized.  I use the word finalized carefully, because while th= at verification occurs, one could using a pending create or one could also = combine a typical registration with all the server prohibited statuses appl= ied.  When the verification process is successfully done, a core EPP c= ommand then results in the registration going to a "regular" stat= e - whatever that happens to be for that particular registry.

 

=

Registry Lock really is a product th= at happens to entail more than just firing a core EPP command, there are el= ements of identity verification, two party involvement, etc, all of which r= eally happen outside the registry.  The final result of all that activ= ity is that a core EPP command is triggered to apply Server prohibited stat= uses or to remove them.  During most of the lead up process, I have no= real need or desire to talk with an EPP server, just at the end of the dec= ision making.

<= o:p> 

The actua= l functionality of an EPP Server is relatively straight-forward, when you t= hink of comparative large systems, which a really good thing in an infrastr= ucture system.  I think if we are to hope to successfully standardize = extensions, we should be critical of which elements of proposed extension u= se cases really need to involve an EPP server, and which are better served = as an external system.

 

= That said, don't get me wrong, I'm all for standardization whenever we can = achieve it.

 

 =

MICHAEL YOUNG<= /o:p>

 



 <= /o:p>

= --_000_CF3C66A5DB184445AE42748BFA64AAA1013BCB3B58E0MBX01cira1c_-- From jay@nzrs.net.nz Fri Sep 20 22:55:11 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6491611E80FF for ; Fri, 20 Sep 2013 22:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqX3N8OcZn1c for ; Fri, 20 Sep 2013 22:55:06 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 092E121F9AA7 for ; Fri, 20 Sep 2013 22:55:05 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 0DABC4B6803; Sat, 21 Sep 2013 17:55:03 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e-xo4tHjHPj; Sat, 21 Sep 2013 17:54:55 +1200 (NZST) Received: from [192.168.43.229] (unknown [122.56.232.7]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id AB7A34B67F1; Sat, 21 Sep 2013 17:54:54 +1200 (NZST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> Date: Sat, 21 Sep 2013 17:53:29 +1200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D0CB1C7-E84E-4DD5-B023-24B28A01CE1F@nzrs.net.nz> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> To: provreg X-Mailer: Apple Mail (2.1510) Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 05:55:11 -0000 On 21/09/2013, at 1:52 AM, Patrik F=E4ltstr=F6m wrote: >> If this is still the business justification (protection against a = compromised Registrar), then there is a problem with facilitating = turning on the Registry Lock via the EPP server. >=20 > Well, I see that as a potential denial of service attack. But my only = point was that we should see the "Turn ON", "Turn OFF", "Make changes" = as separate operations as they MIGHT require different mechanisms. There's quite a big risk here that a hacker compromises a registrar, = switches a domain name to a compromised site and then locks the record, = which makes undoing the malicious change much harder when the registrar = regains control of their systems. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From paf@frobbit.se Fri Sep 20 23:14:25 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC621F9DA8 for ; Fri, 20 Sep 2013 23:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUhzfp3360ls for ; Fri, 20 Sep 2013 23:14:25 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77021F9E36 for ; Fri, 20 Sep 2013 23:14:25 -0700 (PDT) Received: from [IPv6:2a02:80:3ffc::6155:4c0c:2544:e7fc] (unknown [IPv6:2a02:80:3ffc:0:6155:4c0c:2544:e7fc]) by mail.frobbit.se (Postfix) with ESMTPSA id A9FCB21541; Sat, 21 Sep 2013 08:14:23 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_081DB4FD-59D0-4EA8-8263-CF90D2F3D851"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <1D0CB1C7-E84E-4DD5-B023-24B28A01CE1F@nzrs.net.nz> Date: Sat, 21 Sep 2013 08:14:21 +0200 Message-Id: <69F7F02E-CCFA-46C3-BC75-C6165A10D7A9@frobbit.se> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <09598E8F-0A35-42CF-9AA6-880F5CAADB43@frobbit.se> <8578FF26-C623-4D85-993F-0A097B876A84@mwyoung.ca> <9FD29421-0855-451A-8D7B-72959224C2F9@frobbit.se> <1D0CB1C7-E84E-4DD5-B023-24B28A01CE1F@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1510) Cc: provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 06:14:26 -0000 --Apple-Mail=_081DB4FD-59D0-4EA8-8263-CF90D2F3D851 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 21 sep 2013, at 07:53, Jay Daley wrote: > On 21/09/2013, at 1:52 AM, Patrik F=E4ltstr=F6m = wrote: >=20 >>> If this is still the business justification (protection against a = compromised Registrar), then there is a problem with facilitating = turning on the Registry Lock via the EPP server. >>=20 >> Well, I see that as a potential denial of service attack. But my only = point was that we should see the "Turn ON", "Turn OFF", "Make changes" = as separate operations as they MIGHT require different mechanisms. >=20 >=20 > There's quite a big risk here that a hacker compromises a registrar, = switches a domain name to a compromised site and then locks the record, = which makes undoing the malicious change much harder when the registrar = regains control of their systems. Correct, what I would say a "denial of service attack". :-P My point is still that the various operations should be investigated = individually. Nothing more, nothing less. Patrik --Apple-Mail=_081DB4FD-59D0-4EA8-8263-CF90D2F3D851 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSPTk9rMabGguI180RAvZEAKCKs0o2/4a5fTGyyR0RtF7FflGSqgCfckhM UqfOnpqdCHnr2DdQjNN00aM= =51kV -----END PGP SIGNATURE----- --Apple-Mail=_081DB4FD-59D0-4EA8-8263-CF90D2F3D851-- From jan@irial.com Fri Sep 20 23:23:17 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A611E8104 for ; Fri, 20 Sep 2013 23:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36cfQznZRIC1 for ; Fri, 20 Sep 2013 23:23:13 -0700 (PDT) Received: from ns1.knots.net (mail.oa5.net [89.187.75.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9727311E8105 for ; Fri, 20 Sep 2013 23:23:12 -0700 (PDT) Received: from [192.168.224.2] (ns1.knots.net [89.187.75.200]) jan (authenticated bits=0) by ns1.knots.net (8.14.2/8.12.11) with ESMTP id r8L6Mxo8021570 sender jan@irial.com for ; Sat, 21 Sep 2013 07:23:00 +0100 Received: from [192.168.224.2] ([80.217.51.175] helo=[192.168.224.2]) by mail.oa5.com; 21 Sep 2013 06:22:59 +0000 Message-ID: <523D3B43.10800@irial.com> Date: Sat, 21 Sep 2013 08:22:59 +0200 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: provreg References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> In-Reply-To: <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Assp-Whitelisted: Yes X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 06:23:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Here at iis we are have the registry lock implemented as a manual option (pricey) and is in the process of developing an automatic registry lock function. The lock is implemented using the ServerProhobited flags so it is visible in EPP (info), and we are setting the flags so that no change are able to be done over EPP except renew. The lock can be set by a registrar by sending in a form (handled manually) and can be removed by another form. To validate the unlock request we are calling the registrar manually today. The automatic system will use a strong login mechanism to a web based system where changes (lock and unlock) can be set. Our opinion currently is that the lock is there to avoid a registrant system being hacked and therefore is using this OOB method. We also think that its more unlikely that a registrar will do changes by mistake if they have to do this OOB unlock method as it requires extra step and hopefully will make them think twice before doing it. Currently we are aiming the pricing to be free for all registrars when we have it as a automatic procedure. Best regards Jan Saell On 09/20/2013 09:41 AM, Maarten Bosteels wrote: > Hi all, > > At DNS Belgium we are also planning to implement a Registry Lock for > .be, so I am definitely interested in developing a common standard. > > Given the limited interest (by registrants and/or registrars ?) seen at > other registries, we plan to start with a mechamism that requires little > development for the registry and > little to no development effort for the registrars. > > We recently discussed several options with our Registrar Forum and this > is what we came up with for an initial version: > > * a registry lock on a domain name can only be requested by the > sponsoring registrar and only via the web interface and will not be > visible nor updatable via EPP > * the adminsitrative part (signing agreements, passing around contact > details, etc) will be handled manually (exact procedures are still > work-in-progress) > * the registrant chooses who should be contacted when registrar requests > to unlock the domain name > => IMO this offers the most flexibility: a registrant can choose to > let his registrar handle the whole process or he can choose to be > involved in the unlocking process himself > * once the administrative part is handled, someone at the registry flags > the registration as 'registry locked' > => no updates possible to linked registrant nor to the host attributes > (NS and A records) of the domain name nor to the DS records (to be > investigated if we would allow emergency key roll-overs) > * the registrar requests (via the web interface) to unlock a domain name > => the registry seeks confirmation using the previously specified > contact details. Upon confirmation: registry unlocks the domain name > (TBD: indefinitely or for a limited time) > * price: to be decided > > We don't foresee a two-factor authentication mechanism, although one > could consider the pre-specified phonenumber as something you have. > (We do however plan to add two-factor authentication to the registrar > extranet, covering all possible transaction types not just those related > to registry lock.) > > A further simplification (to speed up the roll-out) could be to handle > lock and unlock requests entirely via the customer support system (and > not via the registrar extranet). > > In a later phase (when the feature has enough success) we will consider > to facilitate lock and unlock requests via EPP and to send EPP poll > messages to notify the registrar when the lock or unlock has been > approved. All of this of course preferably using a standardized EPP > extension. > > Best regards, > > Maarten Bosteels > Head of Development > DNS Belgium > +32 16 28 49 70 > *www.dnsbelgium.be * > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI9O0MACgkQQEpdoflEoIt23QCgvl2e4qV6/bksz7BOLZJM9bQx TsQAoJ1OPenpt56gg4++Yj1Vc7Odu/ez =laOW -----END PGP SIGNATURE----- From paf@frobbit.se Fri Sep 20 23:40:47 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0758E21F9C60 for ; Fri, 20 Sep 2013 23:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFDVoa1ZG6b9 for ; Fri, 20 Sep 2013 23:40:45 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCCE21F9C05 for ; Fri, 20 Sep 2013 23:40:44 -0700 (PDT) Received: from [192.168.1.25] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 8471421F76; Sat, 21 Sep 2013 08:40:43 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_BB54B3A8-D894-43D5-AEE2-8A7E4B52BF06"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <523D3B43.10800@irial.com> Date: Sat, 21 Sep 2013 08:40:43 +0200 Message-Id: <1594ECAD-771D-44FA-9086-883B37CB537A@frobbit.se> References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <523D3B43.10800@irial.com> To: Jan Saell X-Mailer: Apple Mail (2.1510) Cc: provreg Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 06:40:47 -0000 --Apple-Mail=_BB54B3A8-D894-43D5-AEE2-8A7E4B52BF06 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 21 sep 2013, at 08:22, Jan Saell wrote: > Our opinion currently is that the lock is there to avoid a registrant > system being hacked and therefore is using this OOB method. Registrant system? paf --Apple-Mail=_BB54B3A8-D894-43D5-AEE2-8A7E4B52BF06 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSPT9rrMabGguI180RAnhIAJ0byhMXtA4Kq3Wkk/2HMzaZ1+2f5gCfRUHP kqAjqTcgHptmEIb3zTXb1LQ= =08kw -----END PGP SIGNATURE----- --Apple-Mail=_BB54B3A8-D894-43D5-AEE2-8A7E4B52BF06-- From jan@irial.com Sat Sep 21 00:25:22 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8180611E810E for ; Sat, 21 Sep 2013 00:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNejBLCHd0nl for ; Sat, 21 Sep 2013 00:25:17 -0700 (PDT) Received: from ns1.knots.net (mail.oa5.net [89.187.75.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6773A11E811A for ; Sat, 21 Sep 2013 00:25:16 -0700 (PDT) Received: from [192.168.224.2] (ns1.knots.net [89.187.75.200]) jan (authenticated bits=0) by ns1.knots.net (8.14.2/8.12.11) with ESMTP id r8L7Ojkq028195 sender jan@irial.com for ; Sat, 21 Sep 2013 08:25:10 +0100 Received: from [192.168.224.2] ([80.217.51.175] helo=[192.168.224.2]) by mail.oa5.com; 21 Sep 2013 07:24:45 +0000 Message-ID: <523D49B0.7030004@irial.com> Date: Sat, 21 Sep 2013 09:24:32 +0200 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 CC: provreg References: <453FA283-6D94-4729-A69C-A3EA81CA6AF7@nzrs.net.nz> <20130918225728.140C65A400F@merlin.blacknight.ie> <20130919083317.977495A400F@merlin.blacknight.ie> <523AEF6F.1080201@sidn.nl> <33814548.1855491.1379662893235.JavaMail.zimbra@staff.dns.be> <523D3B43.10800@irial.com> <1594ECAD-771D-44FA-9086-883B37CB537A@frobbit.se> In-Reply-To: <1594ECAD-771D-44FA-9086-883B37CB537A@frobbit.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Whitelisted: Yes X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Registry lock - two-factor or intervention X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 07:25:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry - registrar system On 09/21/2013 08:40 AM, Patrik Fältström wrote: > > On 21 sep 2013, at 08:22, Jan Saell wrote: > >> Our opinion currently is that the lock is there to avoid a registrant >> system being hacked and therefore is using this OOB method. > > Registrant system? > > paf > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlI9SbAACgkQQEpdoflEoIuPxwCbBBNqRhbctuOKu9P4dSIARL45 DLkAoNSAMLK9sCUVOMpnpLexjMLFPTgS =VWIc -----END PGP SIGNATURE----- From nkong@cnnic.cn Sat Sep 21 19:44:37 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C04911E81FA for ; Sat, 21 Sep 2013 19:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCFdGLE0zp9d for ; Sat, 21 Sep 2013 19:44:33 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id E02E311E81FD for ; Sat, 21 Sep 2013 19:44:28 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [218.241.103.70]) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 22 Sep 2013 10:43:56 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Sun, 22 Sep 2013 10:43:56 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2C5F1C48-DB4A-4CC2-A896-D1BFD02E8557@cnnic.cn> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 02:44:37 -0000 Thanks, Scott. I'd like to review and contribute. Hope my response is = not too late. BTW, I notice that registering internationalized domain name variants is = as a example in the proposed charter. I still think = draft-kong-epp-idn-variants-mapping rightly focuses on this problem. I = hope this draft can also be considered by the new WG. Any thoughts? Cheers, Ning > I recently closed a conversation with Applications Area Director Pete = Resnick to see what he thought about a narrowly-focused charter for a = working group to develop a registry for EPP extensions. Pete has agreed = with the concept in principal. I'm including the text of the proposed = charter that I shared with Pete and I'd like to ask others to review it = and share feedback as appropriate. >=20 > If we have enough support for a proposed charter Pete is willing to = entertain a chartering request. If there's more to discuss we can ask = about scheduling a BOF during the Vancouver meeting. >=20 > I've got one specific question: are people able and willing to write a = draft (or drafts) that describe(s) the registry and registration = procedures? I don't think this will be a difficult task because cloning = an existing registry is a perfectly reasonable approach, but someone = needs to do the work. I'm willing to co-chair (if you all will have me) = if we form a working group, and thus it would be best if we find other = volunteers to write documents. >=20 > Scott > ---------- > Proposed Charter for EPP Extensions (eppext) Working Group >=20 > The Extensible Provisioning Protocol (EPP) was a work product of the = IETF Provisioning Registry Protocol (provreg) working group. EPP was = published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) = in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, = and 4934) in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, = 5732, 5733, and 5734) in August 2009. It is the standard domain name = provisioning protocol for generic top-level domain name registries that = operate under the auspices of the Internet Corporation for Assigned = Names and Numbers (ICANN). It is also used by a number of country code = top-level domain registries. >=20 > Domain name registries implement a variety of business models. The = difference in these models made it very difficult to come up with a "one = size fits all" provisioning protocol, so the provreg working group made = a conscious decision to focus on a minimal set of common functionality. = EPP was designed to be extensible to allow additional features to be = specified on an "as needed" basis. Guidelines for extending EPP were = published as Informational RFC 3735 in March 2004. >=20 > The provreg working group was chartered to develop EPP, but not these = additional extensions. The working group was closed in 2004 after = producing a number of Proposed Standard specifications. As registries = began to implement and deploy EPP the need for extensions became real, = and the user community found itself facing a situation in which multiple = extensions were being developed by different registries to solve the = same basic problems, such as registering internationalized domain name = variants. >=20 > ICANN is now well into a program to delegate a large number of new = generic top-level domains. EPP will be used to provision those domains, = and new registry operators are expected to develop additional protocol = extensions. With no way to coordinate the development of these = extensions, the problem of non-standard extension duplication is only = expected to become worse. >=20 > The goal of the EPP Extensions (eppext) working group is to develop an = IANA registry of EPP extensions and procedures to review specifications = for inclusion in the registry. It will accomplish this goal in two = steps: >=20 > 1. Develop a Proposed Standard specification for the registration and = review of EPP extensions. There is no current Internet Draft that = describes this process. >=20 > 2. Test the extension registration process by developing a small = number of standards track extensions that currently exist in Internet = Draft form, including: >=20 > draft-gieben-epp-keyrelay = (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) >=20 > draft-obispo-epp-idn = (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) >=20 > draft-tan-epp-launchphase = (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) > draft-lozano-tmch-smd = (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) > draft-tan-epp-launchphase has a normative dependency on = draft-lozano-tmch-smd. >=20 > When these milestones have been completed the working group will = consider rechartering to explore the issue of ongoing extension = development and standardization. Modifications to EPP itself are = explicitly out of scope for this working group. >=20 > Milestones: >=20 > TBD Extensions registry document to IESG >=20 > TBD draft-gieben-epp-keyrelay to IESG >=20 > TBD draft-obispo-epp-idn to IESG >=20 > TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG >=20 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From i_faraway@163.com Sat Sep 21 23:59:28 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA0721F8B12 for ; Sat, 21 Sep 2013 23:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.72 X-Spam-Level: X-Spam-Status: No, score=0.72 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, RELAY_IS_220=2.118] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miKdVp0vuLdH for ; Sat, 21 Sep 2013 23:59:24 -0700 (PDT) Received: from m13-17.163.com (m13-17.163.com [220.181.13.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9321F8F6D for ; Sat, 21 Sep 2013 23:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Received:Date:From:To:Cc:Subject:Sender:In-Reply-To: References:Content-Type:MIME-Version:Message-ID; bh=mhWJJjlb4ODe tuPOR7zm8zrw0aTjqIGbn7uYcsut1YQ=; b=n5pou2Z1GF4xdhQgYf1Ujl9yr/Z6 ZKlWtlmG4g/YiY+mBoYb0N37GV+WoGa2gJOUM9L6xPUxg7zNzn1s6SOb3CdkROSv xr9AMKIz6TSASuwy6ja0D2fdoeLjKoBMMHUn+7fU5rBS2+AM9X2PB8ZICfz+PDU4 58QIJ+HKQMqm3H8= Received: from chenjian.conac$gmail.com ( [59.252.170.29] ) by ajax-webmail-wmsvr17 (Coremail) ; Sun, 22 Sep 2013 14:58:38 +0800 (CST) X-Originating-IP: [59.252.170.29] Date: Sun, 22 Sep 2013 14:58:38 +0800 (CST) From: "Jian Chen" To: "Hollenbeck, Scott" X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20130822(23259.5548.5550) Copyright (c) 2002-2013 www.mailtech.cn 163com Sender: i_faraway@163.com In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary="----=_Part_267518_1576641861.1379833118034" MIME-Version: 1.0 Message-ID: X-CM-TRANSID: EcGowADHyggflT5Sjr0VAA--.15707W X-CM-SenderInfo: plbit2pdzd5qqrwthudrp/1tbisQ+gTlD+NblnrQAAs4 X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 06:59:29 -0000 ------=_Part_267518_1576641861.1379833118034 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit Hi Scott, I'm willing to participate and do some help. best regards,Jian Chen -- At 2013-09-18 19:20:51,"Hollenbeck, Scott" wrote: >I recently closed a conversation with Applications Area Director Pete Resnick to see what he thought about a narrowly-focused charter for a working group to develop a registry for EPP extensions. Pete has agreed with the concept in principal. I'm including the text of the proposed charter that I shared with Pete and I'd like to ask others to review it and share feedback as appropriate. > >If we have enough support for a proposed charter Pete is willing to entertain a chartering request. If there's more to discuss we can ask about scheduling a BOF during the Vancouver meeting. > >I've got one specific question: are people able and willing to write a draft (or drafts) that describe(s) the registry and registration procedures? I don't think this will be a difficult task because cloning an existing registry is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will have me) if we form a working group, and thus it would be best if we find other volunteers to write documents. > >Scott >---------- >Proposed Charter for EPP Extensions (eppext) Working Group > >The Extensible Provisioning Protocol (EPP) was a work product of the IETF Provisioning Registry Protocol (provreg) working group. EPP was published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard domain name provisioning protocol for generic top-level domain name registries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain registries. > >Domain name registries implement a variety of business models. The difference in these models made it very difficult to come up with a "one size fits all" provisioning protocol, so the provreg working group made a conscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additional features to be specified on an "as needed" basis. Guidelines for extending EPP were published as Informational RFC 3735 in March 2004. > >The provreg working group was chartered to develop EPP, but not these additional extensions. The working group was closed in 2004 after producing a number of Proposed Standard specifications. As registries began to implement and deploy EPP the need for extensions became real, and the user community found itself facing a situation in which multiple extensions were being developed by different registries to solve the same basic problems, such as registering internationalized domain name variants. > >ICANN is now well into a program to delegate a large number of new generic top-level domains. EPP will be used to provision those domains, and new registry operators are expected to develop additional protocol extensions. With no way to coordinate the development of these extensions, the problem of non-standard extension duplication is only expected to become worse. > >The goal of the EPP Extensions (eppext) working group is to develop an IANA registry of EPP extensions and procedures to review specifications for inclusion in the registry. It will accomplish this goal in two steps: > >1. Develop a Proposed Standard specification for the registration and review of EPP extensions. There is no current Internet Draft that describes this process. > >2. Test the extension registration process by developing a small number of standards track extensions that currently exist in Internet Draft form, including: > >draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) > >draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) > >draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) >draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) >draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-smd. > >When these milestones have been completed the working group will consider rechartering to explore the issue of ongoing extension development and standardization. Modifications to EPP itself are explicitly out of scope for this working group. > >Milestones: > >TBD Extensions registry document to IESG > >TBD draft-gieben-epp-keyrelay to IESG > >TBD draft-obispo-epp-idn to IESG > >TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG > > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg ------=_Part_267518_1576641861.1379833118034 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit 
Hi Scott,

I'm willing to participate and do some help.
best regards,
Jian Chen

--

At 2013-09-18 19:20:51,"Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
>I recently closed a conversation with Applications Area Director Pete Resnick to see what he thought about a narrowly-focused charter for a working group to develop a registry for EPP extensions. Pete has agreed with the concept in principal. I'm including the text of the proposed charter that I shared with Pete and I'd like to ask others to review it and share feedback as appropriate.
>
>If we have enough support for a proposed charter Pete is willing to entertain a chartering request. If there's more to discuss we can ask about scheduling a BOF during the Vancouver meeting.
>
>I've got one specific question: are people able and willing to write a draft (or drafts) that describe(s) the registry and registration procedures? I don't think this will be a difficult task because cloning an existing registry is a perfectly reasonable approach, but someone needs to do the work. I'm willing to co-chair (if you all will have me) if we form a working group, and thus it would be best if we find other volunteers to write documents.
>
>Scott
>----------
>Proposed Charter for EPP Extensions (eppext) Working Group
>
>The Extensible Provisioning Protocol (EPP) was a work product of the IETF Provisioning Registry Protocol (provreg) working group. EPP was published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009. It is the standard domain name provisioning protocol for generic top-level domain name registries that operate under the auspices of the Internet Corporation&nbs
 p;for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain registries.
>
>Domain name registries implement a variety of business models. The difference in these models made it very difficult to come up with a "one size fits all" provisioning protocol, so the provreg working group made a conscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additional features to be specified on an "as needed" basis. Guidelines for extending EPP were published as Informational RFC 3735 in March 2004.
>
>The provreg working group was chartered to develop EPP, but not these additional extensions. The working group was closed in 2004 after producing a number of Proposed Standard specifications. As registries began to implement and deploy EPP the need for extensions became real, and the user community found itself facing a situation in which multiple extensions were being developed by different registries to solve the same basic problems, such as registering internationalized domain name variants.
>
>ICANN is now well into a program to delegate a large number of new generic top-level domains. EPP will be used to provision those domains, and new registry operators are expected to develop additional protocol extensions. With no way to coordinate the development of these extensions, the problem of non-standard extension duplication is only expected to become worse.
>
>The goal of the EPP Extensions (eppext) working group is to develop an IANA registry of EPP extensions and procedures to review specifications for inclusion in the registry. It will accomplish this goal in two steps:
>
>1. Develop a Proposed Standard specification for the registration and review of EPP extensions. There is no current Internet Draft that describes this process.
>
>2. Test the extension registration process by developing a small number of standards track extensions that currently exist in Internet Draft form, including:
>
>draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
>
>draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
>
>draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
>draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
>draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-smd.
>
>When these milestones have been completed the working group will consider rechartering to explore the issue of ongoing extension development and standardization. Modifications to EPP itself are explicitly out of scope for this working group.
>
>Milestones:
>
>TBD Extensions registry document to IESG
>
>TBD draft-gieben-epp-keyrelay to IESG
>
>TBD draft-obispo-epp-idn to IESG
>
>TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG
>
>
>_______________________________________________
>provreg mailing list
>provreg@ietf.org
>https://www.ietf.org/mailman/listinfo/provreg
------=_Part_267518_1576641861.1379833118034-- From peter@denic.de Sun Sep 22 22:28:57 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7F921F9E12 for ; Sun, 22 Sep 2013 22:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r65+BNsrLkor for ; Sun, 22 Sep 2013 22:28:56 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A721F9DFB for ; Sun, 22 Sep 2013 22:28:55 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1VNyhY-0005j8-4w; Mon, 23 Sep 2013 07:28:52 +0200 Received: from localhost by x27.adm.denic.de with local id 1VNyhY-0002qn-15; Mon, 23 Sep 2013 07:28:52 +0200 Date: Mon, 23 Sep 2013 07:28:52 +0200 From: Peter Koch To: provreg@ietf.org Message-ID: <20130923052852.GK20235@x28.adm.denic.de> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 05:28:57 -0000 Scott, all, > Proposed Charter for EPP Extensions (eppext) Working Group looks like a good start for develioping the list discussion into a charter. > ICANN is now well into a program to delegate a large number of new generic top-level domains. EPP will be used to provision those domains, and new registry operators are expected to develop additional protocol extensions. With no way to coordinate the development of these extensions, the problem of non-standard extension duplication is only expected to become worse. The IETF has not made the best experience with working on protocols with explicitly naming ICANN as the primary, let alone single, stakeholder. I understand this is a motivator, but the charter would probably not suffer from an omission of this section. > The goal of the EPP Extensions (eppext) working group is to develop an IANA registry of EPP extensions and procedures to review specifications for inclusion in the registry. It will accomplish this goal in two steps: There seems to be a need for some catalog of extensions, but my feeling is that an IANA registry isn't the right approach. There's no identifier space (except that there's already some XML registration involved) and artificially creating such space just to make IANA eligible for maintaining such a catalog looks odd to me. > 1. Develop a Proposed Standard specification for the registration and review of EPP extensions. There is no current Internet Draft that describes this process. With the above said and just as a nit: an IANA registration policy would fit into a BCP better than into a PS/standards track document. > 2. Test the extension registration process by developing a small number of standards track extensions that currently exist in Internet Draft form, including: > > draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) > > draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) > > draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) > draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) > draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-smd. Work on these could actually progress without (1) done and even without (1) at all. -Peter (otherwise EPP ignorant) From zhoulinlin@cnnic.cn Mon Sep 23 02:16:41 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C521F99F8 for ; Mon, 23 Sep 2013 02:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkmO+hRSUiyY for ; Mon, 23 Sep 2013 02:16:33 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id F051521F9D7C for ; Mon, 23 Sep 2013 02:16:31 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 23 Sep 2013 17:16:07 +0800 From: "Linlin Zhou" To: "'Hollenbeck, Scott'" , References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 23 Sep 2013 17:16:08 +0800 Message-ID: <013001ceb83d$8a2db450$9e891cf0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac60YSDD3AqH2WpnRAOeb5Tvgs6iewD3Fnng Content-Language: zh-cn Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 09:16:41 -0000 volunteer to write and review Regards, Linlin > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf > Of Hollenbeck, Scott > Sent: Wednesday, September 18, 2013 7:21 PM > To: provreg@ietf.org > Subject: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group > > I recently closed a conversation with Applications Area Director Pete Resnick to > see what he thought about a narrowly-focused charter for a working group to > develop a registry for EPP extensions. Pete has agreed with the concept in > principal. I'm including the text of the proposed charter that I shared with Pete > and I'd like to ask others to review it and share feedback as appropriate. > > If we have enough support for a proposed charter Pete is willing to entertain a > chartering request. If there's more to discuss we can ask about scheduling a > BOF during the Vancouver meeting. > > I've got one specific question: are people able and willing to write a draft (or > drafts) that describe(s) the registry and registration procedures? I don't think > this will be a difficult task because cloning an existing registry is a perfectly > reasonable approach, but someone needs to do the work. I'm willing to co-chair > (if you all will have me) if we form a working group, and thus it would be best if > we find other volunteers to write documents. > > Scott > ---------- > Proposed Charter for EPP Extensions (eppext) Working Group > > The Extensible Provisioning Protocol (EPP) was a work product of the IETF > Provisioning Registry Protocol (provreg) working group. EPP was published as a > Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It > became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007, > and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in > August 2009. It is the standard domain name provisioning protocol for generic > top-level domain name registries that operate under the auspices of the > Internet Corporation for Assigned Names and Numbers (ICANN). It is also used > by a number of country code top-level domain registries. > > Domain name registries implement a variety of business models. The > difference in these models made it very difficult to come up with a "one size fits > all" provisioning protocol, so the provreg working group made a conscious > decision to focus on a minimal set of common functionality. EPP was designed > to be extensible to allow additional features to be specified on an "as needed" > basis. Guidelines for extending EPP were published as Informational RFC 3735 > in March 2004. > > The provreg working group was chartered to develop EPP, but not these > additional extensions. The working group was closed in 2004 after producing a > number of Proposed Standard specifications. As registries began to implement > and deploy EPP the need for extensions became real, and the user community > found itself facing a situation in which multiple extensions were being > developed by different registries to solve the same basic problems, such as > registering internationalized domain name variants. > > ICANN is now well into a program to delegate a large number of new generic > top-level domains. EPP will be used to provision those domains, and new > registry operators are expected to develop additional protocol extensions. With > no way to coordinate the development of these extensions, the problem of > non-standard extension duplication is only expected to become worse. > > The goal of the EPP Extensions (eppext) working group is to develop an IANA > registry of EPP extensions and procedures to review specifications for inclusion > in the registry. It will accomplish this goal in two steps: > > 1. Develop a Proposed Standard specification for the registration and review of > EPP extensions. There is no current Internet Draft that describes this process. > > 2. Test the extension registration process by developing a small number of > standards track extensions that currently exist in Internet Draft form, > including: > > draft-gieben-epp-keyrelay > (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/) > > draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/) > > draft-tan-epp-launchphase > (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/) > draft-lozano-tmch-smd > (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/) > draft-tan-epp-launchphase has a normative dependency on > draft-lozano-tmch-smd. > > When these milestones have been completed the working group will consider > rechartering to explore the issue of ongoing extension development and > standardization. Modifications to EPP itself are explicitly out of scope for this > working group. > > Milestones: > > TBD Extensions registry document to IESG > > TBD draft-gieben-epp-keyrelay to IESG > > TBD draft-obispo-epp-idn to IESG > > TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From shollenbeck@verisign.com Mon Sep 23 05:41:26 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3121F9B07 for ; Mon, 23 Sep 2013 05:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvSQK+iR2Boa for ; Mon, 23 Sep 2013 05:41:20 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 03DD021F9E46 for ; Mon, 23 Sep 2013 05:40:00 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUkA2oOFpTmaJbX86DgRHKVcnYJx85/Iw@postini.com; Mon, 23 Sep 2013 05:41:17 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8NCdvfM014280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 08:39:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 23 Sep 2013 08:39:56 -0400 From: "Hollenbeck, Scott" To: Ning Kong Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOtz2ZmX9dBsXS7EmDAJcwQr7Ww5nTPAOw Date: Mon, 23 Sep 2013 12:39:55 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4927F168@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2C5F1C48-DB4A-4CC2-A896-D1BFD02E8557@cnnic.cn> In-Reply-To: <2C5F1C48-DB4A-4CC2-A896-D1BFD02E8557@cnnic.cn> 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 Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:41:26 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOaW5nIEtvbmcgW21haWx0bzpu a29uZ0Bjbm5pYy5jbl0NCj4gU2VudDogU2F0dXJkYXksIFNlcHRlbWJlciAyMSwgMjAxMyAxMDo0 NCBQTQ0KPiBUbzogSG9sbGVuYmVjaywgU2NvdHQNCj4gQ2M6IHByb3ZyZWdAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtwcm92cmVnXSBQcm9wb3NlZCBDaGFydGVyIGZvciBFUFAgRXh0ZW5zaW9u cyAoZXBwZXh0KQ0KPiBXb3JraW5nIEdyb3VwDQo+IA0KPiANCj4gVGhhbmtzLCBTY290dC4gSSdk IGxpa2UgdG8gcmV2aWV3IGFuZCBjb250cmlidXRlLiBIb3BlIG15IHJlc3BvbnNlIGlzDQo+IG5v dCB0b28gbGF0ZS4NCj4gDQo+IEJUVywgSSBub3RpY2UgdGhhdCByZWdpc3RlcmluZyBpbnRlcm5h dGlvbmFsaXplZCBkb21haW4gbmFtZSB2YXJpYW50cw0KPiBpcyBhcyBhIGV4YW1wbGUgaW4gdGhl IHByb3Bvc2VkIGNoYXJ0ZXIuIEkgc3RpbGwgdGhpbmsgZHJhZnQta29uZy1lcHAtDQo+IGlkbi12 YXJpYW50cy1tYXBwaW5nIHJpZ2h0bHkgZm9jdXNlcyBvbiB0aGlzIHByb2JsZW0uIEkgaG9wZSB0 aGlzIGRyYWZ0DQo+IGNhbiBhbHNvIGJlIGNvbnNpZGVyZWQgYnkgdGhlIG5ldyBXRy4gQW55IHRo b3VnaHRzPw0KDQpOaW5nLCBJIHdhcyB0cnlpbmcgdG8gbGltaXQgdGhlIGluaXRpYWwgbGlzdCB0 byBhIHNtYWxsIG51bWJlciBvZiBhY3RpdmUgZHJhZnRzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4g dGhlIHN1YmplY3Qgb2YgZGlzY3Vzc2lvbiBhbmQgaGF2ZSBiZWVuIHJldmlzZWQgYXQgbGVhc3Qg b25jZSB0byByZWZsZWN0IHRoYXQgZGlzY3Vzc2lvbi4gWW91ciBkb2N1bWVudCBpcyBhIC0wMCBk cmFmdCB0aGF0IGV4cGlyZWQgaW4gU2VwdGVtYmVyIDIwMTIuIEdpdmVuIHRoZSBsYWNrIG9mIHJl Y2VudCBwcm9ncmVzcyBJIGRpZG4ndCB0aGluayB5b3VyIGRvY3VtZW50IHdhcyBmYXIgZW5vdWdo IGFsb25nIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBmaXJzdCBiYXRjaC4NCg0KU2NvdHQgDQo= From shollenbeck@verisign.com Mon Sep 23 05:57:05 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7579021F9BEF for ; Mon, 23 Sep 2013 05:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRfSFdF0RZzl for ; Mon, 23 Sep 2013 05:57:00 -0700 (PDT) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6BC21F9D8B for ; Mon, 23 Sep 2013 05:56:58 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUkA6mVvR6fc8kulZSjAZ44/zTU6MK/Rb@postini.com; Mon, 23 Sep 2013 05:57:00 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8NCuvln014870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 08:56:57 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 23 Sep 2013 08:56:56 -0400 From: "Hollenbeck, Scott" To: Peter Koch , "provreg@ietf.org" Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOuB3QfAtH3rfKgEq6lfuskqGIhZnTRAuA Date: Mon, 23 Sep 2013 12:56:55 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4927F255@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20130923052852.GK20235@x28.adm.denic.de> In-Reply-To: <20130923052852.GK20235@x28.adm.denic.de> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 12:57:05 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Peter Koch > Sent: Monday, September 23, 2013 1:29 AM > To: provreg@ietf.org > Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) > Working Group >=20 > Scott, all, >=20 > > Proposed Charter for EPP Extensions (eppext) Working Group >=20 > looks like a good start for develioping the list discussion into a > charter. Thanks for the feedback, Peter. > > ICANN is now well into a program to delegate a large number of new > generic top-level domains. EPP will be used to provision those domains, > and new registry operators are expected to develop additional protocol > extensions. With no way to coordinate the development of these > extensions, the problem of non-standard extension duplication is only > expected to become worse. >=20 > The IETF has not made the best experience with working on protocols > with explicitly naming ICANN as the primary, let alone single, > stakeholder. I understand this is a motivator, but the charter > would probably not suffer from an omission of this section. ICANN's gTLD program isn't the single stakeholder. I'd prefer to keep the t= ext to recognize reality, but I could add more to make it clear that this e= ffort isn't just a reaction to the ICANN program. > > The goal of the EPP Extensions (eppext) working group is to develop > an IANA registry of EPP extensions and procedures to review > specifications for inclusion in the registry. It will accomplish this > goal in two steps: >=20 > There seems to be a need for some catalog of extensions, but my feeling > is that an IANA registry isn't the right approach. There's no > identifier space (except that there's already some XML registration > involved) and artificially creating such space just to make IANA > eligible > for maintaining such a catalog looks odd to me. >=20 > > 1. Develop a Proposed Standard specification for the registration and > review of EPP extensions. There is no current Internet Draft that > describes this process. >=20 > With the above said and just as a nit: an IANA registration policy > would > fit into a BCP better than into a PS/standards track document. There's precedent for using IANA-maintained registries to manage the develo= pment of protocol extensions. The BCP vs. standards track discussion is wor= th having, but again, there is precedent for such documents being on the st= andards track. RFC 5797 is an example of both. I don't have a strong prefer= ence when it comes to PS or BCP, but I do prefer to follow convention. Pete= can certainly provide guidance on this point. I proposed an IANA registry based on recent list threads expressing support= for the idea. Can you suggest an alternative if you don't think this is th= e right approach? > > 2. Test the extension registration process by developing a small > number of standards track extensions that currently exist in Internet > Draft form, including: > > > > draft-gieben-epp-keyrelay (http://datatracker.ietf.org/doc/draft- > gieben-epp-keyrelay/) > > > > draft-obispo-epp-idn (http://datatracker.ietf.org/doc/draft-obispo- > epp-idn/) > > > > draft-tan-epp-launchphase (http://datatracker.ietf.org/doc/draft-tan- > epp-launchphase/) > > draft-lozano-tmch-smd (https://datatracker.ietf.org/doc/draft-lozano- > tmch-smd/) > > draft-tan-epp-launchphase has a normative dependency on draft-lozano- > tmch-smd. >=20 > Work on these could actually progress without (1) done and even without > (1) at all. Of course, but a number of people who have implemented and are using EPP ha= ve suggested that the lack of a more formal process to coordinate extension= development is causing confusion and duplication of effort. Scott From nkong@cnnic.cn Mon Sep 23 23:08:36 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B2F21F9C9A for ; Mon, 23 Sep 2013 23:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnYoQN7qWFlI for ; Mon, 23 Sep 2013 23:08:30 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 1BC6321F9C89 for ; Mon, 23 Sep 2013 23:08:29 -0700 (PDT) Received: from unknown127.0.0.1 (HELO [10.10.122.159]) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 24 Sep 2013 14:08:18 +0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ning Kong In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4927F168@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 24 Sep 2013 14:08:18 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2C5F1C48-DB4A-4CC2-A896-D1BFD02E8557@cnnic.cn> <831693C2CDA2E849A7D7A712B24E257F4927F168@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 06:08:36 -0000 > Ning, I was trying to limit the initial list to a small number of = active drafts that have already been the subject of discussion and have = been revised at least once to reflect that discussion. Your document is = a -00 draft that expired in September 2012. Given the lack of recent = progress I didn't think your document was far enough along to be = included in the first batch. The main reason of the lack of progress is that there is not a suitable = WG to improve it. I had thought to form a new WG for this work. I'm very = glad to see your work for the new eppext WG. I'm not sure we should limit the number of active drafts or limit the = number of topics for the first batch. If we choose topics, I think my = draft is within the scope. As I mentioned in my last email, "registering = internationalized domain name variants" is listed in the proposed = charter, but there is no draft within the current first batch discussing = the variants issue. If necessary, I'd like to update our draft ASAP. Cheers, Ning= From shollenbeck@verisign.com Tue Sep 24 04:03:17 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6A21F8984 for ; Tue, 24 Sep 2013 04:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqU5LZKvtTdQ for ; Tue, 24 Sep 2013 04:03:10 -0700 (PDT) Received: from exprod6og120.obsmtp.com (exprod6og120.obsmtp.com [64.18.1.236]) by ietfa.amsl.com (Postfix) with ESMTP id E2B4A21F9DB4 for ; Tue, 24 Sep 2013 04:01:47 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUkFxGnhPeQh2AKv8TT+AnIVsDvRyJZli@postini.com; Tue, 24 Sep 2013 04:03:04 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8OB1gjC006741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Sep 2013 07:01:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 24 Sep 2013 07:01:42 -0400 From: "Hollenbeck, Scott" To: Ning Kong Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group Thread-Index: AQHOuOx6BObx7A1dsEScintBGXvZ+pnUt7vg Date: Tue, 24 Sep 2013 11:01:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492815E8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <2C5F1C48-DB4A-4CC2-A896-D1BFD02E8557@cnnic.cn> <831693C2CDA2E849A7D7A712B24E257F4927F168@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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 Cc: "provreg@ietf.org" Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 11:03:17 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5pbmcgS29uZyBbbWFpbHRv Om5rb25nQGNubmljLmNuXQ0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTMgMjow OCBBTQ0KPiBUbzogSG9sbGVuYmVjaywgU2NvdHQNCj4gQ2M6IHByb3ZyZWdAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtwcm92cmVnXSBQcm9wb3NlZCBDaGFydGVyIGZvciBFUFAgRXh0ZW5zaW9u cyAoZXBwZXh0KQ0KPiBXb3JraW5nIEdyb3VwDQo+IA0KPiANCj4gPiBOaW5nLCBJIHdhcyB0cnlp bmcgdG8gbGltaXQgdGhlIGluaXRpYWwgbGlzdCB0byBhIHNtYWxsIG51bWJlciBvZg0KPiBhY3Rp dmUgZHJhZnRzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gdGhlIHN1YmplY3Qgb2YgZGlzY3Vzc2lv biBhbmQgaGF2ZQ0KPiBiZWVuIHJldmlzZWQgYXQgbGVhc3Qgb25jZSB0byByZWZsZWN0IHRoYXQg ZGlzY3Vzc2lvbi4gWW91ciBkb2N1bWVudCBpcw0KPiBhIC0wMCBkcmFmdCB0aGF0IGV4cGlyZWQg aW4gU2VwdGVtYmVyIDIwMTIuIEdpdmVuIHRoZSBsYWNrIG9mIHJlY2VudA0KPiBwcm9ncmVzcyBJ IGRpZG4ndCB0aGluayB5b3VyIGRvY3VtZW50IHdhcyBmYXIgZW5vdWdoIGFsb25nIHRvIGJlDQo+ IGluY2x1ZGVkIGluIHRoZSBmaXJzdCBiYXRjaC4NCj4gVGhlIG1haW4gcmVhc29uIG9mIHRoZSBs YWNrIG9mIHByb2dyZXNzIGlzIHRoYXQgdGhlcmUgaXMgbm90IGEgc3VpdGFibGUNCj4gV0cgdG8g aW1wcm92ZSBpdC4gSSBoYWQgdGhvdWdodCB0byBmb3JtIGEgbmV3IFdHIGZvciB0aGlzIHdvcmsu IEknbQ0KPiB2ZXJ5IGdsYWQgdG8gc2VlIHlvdXIgd29yayBmb3IgdGhlIG5ldyBlcHBleHQgV0cu DQo+IA0KPiBJJ20gbm90IHN1cmUgd2Ugc2hvdWxkIGxpbWl0IHRoZSBudW1iZXIgb2YgYWN0aXZl IGRyYWZ0cyBvciBsaW1pdCB0aGUNCj4gbnVtYmVyIG9mIHRvcGljcyBmb3IgdGhlIGZpcnN0IGJh dGNoLiBJZiB3ZSBjaG9vc2UgdG9waWNzLCBJIHRoaW5rIG15DQo+IGRyYWZ0IGlzIHdpdGhpbiB0 aGUgc2NvcGUuIEFzIEkgbWVudGlvbmVkIGluIG15IGxhc3QgZW1haWwsDQo+ICJyZWdpc3Rlcmlu ZyBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFtZSB2YXJpYW50cyIgaXMgbGlzdGVkIGluIHRo ZQ0KPiBwcm9wb3NlZCBjaGFydGVyLCBidXQgdGhlcmUgaXMgbm8gZHJhZnQgd2l0aGluIHRoZSBj dXJyZW50IGZpcnN0IGJhdGNoDQo+IGRpc2N1c3NpbmcgdGhlIHZhcmlhbnRzIGlzc3VlLg0KDQpJ J20gZ29pbmcgd2l0aCBQZXRlJ3Mgb3JpZ2luYWwgZ3VpZGFuY2Ugb24gdGhlIGRyYWZ0cyB0byBi ZSBzZWxlY3RlZC4gVGhpcyBpcyBob3cgSm9obiBMZXZpbmUgZXhwbGFpbmVkIHRoYXQgZ3VpZGFu Y2UgdG8gbWU6DQoNCj4gSSB0YWxrZWQgdG8gUGV0ZSBSZXNuaWNrLCBvbmUgb2YgdGhlIElFVEYg YXBwcyBhcmVhIEFEcyB5ZXN0ZXJkYXksIGFuZA0KPiBoZQ0KPiBzYXlzIGhlJ3Mgd2lsbGluZyB0 byBzZXQgdXAgYSBzaG9ydCBsaXZlZCB3b3JraW5nIGdyb3VwIHRvIHR1cm4gRVBQDQo+IGV4dGVu c2lvbiBkcmFmdHMgaW50byBSRkNzLiAgVGhlcmUgYXJlIHR3byBjb25kaXRpb25zOiB0aGF0IHdl IGlkZW50aWZ5DQo+IHRoZSBkcmFmdHMgaW4gYWR2YW5jZSwgYWxsIG9mIHdoaWNoIGhhdmUgdG8g YmUgaW4gY3VycmVudCB1c2UsIGFuZCB0aGF0DQo+IHdlDQo+IHJvdW5kIHVwIGVub3VnaCBwZW9w bGUgd2l0aCBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHRvIHJlYWQgdGhlbSBhbmQNCj4gY29u ZmlybSB0aGF0IHdoYXQgd2UgcGxhbiB0byBwdWJsaXNoIGlzIHdoYXQgdGhleSBpbXBsZW1lbnRl ZC4NCg0KU28gSSBoYXZlIHRvIGRpc2FncmVlIHdoZW4gaXQgY29tZXMgdG8gaW1wb3NpbmcgbGlt aXRzIC0gYW5kIEkgY2FuIGVhc2lseSBjaGFuZ2UgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBp ZiB0aGVyZSBpcyBhbnkgY29uZnVzaW9uIGFib3V0IElETiB2YXJpYW50cy4gUHVzaGluZyBvdXQg YW4gdXBkYXRlIG5vdyB0byBjcmVhdGUgdGhlIGlsbHVzaW9uIG9mIGFjdGl2aXR5IHdvbid0IGhl bHAgdXMuDQoNClNjb3R0DQo= From shollenbeck@verisign.com Thu Sep 26 04:14:04 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348911E8192 for ; Thu, 26 Sep 2013 04:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfTSg94KFT7E for ; Thu, 26 Sep 2013 04:13:59 -0700 (PDT) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1220A11E818E for ; Thu, 26 Sep 2013 04:13:57 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUkQW9KSEf/yZFSrBQjHAxiDSkj0cuxzX@postini.com; Thu, 26 Sep 2013 04:13:58 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8QBDqDb029263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Sep 2013 07:13:55 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 26 Sep 2013 07:13:52 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: Updated eppext Charter Proposal Thread-Index: Ac66qXsArrRFBOsvR2+12u+sQEcKCA== Date: Thu, 26 Sep 2013 11:13:52 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492843D1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [provreg] Updated eppext Charter Proposal X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 11:14:04 -0000 Updated charter proposal with mods to reflect received comments. Scott ---------- Proposed Charter for EPP Extensions (eppext) Working Group Co-Chair: Scott Hollenbeck Co-Chair: TBD The Extensible Provisioning Protocol (EPP) was a work product of the IETF P= rovisioning Registry Protocol (provreg) working group. EPP was published as= a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.= It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May = 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) i= n August 2009. It is the standard domain name provisioning protocol for gen= eric top-level domain name registries that operate under the auspices of th= e Internet Corporation for Assigned Names and Numbers (ICANN). It is also u= sed by a number of country code top-level domain registries. Domain name registries implement a variety of business models. The differen= ce in these models made it very difficult to come up with a "one size fits = all" provisioning protocol, so the provreg working group made a conscious d= ecision to focus on a minimal set of common functionality. EPP was designed= to be extensible to allow additional features to be specified on an "as ne= eded" basis. Guidelines for extending EPP were published as Informational R= FC 3735 in March 2004. The provreg working group was chartered to develop EPP, but not these addit= ional extensions. The working group was closed in 2004 after producing a nu= mber of Proposed Standard specifications. As registries began to implement = and deploy EPP the need for extensions became real, and the user community = found itself facing a situation in which multiple extensions were being dev= eloped by different registries to solve the same basic problems, such as re= gistering additional contact information. EPP is widely implemented by generic top-level domain name registry operato= rs. It is also used by multiple country-code top-level domain name registry= operators. The Internet Corporation for Assigned Names and Numbers (ICANN)= has an active program to delegate a large number of new generic top-level = domains. EPP will be used to provision those domains, and new registry oper= ators are expected to develop additional protocol extensions. With no way t= o coordinate the development of these extensions, the problem of non-standa= rd extension duplication by multiple operators is only expected to become w= orse. The goal of the EPP Extensions (eppext) working group is to develop an IANA= registry of EPP extensions and procedures to review specifications for inc= lusion in the registry. It will accomplish this goal in two steps: 1. Develop a Proposed Standard specification for the registration and revie= w of EPP extensions. There is no current Internet Draft that describes this= process. 2. Developing a small number of standards track extensions that currently e= xist and use the IANA registration process as developed in 1 to register th= ose extensions, including: DNSSEC key relay: draft-gieben-epp-keyrelay (http://datatracker.ietf.org/do= c/draft-gieben-epp-keyrelay/) Internationalized domain names: draft-obispo-epp-idn (http://datatracker.ie= tf.org/doc/draft-obispo-epp-idn/) New TLD launch phases: draft-tan-epp-launchphase (http://datatracker.ietf.o= rg/doc/draft-tan-epp-launchphase/) Trademark Clearinghouse: draft-lozano-tmch-smd (https://datatracker.ietf.or= g/doc/draft-lozano-tmch-smd/) Note: draft-tan-epp-launchphase has a normative dependency on draft-lozano-= tmch-smd. When these milestones have been completed the working group will consider r= echartering to explore the issue of ongoing extension development and stand= ardization. Modifications to EPP itself are explicitly out of scope for thi= s working group. Milestones: May 2014: Extensions registry document to IESG July 2014: draft-gieben-epp-keyrelay to IESG July 2014: draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG September 2014: draft-obispo-epp-idn to IESG