[Ietf-not43] First draft on Relay bags in FIRS

[Leslie Daigle]

A couple of comments on the error notification/per referral
threads, and then some general comments on the proposal.


1/  Relay bag specific error notification

It seems to me that it's pretty important to be able to distinguish
between relay bag caused errors and generic errors (the error
is in the (content of) the relay bag) -- in general, because there
is a difference between "My client can't access this server" (general
problem) and "My client can't access this server with a referral
obtained from this other server" (relay bag problem).

>From the discussion that followed, it does seem to me that the most
ldap-consistent solution is to use standard ldap error codes and
create FIRS-specific (reserved) labels to go with them  -- as noted,
FIRS-aware clients will be able to use them appropriately, and 
non-FIRS-aware clients won't misbehave/freak out because they received an
unknown error.

However, I'm not entirely comfortable with one of the proposed error codes:

[Peter Gietz proposed:]
> the bag:
> 1.) is of unrecognized format (permanent failure): protocolError (2)

This proposed use of protocolError (2) seems to be consistent with
the cited LDAP definition of the use of that error code, but I'm
having a hard time understanding why bad data generates an error
describing a problem with the *protocol*.  The relay bag is data.

This may be one of those cases where it is particularly beneficial
to be able to distinguish the relay bag provoked error message --
so that the client can know the "protocol error" was in the relay bag.

> 2.) contains unacceptable data (permanent failure): unwillingToPerform
>    (53)
> 3.) contains data that means processing is refused at this time
>     (transient failure): busy (51) 




2/  Relay bag per referral

Some of the use cases discussed originally for relay bags included
allowing referring servers to supply credentials for access to the
referred-to server, for example.  I.e., it is not necessarily the
case that all referrals will include relay bags, and the content
may be different for each.

To support that sort of activity, it is important to be able
to have a relay bag per referral, not per result set.

I think your model in making this proposal was that the referring
server would have one "statement" to make about itself, and that
was what would be presented to *any* server to which the user was
referred.  That's one interpretation, but I don't (personally) 
think it matches up with the reasonably-expected use cases.


Which means either the URL approach Eric has suggested, or
Andy's suggestion of providing enough structure in the control
data that it can carry (and distinguish between) multiple
relay bags (each of which are individually opaque to the client).

3/  Other comments on the proposal

> 3. Operation Requirements
> 
>    A FIRS client SHOULD evaluate if the server it initially connects to
>    supports this feature, by checking if the controlType Object
>    Identifier of the control specified in this document
>    (relayBagSearchOID) is stored in the attribute supportedControl of
>    the root DSE entry, which is specified in [RFC2251], section 3.4.
> 
>    If the server supports this control the Client MUST use it when
>    sending a search request to the server.  The control MUST always be
>    marked as critical when used.  In the initial server contact the
>    controlValue sent by the client SHOULD be empty.
> 


This is consistent with the model that the referring server
provides the (same) data for every referral.  However, in the model
where the actual data supplied is dependent on the server to which
the client is referred, this gets pretty kludgy.  

It may be the case that only a few of the servers to which the 
client *may* get referred requires a relay bag in order to complete
the query.  If the response the client gets doesn't happen to include
any such server, some form of empty control has to be returned.  Always.

Put another way, if the client doesn't support relay bags, it can't
use this server at all, as opposed to being unable to follow some
referrals.

> 4. Relationship to other search controls
> 
>    The Relay Bag Search Control SHOULD NOT be used together with any
>    other existing search controls.  If a new search control is to be
>    used in combination with the Relay Bag Search Control the document,
>    describing that new search control has to deal with possible
>    implications.

This seems like a really unfortunate and limiting requirement.  


