<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [nc-whois] suggestions
I believe that Thomas' post does an excellent job of identifying the
priorities for this group at this point. A spreadsheet such as he
describes, giving the statistical answers by respondent category as well as
totals, would provide a good basis for an interim report.
I also agree with the priorities he suggests as far as free-text answers.
As I read his post, the following questions should take priority in this
regard: 8.1, 10, 17 and 20. The following reviews the proposals on the
table and suggests baskets to be used for three of these four questions.
(It seems that only Tony has begun to tackle question 20.)
With regard to 8.1, there is very little overlap between the baskets
proposed by Laurence and those proposed by Tony (Oscar's remarks do not seem
to address this question). We can combine them as follows (eliminating
Laurence's #4 which goes to the accuracy question addressed elsewhere and
does not propose a new data element):
1. Additional contact information on domain name registrants
Includes: Phone number, fax number, e-mail address, some combination of
those elements, or all of those elements)
2. Contact information for an abuse contact (e.g., telephone, fax,
and/or e-mail address) for reporting unlawful activity.
3. IP ranges
4. Reverse domain look-up capability
5. Information on when last active contact with registrar took place
6. Identity of true owner, aside from individual contact listed
7. Details of owners prior to current domain name owner
8. "For sale" availability of domain name
Eight is more baskets than optimal, but I believe we could work with it. If
necessary we could exclude items 3 and 4 because I believe they propose an
additional functionality for Whois rather than an additional data
element(s).
With regard to question 10, fortunately there is a good deal of overlap
among what Laurence, Tony, and Oscar have observed, and I believe we could
boil it down to the following baskets:
1. By the registrar or registry
2. By registrants
3. By searchers
4. Donations
5. By government support
6. By ICANN
(I collapsed Laurence's category 2 and 3 because they both seem to point to
the searcher paying, whether on a search-by-search basis or on the basis of
a monthly or annual subscription fee. If this proves to be a popular answer
we may need to segregate these two options out. If not, not.)
With regard to question 17, all of Tony's categories are found in Laurence's
list. Oscar did not address this question. So I propose that Laurence's
list be used as follows:
1. No bulk access or sale of data for any purpose
Includes: prohibit all sale of data; no bulk access except for law
enforcement, tracking criminals, etc.; no sale of data for profit (OK to
subsidize registration fee); allow funnel-in marketing instead
2. No bulk access for marketing purposes
Includes: no sale of contact data for spam, commercial purposes,
etc.
3. Require opt-in (includes: express permission) before any sale or
bulk access to data
Includes: opt-in needed for any profitable use; for any use for
non-technical reasons; blanket opt-in requirement for non-commercial
registrants
4. Require opt-in (includes: express permission) before sale or bulk
access for marketing purposes
5. Improve opt-out
Includes: opt-out for data already made available under existing
policy; opt-out for commercial registrants
6. "Better privacy protection" (unspecified)
Includes: more strict, more restricted, comply with EU law
7. Relax existing restrictions
Includes: no restrictions; restore 1999 RAA rules (no restrictions
on tel/fax marketing uses); allow any lawful use unless threatening to
operational integrity or inflicting damage marketplace can't cure
If we can agree upon baskets on Monday's call it may be possible to provide
some kind of breakdown for questions 8.1, 10 and 17 in time for inclusion in
an interim report. Otherwise, that report might attach only the
spreadsheets described in Thomas' post and the analysis of free-text answers
would be delivered later. Our further report would also take into account
any "gems" that are discovered in reading answers in the "other" category
for various questions.
Marilyn and Tony, I suggest that we allocate 15 minutes on Monday's agenda
for discussion of this proposal. Thank you.
Steve Metalitz
-----Original Message-----
From: Thomas Roessler [mailto:roessler@does-not-exist.org]
Sent: Thursday, February 07, 2002 11:30 AM
To: nc-whois@dnso.org
Subject: [nc-whois] suggestions
May I suggest that one of you who has access to staff or executive
assistants (or whatever) could give them the task to take the
results we received last week from Marie Juliano, and prepare one
Excel sheet per multiple choice question, with the sheet having as
column labels the possible answers to the question, as row label the
category of the respondent, and as entry in the cells the number of
responses?
That way, we should be able to easily produce some nice pie charts
for Ghana, with one chart by category of respondent, and one chart
totalling them (i.e., the column sums).
Also, it would be rather easy to discern, from that set of data,
where we have some strong common trends, and where categories of
respondents disagree.
The questions which could reasonably be covered and evaluated that
way are 2, 3, 4, 6, 8, 10 (the yes-no parts), 11, 12, 13, 14, 16,
17, 18, 19.
I do believe that we could produce a preliminary report on these
questions until Accra, when we really start off with the pie charts,
ask (and discuss!) what conclusions can be drawn from these, and
then go on hunting for gems among the "others" (which is faster than
actually classifying them, because you can hunt for gems by more
sloppy reading of answers).
We could then base the decision whether or not we investigate the
"other" answers in detail on the the set of 300 we have all looked
through: If some of us believe that there is information hidden in
these answers which can't be derived from the statistical answers to
the questions mentioned above, or if there are new answers showing
up which are as frequent as choices given on the questionnaire, then
we may have to look at them in a more complete manner - either by
attacking the statistical 300 more systematically, or by attacking
the entire set of answers received. However, we should really make a
cost-benefit decision in that case. ;-)
Questions 15 and the cost part of question 10 are special, since
they should probably have offered the same kind of choices:
- registrants
- users of search service
- other (actually, this answer doesn't really make sense except if
you believe in tax payers or charities bearing the cost of such
services).
(Registrars (or rather: registrars' shareholders), for instance, are
not going to pay for anything. They want to get money back from
their investment, so that particular answer actually means
"registrants".)
Fortunately, question 15 allows for an easy mapping (with 4%
answering "other", which can safely be moved to the "other" category
above without further inspection). Unfortunately, the cost part of
question 10 is free-form, and indeed one of the questions where we
need to assign each answer to one of the above classes.
Question 8.2 is also a multiple-choice question gone wrong, where
the baskets we can use are obviously any combination of points A-I
in q8.
Depending on how people work it may be reasonable to defer this
stuff until after Ghana. However, this should certainly be in the
final report.
8.1 is a question where we need to find out about baskets by reading
answers.
Question 12 (the "why or why not" part) is probably a place where
it's really sufficient to look for gems - I don't believe that we'd
really win anything for our purposes by doing a statistical analysis
of the reasons given.
The "best way" part of questions 13 and 14 is similar. You don't
solve engineering problems by doing public polls.
Question 17 is another case where an approach with putting responses
into baskets and trying to do statistical analysis on this is
probably the only way to get some added value.
Same, of course, with question 20.
--
Thomas Roessler http://log.does-not-exist.org/
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|