Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS]

[Peter Gietz]

Andrew Newton wrote:

> My comments are in-line:
> (I now regret not starting a seperate thread for each item)
> 
> Eric A. Hall wrote:
> 
>>
[...]
> 
>>> #3 - The implementation of 3.2.8.
>>>
>>> Looking at the jabber logs, there is also discussion of this item 
>>> with theorizing about how it might be done but no mention of it in 
>>> the drafts.  Nor can I find it.  I think the conversation in the 
>>> jabber logs is correct with regard to this only needing to be done on 
>>> the LDAP attribute level and not the LDAP value level, which Peter 
>>> seemed to think would be harder to do.  However, either the control 
>>> or the reserved values (or whatever) do need to be specified.
>>
>>
>>
>> Section 5.3.4 of firs-core-02 tries to lay this off onto the LDAP specs:
>>
>>  |  Clients MUST NOT equate the absence of any attributes with the
>>  |  absence of data, and SHOULD assume that the user is not authorized
>>  |  to view any data which has not been provided.
>>  |
>>  |  If a client specifically requests an entry or an attribute which
>>  |  the server is unable or unwilling to provide due to policy
>>  |  constraints, the server MUST use the appropriate LDAPv3 error
>>  |  message. For example, if the user is unable to view an entry or a
>>  |  requested attribute because it has not yet provided sufficient
>>  |  authentication credentials, the server MUST return the
>>  |  "invalidCredentials" error. Similarly, if the client has request
>>  |  an entry or attribute which the server is unwilling to provide due
>>  |  to policy reasons, the server MUST return the unwillingToPerform
>>  |  error to the client.
>>
>> Those examples don't enumerate all of the possible reasons on purpose,
>> although I could do so. See the response to your next question below.
> 
> 
> As I understand it, LDAP error codes are returned per response, not per 
> result or per attribute.  If I'm wrong, then this changes things and 
> please forgive me.
> 
> Let's say I submit a query and get back the following:
> 
> START RESPONSE
> 
> Contact: bob-192
> Name: Bob Smurd
> Email: bob at example.com
> Phone: 555-1212
> 
> Contact: lisa-543
> Name: Lisa Smith
> Phone: 121-5555
> 
> Contact: charles-777
> Name: Charles Taylor
> Email: president at nic.lr
> Status: deposed
> 
> Error: unwillingToPerform
> 
> END RESPONSE
> 
> What happened here?
> 
> 1 - What bit of information did I not get because of a policy decision? 
>  Was that the phone number for charles-777 or the email address for 
> lisa-543?
> 
> 2 - What was the server unwillingToPerform?  It gave me back 3 entries! 
>  It certainly was willing to do something.
> 
> (Sorry for the last example entry... too much coffee this morning!)

There are two LDAP errors that indicate that only a partial list has 
been given back: timeLimitExceeded and sizeLimitExceeded.

unwillingToPerform should not be used for partial lists. Now that we do 
define FIRS specific error codes, I would vote for adding two more for 
this. What about:

authorizationLimitExceeded and privacyConstraintsLimitExceeded


> 
>>> #4 - Enumeration of error codes.
>>>
>>> Given the recent discussion on error codes and the mention of these 
>>> in the jabber logs, I think it is necessary to fully enumerate them 
>>> so that we can better understand what needs further clarification.  
>>> Some of the error codes would naturally map to existing LDAP error 
>>> codes, but as we discussed with the bags, some will not.  This will 
>>> help with listing which new codes needed to be defined.
>>
>>
>>
>> I recognize and appreciate the desire to be explicit. However there is
>> another equally valid consideration, which is over-specifying to the 
>> point
>> where changes to LDAP are not accomodated, or cannot be accomodated,
>> resulting in FIRS becoming version-locked. I'd really like to just point
>> people to the LDAP specs for the proper response, and only give examples
>> where ambiguities exist or where illustration is needed. I'll accomodate
>> the consensus of course, but let's not go overboard.
> 
> 
> See my example on unwillingToPerform in #3.  It is this type of thing 
> that makes me think this excercise should be undertaken.

I more and more tend to agree.


Peter


> 
> Also, I don't follow your comment about version locking with respect to 
> FIRS and LDAP.  Is there a dependency that has implications to CRISP?
> 
> -andy
> 
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43 at lists.verisignlabs.com
> https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 Tübingen                        email: peter.gietz at daasi.de
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________