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

From: [email-masked] (Vittorio Bertola)
Date: Tue, 14 Jan 2003 10:49:16 +0100

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/ <-----------------------

---

From: [email-masked] (Stephane Bortzmeyer)
Date: Tue, 14 Jan 2003 14:35:37 +0100

On Tue, Jan 14, 2003 at 10:49:16AM +0100,
 Vittorio Bertola <[email-masked]> wrote 

> string (for example "<private>") when the required field contains an

It should be noted there is currently a difficult discussion on the
companion IETF Working Group ProvReg (which tries to standardize the
registry interface for modifications, Crisp dealing with "read-only"
queries).

The IESG froze the progress of the EPP protocol documents to the RFC
level because of privacy concerns (the lack of a standard way to
express privacy preferences for the registrant).

A good part of the discussion revolves around wether a simple binary
(Disclose/doNotDisclose) capability is better than nothing or if we
should use a full-fledged system like W3C's P3P to express privacy
preferences.

---

From: [email-masked] (Andrew Newton)
Date: Tue, 14 Jan 2003 09:21:21 -0500

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:
> a) §2.4.2
> b) §3.2.3
> described in §3.1.4. However, as I have been told that that mechanism

---

From: [email-masked] (Vittorio Bertola)
Date: Mon, 20 Jan 2003 11:12:33 +0100

>proposed substitution.  It sounds reasonable to me.

Thanks :-) The proposed substitution is intended to preserve the
informational value without upsetting any policy-oriented reader :-))

>policy, which is probably not universal.

Well - in my opinion, it was not meant to specify policy, but rather,
to define the meaning of the "private" value when attached to a field.
There's no mention of which data should be marked as private, or how,
or by whom, or under which conditions - it just defines that the
"private" flag has some consequences on the behaviour of the service,
i.e. that data must not be shown unless to specially authorized
queries.

>I also so no need for the 
>authorization to see the data or they don't.

So you should simply omit private fields from answers, rather than
substituting them with a warning message such as "<private>", as per
my proposal? Personally, I think that there should be an explicit and
standard "<private>" answer, because it will allow the user (and the
maintainer of the service) to tell between incomplete or missing
answers that happen because the rest of the data are private, and
incomplete or missing answers that happen because of a bug in the
implementation, a fault, or a problem in the data base. Otherwise you
may risk that users try again and again to submit queries that do not
receive complete answers due to privacy settings, because they think
they were incomplete due to a temporary fault.

The only exception to this is when the private field is the one that
your lookup string is matching - in this case, indicating that a
private match has been found is an information that should not be
given to the user, as it would put the privacy of the value at risk.

>rewritten, but there is no reason why it wouldn't apply to 3.2.3.

As I told in the previous message, 3.1.4 was my first idea, before
thinking that it was maybe intended for other uses (e.g. paid bulk
access). But then, if you want to use 3.1.4 for more general purposes
including privacy protection, it lacks a couple of things:

- as you say, the protocol must be able to support more than one level
of access;

- there should be some definition of a specially named level of access
that is the only one allowed to access data marked as private during
the provisioning phase; the implementations of the protocol should
mandatorily support secure authentication for that level of access;

- it must be specified that the level of access must be evaluated at
the level of each single value of each single item, and not simply at
the whole row or whole column level of the database.

For the rest, as I said, I'm not the expert in writing RFCs here :-)
My only desire is to see these points clearly specified in the
requirements, to be sure that they won't be missed by the actual
protocols and the subsequent implementations.

  From 
>    return an error such as "permission denied").

Yes. But I do not want an operator to disable the search features
completely. I only want the operator to support proper authentication
and permissions of access to each single piece of information of his
database. This way, he will be able to support both privacy and
searching in a proper manner, without having to choose between them.

Thanks,
--

---

From: [email-masked] (Jaap Akkerhuis)
Date: Mon, 20 Jan 2003 11:23:30 +0100

