From stuart.olmstead-wilcox@cira.ca Thu Oct 3 08:21:19 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 5ECB121F88BA for ; Thu, 3 Oct 2013 08:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IiWcTZ66EhCr for ; Thu, 3 Oct 2013 08:21:09 -0700 (PDT) Received: from mail02.prd.cira.ca (mail02.tor.cira.ca [192.228.26.136]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED821F8C40 for ; Thu, 3 Oct 2013 08:13:57 -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 r93FDtqn003837 for ; Thu, 3 Oct 2013 11:13:55 -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 E8541ACE5C for ; Thu, 3 Oct 2013 11:13:54 -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 63EF5ACD6B for ; Thu, 3 Oct 2013 11:13:53 -0400 (EDT) Received: from EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50]) by EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c%17]) with mapi id 14.01.0438.000; Thu, 3 Oct 2013 11:13:53 -0400 From: Stuart Olmstead-Wilcox To: "provreg@ietf.org" Thread-Topic: Registry lock - setting statuses on hosts Thread-Index: Ac7ASSd258mf5+8rRhaCy+iu5Mrwpw== Date: Thu, 3 Oct 2013 15:13:52 +0000 Message-ID: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.124] Content-Type: multipart/alternative; boundary="_000_70D5512396D78D4880DA5D7B2363E72324415955EXCH01CORPCIRAC_" MIME-Version: 1.0 Subject: [provreg] Registry lock - setting statuses on hosts 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, 03 Oct 2013 15:21:20 -0000 --_000_70D5512396D78D4880DA5D7B2363E72324415955EXCH01CORPCIRAC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, At CIRA we are working through our approach to Registry Lock and are wonder= ing what perspectives there are out there on the approach to setting of ser= ver statuses on hosts - i.e. the locking of hosts. We are considering two main approaches: 1. From the setting of a "domain lock" (serverUpdate, serverTransfer = and serverDelete prohibited statuses set), automatically cascade the relate= d host statuses (serverUpdate and serverDelete prohibited) to all host enti= ties assigned (nameservers) to the domain in question. 2. Separate the locking of domains and hosts into disparate transacti= ons - i.e. one domain update transaction to set the domain server statuses = followed by subsequent host update transactions to set server statuses on d= esired hosts. Our main considerations here are balancing ease of use from a registrar's p= erspective vs differing too far from a consistent industry approach. All feedback would be appreciated. Thanks, Stu Stu Olmstead-Wilcox, Development Manager Canadian Internet Registration Authority (CIRA) Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYSTEMS Trends, Commentary, Perspective. Stay tuned to cirablog.ca --_000_70D5512396D78D4880DA5D7B2363E72324415955EXCH01CORPCIRAC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

At CIRA we are working through our approach to Regis= try Lock and are wondering what perspectives there are out there on the app= roach to setting of server statuses on hosts – i.e. the locking of ho= sts.

 

We are considering two main approaches:

 

1.     &= nbsp; From the setting of a “domain lock” (se= rverUpdate, serverTransfer and serverDelete prohibited statuses set), autom= atically cascade the related host statuses (serverUpdate and serverDelete p= rohibited) to all host entities assigned (nameservers) to the domain in question.

 

2.     &= nbsp; Separate the locking of domains and hosts into disp= arate transactions – i.e. one domain update transaction to set the do= main server statuses followed by subsequent host update transactions to set= server statuses on desired hosts.

 

Our main considerations here are balancing ease of u= se from a registrar’s perspective vs differing too far from a consist= ent industry approach. 

 

All feedback would be appreciated.

 

Thanks,

Stu

 

Stu Olmstead-Wilcox, Developmen= t Manager
Canadian Internet Registration Authority (CIRA)
Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYS= TEMS
Trends, Commentary, Perspective.  Stay tuned to cirablog.ca

 

