Re: Fwd: New Version Notification for draft-tan-epp-launchphase-01.txt

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.

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg