[Tmch-iag] Comments on P3, P5, T1 and T3

Chris Wright chris at ausregistry.com.au
Wed Dec 14 05:02:01 UTC 2011


All,

Please find below our feedback on the identified issues for this week's call, I have attempted to keep these short this time and am ready to elaborate further during discussions.

Issue P3

We believe that the Trademark Clearing house is the only entity that can send the notices to trademark holders for a number of reasons:


·         They are the only entity that the Trademark holder is guaranteed to have interacted with (thus should be expecting notices from)

·         This means that, at least for this purpose, the contact details need only be with the TMCH, which is the authoritative source

·         It means that trademark holders need to only ensure details are correct in one place

·         It means that no complicated data distribution systems need to be constructed, and issue such as frequency of update or so forth need not be considered

·         It just makes sense

·         The Registry or Registrar would need to send the domain and all its variants if variant matching was required (otherwise the registry/registrar would need to determine a match then send the 'matching' entries back to the clearing house)

Issue P5

This issue is a little more complicated as it depends on the rules around IDNs. We believe that this check should take place somewhere in the land of the Registry or Registrar, there are pros and cons to each approach.


·         Registrar

o   Pros

§  Point of contact with Registrant

§  Simplest implementation solution (Registrar don't need to deal with the potentially different EPP extensions created by each Registry)

o   Cons

§  Registry doesn't know whether Registrar actually 'did it' or not (not 100% convinced this is an issue)

§  If IDN matching required consideration of variants Registrar would need to be able to interpret language tables and generate them correctly (something a registry already does)

·         Registry (doing matching but informing Registrar, to inform Registrant)

o   Pros

§  Understanding of IDN rules (if IDN variant matching required)

o   Cons

§  Still need Registrar involvement anyway

§  EPP extensions (which each registry may do differently)

§  Slightly more complex

·         Registry (doing matching and also informing Registrant)

o   Pros

§  As above

o   Cons

§  As above (but no EPP extension required)

§  Additional Con of Registrant not necessarily knowing who the Registry is

Regardless of which solution, doing the actual matching needs to take into account effects of TMCH database downtime, and consider other options such as database replication or some other solution (of which there are many).

Also consideration needs to be given as to if this is meant to be 'real time' or an offline process (send an email), additionally perhaps we need to be flexible and allow all the models?

Issue T1

We would suggest that this is not as straight forward as this. We can offer a number of different solutions all of which require more discussion that possible in email. Ultimately the TMCH should be the authoritative source of the data, SOME of the data (probably just the 'name' entries for matching) will need to be 100% available and that means replicated to alternative sites (Registrars, Registries) and so forth. There are really three uses for data from the Registry/Registrar perspective:


·         Validation & Verification of information during sunrise processes
For this we would suggest that the data can be encoded in the actually 'auth token' given to the trademark holder, using an appropriate container such as base 64 encoded, XML document that is PGP (GPG) signed by the clearing house. Registrars/Registries can validate the information by validating the signature on the package. This is a very simple model that requires no data replication

·         Checking if a domain 'matches' an entry in the clearing house
This is really domain matching, and we already have a nice way of doing this using DNS. If the 'names' (mark names) that are entered into the clearinghouse are all made available by zone transfer in a DNS zone file, then Registrar and Registries can just do zone transfers of this 'zone'. Registrars that don't want to do the transfer can just do DNS lookups to the Registry (or even clearinghouse) run name servers. As this data is just a list of 'names' it shouldn't be sensitive

·         Displaying claims notices to potential registrants
For this the clearinghouse can have the 'notice' available at a predictable URL (http://tmch.com/claimes?name=<name<http://tmch.com/claimes?name=%3cname>>) for example, then Registrars or Registries can just 'frame up' the notice in their site and be done with it. It just needs to be accepted that if the URL above is not functioning (i.e. the clearing house is down) then registrations can proceed with just a generic notice that states "there has been a match etc etc" but doesn't have specific information about the match (this is expected to be a VERY small period of time when the clearinghouse is down) but still mean that no data has to be replicated

Finally we assume notices to trademark holders are sent by the TMCH thus no data is needed to be replicated for this.


Issue T3

I believe most of our opinion on this is covered in my answer to T1 above

Thanks

[cid:image002.png at 01CCBA79.B7772630]
Chris Wright
Chief Technology Officer
---------------------------------------------------------------------------------------
ARI REGISTRY SERVICES
Level 8, 10 Queens Road. Melbourne. Victoria. Australia. 3004.
P  +61 3 9866 3710  F  +61 3 9866 1970  M  +61 401 873 798
E  chris.wright at ariservices.com<mailto:chris.wright at ariservices.com>
ariservices.com<http://ariservices.com/>
---------------------------------------------------------------------------------------
ARI Registry Services is an evolution of AusRegistry International.
Follow us on Twitter<http://twitter.com/#!/ausregistryint>
---------------------------------------------------------------------------------------
The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tmch-iag/attachments/20111214/007d76a0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5589 bytes
Desc: image001.png
Url : http://mm.icann.org/pipermail/tmch-iag/attachments/20111214/007d76a0/image001-0001.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 3051 bytes
Desc: image002.png
Url : http://mm.icann.org/pipermail/tmch-iag/attachments/20111214/007d76a0/image002-0001.png 


More information about the tmch-iag mailing list