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

[Vittorio Bertola]

On Tue, 14 Jan 2003 09:21:21 -0500, you wrote:

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

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

>Regarding your proposal for 3.1.12: this seems to actually specify=20
>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=20
>protocol to specify "this thing is private".  Either the user has=20
>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.

>In addition, the access levels and privilege levels in the current=20
>document seem to only indicate two tiers.  This is a mistake and will be=
=20
>corrected.  The intent is that there may be multiple levels of access=20
>defined by the policy used by the operator.  3.1.4 needs to be=20
>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.

=46or 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=20
>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").

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,
--=20
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------