[ALAC] Analysis of WHOIS AoC RT Recommendations.

Salanieta T. Tamanikaiwaimaro salanieta.tamanikaiwaimaro at gmail.com
Tue Sep 4 18:34:27 UTC 2012


Dear Alan, and fellow ALAC,

I find that the fact that the controversy within the GNSO where they
questioned your standing as improper. Since this is the second incident at
least that I have become aware of, I would suggest that the ALAC Chair has
a chat with the GNSO Chair to raise our concerns. My view is that ALAC
liaisons represent the ALAC and act as a bridge and to insult Alan is to
insult us all. This can be done diplomatically of course. As promised, I
found the time, lost a few hours but all for a good cause...[?] Well I am
off to breakfast...got something else due today.

After reading the Whois Report (92 pages) [referred to as "*Report*" in my
comments] and your assessment of which recommendations do not require any
prior Policy development. These are my comments in response to your call
for feedback.

*Recommendation1: To make Whois a Strategic Priority*
The commissioning of the Review by ICANN is an indication of the strategic
importance and manner in which the Review Team was constituted. However,
ICANN needs to  monitor and evaluate the implementation process. As far as
the GNSO is concerned they have following advice from the GAC undertaken to
do four studies namely the Whois Misuse Study; Whois Proxy and Privacy
Abuse; Whois Registrant Identification and Whois Proxy & Privacy Relay and
Reveal Study which the Report says is due for completion in 2012. I am not
sure what the status of the Studies are but I can only hypothesize that to
the extent that this would affect existing consensus Policies, then parts
of the PDP may apply. However, if the existing consensus policies address
in principle areas that may require a PDP process then we should be open to
that. I understand that this may be a negligible caveat.

*Recommendation 2 Single Whois Policy*
I agree with your assessment. The Report mentions that there is a current
gTLD Policy as set out in the gTLD Registry and Registrar contracts and
GNSP Consensus Policies and Procedures. So there is no need for the PDP to
be initiated.

*Recommendation 3 Outreach*
*
*
I agree with your assessment that there is no need for a gNSO Policy
development. Whilst* *there may not be need for a gNSO Policy for Outreach
the Report does identify the need to move beyond the confines of the ICANN
community to involve them. Although I read the report, I did not read the
Appendix and note that in terms of studies done on consumers from 8-10
countries, it was unclear from the report which countries were selected and
it would have been good to have it footnoted like the rest of the other
stuff. Consumer groups like Consumer International etc. I found it
interesting given the wake of the Ottawa Principles by the OECD countries
on taxation that they did not make submissions given that they have a stake
in it as well.  It is possible that they made submissions and I missed it.

*Recommendation 4 Compliance*

I agree with your assessment that there is no need for a GNSO Policy to be
initiated. My view is that there only needs to be self regulatory measures
put in place by Registrars and I commend the CINC for reporting 97%
accuracy levels. My view is that there needs to be gold stars [?][?] handed
out by ICANN to Registrars and Resellers who comply. This can be published
and verified independently on the ICANN website.There can also be
incentives such as if you don't meet acceptable compliance levels and don't
have clear plans that meet ICANN's satisfaction, please don't bother
applying for a gTLD. I would also hasten to endorse the findings within the
Report to review and improve all relevant compliance tools and create new
ones where necessary before the gTLDs are assigned and become operational.
Who knows maybe this lag time of waiting can be put to good use.

*Recommendation 5 Data Accuracy [Communicate Need]*
The outcomes of the Studies currently being undertaken by the GNSO coupled
with the NORC Study will definitely form the empirical basis necessary for
further policy development in this area both by the GNSO and also by ICANN.
Data Accuracy is critical in order to navigate through the Internet with
ease. To a large extent, this is self regulatory and with countries all
around the world creating Strategies to secure their Cyber Environment, it
is only a matter of time before it is legislated. To avoid external
regulations forcing data accuracy it is much more easier and productive to
ensure that there is data accuracy. It is of great concern that the NORC
Report shows a 23% no failure rate and 20% full failure and I wonder about
the 57%. I think Data Accuracy is all our responsibility and not just
Registrars but a collective corporate responsibility issue. I agree with
the suggestion by the Business Community (see page 85 of the Report) that
the RAA should be amended to make it mandatory for contracted parties to
verify WHOIS information when registration occurs and when domain names are
renewed. I would add though that is and when there are planned transitions
where there are cut off dates for renewing and updating their information
that this can also be worded into the RAA to enable Registrars to have
sufficient room to issue notices of that nature. For this to work, it will
require a Policy and yes either from the GNSO or ICANN so that this can be
referred to in the contractual arrangements.

*Recommendation 6 Data Accuracy:*
I would say that there is a need for the GNSO to create a PDP to ensure
that there is Data Accuracy. To a large extent compliance in relation to
data accuracy has been self regulatory and dependent on the Registrars.
Were this to be taken away and (best case scenario: ICANN Compliance; worst
case scenario: legislated) it would mean transition to increasing accuracy,
voluntary or otherwise would be enforced. It follows that as per the
recommendation in report (see page 87 para 11], "ICANN should take
appropriate measures to reduce the number of WHOIS registrations that fall
into the accuracy groups Substantial Failure and Full Failure (as defined
by the NORC Data Accuracy Study, 2009/10) by 50% within 12 months and by
50% again over the following 12 months", it is far more beneficial and
useful to manage this process internally.

