Re: [eppext] FW: [IANA #814915] INSERT “Extensible Provisioning Protocol Mapping: Defensive Registration"

Gavin Brown <gavin.brown@centralnic.com> Fri, 03 April 2015 12:02 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 B5CF61A8AEC for <eppext@ietfa.amsl.com>; Fri, 3 Apr 2015 05:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.727
X-Spam-Level:
X-Spam-Status: No, score=-0.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzN2jjoE_Ntv for <eppext@ietfa.amsl.com>; Fri, 3 Apr 2015 05:02:26 -0700 (PDT)
Received: from smtp.centralnic.com (mail-7.fnb.uk.centralnic.net [5.44.25.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844921A8A6D for <eppext@ietf.org>; Fri, 3 Apr 2015 05:02:26 -0700 (PDT)
Received: from Gavins-MacBook-Pro.local (host81-133-130-171.in-addr.btopenworld.com [81.133.130.171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id BF7739E83; Fri, 3 Apr 2015 12:02:24 +0000 (UTC)
Message-ID: <551E814F.8040700@centralnic.com>
Date: Fri, 03 Apr 2015 13:02:23 +0100
From: Gavin Brown <gavin.brown@centralnic.com>
Organization: CentralNic Ltd
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
References: <RT-Ticket-814915@icann.org> <7F30D89F-28F5-47C1-B9B8-C6B2D032F45C@verisign.com> <rt-4.2.9-13014-1427128946-1178.814915-9-0@icann.org> <831693C2CDA2E849A7D7A712B24E257F49F89AE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F89AE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
OpenPGP: id=BB55B2CA91510745E798BCF4E87E3920F923B4CE
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b6XoroPKN8CFs6IBlX30R8lsHH5T428fd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/hvMmItzafnp3IdajaZUfYDhRt_A>
Subject: Re: [eppext] =?utf-8?b?Rlc6IFtJQU5BICM4MTQ5MTVdIElOU0VSVCDigJxFeHRl?= =?utf-8?q?nsible_Provisioning_Protocol_Mapping=3A_Defensive_Registration?= =?utf-8?q?=22?=
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: <http://www.ietf.org/mail-archive/web/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: Fri, 03 Apr 2015 12:02:28 -0000

Here is my review as DE:

1. This extension seems to define functionality specific to the .name
TLD. Familiarity with the particulars of that TLD's business model seems
to be assumed, but for interoperability purposes, an explanation of the
context that this extension was designed for would be useful.

2. The specification appears to create a new "domain-like" object
mapping. I wonder whether any consideration was made of extending RFC
5731 domain objects instead, and what the basis of the decision was.

3. It's not clear whether <defReg:name> values exist in the same
namespace as RFC 5731 domains. Could a server contain a defReg object
whose <defReg:name> is the same as the <domain:name> property of an
RFC5731 domain? This goes back to my comment in #1 above about the lack
of context.

3. Section 3.2.1 describes how the extension can be used in conjunction
with the "idnLang" extension; however, this extension is not listed in
the references.

4. As others have, I'd also like to voice my concerns about the IP terms
in the Legal Disclaimer. The purpose of registering an EPP exension in
the registry is to facilitate harmonisation and interoperability, and
yet the Legal Disclaimer seems designed to discourage that.

5. The specification seems to meet some of the requirements in RFC 7451
Section 2.1.1, in that, in that it meets the guidelines in RFC 3735.
However, there is no comentary on Security or Privacy considerations.
Since the defReg object mapping is very similar to RFC 5731, I would
expect to see some discussion of authorisation and controls on
disclosure of authInfo codes.

G.

On 23/03/2015 17:39, Hollenbeck, Scott wrote:
> Submitted for DE evaluation.
> 
> Scott
> 
> -----Original Message-----
> From: Amanda Baber via RT [mailto:iana-prot-param-comment@iana.org] 
> Sent: Monday, March 23, 2015 12:42 PM
> Cc: Hollenbeck, Scott
> Subject: [IANA #814915] INSERT “Extensible Provisioning Protocol Mapping: Defensive Registration"
> 
> #8 of 18.
> 
> -----BEGIN FORM-----
> Name of Extension:
> “Extensible Provisioning Protocol Mapping: Defensive Registration"
> 
> Document Status: 
> Informational
> 
> Reference: 
> http://www.verisigninc.com/assets/defensive-registration-mapping.pdf
> 
> Registrant Name and Email Address:
> VeriSign Inc., epp-registry@verisign.com
> 
> TLDs: .name
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----
> 
> —
> 
> 
> JG
> 
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgould@Verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com
> 
> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
> 
> Download BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
> 
> image/png 4KiB
> Image not shown because display is disabled in system configuration.
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext
> 

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