Hi Horacio,

On Apr 11, 2014, at 4:30 PM, Horacio T. Cadiz <[log in to unmask]> wrote:

> On April 9, 2014 11:01:19 PM Amr Elsadr <[log in to unmask]> wrote:
> 
>> Thanks McTim,
>> 
>> Substantively, I agree with you and I sympathise with the registries
>> that have .brand applications. On the other hand, I am concerned with >gTLD policy being developed by the ICANN board purely from a
>> process perspective. I would argue on that point out of principle. The
>> idea of the ICANN board developing policy is not one that I relish.
> 
> IIRC, the application guidebook provides the applicants
> an avenue for requesting for exemptions from some of the
> specifications.  Specification 13 looks like an embodiment
> of an exemption sought by a specific group. So this isn't really
> developing a new policy.

Hmm…, I guess the GNSO Council will need to look into that a little more carefully before sending a response to the ICANN board, but thanks Horacio. Your note prompted me to go back and look at the RA again, and I found this as a clause in Specification 9 (Registry Operator Code of Conduct)…, and I’m just thinking out loud here:

“6. Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for its own exclusive use, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest.”

This exemption is not, per se, an exemption from clauses in the agreement, but exemptions to the rest of the code of conduct as specified in Specification 9, which includes:

“1. In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a “Registry Related Party”), to:

a. directly or indirectly show any preference or provide any special consideration to any registrar with respect to operational access to registry systems and related registry services, unless comparable opportunities to qualify for such preferences or considerations are made available to all registrars on substantially similar terms and subject to substantially similar conditions; …,” 

My question now is, if the ICANN board is not in fact developing new policy because the Registry Agreement does allow for some exemptions to be considered, why would an additional specification 13 even be necessary? If .Brand registries could get what they need to operate with a limited number of registrars, this should probably be done without a new specification being added that doesn't go through the appropriate GNSO policy process.

> Like McTim I find it very strange why .Brands would need to
> use registrars at all.

Maybe this model just wasn’t as exhaustively considered at the time the RA was being developed? Maybe it’s got something to do with fee collection by ICANN? I really can’t tell. Someone who was around back then may have more informed answers.

> Another is why they would need to escrow their
> data.  After all, a closed brand's registrants are all units of the
> brand. If the registry fails, it is the brand which suffers, not an innocent
> 3rd party which needs protection from ICANN

:) Another good point. It might be worthwhile to consider if data escrow in this case should be voluntary instead of contractually required?

In any case, wether or not registrars are needed, and data escrow requirements are not being addressed by this specification. From what I can tell…, those two would certainly require the development of new gTLD policies.

Thanks again.

Amr

> 
> 
> 
> 
> Sent with AquaMail for Android
> http://www.aqua-mail.com