*Recommendation 7 Measure and Report Whois Accuracy*
My comments remain the same as for Recommendation 6

*Recommendation 8 Ensure that Compliance has tools to enforce Whois*

There was a comment made by the Commercial Stakeholders Group in Singapore
where they raised and in my view correctly the fact that private
regulations are based on the ability to self regulate and enforce
contractual obligations. There has been much debate and discussion in
relation to strengthening the Compliance Team and giving them tools. My
personal view is that all you need is a MS Excel spreadsheet, a phone, a
clear tangible strategy for various regions in the world and they have more
than enough tools necessary to get the job done. In simple speak, if they
can't enforce compliance change the team. It is not an extraordinarily
complex thing to enforce contracts. I am also not sure whether you need a
policy for this. Do we need a policy to show us how to clean our
kitchen? Incremental sanctions that are mentioned in page 68 of the Report
are relevant. [Please excuse the sarcasm, it's the lack of sleep talking]
Yes whilst I agree that the stick approach which is de-registration and
de-accreditation, I personally feel that even without these additional
revisions and provisions expressly woven into the contract by virtue of
ICANN issuing a Notice to all Registrars to update their records is the
equivalent of a legal notice as "someone" who is assigning names and
numbers.

*Recommendation 9 Data Accuracy: Track Impact of Whois Data Reminder Policy
and Possible Replacement*

The Report clearly outlines the fact that the Whois Data Reminder Policy so
without a doubt there is need to review and revise the Policy. I would say,
yes GNSO much initiate discussions. To save time there may be things within
the Reminder Policy that do not need to be debated again although there is
always the exception. There are many models of doing things and Registrars
can select what works for them and it would help to at least outline a few
generic ones. At the moment, I can deduce that the focus has been based on
the actual "data" and if one methodology does'nt work, there should be
enough innovation to suggest alternative methods that can be either
customer centric or otherwise.

*Recommendation 10 Data Access, Privacy and Proxy Services*
*
*
There is much discussion and debate around the area and I would that a
Draft Policy should be created by the GNSO modelled around the findings
Council of European National TLD Registries as a starting point for policy
discussion.

*Recommendation 11 Internic*
I think that this should be factored into the Strategy for Transition. I am
not sure whose responsibility this is whether this is ICANN's or the GNSO
or the entire community.

*Recommendations 12-14 IDNs*
*
*
It would be good to get some feedback on current work being done within the
IETF on whether the Whois Protocol has been revised or modified. I have
noted the comments that the Whois Protocol has no support for non-ASCII
characters (see page 91) and also note the Review Team's comments that the
failure to maintain registration data is not attributed to the failure of
IDNs but just management of registration data.

*Recommendation 15 Detailed and Comprehensive Plan*

I gather that ICANN has yet to produce this Detailed and Comprehensive
Plan. I do not think that PDP is needed. However, I could be wrong. I would
suggest that in the event that ICANN has yet to draft one, why don't we
initiate drafting this plan and handing it to the community. Should'nt take
more than a week to produce a first draft. All the materials and resources
needed are available already.

*Recommendation 16 Annual Report*
The recommendation within the report is too ambigious and perhaps it was
meant to be that way so that it is broad and you can include anything you
like. The downside is that if you don't spell out what you want precisely,
you can also get nothing. So there's a question of balance.

On Mon, Sep 3, 2012 at 1:24 PM, Alan Greenberg <alan.greenberg at mcgill.ca>wrote:

> You will recall that at its last meeting, the ALAC unanimously approved a
> statement to the Board reiterating its position that all 16 recommendations
> be implemented, and stressed that several were very important and clearly
> did not require any prior GNSO policy development. That ALAC statement can
> be found at http://tinyurl.com/ALAC-WHOIS-**Advice<http://tinyurl.com/ALAC-WHOIS-Advice>
> .
>
> Based on further discussions, and in light of a controversy that has
> arisen in the GNSO, it was suggested that the ALAC explicitly identify
> which recommendations do not require any prior policy development, and
> which might required GNSO policy development.
>
> I had already done a brief review looking at which recommendations might
> require policy development. I have since revised this and present it to you
> here.
>
> In summary, of the 16 recommendations, 12 do not require GNSO policy
> development, 3 *might* require policy development, but that would depend on
> work carried out over the coming months and years, and 1 does require
> policy development by the GNSO along with the rest of the community, but in
> my opinion, does not require a formal PDP.
>
> The detailed analysis is attached. The report with the recommendations in
> detail can be found at http://www.icann.org/en/about/**
> aoc-review/whois/final-report-**11may12-en.pdf<http://www.icann.org/en/about/aoc-review/whois/final-report-11may12-en.pdf>
> .
>
> It is essential that this analysis reach the Board before the Board
> Workshop scheduled for September 12-13.
>
> I am not sure if Olivier wants to hold a formal vote on this, or for the
> ALAC to just reach consensus, but regardless, the first step if for anyone
> who does not agree with this analysis to speak up.
>
> Alan
>
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
>
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)
>



-- 
Salanieta Tamanikaiwaimaro aka Sala
P.O. Box 17862
Suva
Fiji

Twitter: @SalanietaT
Skype:Salanieta.Tamanikaiwaimaro
Fiji Cell: +679 998 2851


More information about the ALAC mailing list