What the answer is on such "private" fields is policy as well. In
the Dutch registry some opt-out fields are silently replaced by
other information. Contact data for registrants, when opted-out is
replaced by contact data of the registrar. The assumption is here
that if there are really urgent matters why the registrant needs
to be contact, the registrar is the most likely one to know. Otjer
registries are likely to have other policies. Just flagging "opted
out" or somethong like that is just one option.

	jaap

---

From: [email-masked] (Vittorio Bertola)
Date: Tue, 21 Jan 2003 18:40:10 +0100

On Mon, 20 Jan 2003 11:23:30 +0100, you wrote:

>What the answer is on such "private" fields is policy as well.

Ok - I got your point, you're right. I'm still wondering whether, in
case the decision is "hide the field behind a <<private>> indication",
such indication should be made standard (or at least recommended) to
increase interoperability (for example, the client could parse the
field and recognize such standard answer). But OTOH some registries
might want, for example, to replace it with a message in the local
language.
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: [email-masked] (Andrew Newton)
Date: Tue, 21 Jan 2003 13:03:26 -0500

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zak-28855-1043171847-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> might want, for example, to replace it with a message in the local

That's probably not a bad thing.  What's the proposed text for this?

-andy

--=_zak-28855-1043171847-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zak-28855-1043171847-0001-2--

---

From: [email-masked] (Vittorio Bertola)
Date: Thu, 23 Jan 2003 10:31:24 +0100

>That's probably not a bad thing.  What's the proposed text for this?

I have tried to rephrase 3.1.4 a little to include this.

I have included the concept of "type of authentication" to allow for
more than one level of privilege. I think that we should talk about
"types", not "levels", because it's not a hierarchical structure - you
could define a type of privilege such as "privacy-protected" and
another type such as "needs payment to be accessed", but entities who
can access privileged data of the first type should not necessarily be
able to access those of the second, and vice versa; so the
authentication should be per-type (i.e. the protocol should be able to
authenticate you, and the service should be able to determine whether
you can access one type, the other, or both types of privileged data).

I'm not sure whether we need the new paragraph #2. You possibly need
it if you talk about the service, not if you talk about the protocol.

3.1.4 Level of Access

   The service MUST allow the classification of data as being either
   privileged or non-privileged, for the purpose of restricting access
   to privileged data.  Note that this requirement makes no assumption
   or prescription as to what data (social or operational) might be
   considered privileged, but merely provides the ability to make the
   classification as necessary. <new>The system SHOULD support more
   than one type of privileges.</new>

   <new>The service MUST be capable of associating a type of privilege
   (or the lack of any privilege requirement) to each single value of
   each entry.</new>

   The service MUST be capable of serving both privileged and non-
   privileged data.

   The service MUST be capable of authenticating privileged entities
   and ensuring that only those entities have access to
   <changed>privileged data of the type(s) for which they were
   authenticated.</changed>

   The service MUST be capable of providing access to non-privileged
   data without requiring authentication of any type (i.e.  anonymous
   access).

   <new>When the answer to be returned to a user after a query
   contains values of a privilege type for which the user does not
   have authorization, the service MUST NOT return such values. In
   case the choice is made to make it explicit that those values are
   not being returned due to insufficient permissions, the service
   SHOULD return the standard string "[permission denied]" in place of
   such values. In case such values are being denied for privacy
   protection reasons and the choice is made to make it explicit that
   those values are not being returned due to privacy protection
   reasons, the service SHOULD return the standard string "[private]"
   in place of such values.</new>
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: [email-masked] (Andrew Newton)
Date: Thu, 23 Jan 2003 14:35:00 -0500

I'd like to list this as its own item, perhaps making a reference to 
3.1.4.  I think that would be clearer.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Thu, 23 Jan 2003 16:30:58 -0500

Vittorio,

Based on my previous comment that I'd like to separate these two items, 
here is what I have... let me know if this doesn't work.

3.1.4 Level of Access

3.1.4.1 Protocol Requirement

    The protocol MUST NOT prohibit an operator from assigning multiple
    types of access to data according to the policies of the operator.
    The protocol MUST provide an authentication mechanism and MUST NOT
    prohibit an operator from granting types of access based on
    authentication.

    The protocol MUST provide an anonymous access mechanism that may be
    turned on or off based on the policy of an operator.

3.1.4.2 Service Description

    Server operators will offer varying degrees of access depending on
    policy and need.  The following are some examples:

    o  users will be allowed access only to data for which they have a
       relationship

    o  unauthenticated or anonymous access status may not yield any
       contact information

    o  full access may be granted to a special group of authenticated
       users

    The types of access allowed by a server will most likely vary from
    one operator to the next.

3.2.11 Data Omission

3.2.11.1 Protocol Requirements

    When a value in an answer to a query cannot be given due to policy
    contraints, the protocol MUST be capable of expressing the value in
    one of three ways:

    1.  complete omission of the value without explanation

    2.  an indication that the value cannot be given due to insufficient
        authorization

    3.  an indication that the value cannot be given due to privacy
        constraints regardless of authorization status

3.2.11.2 Service Description

    Internet registries will have varying constraints regarding their
    ability to expose certain types of data, usually social information.
    Server operators must have the ability to accomodate this need while
    client software will more useful when provided with proper
    explanations.  Therefore, depending on policy, a server operator has
    a choice between not returning the data at all, signaling a
    permission error, or indicating a privacy constraint.

---

From: [email-masked] (Vittorio Bertola)
Date: Mon, 27 Jan 2003 09:11:43 +0100

On Thu, 23 Jan 2003 16:30:58 -0500, you wrote:

>Vittorio,
>
>Based on my previous comment that I'd like to separate these two items,=20

I hope I understood correctly the "must not prohibit" statement in
3.1.4.1 - basically you can't mandate support for access privileges
here, because it's a matter of the provisioning side, but you have to
be certain that the retrieval protocol will not have any
characteristic that prevents the operator from implementing such
support. Perhaps the only slight change I'd do is "types of access to
each piece of data" in the second line, to make sure that we are
talking of privileges that are customizable at a granular level. Don't
know if "piece of data" is English, though :-)

Also, I'm wondering whether in 3.2.11.1 you should say "at least in
one of the following ways", rather than "in one of three ways"; you
would then allow for additional types of reasons to be specified by
the protocol. (Perhaps you would allow also for non-standard
extensions done by the operator/implementor, unless you rule them out
by adding another sentence there.)

Anyway, it seems great (obviously much better than mine). Thanks.
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: [email-masked] (Andrew Newton)
Date: Mon, 27 Jan 2003 05:45:31 -0500

Vittorio,

> know if "piece of data" is English, though :-)

Would it be ok just to say: ...MUST NOT prohibit an operator from 
assigning multiple types of access to granular data...

Otherwise, the other works.

> by adding another sentence there.)

Good point.  We just want to point out the minimum set, but there 
doesn't seem to be a reason to limit it to just three.

> Anyway, it seems great (obviously much better than mine). Thanks.

Thanks.

-andy

---

From: [email-masked] (Vittorio Bertola)
Date: Tue, 28 Jan 2003 11:07:26 +0100

On Mon, 27 Jan 2003 05:45:31 -0500, you wrote:

>Would it be ok just to say: ...MUST NOT prohibit an operator from=20

Perhaps "granularly assigning multiple types of access" (the
assignment is granular, not the data).
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: [email-masked] (Andrew Newton)
Date: Tue, 28 Jan 2003 05:20:29 -0500

--=_zak-14123-1043749478-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> assignment is granular, not the data).

Sounds good to me.

-andy

--=_zak-14123-1043749478-0001-2

--=_zak-14123-1043749478-0001-2--