Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster

Gavin Brown <gavin.brown@centralnic.com> Thu, 17 September 2015 13:58 UTC

Return-Path: <gavin.brown@centralnic.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2E71B2FFE for <eppext@ietfa.amsl.com>; Thu, 17 Sep 2015 06:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.037
X-Spam-Level:
X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HynscWXL4i-L for <eppext@ietfa.amsl.com>; Thu, 17 Sep 2015 06:58:00 -0700 (PDT)
Received: from smtp.centralnic.com (mail-9.bfn.uk.centralnic.net [212.18.250.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18B41B2FCA for <eppext@ietf.org>; Thu, 17 Sep 2015 06:57:59 -0700 (PDT)
Received: from Gavins-MacBook-Pro.local (unknown [217.138.20.162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id D8FC2E0F87 for <eppext@ietf.org>; Thu, 17 Sep 2015 13:57:57 +0000 (UTC)
To: "eppext@ietf.org" <eppext@ietf.org>
From: Gavin Brown <gavin.brown@centralnic.com>
X-Enigmail-Draft-Status: N1110
Organization: CentralNic
Message-ID: <55FAC6E5.6090207@centralnic.com>
Date: Thu, 17 Sep 2015 14:57:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o6Lh6dOLxFxs2baL44uVPEgnEeiIHmCAi"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/ZZ6O6HKUad01kYc8xItQduSyOZ4>
Subject: Re: [eppext] EPP Extension Registration Requests from DK-Hostmaster
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Sep 2015 13:58:01 -0000

As a designated expert I have reviewed the registration requests and the
specifications submitted. I think they meet the criteria for
registration. Specifically, they meet the requirements of RFC 3735,
including the Security Considerations; and there are no privacy
consequences that I can determine.

However, I do have a couple of points that I'd like to suggest be
considered by the authors:

* Use an element naming convention that's consistent with the main EPP
standards. The extension mixes camelCased element names like
<domainAdvisory> with underscore_separated names like <domain_confirmed>.

* Consider using a single element under <extension> with the data
elements as its children - this would follow the convention used by
other extensions.

G.

On Wed, 9 Sep 2015 11:20:12 +0000, "Hollenbeck, Scott" <shollenbeck at
verisign.com> wrote:
>> -----Original Message-----
>> From: EppExt [mailto:eppext-bounces at ietf.org] On Behalf Of Hollenbeck,
>> Scott
>> Sent: Wednesday, September 09, 2015 7:02 AM
>> To: eppext at ietf.org
>> Subject: [eppext] EPP Extension Registration Requests from DK-
>> Hostmaster
>> 
>> Yesterday I received 10 requests from IANA to review EPP extensions
>> submitted by DK-Hostmaster. I'll forward each of them to this list
>> momentarily. I've reviewed all of them and I'm going to suggest that
>> they be considered as one request since each describes an element that
>> is part of the same schema and the same specification.
> 
> More detail:
> 
> The specification for each of the registration requests can be found here:
> 
> https://github.com/DK-Hostmaster/epp-service-specification
> 
> The current version of the schema can be found here:
> 
> https://github.com/DK-Hostmaster/epp-xsd-files/blob/master/dkhm-1.4.xsd
> 
> Each of the registration requests refers to an element that is defined in this schema:
> 
> <element name="userType" type="dkhm:userType" /> 
> <element name="EAN" type="dkhm:EAN" /> 
> <element name="CVR" type="dkhm:CVR" /> 
> <element name="pnumber" type="dkhm:pnumber" /> 
> <element name="contact" type="dkhm:contact" /> 
> <element name="trackingNo" type="dkhm:trackingNo" /> 
> <element name="domainAdvisory" type="dkhm:domainAdvisory" /> 
> <element name="orderconfirmationToken" type="dkhm:orderconfirmationToken" /> 
> <element name="domain_confirmed" type="dkhm:domain_confirmed" /> 
> <element name="contact_validated" type="dkhm:contact_validated" /> 
> <element name="registrant_validated" type="dkhm:registrant_validated" />
> 
> Each of these elements ultimately refers to an XML schema simpleType that includes a restriction for a base of type token. Based on my reading of the specification I believe the last three elements could be more efficiently represented as booleans, but what's there certainly works.
> 
> As I said in my first message in this thread I'd like to recommend to IANA that they process these requests as a single addition to the registry since each request describes an XML element that is part of the same schema and namespace. Could the other DEs please share your thoughts?
> 
> Scott

-- 
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.