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

["Gould, James" <[e-mail]>]

Gavin,

Thanks for the review.  Below is my review feedback.


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Apr 3, 2015, at 8:02 AM, Gavin Brown <[e-mail]<mailto:[e-mail]>> wrote:

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.


This extension was specifically created for the .name TLD, but the concept could be made for a more general purpose application.  To provide some background, .name is meant for personal registrations, where I could register jim.gould.name or I could register the email forwarding object [e-mail]<mailto:[e-mail]>, so trademark holders were not allowed to register their trademarks.  Support for second level domain names were added later.  To protect the trademarks, a defensive registration object could be used to block a specific set of domain names and matching email forwarding objects.  This is pretty much a mechanism to create a new set of reserved names but as provisioning objects by trademark holders.  There are two forms of defensive registrations, standard defensive registration like “acme.computer" that would block the registration of either the domain “acme.computer.name" or the email forwarding object "[e-mail]<mailto:[e-mail]>" and premium defensive registration like “acme” that would block the domain names “*.acme.name”, "acme.*.name”, “acme.name” (once second level was supported), and the matching set of e-mail forwarding objects "*@acme.name”name”, “acme@*.name”.

I hope this helps with your understanding.

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.


Defensive Registration objects may have domain labels associated with them (2 labels for standard defensive registration and 1 label for premium defensive registration), but that is just about the only similarity that exists with domain names.  Defensive Registration objects are first class provisioning objects with a different purpose and life cycle from domain names, since they block the registration of both domain names and email forwarding objects.


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.


The <defReg:name> element is not the same thing as the <domain:name> element of RFC 5731.  Yes, there are domain labels, but there is no TLD used with <defReg:name> since there are multiple forms of defensive registrations (standard and premium).  I hope my feedback to #1 helps with #3 as well.

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.


I made note of the lack of the reference to the idnLang extension, which is defined at http://www.verisigninc.com/assets/epp-sdk/verisign_epp-extension_idn-lang_v00.html for clarification.


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.


Same response to the concern over the legal disclaimer.

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.


The Defensive Registration mapping was defined off of the language in the EPP drafts 04/07, which I assume did not include the Security Considerations section included in the RFC’s today.  I will make note of the need to update the draft to include this section.

G.

On 23/03/2015 17:39, Hollenbeck, Scott wrote:
Submitted for DE evaluation.

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[e-mail]]
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., [e-mail]

TLDs: .name

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—


JG





James Gould
Distinguished Engineer
[e-mail]

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
[e-mail]
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.

_______________________________________________
EppExt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext