Subject: Re: [provreg] Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

From: "Gould, James" <[email-masked]>
Date: Thu, 10 Nov 2011 20:32:47 +0000

Wil,

Below is some feedback to the draft:

  1.  Hopefully the trademark clearinghouse interface can be better understood to help drive the elements needed by the launchphase extension, since things could greatly change once that interface is defined.  Hopefully an EPP interface can be defined for the trademark clearinghouse that goes hand in hand with the launchphase extension.
  2.  Please add the XML schema to the Formal Syntax section
  3.  Why is the status optional in <lp:infData>?  Shouldn't an application always have a status?
  4.  The text says that <lp:claim> is "(optional) one or more <lp:claim> elements" where optional kind of conflicts with one or more.  I would state "zero or more <lp:claim> elements" instead.
  5.  Are all of the <lp:claim> elements required?
  6.  Shouldn't the <lp:claimRegDate> be of type dateTime instead of date?
  7.  Shouldn't the <lp:claimExDate> be of type dateTime instead of date?
  8.  Wouldn't it be better to shorten the <lp:claim> element names by not including the "claim" prefix (e.g. <lp:issuer> instead of <lp:claimIssuer>)?
  9.  It would be good if there is guidance or a description of the possible values of the <lp:phase> optional element.
  10. Isn't it assuming a certain trademark clearinghouse interface with the name <lp:pvcs>?  What if the elements are signed by the clearinghouse and the clearinghouse generates a verifiable token?
  11. Would the <lp:claimIssuer> really be a contact identifier defined in RFC 5733 or would it simply be a issuer identifier / handle?  I'm not sure how many issuers there will be and how they would be referenced.
  12. The info response sample needs to change the duplicate <lp:claimCountry> element to a <lp:region> element.

I'll provide more feedback as I work through the draft.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

VerisignInc.com

From: Wil Tan <[email-masked]<mailto:[email-masked]>>
Date: Tue, 18 Oct 2011 01:36:11 +1100
To: <[email-masked]<mailto:[email-masked]>>
Subject: [provreg] Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

Dear colleagues,

Gavin and I have published a new version of the draft: http://tools.ietf.org/html/draft-tan-epp-launchphase-01

This is mostly Gavin's work, with the following changes:

- element names are now in camelCase
- renamed <trademark> to <claim>
- a "preValidated" attribute of <claim> element
- there can be one or more <claim> elements

As usual, we'd love to hear any feedback that you may have.

--
.wil
Cloud Registry <http://www.cloudregistry.net>

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Fri, Oct 14, 2011 at 3:16 AM
Subject: New Version Notification for draft-tan-epp-launchphase-01.txt
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

A new version of I-D, draft-tan-epp-launchphase-01.txt has been successfully submitted by Wil Tan and posted to the IETF repository.

Filename:        draft-tan-epp-launchphase
Revision:        01
Title:           Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)
Creation date:   2011-10-14
WG ID:           Individual Submission
Number of pages: 19

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for the provisioning and management of domain names
  during the launch phase of a domain name registry.

The IETF Secretariat
_______________________________________________ provreg mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/provreg

---

From: Gavin Brown <[email-masked]>
Date: Thu, 17 Nov 2011 10:20:22 +0100

Hi James,
> Hopefully the trademark clearinghouse interface can be better understood to help drive the elements needed by the launchphase extension, since things could greatly change once that interface is defined.  Hopefully an EPP interface can be defined for the trademark clearinghouse that goes hand in hand with the launchphase extension.  
The data elements in our draft are derived from our experience of working with CHIP (ipclearinghouse.org) as both a registry and as a registrar. My guess is that any entity that operates a trademark clearing house for the new gTLD round will require most of the data elements as CHIP do. We've been reaching out to potential clearing house operators (as well as organisations like WIPO and the UK's Intellectual Property Office) for their feedback on this, and would appreciate further input.
> Please add the XML schema to the Formal Syntax section
We removed it from this draft because we wanted to get the description of the data model out there for discussion and revision before encoding it into a schema. The next draft will have the schema included.
> Why is the status optional in <lp:infData>?  Shouldn't an application always have a status?
Yes, it should. We'll correct that.
> The text says that <lp:claim> is "(optional) one or more <lp:claim> elements" where optional kind of conflicts with one or more.  I would state "zero or more <lp:claim> elements" instead.  
Thanks, we'll fix that.
> Are all of the <lp:claim> elements required?  
Most of them should be optional in the standard as different servers (and phases) will have different requirements (eg registered trademarks versus company names).
> Shouldn't the <lp:claimRegDate> be of type dateTime instead of date?  
> Shouldn't the <lp:claimExDate> be of type dateTime instead of date?
I think that using a dateTime is excessive precision, unless there is a presumption to use dateTimes where possible in EPP.
> Wouldn't it be better to shorten the <lp:claim> element names by not including the "claim" prefix (e.g. <lp:issuer> instead of <lp:claimIssuer>)?
That makes sense.
> It would be good if there is guidance or a description of the possible values of the <lp:phase> optional element.  
This would be useful.
> Isn't it assuming a certain trademark clearinghouse interface with the name <lp:pvcs>?  What if the elements are signed by the clearinghouse and the clearinghouse generates a verifiable token?  
Perhaps a more flexible solution would be something like the way domain authorisation works, which supports a <domain:pw> as well as as <domain:ext> which can contain anything.
> Would the <lp:claimIssuer> really be a contact identifier defined in RFC 5733 or would it simply be a issuer identifier / handle?  I'm not sure how many issuers there will be and how they would be referenced.
We've previously envisioned scenarios where the issuer may not be known to the server at the time of request. For a real world example, during the sunrise we ran for .com.de domains, we allowed registrations based on company names. In Germany, there is no central registry of German companies: each company is registered with its local court, so there are potentially thousands of issuers, too many for the server to know about in advance.

Perhaps a better approach would be to allow an arbitrary identifier in this element, but provide a suggestion that a good solution to the above scenario is to use contact IDs.
> The info response sample needs to change the duplicate <lp:claimCountry> element to a <lp:region> 
Thanks, we'll fix that.

Gavin.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.