--_000_70D5512396D78D4880DA5D7B2363E72324415955EXCH01CORPCIRAC_-- From jan@irial.com Sun Oct 6 09:10: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 84A0221F9D09 for ; Sun, 6 Oct 2013 09:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] 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 nA0NpIM5Ev34 for ; Sun, 6 Oct 2013 09:10:12 -0700 (PDT) Received: from assp.oa5.com (unknown [IPv6:2a01:c0:2:6:225:90ff:fed2:2b47]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED01F0D21 for ; Sun, 6 Oct 2013 09:10:07 -0700 (PDT) Received: from [192.168.224.2] (localhost.localdomain [127.0.0.1]) jan@assp.knots.net (authenticated bits=0) by assp.oa5.com (8.14.4/8.12.11) with ESMTP id r96GA5sM027699 sender jan@irial.com for ; Sun, 6 Oct 2013 17:10:05 +0100 Received: from [192.168.224.2] ([80.217.51.175] helo=[192.168.224.2]) by ASSP.OA5.COM with SMTP (2.3.3); 6 Oct 2013 17:10:05 +0100 Message-ID: <52518B5D.9020606@irial.com> Date: Sun, 06 Oct 2013 18:10:05 +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: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> In-Reply-To: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Version: 2.3.3(13276) on ASSP.OA5.COM X-Assp-ID: ASSP.OA5.COM X-Assp-Session: 7FA58AD07F58 (mail 1) X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 06 Oct 2013 16:10:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all. - From my point of view the Server flags is never ever something that the registrar should be able to set over EPP. This (in my opinion) is something that the registry only can set, and perhaps the registrar och registrant with some other, out of bound, method. But if we put that aside, i think one have to separate the domain lock from the host lock. Think of the possibility that you have one domain having hosts (name servers) from another domain. IN that case, you might want to lock the domain without host and also unlock a has separate to update it. This is my 5 cents. Mvh jan On 10/03/2013 05:13 PM, Stuart Olmstead-Wilcox wrote: > Hello, > > > > At CIRA we are working through our approach to Registry Lock and are > wondering what perspectives there are out there on the approach to > setting of server statuses on hosts – i.e. the locking of hosts. > > > > We are considering two main approaches: > > > > 1. From the setting of a “domain lock” (serverUpdate, > serverTransfer and serverDelete prohibited statuses set), automatically > cascade the related host statuses (serverUpdate and serverDelete > prohibited) to all host entities assigned (nameservers) to the domain in > question. > > > > 2. Separate the locking of domains and hosts into disparate > transactions – i.e. one domain update transaction to set the domain > server statuses followed by subsequent host update transactions to set > server statuses on desired hosts. > > > > Our main considerations here are balancing ease of use from a > registrar’s perspective vs differing too far from a consistent industry > approach. > > > > All feedback would be appreciated. > > > > Thanks, > > Stu > > > > *Stu Olmstead-Wilcox, *Development Manager > Canadian Internet Registration Authority (CIRA) > Tel: (613) 237-5335 x265 | www.cira.ca |Twitter: @CIRASYSTEMS > > Trends, Commentary, Perspective. Stay tuned to cirablog.ca > > > > > > > _______________________________________________ > 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/ iEYEARECAAYFAlJRi10ACgkQQEpdoflEoIvL9gCeNAOCtTo7/Dgn1M/HRZk3U4UI ktUAn1KKcV7kV1Zvtir0yD9DdNmxjCWm =S7Ik -----END PGP SIGNATURE----- From mje@posix.co.za Sun Oct 6 10:01: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 8CB5411E8114 for ; Sun, 6 Oct 2013 10:01:52 -0700 (PDT) X-Quarantine-ID: 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 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=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 t6EplOMpkKX8 for ; Sun, 6 Oct 2013 10:01:51 -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 BDB5621F9E4F for ; Sun, 6 Oct 2013 10:01:46 -0700 (PDT) Received: from [2001:42a0:1000:48:c5a7:2ef8:d914:f696] by mje99.posix.co.za with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80.1) (envelope-from ) id 1VSrhu-0006Hq-Nk for provreg@ietf.org; Sun, 06 Oct 2013 19:01:38 +0200 From: Mark Elkins To: provreg In-Reply-To: <523D3B43.10800@irial.com> 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> Content-Type: multipart/signed; micalg="sha1"; protocol="application/x-pkcs7-signature"; boundary="=-SpiJCYAYB0wZm6xjnHu3" Organization: Posix Systems Date: Sun, 06 Oct 2013 19:01:26 +0200 Message-ID: <1381078886.7222.59.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: Sun, 06 Oct 2013 17:01:52 -0000 --=-SpiJCYAYB0wZm6xjnHu3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 2013-09-21 at 08:22 +0200, Jan Saell wrote: > 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. For interests sake, this weekend I devoted time to enhance security on my web based Registrar System. I added both Access-Control-Lists and an One-Time-Password system to supplement the normal security of Usernames and Passwords. The ACL is probably similar to what most EPP systems implement. Its managed by the customer (Reseller/Registrant), basically a simple string containing multiple CIDR-ed IPv4/6 addresses. The OTP coding ideas came from http://motp.sourceforge.net and is currently used to gain access to the website when one is denied access by the ACL system. Works just fine. Cost a day of development. I also have a generic application that creates OTP's on my Android mobile device which allows me access to my Registrar System. Now to convince my customers to use it! For OTP, they need to add and manage a 20 character seed and a 4 digit Pin. It would be simple to demand an OTP in order to switch off some sort of lock. --=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 --=-SpiJCYAYB0wZm6xjnHu3 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 CQUxDxcNMTMxMDA2MTcwMTI2WjAjBgkqhkiG9w0BCQQxFgQUKilN8Rsm/Qv3Ylq1+S3JzJEttAUw gaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMFFf4wgacG CyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwUV/jANBgkq hkiG9w0BAQEFAASCAQCJQttG1xpfBzGGM8GAh4DmEKkshQreRKxDMhueR+diUysERKgmTMmwvk7o CsLd4RjoudbjeZ8VWThGVfOApt51lIgwJ/gldzvZPOZcOYugL11+w41VkUNNCuXIlh4vh2RuR5b6 g6qYX1XLsp0NUQMJu+UG55+UcyfHFLws/h3pmnTMVLEraFpO59+kgc3S3bLjW4CrAshXUgiK//cc gZFkFaI9mk4Lieb9mPy5ReksgH/Bi5C1cN6XyYzBJJ53Lt3SUruXw77oUTymz9cUp0alWzCtplIF nBOdHtaCRgBDEHpyuPs1yysZ6DBDY4b/sJaJcEe/0dQpQcjf4QRhPOEnAAAAAAAA --=-SpiJCYAYB0wZm6xjnHu3-- From paf@frobbit.se Mon Oct 7 07:30:13 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 3FF1721E81AF for ; Mon, 7 Oct 2013 07:30:13 -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 DmTn2Nv3zP9D for ; Mon, 7 Oct 2013 07:30:12 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 5A93421E818D for ; Mon, 7 Oct 2013 07:30:06 -0700 (PDT) Received: from [172.20.10.2] (2.65.162.238.mobile.tre.se [2.65.162.238]) by mail.frobbit.se (Postfix) with ESMTPSA id 43654240F3; Mon, 7 Oct 2013 16:30:01 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F9BEF9DC-AAF9-49DE-BE14-C976B9CD1D44"; 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: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> Date: Mon, 7 Oct 2013 15:56:24 +0200 Message-Id: <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> To: Stuart Olmstead-Wilcox X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 07 Oct 2013 14:30:13 -0000 --Apple-Mail=_F9BEF9DC-AAF9-49DE-BE14-C976B9CD1D44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 3 okt 2013, at 17:13, Stuart Olmstead-Wilcox = wrote: > At CIRA we are working through our approach to Registry Lock and are = wondering what perspectives there are out there on the approach to = setting of server statuses on hosts =96 i.e. the locking of hosts. > =20 > We are considering two main approaches: > =20 > 1. =46rom the setting of a =93domain lock=94 (serverUpdate, = serverTransfer and serverDelete prohibited statuses set), automatically = cascade the related host statuses (serverUpdate and serverDelete = prohibited) to all host entities assigned (nameservers) to the domain in = question. > =20 > 2. Separate the locking of domains and hosts into disparate = transactions =96 i.e. one domain update transaction to set the domain = server statuses followed by subsequent host update transactions to set = server statuses on desired hosts. > =20 > Our main considerations here are balancing ease of use from a = registrar=92s perspective vs differing too far from a consistent = industry approach.=20 Do we actually know exactly what changes are no longer allowed when = there is a registry lock? For example, what about DNSSEC material? Patrik --Apple-Mail=_F9BEF9DC-AAF9-49DE-BE14-C976B9CD1D44 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 iD8DBQFSUr2JrMabGguI180RApx4AJ0S45mEuEY+rSDNInEhykoQeI+mAgCcCKaj b5aKuwJMZX5/CVwvYtQzv1Q= =Q64Q -----END PGP SIGNATURE----- --Apple-Mail=_F9BEF9DC-AAF9-49DE-BE14-C976B9CD1D44-- From stuart.olmstead-wilcox@cira.ca Wed Oct 9 18:41: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 B1F4F21F9FAC for ; Wed, 9 Oct 2013 18:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 EP47-wlFl4ev for ; Wed, 9 Oct 2013 18:41:19 -0700 (PDT) Received: from mail01.prd.cira.ca (mail01.tor.cira.ca [192.228.26.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C24E21E8256 for ; Wed, 9 Oct 2013 18:41:14 -0700 (PDT) Received: from crp-spam-01.crp-dmz.cira.ca ([10.2.36.116]) by mail01.prd.cira.ca (8.13.8/8.13.1) with SMTP id r9A1fCfX027178; Wed, 9 Oct 2013 21:41:12 -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 BA42AACDC1; Wed, 9 Oct 2013 21:41:12 -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 38290ACD71; Wed, 9 Oct 2013 21:41:11 -0400 (EDT) Received: from EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50]) by EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c%17]) with mapi id 14.01.0438.000; Wed, 9 Oct 2013 21:41:11 -0400 From: Stuart Olmstead-Wilcox To: Jan Saell , "provreg@ietf.org" Thread-Topic: [provreg] Registry lock - setting statuses on hosts Thread-Index: Ac7ASSd258mf5+8rRhaCy+iu5MrwpwChuSCAAKIhTvA= Date: Thu, 10 Oct 2013 01:41:10 +0000 Message-ID: <70D5512396D78D4880DA5D7B2363E7232441CC32@EXCH-01.CORP.CIRA.CA> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <52518B5D.9020606@irial.com> In-Reply-To: <52518B5D.9020606@irial.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 10 Oct 2013 01:41:23 -0000 SmFuLA0KDQpXZSBhcmUgaW4gYWdyZWVtZW50IG9uIGJvdGggY291bnRzLiAgDQoNCj4gRnJvbSBt eSBwb2ludCBvZiB2aWV3IHRoZSBTZXJ2ZXIgZmxhZ3MgaXMgbmV2ZXIgZXZlciBzb21ldGhpbmcg dGhhdCB0aGUgcmVnaXN0cmFyIHNob3VsZCBiZSBhYmxlIHRvIHNldCBvdmVyIEVQUC4gVGhpcyAo aW4gbXkgb3BpbmlvbikgaXMgc29tZXRoaW5nIHRoYXQgIA0KPiB0aGUgcmVnaXN0cnkgb25seSBj YW4gc2V0LCBhbmQgcGVyaGFwcyB0aGUgcmVnaXN0cmFyIG9jaCByZWdpc3RyYW50IHdpdGggc29t ZSBvdGhlciwgb3V0IG9mIGJvdW5kLCBtZXRob2QNCg0KQXQgbGVhc3QgZm9yIG91ciBpbml0aWFs IGltcGxlbWVudGF0aW9uIHdlIHdpbGwgbm90IGJlIGFsbG93aW5nIGxvY2tpbmcgdmlhIGVwcC4N Cg0KID4gQnV0IGlmIHdlIHB1dCB0aGF0IGFzaWRlLCBpIHRoaW5rIG9uZSBoYXZlIHRvIHNlcGFy YXRlIHRoZSBkb21haW4gbG9jayBmcm9tIHRoZSBob3N0IGxvY2suDQoNCkZ1bmRhbWVudGFsbHkg YWdyZWUuDQoNClRoZSBvbmx5IGNvbnNpZGVyYXRpb24gaGVyZSBpcyBlYXNlIG9mIHVzZSBmb3Ig cmFudCAvIHJhciBpZiB3ZSBjYXNjYWRlIHNlcnZlciBzdGF0dXNlcyB0byBhbGwgaG9zdHMgYXNz aWduZWQgdG8gYSBkb21haW4gLi4uIGEgInN1cGVyIiBsb2NrIGZvciBsYWNrIG9mIGEgYmV0dGVy IHRlcm0uICBJJ20gY29uY2VybmVkIGFib3V0IHJhbnQncyB3aG8gdGhpbmsgdGhlaXIgZG9tYWlu IGlzIGxvY2tlZCwgYnV0IGl0IGlzIGFjdHVhbGx5IHN0aWxsIHBvdGVudGlhbGx5IHZ1bG5lcmFi bGUgYmVjYXVzZSB0aGUgaG9zdChzKSBhcmUgbm90IGxvY2tlZC4NCg0KU3R1DQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwcm92cmVnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwcm92cmVnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW4gU2FlbGwNClNlbnQ6 IE9jdG9iZXItMDYtMTMgMTI6MTAgUE0NClRvOiBwcm92cmVnQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3Byb3ZyZWddIFJlZ2lzdHJ5IGxvY2sgLSBzZXR0aW5nIHN0YXR1c2VzIG9uIGhvc3RzDQoN Ci0tLS0tQkVHSU4gUEdQIFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6IFNIQTENCg0KSGVsbG8g YWxsLg0KDQotIEZyb20gbXkgcG9pbnQgb2YgdmlldyB0aGUgU2VydmVyIGZsYWdzIGlzIG5ldmVy IGV2ZXIgc29tZXRoaW5nIHRoYXQgdGhlIHJlZ2lzdHJhciBzaG91bGQgYmUgYWJsZSB0byBzZXQg b3ZlciBFUFAuIFRoaXMgKGluIG15IG9waW5pb24pIGlzIHNvbWV0aGluZyB0aGF0IHRoZSByZWdp c3RyeSBvbmx5IGNhbiBzZXQsIGFuZCBwZXJoYXBzIHRoZSByZWdpc3RyYXIgb2NoIHJlZ2lzdHJh bnQgd2l0aCBzb21lIG90aGVyLCBvdXQgb2YgYm91bmQsIG1ldGhvZC4NCg0KQnV0IGlmIHdlIHB1 dCB0aGF0IGFzaWRlLCBpIHRoaW5rIG9uZSBoYXZlIHRvIHNlcGFyYXRlIHRoZSBkb21haW4gbG9j ayBmcm9tIHRoZSBob3N0IGxvY2suDQoNClRoaW5rIG9mIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHlv dSBoYXZlIG9uZSBkb21haW4gaGF2aW5nIGhvc3RzIChuYW1lDQpzZXJ2ZXJzKSBmcm9tIGFub3Ro ZXIgZG9tYWluLiBJTiB0aGF0IGNhc2UsIHlvdSBtaWdodCB3YW50IHRvIGxvY2sgdGhlIGRvbWFp biB3aXRob3V0IGhvc3QgYW5kIGFsc28gdW5sb2NrIGEgaGFzIHNlcGFyYXRlIHRvIHVwZGF0ZSBp dC4NCg0KVGhpcyBpcyBteSA1IGNlbnRzLg0KDQpNdmggamFuDQoNCg0KT24gMTAvMDMvMjAxMyAw NToxMyBQTSwgU3R1YXJ0IE9sbXN0ZWFkLVdpbGNveCB3cm90ZToNCj4gSGVsbG8sDQo+IA0KPiAg DQo+IA0KPiBBdCBDSVJBIHdlIGFyZSB3b3JraW5nIHRocm91Z2ggb3VyIGFwcHJvYWNoIHRvIFJl Z2lzdHJ5IExvY2sgYW5kIGFyZSANCj4gd29uZGVyaW5nIHdoYXQgcGVyc3BlY3RpdmVzIHRoZXJl IGFyZSBvdXQgdGhlcmUgb24gdGhlIGFwcHJvYWNoIHRvIA0KPiBzZXR0aW5nIG9mIHNlcnZlciBz dGF0dXNlcyBvbiBob3N0cyDigJMgaS5lLiB0aGUgbG9ja2luZyBvZiBob3N0cy4NCj4gDQo+ICAN Cj4gDQo+IFdlIGFyZSBjb25zaWRlcmluZyB0d28gbWFpbiBhcHByb2FjaGVzOg0KPiANCj4gIA0K PiANCj4gMS4gICAgICAgRnJvbSB0aGUgc2V0dGluZyBvZiBhIOKAnGRvbWFpbiBsb2Nr4oCdIChz ZXJ2ZXJVcGRhdGUsDQo+IHNlcnZlclRyYW5zZmVyIGFuZCBzZXJ2ZXJEZWxldGUgcHJvaGliaXRl ZCBzdGF0dXNlcyBzZXQpLCANCj4gYXV0b21hdGljYWxseSBjYXNjYWRlIHRoZSByZWxhdGVkIGhv c3Qgc3RhdHVzZXMgKHNlcnZlclVwZGF0ZSBhbmQgDQo+IHNlcnZlckRlbGV0ZQ0KPiBwcm9oaWJp dGVkKSB0byBhbGwgaG9zdCBlbnRpdGllcyBhc3NpZ25lZCAobmFtZXNlcnZlcnMpIHRvIHRoZSBk b21haW4gDQo+IGluIHF1ZXN0aW9uLg0KPiANCj4gIA0KPiANCj4gMi4gICAgICAgU2VwYXJhdGUg dGhlIGxvY2tpbmcgb2YgZG9tYWlucyBhbmQgaG9zdHMgaW50byBkaXNwYXJhdGUNCj4gdHJhbnNh Y3Rpb25zIOKAkyBpLmUuIG9uZSBkb21haW4gdXBkYXRlIHRyYW5zYWN0aW9uIHRvIHNldCB0aGUg ZG9tYWluIA0KPiBzZXJ2ZXIgc3RhdHVzZXMgZm9sbG93ZWQgYnkgc3Vic2VxdWVudCBob3N0IHVw ZGF0ZSB0cmFuc2FjdGlvbnMgdG8gc2V0IA0KPiBzZXJ2ZXIgc3RhdHVzZXMgb24gZGVzaXJlZCBo b3N0cy4NCj4gDQo+ICANCj4gDQo+IE91ciBtYWluIGNvbnNpZGVyYXRpb25zIGhlcmUgYXJlIGJh bGFuY2luZyBlYXNlIG9mIHVzZSBmcm9tIGEgDQo+IHJlZ2lzdHJhcuKAmXMgcGVyc3BlY3RpdmUg dnMgZGlmZmVyaW5nIHRvbyBmYXIgZnJvbSBhIGNvbnNpc3RlbnQgDQo+IGluZHVzdHJ5IGFwcHJv YWNoLg0KPiANCj4gIA0KPiANCj4gQWxsIGZlZWRiYWNrIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0K PiANCj4gIA0KPiANCj4gVGhhbmtzLA0KPiANCj4gU3R1DQo+IA0KPiAgDQo+IA0KPiAqU3R1IE9s bXN0ZWFkLVdpbGNveCwgKkRldmVsb3BtZW50IE1hbmFnZXIgQ2FuYWRpYW4gSW50ZXJuZXQgDQo+ IFJlZ2lzdHJhdGlvbiBBdXRob3JpdHkgKENJUkEpDQo+IFRlbDogKDYxMykgMjM3LTUzMzUgeDI2 NSB8IHd3dy5jaXJhLmNhIHxUd2l0dGVyOiBAQ0lSQVNZU1RFTVMgDQo+IDxodHRwOi8vdHdpdHRl ci5jb20vQ0lSQU5FV1M+IFRyZW5kcywgQ29tbWVudGFyeSwgUGVyc3BlY3RpdmUuICBTdGF5IA0K PiB0dW5lZCB0byBjaXJhYmxvZy5jYSA8aHR0cDovL3d3dy5jaXJhYmxvZy5jYS8+DQo+IA0KPiAg DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHByb3ZyZWcgbWFpbGluZyBsaXN0DQo+IHByb3ZyZWdAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcm92cmVnDQo+IA0KDQotIC0tIA0K Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCiEgSXJpYWwgLyBZQVNLIEFCDQohIEF0dDogSmFuIFNhZWxsDQohIEJveCA1 OSwgUy02OTIgMjEgS1VNTEEsIFNXRURFTg0KISBUZWw6IDAxOS01OCAyNSAxNSAgICAgSW50ICs0 Ni0xOSA1OCAyNSAxNSAgICAgRmF4ICs0Ni0xOSA1OCAzOCAwNQ0KISBFLW1haWw6IGphbkBpcmlh bC5jb20NCiEgUEdQIEZpbmdlcnByaW50OiBFOTU3IDIzQzggOUY1MSAwOTU4IEI5QUQgIDdGMTgg NDA0QSA1REExIEY5NDQgQTA4Qg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVy c2lvbjogR251UEcgdjEuNC4xMSAoR05VL0xpbnV4KQ0KQ29tbWVudDogVXNpbmcgR251UEcgd2l0 aCBUaHVuZGVyYmlyZCAtIGh0dHA6Ly93d3cuZW5pZ21haWwubmV0Lw0KDQppRVlFQVJFQ0FBWUZB bEpSaTEwQUNna1FRRXBkb2ZsRW9Jdkw5Z0NlTkFPQ3RUbzcvRGduMU0vSFJaazNVNFVJDQprdFVB bjFLS2NWN2tWMVp2dGlyMHlEOURkTm14akNXbQ0KPVM3SWsNCi0tLS0tRU5EIFBHUCBTSUdOQVRV UkUtLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnByb3ZyZWcgbWFpbGluZyBsaXN0DQpwcm92cmVnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Byb3ZyZWcNCg== From rubensk@nic.br Wed Oct 9 18:44:31 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 2D54C21E8260 for ; Wed, 9 Oct 2013 18:44:31 -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 EU1kY4GqJtgx for ; Wed, 9 Oct 2013 18:44:30 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7C21E825D for ; Wed, 9 Oct 2013 18:44:30 -0700 (PDT) Received: from [192.168.0.10] (unknown [189.33.228.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 69E252080343 for ; Wed, 9 Oct 2013 22:44:29 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Rubens Kuhl In-Reply-To: <70D5512396D78D4880DA5D7B2363E7232441CC32@EXCH-01.CORP.CIRA.CA> Date: Wed, 9 Oct 2013 22:44:28 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <52518B5D.9020606@irial.com> <70D5512396D78D4880DA5D7B2363E7232441CC32@EXCH-01.CORP.CIRA.CA> To: "EPP Provreg (provreg@ietf.org)" X-Mailer: Apple Mail (2.1283) Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 10 Oct 2013 01:44:31 -0000 > Fundamentally agree. >=20 > The only consideration here is ease of use for rant / rar if we = cascade server statuses to all hosts assigned to a domain ... a "super" = lock for lack of a better term. I'm concerned about rant's who think = their domain is locked, but it is actually still potentially vulnerable = because the host(s) are not locked. One option would be to require registry lock to only be offered to 1) Domains with in-bailwick nameservers=20 2) Domains with nameservers from domains that are also subject to = registry lock Rubens From stuart.olmstead-wilcox@cira.ca Wed Oct 9 18:45: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 950E721E8269 for ; Wed, 9 Oct 2013 18:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 NlIwLvzCgSnI for ; Wed, 9 Oct 2013 18:45:45 -0700 (PDT) Received: from mail02.prd.cira.ca (mail02.tor.cira.ca [192.228.26.136]) by ietfa.amsl.com (Postfix) with ESMTP id BDA9A21E8264 for ; Wed, 9 Oct 2013 18:45:33 -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 r9A1jTGg032299; Wed, 9 Oct 2013 21:45:29 -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 88B3FACDC1; Wed, 9 Oct 2013 21:45:29 -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 5DDACACD71; Wed, 9 Oct 2013 21:45:28 -0400 (EDT) Received: from EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50]) by EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c%17]) with mapi id 14.01.0438.000; Wed, 9 Oct 2013 21:45:28 -0400 From: Stuart Olmstead-Wilcox To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [provreg] Registry lock - setting statuses on hosts Thread-Index: Ac7ASSd258mf5+8rRhaCy+iu5MrwpwDPWIEAAHTSjUA= Date: Thu, 10 Oct 2013 01:45:27 +0000 Message-ID: <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> In-Reply-To: <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 10 Oct 2013 01:45:51 -0000 > Do we actually know exactly what changes are no longer allowed when there= is a registry lock? > For example, what about DNSSEC material? Our initial approach will be to adhere strictly to the serverUpdateProhibit= ed definition. If set via lock, then no domain updates will be permitted -= including DNSSEC material. =20 If this begins to pose a problem in the future (we will be fully epp DNSSEC= compliant 1st quarter 2014) we will revisit. Stu -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@frobbit.se]=20 Sent: October-07-13 9:56 AM To: Stuart Olmstead-Wilcox Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - setting statuses on hosts On 3 okt 2013, at 17:13, Stuart Olmstead-Wilcox wrote: > At CIRA we are working through our approach to Registry Lock and are wond= ering what perspectives there are out there on the approach to setting of s= erver statuses on hosts - i.e. the locking of hosts. > =20 > We are considering two main approaches: > =20 > 1. From the setting of a "domain lock" (serverUpdate, serverTransfe= r and serverDelete prohibited statuses set), automatically cascade the rela= ted host statuses (serverUpdate and serverDelete prohibited) to all host en= tities assigned (nameservers) to the domain in question. > =20 > 2. Separate the locking of domains and hosts into disparate transac= tions - i.e. one domain update transaction to set the domain server statuse= s followed by subsequent host update transactions to set server statuses on= desired hosts. > =20 > Our main considerations here are balancing ease of use from a registrar's= perspective vs differing too far from a consistent industry approach.=20 Do we actually know exactly what changes are no longer allowed when there i= s a registry lock? For example, what about DNSSEC material? Patrik From paf@frobbit.se Wed Oct 9 19:27: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 56BF421E8264 for ; Wed, 9 Oct 2013 19:27:41 -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 x8P-p8ASu6lq for ; Wed, 9 Oct 2013 19:27:41 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id D104221E825D for ; Wed, 9 Oct 2013 19:27:40 -0700 (PDT) Received: from [192.168.1.31] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 3E5AE23FE3; Thu, 10 Oct 2013 04:27:39 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_A336EFC0-3CB0-44F5-803E-4835E9DE3FF9"; 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: <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> Date: Thu, 10 Oct 2013 04:27:37 +0200 Message-Id: <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> To: Stuart Olmstead-Wilcox X-Mailer: Apple Mail (2.1510) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 10 Oct 2013 02:27:41 -0000 --Apple-Mail=_A336EFC0-3CB0-44F5-803E-4835E9DE3FF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 10 okt 2013, at 03:45, Stuart Olmstead-Wilcox = wrote: >> Do we actually know exactly what changes are no longer allowed when = there is a registry lock? >=20 >> For example, what about DNSSEC material? >=20 > Our initial approach will be to adhere strictly to the = serverUpdateProhibited definition. If set via lock, then no domain = updates will be permitted - including DNSSEC material. =20 >=20 > If this begins to pose a problem in the future (we will be fully epp = DNSSEC compliant 1st quarter 2014) we will revisit. Thanks! How do other registries handle registry lock and for example DNSSEC = material updates? I.e. it seems to be that a registry lock make key rollover of the KSK = for the zone be impossible. Patrik --Apple-Mail=_A336EFC0-3CB0-44F5-803E-4835E9DE3FF9 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 iD8DBQFSVhCZrMabGguI180RAhfiAJwPDpW7xBQSmzXZ/OPWRJFioftQ+wCffEj2 Ew49HYHoPfyYODBeWqdYeRM= =Uywi -----END PGP SIGNATURE----- --Apple-Mail=_A336EFC0-3CB0-44F5-803E-4835E9DE3FF9-- From stuart.olmstead-wilcox@cira.ca Thu Oct 10 05:43: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 F2AAD21E8064 for ; Thu, 10 Oct 2013 05:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 upTq3w3TvDDo for ; Thu, 10 Oct 2013 05:43:22 -0700 (PDT) Received: from mail02.prd.cira.ca (mail02.tor.cira.ca [192.228.26.136]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA011E8164 for ; Thu, 10 Oct 2013 05:43:18 -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 r9AChEm0006713; Thu, 10 Oct 2013 08:43:15 -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 E70C4ACE43; Thu, 10 Oct 2013 08:43:14 -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 93012ACD71; Thu, 10 Oct 2013 08:43:13 -0400 (EDT) Received: from EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50]) by EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c%17]) with mapi id 14.01.0438.000; Thu, 10 Oct 2013 08:43:13 -0400 From: Stuart Olmstead-Wilcox To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= Thread-Topic: [provreg] Registry lock - setting statuses on hosts Thread-Index: Ac7ASSd258mf5+8rRhaCy+iu5MrwpwDPWIEAAHTSjUAACf8PgAANFcRg Date: Thu, 10 Oct 2013 12:43:12 +0000 Message-ID: <70D5512396D78D4880DA5D7B2363E7232441D0B0@EXCH-01.CORP.CIRA.CA> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> In-Reply-To: <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.40.124] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 10 Oct 2013 12:43:27 -0000 > How do other registries handle registry lock and for example DNSSEC mater= ial updates? > I.e. it seems to be that a registry lock make key rollover of the KSK for= the zone be impossible. It certainly does seem that it would make that process cumbersome. Interes= ted in other registry feedback here as well. -----Original Message----- From: Patrik F=E4ltstr=F6m [mailto:paf@frobbit.se]=20 Sent: October-09-13 10:28 PM To: Stuart Olmstead-Wilcox Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - setting statuses on hosts On 10 okt 2013, at 03:45, Stuart Olmstead-Wilcox wrote: >> Do we actually know exactly what changes are no longer allowed when ther= e is a registry lock? >=20 >> For example, what about DNSSEC material? >=20 > Our initial approach will be to adhere strictly to the serverUpdateProhib= ited definition. If set via lock, then no domain updates will be permitted= - including DNSSEC material. =20 >=20 > If this begins to pose a problem in the future (we will be fully epp DNSS= EC compliant 1st quarter 2014) we will revisit. Thanks! How do other registries handle registry lock and for example DNSSEC materia= l updates? I.e. it seems to be that a registry lock make key rollover of the KSK for t= he zone be impossible. Patrik From mje@posix.co.za Tue Oct 15 03:49: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 8ACBF21F9A1C for ; Tue, 15 Oct 2013 03:49:51 -0700 (PDT) X-Quarantine-ID: 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: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 jqhMTwErD193 for ; Tue, 15 Oct 2013 03:49:50 -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 E4B0811E81D1 for ; Tue, 15 Oct 2013 03:49:30 -0700 (PDT) Received: from [2001:43f8:30:0:4c16:290a:674d:e798] by mje99.posix.co.za with esmtpsa (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80.1) (envelope-from ) id 1VW2Bg-0002yg-VM for provreg@ietf.org; Tue, 15 Oct 2013 12:49:24 +0200 From: Mark Elkins To: provreg@ietf.org In-Reply-To: <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> Content-Type: text/plain; charset="UTF-8" Organization: Posix Systems Date: Tue, 15 Oct 2013 12:49:15 +0200 Message-ID: <1381834155.9905.43.camel@mjelap.posix.co.za> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 8bit Subject: Re: [provreg] Registry lock - setting statuses on hosts 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: Tue, 15 Oct 2013 10:49:51 -0000 I'd like to follow up this question with a similar question.... Should anything be allowed to block an EPP based DNSSEC update? ie any type of registry/domain/host whatever lock... only exception being ServerHold - which to me is the Registrar has been locked out of the Registry System... I believe it is "No" - in order to keep DNSSEC updates as simple as possible. (KISS). Even if the Nameservers (and associated) records of a domain are no longer being published (In a Delete/Redemption or ClientHold) - I think the Registry should still not hinder a DNSSEC Update/Key Rollover. This could stop a Key-Rollover completing if the DNS Provider can not see "DS's" - because Records are not being published - but that is a different problem. What do registries say/do? On Thu, 2013-10-10 at 04:27 +0200, Patrik Fältström wrote: > On 10 okt 2013, at 03:45, Stuart Olmstead-Wilcox wrote: > > >> Do we actually know exactly what changes are no longer allowed when there is a registry lock? > > > >> For example, what about DNSSEC material? > > > > Our initial approach will be to adhere strictly to the serverUpdateProhibited definition. If set via lock, then no domain updates will be permitted - including DNSSEC material. > > > > If this begins to pose a problem in the future (we will be fully epp DNSSEC compliant 1st quarter 2014) we will revisit. > > Thanks! > > How do other registries handle registry lock and for example DNSSEC material updates? > > I.e. it seems to be that a registry lock make key rollover of the KSK for the zone be impossible. > > Patrik > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg -- . . ___. .__ 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 From jan@irial.com Tue Oct 15 06:25: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 7E6E221E8088 for ; Tue, 15 Oct 2013 06:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765] 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 oPZzM7K-x3NN for ; Tue, 15 Oct 2013 06:25:26 -0700 (PDT) Received: from assp.oa5.com (unknown [IPv6:2a01:c0:2:6:225:90ff:fed2:2b47]) by ietfa.amsl.com (Postfix) with ESMTP id 410CA11E81DB for ; Tue, 15 Oct 2013 06:25:24 -0700 (PDT) Received: from [10.10.20.63] (localhost.localdomain [127.0.0.1]) jan@assp.knots.net (authenticated bits=0) by assp.oa5.com (8.14.4/8.12.11) with ESMTP id r9FDPLxn016541 sender jan@irial.com for ; Tue, 15 Oct 2013 14:25:23 +0100 Received: from [10.10.20.63] ([79.136.100.43] helo=[10.10.20.63]) by ASSP.OA5.COM with SMTP (2.3.3); 15 Oct 2013 14:25:21 +0100 Message-ID: <525D4241.6090807@irial.com> Date: Tue, 15 Oct 2013 15:25:21 +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: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> <1381834155.9905.43.camel@mjelap.posix.co.za> In-Reply-To: <1381834155.9905.43.camel@mjelap.posix.co.za> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Version: 2.3.3(13276) on ASSP.OA5.COM X-Assp-ID: ASSP.OA5.COM X-Assp-Session: 7FC4F833E078 (mail 1) X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 15 Oct 2013 13:25:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well an update is and update. And if we are talking about registry lock (in whatever form you do it) i think that its a form of lock for any changes. And to do the unlock (and lock), you need some sort of out of band method from EPP to protect the domain. And if you would allow a DNSSEC update regardless of lock status, then this would be a prime target for disabling a domain (Inserting false DNSSEC records and remove old ones would disable the domain). This means that to do a key rollover you have to plan ahead, thats true and it also means that the administration is harder but thats kind of the point to the lockdown isn't it. Best regards jan On 10/15/2013 12:49 PM, Mark Elkins wrote: > I'd like to follow up this question with a similar question.... > > Should anything be allowed to block an EPP based DNSSEC update? > > ie any type of registry/domain/host whatever lock... only exception > being ServerHold - which to me is the Registrar has been locked out of > the Registry System... > > I believe it is "No" - in order to keep DNSSEC updates as simple as > possible. (KISS). Even if the Nameservers (and associated) records of a > domain are no longer being published (In a Delete/Redemption or > ClientHold) - I think the Registry should still not hinder a DNSSEC > Update/Key Rollover. > This could stop a Key-Rollover completing if the DNS Provider can not > see "DS's" - because Records are not being published - but that is a > different problem. > > What do registries say/do? > > > On Thu, 2013-10-10 at 04:27 +0200, Patrik Fältström wrote: >> On 10 okt 2013, at 03:45, Stuart Olmstead-Wilcox wrote: >> >>>> Do we actually know exactly what changes are no longer allowed when there is a registry lock? >>> >>>> For example, what about DNSSEC material? >>> >>> Our initial approach will be to adhere strictly to the serverUpdateProhibited definition. If set via lock, then no domain updates will be permitted - including DNSSEC material. >>> >>> If this begins to pose a problem in the future (we will be fully epp DNSSEC compliant 1st quarter 2014) we will revisit. >> >> Thanks! >> >> How do other registries handle registry lock and for example DNSSEC material updates? >> >> I.e. it seems to be that a registry lock make key rollover of the KSK for the zone be impossible. >> >> Patrik >> >> _______________________________________________ >> 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/ iEYEARECAAYFAlJdQkEACgkQQEpdoflEoIsSkgCghoJkVEuQJXU3jamZEIlOsD0K jeoAn2PZwBZDDk1sImuqA0KfhNOHSCzx =cyBl -----END PGP SIGNATURE----- From Antoin.Verschuren@sidn.nl Tue Oct 15 06:40: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 C9E6C11E8128 for ; Tue, 15 Oct 2013 06:40:07 -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 d7bcddcmfiHW for ; Tue, 15 Oct 2013 06:40:03 -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 7B0E921F9FE9 for ; Tue, 15 Oct 2013 06:39:59 -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=qTyk26xbNWmZYeKaA38z46wy0121QmttMQ7hxmJFXiU=; b=t3Q2Qkp8Lw8m3AGea/9F/9uHejZi9XjkFMLNr1R68UoMN/vBG4sWzA0MBuvVw67FQApkMIfEz+MsQQOkNrPIc92CbMRxpKrrodqFt9OR3zefPy4txiBBq7c+XbRX1ZUZGMqbZI2X5bI8w+yMhBCP2wnXNyGt6tkTKQVuuwx9v5c= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r9FDdwWR003655-r9FDdwWT003655 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Tue, 15 Oct 2013 15:39:58 +0200 Received: from [94.198.152.221] (94.198.152.221) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 15 Oct 2013 15:39:57 +0200 Message-ID: <525D45AB.7050505@sidn.nl> Date: Tue, 15 Oct 2013 15:39:55 +0200 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> <1381834155.9905.43.camel@mjelap.posix.co.za> In-Reply-To: <1381834155.9905.43.camel@mjelap.posix.co.za> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.221] Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 15 Oct 2013 13:40:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 op 15-10-13 12:49, Mark Elkins schreef: > I believe it is "No" - in order to keep DNSSEC updates as simple > as possible. (KISS). Even if the Nameservers (and associated) > records of a domain are no longer being published (In a > Delete/Redemption or ClientHold) - I think the Registry should > still not hinder a DNSSEC Update/Key Rollover. This could stop a > Key-Rollover completing if the DNS Provider can not see "DS's" - > because Records are not being published - but that is a different > problem. > > What do registries say/do? There is a scenario where you hijack the registrar, and change the DNSSEC key material at the registry to DOS the victim. Or delete the DNSSEC key material so you can do cache pollution. So I think the registrant should be able to state what should be locked: - -Administrative parameters to prevent legal registrant/registrar changes - -NS and in bailiwick glue records to prevent delegation redirection - -DNSSEC key material changes to adjust security levels If you do the latter, you should unlock before you do a key rollover, but that is your own child policy decision. I would personally do so as my child policy is to only do a well prepared key rollover every X years. In stead of a very strict administrative (un)lock procedure, I would also favor a mechanism where a registrant needs to approve every change at the registry by supplying a credential that the registry and registrant both know. A request could be approved by the registrants pgp signature for example, where the public key is registered at the registry when the domain is registered. But that would need to be supported over the complete chain, and needs standardization. - -- 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) iQEcBAEBAgAGBQJSXUWlAAoJEDqHrM883AgnOZoH/R4iHsk4WPKc3D8hFAcNGQQG 4fgBW6EfGr+oWP34b93jIo1ordSBnLl0frbMg3hx3nxu/Xka0tFFb5RooD2uT2dh 4Ox7YEeo0ubsWI2g/hb3TWAY0udKTKWaIrsNMNSIutY+gAalI3YJwmnGyuXqSKmK i9dPkxYk54SDU7leXFx4LtpfoAXvaZBBFMl8IuCkzYNVFgm5MeN6mlsOwqlAswGb 7RmyV5CDaqr9EF3b0ESU7yjAa/roj7bym+c3IOCLay64+HFScNuMxnsoBwLQXTPU apTWSWAFk5Le3wg2h6GOjqZn/6Q0TDJ7Oc2StSnJ9DaQs8lZqyEsFqjks04/OS4= =OGue -----END PGP SIGNATURE----- From jaap@NLnetLabs.nl Tue Oct 15 22:32: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 D639F11E80FB for ; Tue, 15 Oct 2013 22:32: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 AURtgRqti240 for ; Tue, 15 Oct 2013 22:32:48 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 2F62C11E80E2 for ; Tue, 15 Oct 2013 22:32:48 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.7) with ESMTP id r9G5WixA069712; Wed, 16 Oct 2013 07:32:45 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201310160532.r9G5WixA069712@bela.nlnetlabs.nl> To: Antoin Verschuren From: Jaap Akkerhuis In-reply-to: <525D45AB.7050505@sidn.nl> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> <1381834155.9905.43.camel@mjelap.posix.co.za> <525D45AB.7050505@sidn.nl> Comments: In-reply-to Antoin Verschuren message dated "Tue, 15 Oct 2013 15:39:55 +0200." Date: Wed, 16 Oct 2013 07:32:44 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Wed, 16 Oct 2013 07:32:46 +0200 (CEST) Cc: provreg@ietf.org Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 16 Oct 2013 05:32:48 -0000 There is a scenario where you hijack the registrar, and change the DNSSEC key material at the registry to DOS the victim. Or delete the DNSSEC key material so you can do cache pollution. Having the private key at the domain holder would actually prevent that. jaap From Marc.Groeneweg@sidn.nl Wed Oct 16 00:59: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 4C32711E8117 for ; Wed, 16 Oct 2013 00:59:29 -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 0xy4rAYXa+Of for ; Wed, 16 Oct 2013 00:59:28 -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 8CE8111E8115 for ; Wed, 16 Oct 2013 00:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:content-transfer-encoding:mime-version; bh=2cFjo+jiEDDlBkQJhSB9dYo2lSowlJ9avyVmBcuPd0I=; b=HJsQs3fYYeCRkGeWI0or1mzqUxl12jwaxkdwsLsrr/JZHftGvqDxXcgRJwF6kqVTue36hQUJxuCZTocPkmf/xoO6pFIPuljlLjE3kbvCVQ2WlCrluU4m9XRAk6GMPKmxijKjYUnEkB4YjZMZOgCtyLaA4mx1aDaU01wVJbDD53A= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r9G7xMpS022551-r9G7xMpU022551 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL) for ; Wed, 16 Oct 2013 09:59:22 +0200 Received: from KAMBX1.SIDN.local ([fe80::501d:affc:30a9:4edf]) by kahubcasn01 ([192.168.2.73]) with mapi id 14.03.0158.001; Wed, 16 Oct 2013 09:59:22 +0200 From: Marc Groeneweg To: "'provreg@ietf.org'" Thread-Topic: [provreg] Registry lock - setting statuses on hosts Thread-Index: Ac7ASSd258mf5+8rRhaCy+iu5MrwpwDCxdsAAH1Ym4AAAXkAgAEM+fiAAAX14YAAIUbYAAAJNrcQ Date: Wed, 16 Oct 2013 07:59:22 +0000 Message-ID: <5BFD186DCB661E4D951017B0818285AE7EB33467@kambx1.SIDN.local> References: <70D5512396D78D4880DA5D7B2363E72324415955@EXCH-01.CORP.CIRA.CA> <7D5275A2-CD2D-416D-8627-4F802E894A72@frobbit.se> <70D5512396D78D4880DA5D7B2363E7232441CC60@EXCH-01.CORP.CIRA.CA> <0C8D2E3A-DC85-47EE-B055-0A6D809FE9D6@frobbit.se> <1381834155.9905.43.camel@mjelap.posix.co.za> <525D45AB.7050505@sidn.nl> <201310160532.r9G5WixA069712@bela.nlnetlabs.nl> In-Reply-To: <201310160532.r9G5WixA069712@bela.nlnetlabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry lock - setting statuses on hosts 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, 16 Oct 2013 07:59:29 -0000 >> There is a scenario where you hijack the registrar, and change the >> DNSSEC key material at the registry to DOS the victim. Or delete the >> DNSSEC key material so you can do cache pollution. > >Having the private key at the domain holder would actually prevent that. Is that true Jaap? I don't think so. The villain makes his own private key,= and makes sure he gets a real secure delegation to his own infrastructure, hijacking = the domain name and still have DNSSEC validation in place. I guess it's all about timi= ng isn't it? Regards, Marc From shollenbeck@verisign.com Fri Oct 18 14:41: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 3DB1E11E833D for ; Fri, 18 Oct 2013 14:41:37 -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 UQoAufahlh1x for ; Fri, 18 Oct 2013 14:41:32 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 10EFF11E8352 for ; Fri, 18 Oct 2013 14:41:19 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUmGq9sP8nlZLmNUFo6AuS3388+a4ZSF2@postini.com; Fri, 18 Oct 2013 14:41:19 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 r9ILaTpv015234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 18 Oct 2013 17:36:29 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 18 Oct 2013 17:36:24 -0400 From: "Hollenbeck, Scott" To: "provreg@ietf.org" Thread-Topic: EPP Extensions Registry Draft and WG Charter Status Thread-Index: Ac7MShmelNve4LyjRUmEsLScclDGWw== Date: Fri, 18 Oct 2013 21:36:24 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492B713C@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 Registry Draft and WG Charter 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: Fri, 18 Oct 2013 21:41:37 -0000 No one volunteered to put some thoughts in an I-D describing the creation a= nd management of a registry as requested here: http://www.ietf.org/mail-archive/web/provreg/current/msg07451.html So I did it myself: http://www.ietf.org/id/draft-hollenbeck-epp-ext-reg-00.txt I'm still waiting to hear back from Pete on next steps to charter a working= group. He provided some comments on the draft charter I sent to him and I = made the requested changes. He has the token to proceed or not. Scott From JGould@verisign.com Fri Oct 18 21:42: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 A9EC411E8175 for ; Fri, 18 Oct 2013 21:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, 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 mFnE6nKT5ENH for ; Fri, 18 Oct 2013 21:42:40 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id B259C11E8165 for ; Fri, 18 Oct 2013 21:42:39 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUmINv/6Yjr+8ij08pJy8HodfDAzKppeI@postini.com; Fri, 18 Oct 2013 21:42:39 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 r9J4gckw025341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 19 Oct 2013 00:42:38 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Sat, 19 Oct 2013 00:42:32 -0400 From: "Gould, James" To: "Hollenbeck, Scott" Thread-Topic: [provreg] EPP Extensions Registry Draft and WG Charter Status Thread-Index: AQHOzIWfvTQkJvYS00WWBf7y8f9hCg== Date: Sat, 19 Oct 2013 04:42:32 +0000 Message-ID: <10542AF3-D345-4984-B839-0601B2DB1C8E@verisign.com> References: <831693C2CDA2E849A7D7A712B24E257F492B713C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492B713C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] EPP Extensions Registry Draft and WG Charter 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: Sat, 19 Oct 2013 04:42:44 -0000 Scott, It looks like a great start. One question is whether we should include any= references to the namespace URI's used in the extension? Also should we i= nclude any dependencies like listing that an extension extends the domain R= FC or even another custom mapping?I am assuming that we include both object= mappings as well as extensions. Thanks for creating the draft! JG James F. Gould Principal Engineer Verisign jgould@verisign.com On Oct 19, 2013, at 6:42 AM, "Hollenbeck, Scott" = wrote: > No one volunteered to put some thoughts in an I-D describing the creation= and management of a registry as requested here: >=20 > http://www.ietf.org/mail-archive/web/provreg/current/msg07451.html >=20 > So I did it myself: >=20 > http://www.ietf.org/id/draft-hollenbeck-epp-ext-reg-00.txt >=20 > I'm still waiting to hear back from Pete on next steps to charter a worki= ng group. He provided some comments on the draft charter I sent to him and = I made the requested changes. He has the token to proceed or not. >=20 > Scott > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From shollenbeck@verisign.com Sat Oct 19 07:41: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 D735711E81C7 for ; Sat, 19 Oct 2013 07:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_71=0.6, 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 GyWhkEnCmtuv for ; Sat, 19 Oct 2013 07:41:10 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 0571511E81D1 for ; Sat, 19 Oct 2013 07:41:07 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUmKaAwMwIn1/4YWc83wl5XV0Y/5KimpD@postini.com; Sat, 19 Oct 2013 07:41:08 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 r9JEf7n4001758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 19 Oct 2013 10:41:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Sat, 19 Oct 2013 10:40:58 -0400 From: "Hollenbeck, Scott" To: "Gould, James" Thread-Topic: [provreg] EPP Extensions Registry Draft and WG Charter Status Thread-Index: Ac7MShmelNve4LyjRUmEsLScclDGWwAXQ0AAAAyE0xA= Date: Sat, 19 Oct 2013 14:40:59 +0000 Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F492B713C@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <10542AF3-D345-4984-B839-0601B2DB1C8E@verisign.com> In-Reply-To: <10542AF3-D345-4984-B839-0601B2DB1C8E@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] EPP Extensions Registry Draft and WG Charter 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: Sat, 19 Oct 2013 14:41:16 -0000 Jim, I tried to balance the info in the registry form vs. what can be found= by reading the spec. The text name is an exception, but in general I thoug= ht it best to not register redundant information. Scott > On Oct 19, 2013, at 12:42 AM, "Gould, James" wrote: >=20 > Scott, >=20 > It looks like a great start. One question is whether we should include a= ny references to the namespace URI's used in the extension? Also should we= include any dependencies like listing that an extension extends the domain= RFC or even another custom mapping?I am assuming that we include both obje= ct mappings as well as extensions. >=20 > Thanks for creating the draft! >=20 > JG >=20 > James F. Gould > Principal Engineer > Verisign >=20 > jgould@verisign.com >=20 >> On Oct 19, 2013, at 6:42 AM, "Hollenbeck, Scott" wrote: >>=20 >> No one volunteered to put some thoughts in an I-D describing the creatio= n and management of a registry as requested here: >>=20 >> http://www.ietf.org/mail-archive/web/provreg/current/msg07451.html >>=20 >> So I did it myself: >>=20 >> http://www.ietf.org/id/draft-hollenbeck-epp-ext-reg-00.txt >>=20 >> I'm still waiting to hear back from Pete on next steps to charter a work= ing group. He provided some comments on the draft charter I sent to him and= I made the requested changes. He has the token to proceed or not. >>=20 >> Scott >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg From gavin.brown@centralnic.com Thu Oct 31 09:51:54 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 9E59D11E8250 for ; Thu, 31 Oct 2013 09:51:54 -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 5WoZ6hxNt2Qv for ; Thu, 31 Oct 2013 09:51:50 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97F11E823D for ; Thu, 31 Oct 2013 09:51:50 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 8A5AA72059D for ; Thu, 31 Oct 2013 16:51:48 +0000 (UTC) Message-ID: <52728A9C.40506@centralnic.com> Date: Thu, 31 Oct 2013 16:51:40 +0000 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: provreg@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 16:51:54 -0000 Dear colleagues, As the I-D submission window is closed, I am unable to submit this to the IETF, but I plan to do so once the submissions re-open. https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-fees.txt I would like to request that this be considered for adoption by the eppext group. >From the introduction: Historically, domain name registries have applied a simple fee structure for billable transactions, namely a basic unit price applied to domain , , and RGP restore commands. Given the relatively small number of EPP servers that EPP clients have been required to connect to, it has generally been the case that client operators have been able to obtain details of these fees out-of-band by contacting the server operators. Given the imminent expansion of the DNS namespace, and the proliferation of novel business models, it is now desirable to provide a method for EPP clients to query EPP servers for the fees associated with certain commands and specific objects. This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping provides a mechanism by which EPP clients may query the fees associated with various billable transactions. You can fork the draft and push changes to me from here: https://github.com/centralnic/epp-fee-extension Regards, -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From michele@blacknight.com Thu Oct 31 09:54: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 8768221F9FCF for ; Thu, 31 Oct 2013 09:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fKRRCAp0Oi9Y for ; Thu, 31 Oct 2013 09:54:03 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB821F9CED for ; Thu, 31 Oct 2013 09:54:02 -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, 31 Oct 2013 16:54:01 +0000 From: Michele Neylon - Blacknight To: Gavin Brown , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO1lmLGL3yt6av5kuTBuUq9TrUVpoPBrpv Date: Thu, 31 Oct 2013 16:54:00 +0000 Message-ID: References: <20131031165212.58C7A5A400F@merlin.blacknight.ie> In-Reply-To: <20131031165212.58C7A5A400F@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.26.67.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 16:54:07 -0000 Gavin=0A= =0A= So in plain English you think that registrars should be getting pricing fro= m registries via EPP??=0A= =0A= Did I understand you correctly?=0A= =0A= Regards=0A= =0A= Michele=0A= =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://www.technology.ie=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: provreg-bounces@ietf.org [provreg-bounces@ietf.org] on behalf of Gavi= n Brown [gavin.brown@centralnic.com]=0A= Sent: 31 October 2013 16:51=0A= To: provreg@ietf.org=0A= Subject: [provreg] Registry Fee Extension for the Extensible Provisioning = Protocol=0A= =0A= Dear colleagues,=0A= =0A= As the I-D submission window is closed, I am unable to submit this to=0A= the IETF, but I plan to do so once the submissions re-open.=0A= =0A= https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-= fees.txt=0A= =0A= I would like to request that this be considered for adoption by the=0A= eppext group.=0A= =0A= >From the introduction:=0A= =0A= Historically, domain name registries have applied a simple fee structure=0A= for billable transactions, namely a basic unit price applied to domain=0A= , , and RGP restore commands. Given the=0A= relatively small number of EPP servers that EPP clients have been=0A= required to connect to, it has generally been the case that client=0A= operators have been able to obtain details of these fees out-of-band by=0A= contacting the server operators.=0A= =0A= Given the imminent expansion of the DNS namespace, and the proliferation=0A= of novel business models, it is now desirable to provide a method for=0A= EPP clients to query EPP servers for the fees associated with certain=0A= commands and specific objects.=0A= =0A= This document describes an extension mapping for version 1.0 of the=0A= Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping=0A= provides a mechanism by which EPP clients may query the fees associated=0A= with various billable transactions.=0A= =0A= You can fork the draft and push changes to me from here:=0A= =0A= https://github.com/centralnic/epp-fee-extension=0A= =0A= Regards,=0A= =0A= --=0A= Gavin Brown=0A= Chief Technology Officer=0A= CentralNic Group plc (LSE:CNIC)=0A= Innovative, Reliable and Flexible Registry Services=0A= for ccTLD, gTLD and private domain name registries=0A= https://www.centralnic.com/=0A= =0A= CentralNic Group plc is a company registered in England and Wales with=0A= company number 8576358. Registered Offices: 35-39 Moorgate, London,=0A= EC2R 6AR.=0A= _______________________________________________=0A= provreg mailing list=0A= provreg@ietf.org=0A= https://www.ietf.org/mailman/listinfo/provreg=0A= From rubensk@nic.br Thu Oct 31 09:57: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 5B1A411E8267 for ; Thu, 31 Oct 2013 09:57: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 F6g-4tTapSTe for ; Thu, 31 Oct 2013 09:57:03 -0700 (PDT) Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27321F9DCF for ; Thu, 31 Oct 2013 09:57:03 -0700 (PDT) Received: from rubens.in.registro.br (3.195.net.registro.br [200.160.3.195]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id DD0D5208040B; Thu, 31 Oct 2013 14:56:58 -0200 (BRST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Rubens Kuhl In-Reply-To: <52728A9C.40506@centralnic.com> Date: Thu, 31 Oct 2013 14:56:58 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <801E6CDC-4095-4F23-A0C3-874147DB3C78@nic.br> References: <52728A9C.40506@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1816) Cc: "provreg@ietf.org \(provreg@ietf.org\)" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 16:57:04 -0000 Gavin, Although ccTLDs operate on their own regulatory framework, the fact that = renew and transfers are ICANN-regulated to be of equal value would = probably lessen the interest of the community in having variable fee = or operations.=20 In this case I need to ask if there are enough ccTLDs that both operate = on registry-registrar model and allow for and prices = be based on some kind of premium status=85=20 Rubens Em 31/10/2013, =E0(s) 14:51:000, Gavin Brown = escreveu: > Dear colleagues, >=20 > As the I-D submission window is closed, I am unable to submit this to > the IETF, but I plan to do so once the submissions re-open. >=20 > = https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp= -fees.txt >=20 > I would like to request that this be considered for adoption by the > eppext group. >=20 > =46rom the introduction: >=20 > Historically, domain name registries have applied a simple fee = structure > for billable transactions, namely a basic unit price applied to domain > , , and RGP restore commands. Given the > relatively small number of EPP servers that EPP clients have been > required to connect to, it has generally been the case that client > operators have been able to obtain details of these fees out-of-band = by > contacting the server operators. >=20 > Given the imminent expansion of the DNS namespace, and the = proliferation > of novel business models, it is now desirable to provide a method for > EPP clients to query EPP servers for the fees associated with certain > commands and specific objects. >=20 > This document describes an extension mapping for version 1.0 of the > Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping > provides a mechanism by which EPP clients may query the fees = associated > with various billable transactions. >=20 > You can fork the draft and push changes to me from here: >=20 > https://github.com/centralnic/epp-fee-extension >=20 > Regards, >=20 > --=20 > Gavin Brown > Chief Technology Officer > CentralNic Group plc (LSE:CNIC) > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ >=20 > CentralNic Group plc is a company registered in England and Wales with > company number 8576358. Registered Offices: 35-39 Moorgate, London, > EC2R 6AR. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From shollenbeck@verisign.com Thu Oct 31 09:57: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 D3A1121E80B2 for ; Thu, 31 Oct 2013 09:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 GV57MdZb2hli for ; Thu, 31 Oct 2013 09:57:05 -0700 (PDT) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41111E823E for ; Thu, 31 Oct 2013 09:57:03 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUnKL3CTL2F2dhqh/9pVViLthkgREb2YZ@postini.com; Thu, 31 Oct 2013 09:57:05 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 r9VGuxBa008226 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 12:56:59 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 31 Oct 2013 12:56:59 -0400 From: "Hollenbeck, Scott" To: Gavin Brown , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO1lmD3srpOKV0Nk6WxqR2JCTfk5oPBsWQ Date: Thu, 31 Oct 2013 16:56:58 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492C4FC1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52728A9C.40506@centralnic.com> In-Reply-To: <52728A9C.40506@centralnic.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: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 16:57:11 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Gavin Brown > Sent: Thursday, October 31, 2013 12:52 PM > To: provreg@ietf.org > Subject: [provreg] Registry Fee Extension for the Extensible > Provisioning Protocol >=20 > Dear colleagues, >=20 > As the I-D submission window is closed, I am unable to submit this to > the IETF, but I plan to do so once the submissions re-open. >=20 > https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown- > epp-fees.txt >=20 > I would like to request that this be considered for adoption by the > eppext group. We don't yet have an eppext working group; Pete has said that he intends to= start the chartering process soon. It would be a good course of action to = watch for the charter proposal announcement and add this request as a comme= nt on the proposal when the window of opportunity opens. Scott From gavin.brown@centralnic.com Thu Oct 31 09:57: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 0737321E80FE for ; Thu, 31 Oct 2013 09:57:40 -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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] 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 MxUzHqEGw4ij for ; Thu, 31 Oct 2013 09:57:32 -0700 (PDT) Received: from smtp.centralnic.com (smtp.centralnic.com [193.105.170.131]) by ietfa.amsl.com (Postfix) with ESMTP id 2C15211E823E for ; Thu, 31 Oct 2013 09:57:28 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 53D1472059D; Thu, 31 Oct 2013 16:57:27 +0000 (UTC) Message-ID: <52728BEF.8000600@centralnic.com> Date: Thu, 31 Oct 2013 16:57:19 +0000 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Michele Neylon - Blacknight , "provreg@ietf.org" References: <20131031165212.58C7A5A400F@merlin.blacknight.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 16:57:41 -0000 On 31/10/2013 16:54, Michele Neylon - Blacknight wrote: > > So in plain English you think that registrars should be getting pricing from registries via EPP?? Yes. Let's say you have a registry which has a complex pricing model: casino.foobar might be $1000 but randomname.foobar is only $10. Similarly, it might cost $10 to register a domain for 1 year but only $15 for 2 years. As a registrar you need to know what to charge your customer. If the rules are complicated, you'd otherwise have to implement your own code to calculate the price to show the customer. This extension eliminates this need, because you can ask for the price at the same time you do your check, and then display as part of your availability results (having added your markup, presumably). G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From michele@blacknight.com Thu Oct 31 10:00:55 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 369A221E80F9 for ; Thu, 31 Oct 2013 10:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=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 clVkHth8lwrH for ; Thu, 31 Oct 2013 10:00:51 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id CAD7421F9E7C for ; Thu, 31 Oct 2013 10:00:50 -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, 31 Oct 2013 17:00:40 +0000 From: Michele Neylon - Blacknight To: Gavin Brown , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO1lpQdr8QueecAEWTyt82TpgAOJoPCE6u Date: Thu, 31 Oct 2013 17:00:40 +0000 Message-ID: References: <20131031165212.58C7A5A400F@merlin.blacknight.ie> , <20131031165741.CAF515A400F@merlin.blacknight.ie> In-Reply-To: <20131031165741.CAF515A400F@merlin.blacknight.ie> Accept-Language: en-IE, en-US Content-Language: en-IE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.26.67.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 17:00:55 -0000 Gavin=0A= =0A= If the registry has that kind of complex pricing I doubt many registrars wo= uld want to deal with them .. =0A= =0A= And EPP really isn't the best way to communicate pricing=0A= =0A= Seriously=0A= =0A= Regards=0A= =0A= Michele=0A= =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://www.technology.ie=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: Gavin Brown [gavin.brown@centralnic.com]=0A= Sent: 31 October 2013 16:57=0A= To: Michele Neylon - Blacknight; provreg@ietf.org=0A= Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioni= ng Protocol=0A= =0A= On 31/10/2013 16:54, Michele Neylon - Blacknight wrote:=0A= >=0A= > So in plain English you think that registrars should be getting pricing f= rom registries via EPP??=0A= =0A= Yes.=0A= =0A= Let's say you have a registry which has a complex pricing model:=0A= casino.foobar might be $1000 but randomname.foobar is only $10.=0A= Similarly, it might cost $10 to register a domain for 1 year but only=0A= $15 for 2 years.=0A= =0A= As a registrar you need to know what to charge your customer. If the=0A= rules are complicated, you'd otherwise have to implement your own code=0A= to calculate the price to show the customer. This extension eliminates=0A= this need, because you can ask for the price at the same time you do=0A= your check, and then display as part of your availability results=0A= (having added your markup, presumably).=0A= =0A= G.=0A= =0A= --=0A= Gavin Brown=0A= Chief Technology Officer=0A= CentralNic Group plc (LSE:CNIC)=0A= Innovative, Reliable and Flexible Registry Services=0A= for ccTLD, gTLD and private domain name registries=0A= https://www.centralnic.com/=0A= =0A= CentralNic Group plc is a company registered in England and Wales with=0A= company number 8576358. Registered Offices: 35-39 Moorgate, London,=0A= EC2R 6AR.=0A= From JGould@verisign.com Thu Oct 31 10:31: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 AD0DC21F9D70 for ; Thu, 31 Oct 2013 10:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 QYya+07ng4IG for ; Thu, 31 Oct 2013 10:31:54 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id EE55311E8166 for ; Thu, 31 Oct 2013 10:31:51 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUnKUB5iHF1k3oupa8cupy39N8MbXpReN@postini.com; Thu, 31 Oct 2013 10:31:53 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 r9VHVoTK006460 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 13:31:50 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 31 Oct 2013 13:31:50 -0400 From: "Gould, James" To: Gavin Brown , "provreg@ietf.org" Thread-Topic: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol Thread-Index: AQHO1l8URhS6Vf344UipPTXcIskg7Q== Date: Thu, 31 Oct 2013 17:31:49 +0000 Message-ID: In-Reply-To: <52728A9C.40506@centralnic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CE9804B550FB6jgouldverisigncom_" MIME-Version: 1.0 Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 17:32:00 -0000 --_000_CE9804B550FB6jgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gavin, It looks like an interesting idea. I do have the following comments / feed= back: 1. Why extend the check instead of info (e.g. fee info)? 2. How about supporting the use of the extension with the billable comma= nds themselves as well, where the client can ask for the fee information an= d the server can return the information in the response upon successful exe= cution? 3. It would be good to support a more flexible set of commands, like we = support the concept of sync (consolidate extension) that is also billable. = There might be other billable commands. 4. The fee could have an optional breakdown as well, where some billable= commands include a fixed fee plus another variable fee (e.g. based on peri= od extended). The total fee should obviously be a total of the more detail= ed fees. The type of fees might need to be flexible as well to support var= ious billing models. The Registrar might only be interested in the resulti= ng fee, but having the breakdown could be useful. 5. The client might be interested in any variable pricing based on perio= ds. We had created a Price Extension a while back that extended the domain info= command and response along with the other billable commands (create comman= d/response, renew command/response, transfer command/response, and update c= ommand/response for billable extensions to update like restore or sync), wi= th the following elements: * Domain Info * Command * Command Name * OPTIONAL desired period * Response =96 The idea is that a specific period could be returned = or the entire table of period pricing would be returned. * One or more priceData elements containing * Start period (.e.g starting with 1 year or 3 year period) * End period (e.g. end with 2 year or 10 year period) * Price type (e.g. regular or promotion) * Eligible =96 Is client eligible for promotion pricing * Amount =96 Price amount * Create, Renew, Transfer, and Update (for restore and sync) * Command * Marker to indicate that price information should be returned in= response * Response * Price type (e.g. regular or promotion) * Amount One other command that would be interesting is creating an extension to del= ete command / response to return any grace period credit information. -- JG James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On 10/31/13 12:51 PM, "Gavin Brown" > wrote: Dear colleagues, As the I-D submission window is closed, I am unable to submit this to the IETF, but I plan to do so once the submissions re-open. https://raw.github.com/centralnic/epp-fee-extension/master/draft-brown-epp-= fees.txt I would like to request that this be considered for adoption by the eppext group. >From the introduction: Historically, domain name registries have applied a simple fee structure for billable transactions, namely a basic unit price applied to domain , , and RGP restore commands. Given the relatively small number of EPP servers that EPP clients have been required to connect to, it has generally been the case that client operators have been able to obtain details of these fees out-of-band by contacting the server operators. Given the imminent expansion of the DNS namespace, and the proliferation of novel business models, it is now desirable to provide a method for EPP clients to query EPP servers for the fees associated with certain commands and specific objects. This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping provides a mechanism by which EPP clients may query the fees associated with various billable transactions. You can fork the draft and push changes to me from here: https://github.com/centralnic/epp-fee-extension Regards, -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_CE9804B550FB6jgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <93F2CD9DB3257648BF16E0C8728CC52A@verisign.com> Content-Transfer-Encoding: quoted-printable
Gavin,