Leslie.


 
Peter Gietz wrote:
> Andrew,
> 
> Thanks for your valuable comments.
> 
> Andrew Newton wrote:
> 
>> Peter,
>>
>> What you have defined seems to be fairly straight forward.  However, I 
>> think it needs further refinement per the requirements.
> 
> 
> Yes that is what I wrote in the Open Issues section.
> 
>>
>> Peter Gietz wrote:
>>
>>>
>>>    Servers that support this control MAY decide to only serve clients
>>>    that support and use this control.  If a server wants to thus enforce
>>>    the control, every search request without this control SHOULD be
>>>    responded to with the resultCode unwillingToPerform (53).
>>
>>
>>
>> This does not cover all the error conditions listed:
>>
>> from 3.1.13.1
>>
>>>    The protocol MUST provide different error messages to indicate
>>>    whether the bag is of unrecognized format (permanent failure), if it
>>>    contains unacceptable data (permanent failure), or if it contains
>>>    data that means processing is refused at this time (transient
>>>    failure).
>>
>>
>>
>> Also, it would seem that for best interoperability, the error codes 
>> for bags should be specific to the use of the control.  As in, 
>> "unwilling to perform (generic reason)" and "unwilling to perform 
>> because bag is unrecognized".
> 
> 
> Well, I thought we should try to use the already defined LDAP error 
> codes. I have BTW never seen an LDAP specification that uses error codes 
> not specified in RFC2251. There is an expired but quite valuable Draft 
> (http://www.watersprings.org/pub/id/draft-just-ldapv3-rescodes-02.txt) 
> that deals with LDAP error codes. having gone through that document 
> again, I propose the following error codes:
> 
> the bag:
> 1.) is of unrecognized format (permanent failure): protocolError (2)
> 2.) contains unacceptable data (permanent failure): unwillingToPerform
>    (53)
> 3.) contains data that means processing is refused at this time
>     (transient failure): busy (51)
> 
> To quote the afore mentioned document:
> 
>> 5.2.2.4.2 protocolError(2)
>>
>>    Applicable operations: all.
> 
> 
>>    A protocol error should be returned by the server when an invalid or
>>    malformed request is received from the client. This may be a request
>>    that is not recognized as an LDAP request, for example, if a
>>    nonexistent operation were specified in LDAPMessage.  As well, it may
>>    be the result of a request that is missing a required parameter, such
>>    as a search filter in a search request. If the server can return an
>>    error, which is more specific than protocolError, then this error
>>    should be returned instead. For example if the server does not
>>    recognize the authentication method requested by the client then the
>>    error authMethodNotSupported should be returned instead of
>>    protocolError. The server may return details of the error in the
>>    error string.
> 
> 
>> 5.2.2.4.9 unwillingToPerform(53)
>>
>>    Applicable operations: all.
>>
>>    This error code should be returned by the server when a client
>>    request is properly formed but which the server is unable to complete
>>    due to server-defined restrictions.  For example, the server, or some
>>    part of it, is not prepared to execute this request, e.g. because it
>>    would lead to excessive consumption of resources or violates the
>>    policy of an Administrative Authority involved [X511, Section 12.8].
>>    If the server is able to return a more specific error code such as
>>    adminLimitExceeded it should. This error may also be returned if the
>>    client attempts to modify attributes which can not be modified by
>>    users, e.g., operational attributes such as creatorsName or
>>    createTimestamp [X511, Section 7.12]. If appropriate, details of the
>>    error should be provided in the error message.
> 
> 
>> 5.2.2.4.7 busy(51)
>>
>>    Applicable operations: all.
>>
>>    This error code may be returned if the server is unable to process
>>    the clientÆs request at this time. This implies that if the client
>>    retries the request shortly the server will be able to process it
>>    then.
>>
> 
> If I hear no protest, I will align the draft along these lines.
> We could additionally specify apropriate errorMessages the server should 
> return along with the error code, which may contain FIRS specifics 
> without breaking the LDAP protocol.
> 
> If people insist in defining new error codes for FIRS, we may want to 
> return them in a dedicated FIRS control and not in the resultCode field.
> 
> 
>>
>> Finally, a question.  Is this one bag per referral or one bag per 
>> response/result set?
> 
> 
> 
> No, and this has implications for the relay bag: The searchresponse can 
> include an unlimited number of referrals but only one controlValue. That 
> is why I sort of asumed that the Relay Bag contains only general 
> information about the referring server and about what that server has to 
> say about the client (authentication status, etc.).
> 
> If the Relay bag has also to contain information about the referred to 
> server, we would have a problem here.
> 
> 
> Cheers,
> 
> Peter
> 
>>
>> -andy
>>
> 


-- 

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
leslie at thinkingcat.com
-------------------------------------------------------------------