From owner-ietf-provreg@cafax.se Fri Apr 22 10:35:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23789 for ; Fri, 22 Apr 2005 10:35:06 -0400 (EDT) Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOzQv-0004EN-O8 for provreg-archive@ietf.org; Fri, 22 Apr 2005 10:47:10 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j3MEPsLV004729 for ; Fri, 22 Apr 2005 16:25:54 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j3MEPsed008694 for ietf-provreg-outgoing; Fri, 22 Apr 2005 16:25:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.gnr.com (mail.gnr.com [193.109.220.131]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j3MEPrxf017759 for ; Fri, 22 Apr 2005 16:25:53 +0200 (MEST) Received: (qmail 28025 invoked from network); 22 Apr 2005 14:25:53 -0000 Received: from localhost (HELO ?192.168.1.37?) (asteira@127.0.0.1) by mail.gnr.com with SMTP; 22 Apr 2005 14:25:53 -0000 Subject: [ietf-provreg] .name EPP 1.0 implementation From: "Asbjorn S. Mikkelsen" To: ietf-provreg@cafax.se Content-Type: text/plain Date: Fri, 22 Apr 2005 15:25:52 +0100 Message-Id: <1114179952.1909.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk X-Spam-Score: 1.8 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Status: O Hi, As you might or might not be aware, dotName implemented EPP version 05/03 with the following additional feature added from EPP version 06/04: "External host objects MUST be managed on a per-client basis. No superordinate domain object exists in the repository, thus no single client has management authority for the superordinate domain object. Per-client management ensures that no single client can create an instance of an external host object to the detriment of other clients who might need to use the host for DNS delegation purposes." (draft-ietf-provreg-epp-host-04.txt, page 3) The per-client management of external hosts were added as a means to avoid potential domain hijackings and conflicts between registrars. We have been in the process of upgrading to EPP 1.0 for some time now, and as the above feature has since been removed from the protocol description, we have fine-read the RFCs to find out if anything in them prohibits this behaviour. We have also consulted a few members on this list to get their views on this issue. As far as we can tell it is not clear in EPP 1.0 if having external host objects managed on a per-client basis are acceptable behaviour according to the RFC. We are aware that some people think this is an implementation detail but we are not sure and would like to ask your opinion on whether this should be explicitly stated in the RFC as acceptable behaviour. We have discussed converting from managing host objects on a per-client basis to have one shared external hosts namespace, but coordinating this when 50+ registrars have registered the same name server with us seems not feasible to either us or the registrars. Please feel free to contact me privately or on the list if you have any questions or concerns. Best regards, Asbjorn Mikkelsen CTO GNR Ltd Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j3MEPsLV004729 for ; Fri, 22 Apr 2005 16:25:54 +0200 (MEST) Received: (from majordom@localhost) by nic.cafax.se (8.12.11/8.12.11/Submit) id j3MEPsed008694 for ietf-provreg-outgoing; Fri, 22 Apr 2005 16:25:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.gnr.com (mail.gnr.com [193.109.220.131]) by nic.cafax.se (8.12.11/8.12.11) with ESMTP id j3MEPrxf017759 for ; Fri, 22 Apr 2005 16:25:53 +0200 (MEST) Received: (qmail 28025 invoked from network); 22 Apr 2005 14:25:53 -0000 Received: from localhost (HELO ?192.168.1.37?) (asteira@127.0.0.1) by mail.gnr.com with SMTP; 22 Apr 2005 14:25:53 -0000 Subject: [ietf-provreg] .name EPP 1.0 implementation From: "Asbjorn S. Mikkelsen" To: ietf-provreg@cafax.se Content-Type: text/plain Date: Fri, 22 Apr 2005 15:25:52 +0100 Message-Id: <1114179952.1909.38.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Hi, As you might or might not be aware, dotName implemented EPP version 05/03 with the following additional feature added from EPP version 06/04: "External host objects MUST be managed on a per-client basis. No superordinate domain object exists in the repository, thus no single client has management authority for the superordinate domain object. Per-client management ensures that no single client can create an instance of an external host object to the detriment of other clients who might need to use the host for DNS delegation purposes." (draft-ietf-provreg-epp-host-04.txt, page 3) The per-client management of external hosts were added as a means to avoid potential domain hijackings and conflicts between registrars. We have been in the process of upgrading to EPP 1.0 for some time now, and as the above feature has since been removed from the protocol description, we have fine-read the RFCs to find out if anything in them prohibits this behaviour. We have also consulted a few members on this list to get their views on this issue. As far as we can tell it is not clear in EPP 1.0 if having external host objects managed on a per-client basis are acceptable behaviour according to the RFC. We are aware that some people think this is an implementation detail but we are not sure and would like to ask your opinion on whether this should be explicitly stated in the RFC as acceptable behaviour. We have discussed converting from managing host objects on a per-client basis to have one shared external hosts namespace, but coordinating this when 50+ registrars have registered the same name server with us seems not feasible to either us or the registrars. Please feel free to contact me privately or on the list if you have any questions or concerns. Best regards, Asbjorn Mikkelsen CTO GNR Ltd