It looks like an interesting idea. &= nbsp;I do have the following comments / feedback:
  1. Why extend the check instead of info = (e.g. fee info)?  
  2. How about supporting the use of the = extension with the billable commands themselves as well, where the client c= an ask for the fee information and the server can return the information in= the response upon successful execution?  
  3. It would be good to= support a more flexible set of commands, like we support the concept of sy= nc (consolidate extension) that is also billable.  There might be othe= r billable commands.
  4. The fee could have an optional breakdown as we= ll, where some billable commands include a fixed fee plus another variable = fee (e.g. based on period extended).  The total fee should obviously b= e a total of the more detailed fees.  The type of fees might need to be flexible as well to support various billing models.  The Regist= rar might only be interested in the resulting fee, but having the breakdown= could be useful. 
  5. The client might be interested in any varia= ble pricing based on periods.   
We had created a Price Extension a while back that extended the domain= info command and response along with the other billable commands (create c= ommand/response, renew command/response, transfer command/response, and upd= ate command/response for billable extensions to update like restore or sync), with the following elements:

  • Domain Info 
    • Command
      • Command Name 
      • OPTIONAL desired period
    • Response =96 The idea is that a specific period could be returned or th= e entire table of period pricing would be returned.
      • One or more priceData elements containing
        • Start period (.e.g starting with 1 year or 3 year period)
        • End p= eriod (e.g. end with 2 year or 10 year period)
        • Price type (e.g. reg= ular or promotion)
        • Eligible =96 Is client eligible for promotion pr= icing
        • Amount =96 Price amount
  • Create, Renew, Transfer, and Update (for restore and sync)
    • Command
      • Marker to indicate that price information should be returned in respons= e
    • Response
      • Price type (e.g. regular or promotion)
      • Amount 
