[IETF-Not43] Suggestions of changes to the requirements document
(Inglese, messaggio sulla lista del gruppo di lavoro Not-43 della IETF, 14 Gennaio 2003)
[Ietf-not43] Suggestions of changes to the requirements document
Vittorio Bertola vb@bertola.eu.orgTue, 14 Jan 2003 10:49:16 +0100
- Previous message: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-02.txt
- Next message: [Ietf-not43] Suggestions of changes to the requirements document
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello,
first of all, this is the first time I take part in an IETF working
group. Please pardon me for any inappropriate behaviour I might
unvoluntarily have.
I have discovered the existence of this group only in the last few
weeks, thanks to a post on ICANN's General Assembly list. Though being
an ICT engineer, I do not work for any DNS-related company, and in
this field I am more interested in the policy aspects related to
individual users of the Internet, than in the actual technical
details. This is why (speaking personally, and not for any of the orgs
I participate in) I really want to say a couple of things about the
draft requirements document, and in particular about a couple of
paragraphs that I find really worrying.
a) =A72.4.2
>Intellectual Property Holders have legal rights to the use of domain
>names based on copyright and trademark laws of various governments.
This statement is clearly incorrect. In fact, according to
international trademark law (but also to the UDRP), trademark owners
have a right not to see domain names equal or confusingly similar to
their trademarks used for improper competition or registered in bad
faith with the purpose of resale. However, they have no specific
"right to the use" of a domain name. Not all trademark owners on a
given alphanumeric string own the same string as a domain name - often
it is owned by the owner of a trademark on the same string in another
country or commercial sector, or by a non-trademark owner who is not
using it to infringe the trademark rights. This is perfectly
legitimate and shows that there is no "right to the use", but only a
right not to see it used by someone else in an infringing way.
Moreover, most countries recognize other potential rights on
alphanumeric strings - for example, individuals have a right to their
identity and to prevent defamation (so "john-doe-is-a-jerk.com" might
be illegal in many countries), or countries and other geopolitical
entities have some rights to monitor and restrict the usage of their
names.
I think that the IETF should not enter into the (mined) field of
stating who has legal rights to the use of domain names - something
which is not a technical task at all. So I would definitely suggest
that you wipe this paragraph out completely. However, if you want to
keep it as an informational statement, I suggest it is substituted
with a more balanced sentence such as:
"A number of parties, such as trademark, service mark and intellectual
property holders, individuals, governments and other geopolitical
entities, have some legal rights on certain alphanumeric strings. They
use the directory services of Internet registries, mostly domain
registries and registrars, for purposes of maintaining and defending
claims to domain names consistent with applicable laws and
regulations."
b) =A73.2.3
This feature, if deployed widely, would in practice allow to track
down the worldwide DNS activities of a given registrant with a single
query. Especially in the case when this registrant is an individual
and has not specifically consented to this, this would constitute an
unacceptable break of the personal privacy, and would likely be
illegal under the laws of many countries (for example the European
Union). Similar concerns may apply to other types of search designed
in the document.
If such technical capabilities are to be developed, IMHO it is
mandatory that at the same time other technical capabilities are added
to allow for a simple implementation of the protections to people's
privacy required by law. In the absence of this, the specifications
and the resulting implementations and services will either be deployed
illegally or discarded because of their illegality. In both cases, the
specifications will be practically useless or even damaging.
Practically, I think that the service should be able to classify data
(not by class, but at the level of a single data field entry of a
single domain name, to allow for the maximum flexibility) as "private"
if the registrant has not consented to distribute them publicly
through the service. Queries by domain name must return a standard
string (for example "<private>") when the required field contains an
entry marked as private. Queries by other fields must not return
results when the lookup string is found inside an entry marked as
private. As an exception to this, the system should be able to support
"full access" authenticated accounts that can query the private
entries too - to be distributed to law enforcement and investigation
agencies.
Of course the requirements should not enter into discussing which
fields should be allowed to be marked public or private, and under
which conditions, or who should be able to get full access accounts -
these are policy issues that are likely to be defined by each
registry's applicable law and by the local community. But it is
important that the protocol has the flexibility to allow each registry
to adopt its own policy without being bound by technical limitations.
Perhaps this could be accomplished by the "privilege" mechanism
described in =A73.1.4. However, as I have been told that that mechanism
was designed for other purposes, what I propose is to add a new
paragraph among the base functions. I have tried to draft it, but
certainly there are people here who can do it better than me...
however here it is:
"3.1.12 Privacy Protection Support
The service MUST be capable of associating to the value of each field
of each row of data (e.g. domain name or address block) a flag marking
the value as "private".
Queries MUST NOT return those results for which the value of the
queried field matches the query but is marked as "private". In this
case, the service MUST NOT give indication that a private result was
found.
Results of queries which include values that have been marked as
"private" MUST substitute those values with the standard string
"<private>" before sending back the result to the user.
As the only exception to this, the service MUST be capable of
authenticating entities who have a right to full access to the
database (i.e. those described in 2.4.3). For all queries submitted by
such entities after authentication, all values marked as "private"
will be considered as if they were not marked. All other levels of
access (either anonymous or authenticated) MUST NOT have any way to
access data marked as "private"."
As a further enhancement, the system could support more than one level
of privacy (for example: total privacy, publicity only for
non-commercial and statistic use, total publicity) but it would get
even more complex and depending on local policies. I think that the
mechanism described above would already be a great step forward.
--=20
vb. [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------
faith with the purp