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

[Andrew Newton]

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.


Vittorio Bertola wrote:
> On Tue, 21 Jan 2003 13:03:26 -0500, you wrote:
> 
> 
>>>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.
>>
>>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>