One other command that would be interesting is creating an extension t= o delete command / response to return any grace period credit information. =  


-- 
 
JG
 

 
James Gould
Principal Software Engineer
jgould@verisign.com
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com



On 10/31= /13 12:51 PM, "Gavin Brown" <gavin.brown@centralnic.com> wrote:

Dear colleagues,

As the I-D submission window is closed, I am unable to submit this to<= /div>
the IETF, but I plan to do so once the submissions re-open.


I would like to request that this be considered for adoption by the
eppext group.

From the introduction:

Historically, domain name registries have applied a simple fee structu= re
for billable transactions, namely a basic unit price applied to domain=
<create>, <renew>, <transfer> and RGP restore comman= ds.  Given the
relatively small number of EPP servers that EPP clients have been
required to connect to, it has generally been the case that client
operators have been able to obtain details of these fees out-of-band b= y
contacting the server operators.

Given the imminent expansion of the DNS namespace, and the proliferati= on
of novel business models, it is now desirable to provide a method for<= /div>
EPP clients to query EPP servers for the fees associated with certain<= /div>
commands and specific objects.

This document describes an extension mapping for version 1.0 of the
Extensible Provisioning Protocol (EPP) [RFC5730].  This EPP = mapping
provides a mechanism by which EPP clients may query the fees associate= d
with various billable transactions.

You can fork the draft and push changes to me from here:


Regards,

--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries

CentralNic Group plc is a company registered in England and Wales with=
--_000_CE9804B550FB6jgouldverisigncom_-- From Klaus.Malorny@knipp.de Thu Oct 31 11:05: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 6F29A11E817A for ; Thu, 31 Oct 2013 11:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tVcz2E9HqmQM for ; Thu, 31 Oct 2013 11:05:16 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 004A221F9D5F for ; Thu, 31 Oct 2013 11:05:11 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 1C8E552; Thu, 31 Oct 2013 19:05:10 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id l4UAQ0Ex0Y9K; Thu, 31 Oct 2013 19:05:02 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id DF7AD51; Thu, 31 Oct 2013 19:05:01 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r9VI50R8013213; Thu, 31 Oct 2013 19:05:01 +0100 (MEZ) Message-ID: <52729BD2.4040207@knipp.de> Date: Thu, 31 Oct 2013 19:05:06 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1 MIME-Version: 1.0 To: Michele Neylon - Blacknight , Gavin Brown , "provreg@ietf.org" References: <20131031165212.58C7A5A400F@merlin.blacknight.ie> , <20131031165741.CAF515A400F@merlin.blacknight.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 18:05:22 -0000 On 31.10.2013 18:00, Michele Neylon - Blacknight wrote: Hi, > > If the registry has that kind of complex pricing I doubt many registrars would want to deal with them .. I wouldn't say that. For a registry, we developed a similar extension (actually, it is a pseudo object) in the context of a promotion system. By using it, the registrar can inquire whether a given promotion code is valid as such, has been consumed, the validity period of the promotion, the purpose (create/renew) and the resulting (lowered) price. And to my knowledge, it is actually used. The only problem I see with such an extension are promotional models of registries that depend on some total numbers, (e.g. you get some rebates if you register more than x domains/month). > > And EPP really isn't the best way to communicate pricing Why, and what is the better way? By the way, maybe just as an inspiration ;-) -- I once had the idea of an extension that allows the reporting of the "total cost of ownership" of a domain, i.e. the book entries of the create/transfer/renews (and maybe other charged operations). But for various reasons, I did not follow up that matter. One reason was that I don't know whether there is actually a use case for this on the registrar side. > > Seriously > > Regards > > Michele > > Regards, Klaus From lem@isc.org Thu Oct 31 11:53:43 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 4A31211E8247 for ; Thu, 31 Oct 2013 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 bzMYs9+hOlID for ; Thu, 31 Oct 2013 11:53:37 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4E79211E822D for ; Thu, 31 Oct 2013 11:53:36 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.ams1.isc.org (Postfix) with ESMTP id 3EA9E2383E3; Thu, 31 Oct 2013 18:53:23 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.0.148] (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 BB8AF216C1E; Thu, 31 Oct 2013 18:52:39 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Thu, 31 Oct 2013 14:52:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06FD9596-08BC-4D42-936E-01885F880601@isc.org> References: To: "Gould, James" X-Mailer: Apple Mail (2.1283) Cc: "provreg@ietf.org" Subject: Re: [provreg] Registry Fee Extension for the Extensible Provisioning Protocol 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, 31 Oct 2013 18:53:43 -0000 On Oct 31, 2013, at 1:31 PM, Gould, James wrote: > =95 It would be good to support a more flexible set of commands, = like we support the concept of sync (consolidate extension) that is also = billable. There might be other billable commands. I agree to this. Creating launch applications, for example, could be = something to add as well. While responding in an ISO 4217 currency works well, there should also = be support to respond in opaque or internal value representations. It is = conceivable that an EPP server is currency agnostic, instead working = with internal currency units. Best regards -lem