[Ietf-not43] Suggestions of changes to the requirements document

[Andrew Newton]

Vittorio,

The inclusion of 2.4.2 and most of section 2 is to scope the problem. 
However, there is no use of MUST/SHOULD language there and we are not 
attempting to define an intellectual property holder.  This section just 
describes the user scope.  That being said, I have no problems with your 
proposed substitution.  It sounds reasonable to me.

Regarding your proposal for 3.1.12: this seems to actually specify 
policy, which is probably not universal.  I also so no need for the 
protocol to specify "this thing is private".  Either the user has 
authorization to see the data or they don't.  This seems more 
appropriate for the provisioning side (see the current fuss in the 
PROVREG WG).

In addition, the access levels and privilege levels in the current 
document seem to only indicate two tiers.  This is a mistake and will be 
corrected.  The intent is that there may be multiple levels of access 
defined by the policy used by the operator.  3.1.4 needs to be 
rewritten, but there is no reason why it wouldn't apply to 3.2.3.  From 
the text of section 3:
    For instance, this
    document may say that the service "MUST" support search features.  An
    actual service operator is always free to disable it (and then to
    return an error such as "permission denied").



-andy

Vittorio Bertola wrote:
> 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) §2.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) §3.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 §3.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.