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

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 2 Apr 2015 15:36:07 +0000

Hi,

I've finished my review of the extension registration request, and my (nit-picking) comments are as follows:

- The previous comment about the "VERISIGN PROPRIETORY INFORMATION" does apply to the document as well.

 - section 3.1.1 mentions "fully qualified names of the Defensive Registration objects", but then lists the name of the objects in 
the example as "doe" and "john.doe". Understanding this is for the ".name" TLD, those objects don't seem to be "fully qualified", as 
they are missing the TLD (assuming these are objects related to domain names..). I do understand that Section 2.1 defines the format 
of the Defensive registrations, but the relation to "fully qualified" remains unclear..

- For the IDN case, the document could clarify the format of the Defensive registration "name" element. It's pretty obvious from the example
what's intended, but not specified in text. 

- I didn't formally check the XML Schema definition.

tia,
Alex

> -----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., [email-masked]
> 
> TLDs: .name
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----

---

From: "Gould, James" <[email-masked]>
Date: Thu, 2 Apr 2015 15:52:09 +0000

Alex,

Thanks again for the detailed review and feedback.  My feedback is included below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Apr 2, 2015, at 11:36 AM, Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Same response on the copyright notice.

Fully qualified for a defensive registration object means inclusion of all of the labels for the defensive registration object, so that would be one label (e.g. “doe”) for a premium defensive registration and two labels (e.g. john.doe”) for a standard defensive registration.  The TLD is not included with the definition of “fully qualified” for defensive registration objects.  This detail could have been more clearly defined within the draft.

To clarify the defensive registration name is the A-label, which as you point out could have been explicitly defined in the text.

tia,
Alex

-----BEGIN FORM-----
Name of Extension:

Document Status:
Informational

Reference:

TLDs: .name

IPR Disclosure: None

Status: Active

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

_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Gavin Brown <[email-masked]>
Date: Fri, 03 Apr 2015 13:02:23 +0100

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:[email-masked]] 
> 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:
> 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.
> [email-masked]

-- 
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: "Gould, James" <[email-masked]>
Date: Fri, 3 Apr 2015 16:15:10 +0000

Gavin,

Thanks for the review.  Below is my review feedback.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

Here is my review as DE:

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 [email-masked]<mailto:[email-masked]>, 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 "[email-masked]<mailto:[email-masked]>" 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 "[email-masked]”, “acme@*.name”.

I hope this helps with your understanding.

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.

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.

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.

Same response to the concern over the legal disclaimer.

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.

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[email-masked]]
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:

Document Status:
Informational

Reference:

TLDs: .name

IPR Disclosure: None

Status: Active

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

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com

image/png 4KiB

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 6 Apr 2015 21:27:25 +0000

I have sent a note to IANA indicating DE approval for this request.

Scott

> From: EppExt [mailto:[email-masked]] On Behalf Of Hollenbeck,
> Scott
> Sent: Monday, March 23, 2015 1:40 PM
> To: [email-masked]
> Subject: [eppext] FW: [IANA #814915] INSERT “Extensible Provisioning
> Protocol Mapping: Defensive Registration"
> 
> “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.”
>