ICANN/DNSO
DNSO Mailling lists archives

[nc-whois]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-whois] More detailed feedback from gTLD member on Whois report


Team:
Here is more detailed feedback from a member of the gTLD constituency.  This
is somewhat reflective of the general tone inside gTLD regarding our work
product -- appreciation and respect for what we've done, and suggestions and
guidance for where we may have under-reached or over-reached.

I have reproduced the comments verbatim, with no edits of my own.

As always, please write or call me for clarifications.

Best Regards,
Ram
--------------------------------------------------------
Ram Mohan
Vice President, Business Operations
Chief Technology Officer
Afilias.INFO
p: +1-215-706-5700; f: +1-215-706-5701
e: rmohan@afilias.info
--------------------------------------------------------

----- Original Message -----
Subject: [GTLD-RC] Whois TF Report


> Here are my comments regarding the Whois TF Report.
>
>
> General Comments
>
> Even when only considering the two specific recommendations made in the
> report, the report makes it clear that there is still too many areas that
> require further work, so it seems to me that it is premature to make the
> recommendations.
>
> The TF acknowledges that more work needs to be done on the issue of
privacy
> while at the same time making a recommendation regarding enforcement of
> accuracy requirements that is heavily dependent on solution of the privacy
> issue.  My point is this, the recommendation only deals with the surface
of
> the problem, not one of the root causes (lack of privacy of Whois data) so
> the recommendation does not really solve the problem and will simply
> motivate creative ways to beat the system until privacy of informaiton is
> provided.
>
> "Consensus" is used in the document but there is absolutely no objective
> evidence provided to demonstrate consensus, not within the TF itself, nor
> and moreimportantly in the broader community including seriously impacted
> stakeholders like registrars and individual users.
>
> Specific Comments
>
> I. Enforcement of existing contractual obligations:
>
> A.3 - Posting registrar contact points might be okay if the contact points
> are generic but posting specific names of contacts with there contact
> information sounds troublesome to me.  Who would want there name posted?
It
> could easily turn into an avenue for harassment.  Moreover, individuals
> assigned as contacts will change over time so a generic contact point is
> much more functional.
>
> B.2 - The 15-day requirement is too short.  The requirement to provide
> documentary proof sounds reasonable but may be very difficult to enforce
> because it likely would require manual processes that do not scale.  To
the
> extent that it can be automated, it might be okay.
>
> III. RAA Changes:
>
> B. Requiring the redeemed names not be put in the zone file has an impact
on
> registries.  If this requirement is implemented, it is critical that
> enforcement happen at the registrar level because registrars have the
> registrant relationship.  In the case of a thin registry, the registry
would
> have no way of enforcing this.  I suspect that thick registries wouldn't
> want to get involved in this either.
>
> II. Summary of Recommendations:
>
> A.1 - How would the requirement to eliminate the use of bulk Whois data
for
> marketing purposes be enforced?  It might be okay to have the requirement
as
> long as there is not too much expected of registrars and registries in
this
> regard because I think it is a tough one to enforce.
>
> 4. Impact Analysis:
>
> Registrants - "The Task Force . . has recommended monitoring of the impact
> of the 15-day period and its implementation."  There is too much
likelihood
> that the 15- day requirement is too short to risk implementing it and
simply
> monitoring it.  Too much damage could be done and it would take time to
> change the requirement later to a more reasonable time period.  In the
> meantime, registrants are harmed.  More investigation should be done in
this
> regard before finalizing a time period.  Monitoring a bad requirement to
> prove that it is bad is the wrong way to go.  The fact that one registrar
> imposed a 7-day deadline is a rediculous argument.
>
> 9. Risk / Cost Analysis:
>
> The TF recommends that the risk/cost analysis be undertaken during the
> implementation phase.  In my opinion, it is too late to do it then.  It
> should be done before recommendations are finalized.
>
> The term "purposely fraudulant data" is used.  How would one determine
> "purpose?"
>



<<< Chronological Index >>>    <<< Thread Index >>>