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

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Wed Aug 13 09:38:19 2003

Hi all,

please find attached a first version of the promissed Draft on FIRS 
Relay Bag.

As you can see in the todo section, there is still a little work to do, 
which I can finalize after your comments on the document.

I would also be interested in editorial comments, e.g. to improve the 
English. Such comments could be sent to me directly.

Cheers,

Peter

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: +49 7071 2970336
Wilhelmstr. 106                         Fax:   +49 7071 295114
D-72074 T?bingen                        email: [email-masked]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information Management
_______________________________________________________________________
-------------- next part --------------

Network Working Group                                           P. Gietz
Internet-Draft                                  DAASI International GmbH
Expires: February 11, 2004                               August 13, 2003

 Relay Bag Search Control for the  Federated Internet Registry Service
                     draft-ietf-crisp-firs-relay-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 11, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document describes an LDAP control to allow additional
   unspecified data to be returned with a referral to the client, which
   can submit these data to the referred to server in support of the
   Federated Internet Registry Service (FIRS) described in [FIRS-ARCH]
   and [FIRS-CORE].  A flexible container called Relay Bag as required
   in [CRISP-REQ] is included into this extension to the LDAP search
   operation.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

Gietz                   Expires February 11, 2004               [Page 1]

Internet-Draft                  Relay Bag                    August 2003

   document are to be interpreted as described in [RFC2119].

1. Background and Intent of use

   The Federated Internet Registry Service (FIRS) described in [FIRS-
   ARCH] and [FIRS-CORE] is a distributed service for storing, locating
   and transferring information about the Internet Resources using
   LDAPv3 [RFC3377].  It is thus an implementation of a Cross Registry
   Information Service Protocol as specified in the requirements
   document [CRISP-REQ].  To completly fulfil these requirements, a
   feature called Relay Bag has to be supported.

   A Relay Bag is a flexible container which may contain unspecified
   data that a server can give back to a client in addition to a
   referral.  The data are not to be read and understood by the client,
   but to be forwarded by the client to the referred to server.  The
   data transported in the Relay Bag are thus server operator-to-
   operator coordination data, e.g.  for auditing or tracking.

   This document specifies such a Relay Bag with the means of an LDAP
   control extenting the LDAP search operation.  Basically an LDAP
   control consists of a controlType, containing the OID for the
   control, a boolean field for marking the criticality of the control,
   and an optional controlValue containing arbitrary data with octet
   string syntax.

2. Relay Bag Search Request and Response control

   The Relay Bag control is included in the SearchRequest and in the
   SearchResultReference message as part of the controls field of
   LDAPMessage, as defined in section 4.1.12 of [RFC2251].  It MUST NOT
   be included in any other request or result message.

   Since the control syntax is the same in request and response, the
   following controlType is used in both cases:

      relayBagSearchOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.10126.1.15.7.1

   The controlValue is a BER-encoded Octet string, which can contain any
   kind of data:

      relayBagValue ::== OCTET STRING

   The criticality MUST be set to TRUE.

Gietz                   Expires February 11, 2004               [Page 2]

Internet-Draft                  Relay Bag                    August 2003

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.

   When the server sends back the search response, it MUST include the
   control identified by the controlType field.  The controlValue SHOULD
   contain data that at least give the information that the server had
   referred the client to another server.  The semantics for such
   information is not defined in this document and is to be specified by
   the service operators.  The semantics could include a mechanism to
   make sure that the data have not been changed, e.g.  by digitally
   signing a hash value of the contents.

   When the client follows the referral and sends its search request to
   the referred to server, it MUST again check if the referred to server
   supports the Relay Bag control.  If so, the client MUST use the
   control and send the data given by the referring server in the
   controlValue field unchanged in the controlValue field of the search
   request.

   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).

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.

5. Security considerations

   The Relay Bag Search Control can be used in services to provide data
   only to clients that have properly authenticated to one server, by
   passing over the authentication status of the client to the referred
   to server.

Gietz                   Expires February 11, 2004               [Page 3]

Internet-Draft                  Relay Bag                    August 2003

   To make sure the client has not changed the contents of the Relay
   Bag, it is possible to use the PKI feature of digitally signing the
   contents of the Relay Bag, e.g.  by using X.509 based PKI with
   certificates as specified in [RFC3280].

   Obviously any usage of this search control is dependant on the
   services that use it, since this document does not specify and
   enforce any semantics of the controlValue field.  Thus every service,
   using this control has to be aware of the possible security
   implications.

6. IANA considerations

   TBD

7. Open issues

   There are still a number of todos with respect to this draft.
   Following work items will be dealt with in the next version of this
   draft:

   o  re-evaluate the MUST, SHOUD and MAY with respect to the
      requirements specified in [CRISP-REQ], especially with respect to
      the criticality of the control

   o  Section on IANA considerations

   o  proofread

8. Acknowledgments

   This document is the result of discussions taking place in the IETF
   CRISP WG.  The concept of Relay Bags is derived from that activity.

   This document has been written in XML according to the DTD specified
   in RFC2629.  xml2rfc has been used to generate an RFC2033 compliant
   plain text form.  The XML source and a HTML version are available on
   request.

9. References

Normative references

   [CRISP-REQ]  Newton, A., "Cross Registry Internet Service Protocol
                (CRISP) Requirements", May 2003, <draft-ietf-crisp-
                requirements-05.txt>.

Gietz                   Expires February 11, 2004               [Page 4]

Internet-Draft                  Relay Bag                    August 2003

   [FIRS-ARCH]  Hall, E., "The Federated Internet Registry Service:
                Architecture and Implementation Guide", May 2003,
                <draft-ietf-crisp-firs-arch-01.txt>.

   [FIRS-CORE]  Hall, E., "The Federated Internet Registry Service: Core
                Elements", May 2003, <draft-ietf-crisp-firs-core-
                01.txt>.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2251]    Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
                Access Protocol (v3)", RFC 2251, December 1997.

   [RFC3377]    Hodges, J. and RL. Morgan, "Lightweight Directory Access
                Protocol (v3):  Technical Specification", RFC 3377,
                September 2002.

Non-normative references

   [RFC3280]  Housley, R., Polk, T., Ford, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 3280, April 2002.

Author's Address

   Peter Gietz
   DAASI International GmbH
   Wilhelmstr. 106
   Tuebingen  72074
   DE

   Phone: +49 7071 29 70336
   EMail: [email-masked]
   URI:   http://www.daasi.de/

Gietz                   Expires February 11, 2004               [Page 5]

Internet-Draft                  Relay Bag                    August 2003

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Gietz                   Expires February 11, 2004               [Page 6]

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed Aug 13 17:08:59 2003

Peter,

What you have defined seems to be fairly straight forward.  However, I 
think it needs further refinement per the requirements.

>    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".

Finally, a question.  Is this one bag per referral or one bag per 
response/result set?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed Aug 13 19:53:44 2003

>    the root DSE entry, which is specified in [RFC2251], section 3.4.

I'll put some more time into this in a couple of days but the first thing
that jumps out at me is that this should be a MAY instead of a SHOULD. Too
many round-trips spent on query setup will make this service unusable for
fast lookups. There might be some other options for dealing with the need
for this, such as having the control returned as a bind response similar
to firsVersion.

Also, does there need to be any wording on how the data should be
encapsulated within an LDAP URL?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 14 02:05:40 2003

> for this, such as having the control returned as a bind response similar

Will this test only be necessary if a server actually provides a relay
bag? Can a client just be assumed to support the extension? If so, that
would mean the client only had to spend time probing the referral-target
server, and would only have to do this if it got a relay bag from a
referral-source, which might be a small enough subset to make the probes
mandatory in those limited scenarios. I may be assuming too much, but I
haven't heard anybody say anything about actually using these.

Also, to reiterate the point I was trying to make during the meeting, this
whole area is almost certain to be reinvented when somebody tries to
actually make use of relay bags and recognizes the real requirements
reflecting the real deployment, so whatever we spec now has a high
probability of getting thrown out at some later point.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Thu Aug 14 09:29:50 2003

Andrew,

Thanks for your valuable comments.

> think it needs further refinement per the requirements.

Yes that is what I wrote in the Open Issues section.

> perform (generic reason)" and "unwilling to perform because bag is 

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 

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

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 14 09:42:29 2003

on 8/14/2003 8:29 AM Peter Gietz wrote:

> 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.).
> 

What about providing the bag as a URL extension? Each referral target can
have its own bag then.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Aug 14 10:37:23 2003

>     (transient failure): busy (51)
[...snip...]
> without breaking the LDAP protocol.

As I said, interoperability would be aided by errors specific to the 
bags.  If current errors have overloaded meanings then how is a client 
to distinquish between them and how is a server operator to know which 
one to use?  Would the definitions in 2251 be deprecated?

> return them in a dedicated FIRS control and not in the resultCode field.

I'm not sure how this is better, but I'll take your word for it.

> server, we would have a problem here.

Perhaps creating a syntax for the controlValue that partitions the value 
as Strings of octets (or however it was defined) per referral, with each 
related to the referral either by key or index.

-andy

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Thu Aug 14 12:57:15 2003

Andrew Newton wrote:

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

2251 just lists the error codes and names. The quotes I gave were from 
an expired Internet Draft that wanted to provide a common understanding 
of how the error codes should be intepreted and used.

I am not aware of any error codes not specified in 2251 nor of any 
extension mechanism to specify new error codes (There is an exception 
for API error codes 81-90, but they MUST NOT be returned by a server). 
Thus I think it is breaking the LDAP protocol to add new error codes for 
LDAP based services. I may be wrong here, but cannot find any evidence 
that tells me I am. I think the proposal to use 2, 53 and 51 for the 
FIRS errors is not overloaded and the clients can  react apropriately 
without any additional hints. Nevertheless I proposed such additional 
hints in the errorMessage, which are specified (in 2251) as :

> The errorMessage field of this construct may, at the server's option,
> be used to return a string containing a textual, human-readable
> (terminal control and page formatting characters should be avoided)
> error diagnostic. As this error diagnostic is not standardized,
> implementations MUST NOT rely on the values returned.  If the server
> chooses not to return a textual diagnostic, the errorMessage field of
> the LDAPResult type MUST contain a zero length string.

> I'm not sure how this is better, but I'll take your word for it.

see my explanation above

>> 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.).
>>

I call this Solution I here:

I though of that, but then refrained from it because the requirements 
doc says in 3.1.13.1:

> The protocol MUST NOT make any assumptions regarding the contents of
> the relay bag

This solution would anyway force the client to look into the relay bag, 
we would need the referral stored there too to have a clear attribution 
between referral and relay bag.

Now comes Solution II:

The alternative, Eric is proposing, is to use the extension mechanism in 
the LDAP URL, which is specified in RFC 2255 (text in [[ ]] are my 
comments):

>        extensions = extension *("," extension)
>        extension  = ["!"] extype ["=" exvalue]
>        extype     = token / xtoken
>        exvalue    = LDAPString from section 4.1.2 of [RFC 2251] [[basically an OCTET STRING]]]
>        token      = oid from section 4.1 of [RFC2252] [[an oid either numeric or as object descriptor]]
>        xtoken     = ("X-" / "x-") token
> The extensions construct provides the LDAP URL with an extensibility
> mechanism, allowing the capabilities of the URL to be extended in the
> future. Extensions are a simple comma-separated list of type=value
> pairs, where the =value portion MAY be omitted for options not
> requiring it. Each type=value pair is a separate extension. These
> LDAP URL extensions are not necessarily related to any of the LDAPv3
> extension mechanisms. Extensions may be supported or unsupported by
> the client resolving the URL. [...]

There are pros and cons here:

Pro:
- This solves our problem.
- for every referral we have a Relay Bag

Cons:
- There is a "media change". Since clients usually don't communicate 
with servers via LDAP URLs, the client has to convert this information 
into the search control as specified in the new draft. Not too complex 
though:
   * the token (provided the numeric od form is used) can be the same as
     the controlType
   * the criticality sign ('!') or its absebse can be stored in the
     criticality field
   * the exvalue is the controlValue (might need reencoding though, see
     next bullet)

- the exvalue has to be URLencoded, in the words of 2255:
> Note that any URL-illegal characters (e.g., spaces), URL special
> characters (as defined in section 2.2 of RFC 1738) and the reserved
> character '?' (ASCII 63) occurring inside a dn, filter, or other
> element of an LDAP URL MUST be escaped using the % method described
> in RFC 1738 [5]. If a comma character ',' occurs inside an extension
> value, the character MUST also be escaped using the % method.

- The URL might not be a very good vehicle to transport greater amounts 
of data, which might restrict the usage of relay bags. I think it is 
doable though and I don't know of any length restrictions for URLS 
(hasn't there been a data field extensions for http urls as well?

- we loose the symmetry between request extension and response 
extension, which would have made the implementation fairly easy, the 
client had only to take the whole control construct and add it to its 
next request

Solution III:
Another very easy solution would be to always give back only one 
referral to the client, but that might not be what we want either.
If the Relay Bag is to store information about the referring server and 
about the client, we would not need more than one relay bag. But this 
would make it impossible, e.g. to encrypt the relay bag information 
with the public key of the server referred to, and we might want to have 
that.

You see I am biased and none of the solutions looks very promissing to 
me. But I think we have to choose between Solution I and II.

Peter

Peter Gietz (CEO)

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Thu Aug 14 13:13:22 2003

> one to use?  Would the definitions in 2251 be deprecated?

A non FIRS client will react to the error codes proposed by me just as 
we would want them to.

A FIRS client will even better know how to interprete the error codes.

I don't see an interoperability issue here. The error codes and their 
FIRS usages will be specified in the draft and conforming 
implementations will be interoperable.

Cheers,

Peter

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 14 13:22:36 2003

> me. But I think we have to choose between Solution I and II.

Solution II because it (1) solves the immediate problem, (2) allows for
permament storage, and (3) eliminates the mandatory negotiation for
non-referrals.

(1) is obvious in context of this thread

(2) essentailly means that I can store referral URLs with hard-coded
cookies or whatever data format we need. That way, any referrals my server
returns can always bark an identifier, regardless of the client.

(3) if its flagged as critical, the client has to deal with it, so
non-conforming clients will self-destruct. Plus, the client only has to
check if the referral target supports the extension, and doesn't have to
ask in other situations. That eliminates the mandatory negotiation step.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Thu Aug 14 13:30:37 2003

> hints in the errorMessage, which are specified (in 2251) as :

The need is for the client to unambigously (sp?) understand the 
difference.  I'm not sure overloading the existing error codes and using 
the errorMessage field is an excellent idea.  However, it might work if 
the field were given a reserved value (or started with a reserved value
so that the rest of the field could be used for its original purpose.

> the LDAP URL, which is specified in RFC 2255 (text in [[ ]] are my 

While I do not believe there is an official limit to the size of a URL,
they certainly weren't meant to contain large amounts of data.  There 
have definitely been pieces of software that have not played well with 
large URLs.  This seems like a mistake we should not recreate.

> would make it impossible, e.g. to encrypt the relay bag information with 
> the public key of the server referred to, and we might want to have that.

This seems rather limiting.  I'd rather see Solution I worked out.

-andy

---

From: mcs at netscape.com (Mark C Smith)
Date: Thu Aug 14 14:06:12 2003

Peter Gietz wrote:
> ... 
> that tells me I am.

If you really need to add new LDAP result codes, you can.  See RFC 3383 
(http://www.ietf.org/rfc/rfc3383.txt) section 3.6.

-- 
Mark Smith
Netscape Directory Product Development
My words are my own, not my employer's.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Thu Aug 14 14:30:19 2003

> (http://www.ietf.org/rfc/rfc3383.txt) section 3.6.

That took an item off my to-do list.

I agree with Andy that defining them is the right thing to do.

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Thu Aug 14 16:11:55 2003

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:]
> 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.

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

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

>    describing that new search control has to deal with possible

This seems like a really unfortunate and limiting requirement.  

Leslie.

Peter Gietz wrote:
>> 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".
> 
> 

-- 

-------------------------------------------------------------------
"Reality:
     Yours to discover."
                                -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: steven.legg at adacel.com.au (Steven Legg)
Date: Thu Aug 14 22:05:25 2003

Eric & Peter,

> for this, such as having the control returned as a bind 

I don't see a need for any sort of check. The control in the request
is required to be marked critical. The client should just send in its
query with the control attached. FIRS-aware LDAP servers will do their
job. Conformant LDAP servers that are not FIRS-aware will respond with
the error unsupportedCriticalExtension.

Regards,
Steven

_______________________________________________
Ietf-not43 mailing list
[email-masked]
https://lists.verisignlabs.com/mailman/listinfo/ietf-not43

---

From: steven.legg at adacel.com.au (Steven Legg)
Date: Thu Aug 14 22:49:26 2003

Peter,

> between referral and relay bag.

I think you are getting hung up on your own assumptions here.
Suppose that the format of the controlValue in a response were
something like this:

SEQUENCE OF SEQUENCE {
    ldapurl    [0] LDAPURL,
    relayBag   [1] OCTET STRING
}

The referral URL is clearly associated with the relay bag and the relay bag
is still opaque. Anything else that's needed can be added to the SEQUENCE.
The ldapurl field duplicates information in the SearchResultReference,
but we can deal with that in the definition of the control by saying
that any URL included in the controlValue is omitted from the
SearchResultReference.

RFC 2251 does not allow SearchResultReference to be empty but I don't
see any interoperability problems from explicitly allowing that constraint
to be violated since the response is never unsolicited (as far as I know)
The LDAPbis working group might also be willing to drop the constraint.

Regards,
Steven

> >        token      = oid from section 4.1 of [RFC2252] [[an
> oid either numeric or as object descriptor]]

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Fri Aug 15 11:59:54 2003

Mark,

Thanks, it seems I overread that. But I see it is a possible way to go, 
although the IANA registry based on 3383 is not yet operating, but that 
should not be a problem.

OK, since the group seems to want it, I will specify apropriate FIRS 
errorcodes. If we do such, we should as well re-evaluate, if we need 
additional error codes for the rest of the FIRS stuff. Eric: comments?

Cheers,

Peter

Mark C Smith wrote:

> Peter Gietz wrote:
> 
>> ... I am not aware of any error codes not specified in 2251 nor of any 
>> Thus I think it is breaking the LDAP protocol to add new error codes 
>> for LDAP based services. I may be wrong here, but cannot find any 
>> evidence that tells me I am.
> 
> 

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Aug 15 12:28:58 2003

> additional error codes for the rest of the FIRS stuff. Eric: comments?

The only other FIRS-specific stuff I can think of that might benefit from
additional codes would be search responses, but I don't see any demand for
any of these right now. It's worth keeping in mind though.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Fri Aug 15 12:31:14 2003

Steven,

Thanks for your comment. I do favour the controlValue solution. The URL 
stuff seems to be more of a rathole to me (see the cons listed in my 
prior posting).

I will include

>>     relayBag   [1] OCTET STRING

into the next version of the Draft (which I will hopefully have ready on 
Monday).

As to the empty SearchResultReference: A possibility to get away with 
it, without violating 2251, we could include something in the line of:

"
A server may send back referrals without a Relay Bag, referrals with a 
Relay Bag and a combination of both.
Referrals without Relay Bag MUST be submitted via the 
SearchResultReference  construct specified in RFC 2251, section 4.5.2 
for this purpose.
Referrals with a Relay Bag MUST be submitted inside the controlValue 
field as specified above, without redundantly storing the referrals in 
the SearchResultReference construct.
If only referrals with Relay Bag are submitted, the server MUST store a 
dummy-referral in the SearchResultReference construct. The dummy 
referral, which MUST be ignored by the client, is:
    ldap:///
"

Eric: You being the only one preferring the URL solution, can you live 
with this? Or do you see any serious issues?

Steven Legg wrote:

>>>       exvalue    = LDAPString from section 4.1.2 of [RFC
>>
>>2251] [[basically an OCTET STRING]]]
>>
>>>mechanism, allowing the capabilities of the URL to be
>>
>>extended in the
>>

Peter Gietz (CEO)

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Fri Aug 15 12:53:58 2003

Leslie,
Thanks for your comments, which I will comment in line:

> describing a problem with the *protocol*.  The relay bag is data.

data inside a protocol element. But anyway, I think consensus is to 
define FIRS specific error codes now, so this issue will be dissolved.

> referred.  That's one interpretation, but I don't (personally) think it 
> matches up with the reasonably-expected use cases.
> 
> 

Agreed, as you see in my last posting, Andy's proposal will be included 
if Eric won't shout otherwise.

> 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

I get following changes out of this:

The first SHOULD to a MAY  (check supportedControl)

And another Par.:

"If the server sends back no referrals with Relay Bags, or no referrals 
at all, the controlValue MUST be empty"

Did I get you right?

BTW if no referrals at all are sent back, the searchresult will be 
entries in the constructs  SearchResultEntry or the construct 
SearchResultDone instead of the construct SearchResultReference.

> This seems like a really unfortunate and limiting requirement. 

To be honest, I just wanted do evade to analyse the compatibility of all 
existing search controls with this one. I also didn't see any need for 
them. If in future additional FIRS controls will be specified they have 
to take this control into consioderation though.

Would you feel more comfortable, if I changed the "SHOULD NOT" into  "is 
not intended to"

Cheers,

Peter

>>> What you have defined seems to be fairly straight forward.  However, 
>>> I think it needs further refinement per the requirements.
>>
>>
>>
>> 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 

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sun Aug 17 11:31:34 2003

> with this? Or do you see any serious issues?

Using the control data seems fine to me, with one caveat.

> referral, which MUST be ignored by the client, is:

I don't see the value in omitting the referral data in those cases where
the relay bag is also provided. That would introduce additional complexity
for servers (additional logic), mucks with the protocol, and doesn't seem
to provide any real value since we're talking about a protocol extension
that the client has to explicitly support in order to request. Remember
that we have a high probability of changing this as well, and it may be
necessary to switch to a combination of referral data plus control data,
and that will be unnecessarily difficult if servers have changed behavior
to support this draft.

So in summary, I would be happier if the text just said to ignore the
referral data if a relay bag is provided, and did not muck with the rest
of the message contents or protocol.

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Sun Aug 17 23:14:49 2003

I think the other issues have been sorted out one way
or another, leaving:

> Would you feel more comfortable, if I changed the "SHOULD NOT" into  "is 

I believe that's a better formulation, but the root of my concern
is this:  it still seems you're cutting away at the flexibility of
LDAP by asserting things that cannot be used in conjunction with the
FIRS-specific use.

I understand why that is, and personally believe it is the necessary
approach to pitch LDAP at a specific, complex application (I did,
after all, some pretty serious and crude hacking myself for the
TISDAG project :-)

However, this is also one of the reasons that I disbelieve that LDAP
is as conveniently-usable a solution to this problem as some believe.

Leslie.

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Aug 18 09:12:49 2003

Leslie Daigle wrote:
>> To be honest, I just wanted do evade to analyse the compatibility of 
>> all existing search controls with this one. I also didn't see any need 
>> for them. If in future additional FIRS controls will be specified they 
>> have to take this control into consioderation though.
>>
>> Would you feel more comfortable, if I changed the "SHOULD NOT" into  
>> "is not intended to"
> 
> 

I included the respective section in accordance to "Considerations for 
LDAP Extensions" (draft-zeilenga-ldap-ext-04). There are only a few 
search controls specified in RFCs and it is not too much of a hazle to 
analyse their interaction with the FIRS relay bag control. The most 
important that comes into my mind now is Scrolling View Browsing of 
Search Results 
(http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-vlv-09.txt), 
which would not interfere with the relay bag control. I just didn't have 
time tosearch for all search controls and make comments with respect to 
the relay bag control. If people think it is worth while, I will include 
respective language into the draft, but not in the version 02 I intend 
to submit to the list tonight.

> is as conveniently-usable a solution to this problem as some believe.

I don't really understand this argument: only because there are 
additional features in LDAP that might have a mere theoretical impact to 
FIRS features, why does this make LDAP a bad choice. The difference 
between the IRIS and the FIRS approach is that IRIS is more 
encapsulated, thus being more a protocol of its own than an addition to 
an existing protocol, which means using IRIS will give you exactly what 
IRIS specifies, with FIRS you will get what FIRS specifies and 
additional LDAP features that might or might not be usefull for crisp.

Cheers,

Peter

Peter Gietz (CEO)

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Aug 18 09:24:08 2003

Eric,

> of the message contents or protocol.

Isn't that unneccessary redundancy? The client has to go through both 
lists anyway, since referrals without relay bag will only be found in 
the LDAP standard construct.

With your proposal the client has to do the following:

Get the referrels from the LDAPSearchReference construct
for each referral
   check, if the referral is stored in the control as well,
      if so use the relay bag when following the referral
      if not just follow the referral

This means you have to do a search of the referrals found in the relay 
bag data, which might be more costly than in my proposal:

The algorithm for my proposal would be:

Get the referrels from the LDAPSearchReference construct
if first referral equals ldap://
    done with this part of referrals
else
   for each referral
      follow the referral
Get the control data
   for each referral
      follow the referal using the relay bag

The difference in complexity is there but might not mean too much 
performancewise. Thus I don't have very strong feelings, and if the 
group agrees with Eric, I have no big problem following his lines.

Cheers,

Peter

Peter Gietz (CEO)

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Aug 18 09:41:02 2003

catching up with some older postings:

> for this, such as having the control returned as a bind response similar

I'll put MAY instead of SHOULD for now. To integrate this with a FIRS 
version negotiation bind control is ok with me. I need your text on the 
bind control befor I can refer to it.

> encapsulated within an LDAP URL?

I think this is outdated now if relay bags will not be part of an URL.

But again we have here the "LDAP has more predefined features than 
XML"-"problem". Do we want to have the relay bag feature be usable 
inside LDAP URLs, which BTW have the full LDAP search functionality? If 
so we have to define the URL encoding and additional text in a section 
on "Using the relay bag in LDAP-URLS".

I haven't seen such in other search control specs yet and don't really 
think it is neccessary.

Cheers,

Peter

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 10:34:10 2003

>       if not just follow the referral

Actually my suggestion was

  if a relay bag exists
    ignore the referral URL
    use the relay bag data

---

From: leslie at thinkingcat.com (Leslie Daigle)
Date: Mon Aug 18 10:59:32 2003

A brief reply, as I am (really, truly) heading off to the woods
for a few days:

> to submit to the list tonight.

Is searching published RFCs really the universe of controls?  Is
the expectation in the LDAP development community that controls
are only applicable to particular applications, and therefore
there won't be software written that attempts to emit queries

> additional LDAP features that might or might not be usefull for crisp.

I have no problem with there being LDAP features that are not
useful to CRISP.  I am concerned about LDAP features that *won't*
*work* with CRISP.

Once you've defined the FIRS approach to CRISP as being a very
profiled use of LDAP, it becomes harder to use off-the-shelf clients,
servers and even libraries to build FIRS-compliant software.  Each
of these off-the-shelf-components has its own view on the *generic*
LDAP universe that is going to be inconsistent with FIRS' restrictions.

So, IMO, you are back to writing FIRS-specific clients & servers,
and then I don't see the "convenience of LDAP" argument being
applicable.  (And note that my comment was on that argument,
not (yet :-) the LDAP approach specifically).

Leslie.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 11:09:25 2003

> LDAP universe that is going to be inconsistent with FIRS' restrictions.

FWIW, I agree with this and stil think that URL extensions represent the
least disruption since they are known parts of the core spec.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 11:55:09 2003

> least disruption since they are known parts of the core spec.

Throwing 2 and 4k url-encoded binary data in a URL is certainly not what 
they were meant for and it has been known to cause problems with 
software in the past.  Otherwise, I would tend to agree with you.  This 
is why I favor Peter's solution.  As for the differing of opinions on 
the LDAP interactions involved: I honestly do not know.

-andy

---

From: Peter.Gietz at daasi.de (Peter Gietz)
Date: Mon Aug 18 12:13:26 2003

> Actually my suggestion was

I don't see the difference. You have to allign the two referral lists by 
individually checking.

If you start with all referrals in the relay bag, you have to sort of 
mark all referrals already dealt with in the referral list and finally 
follow all referals not marked. In any case you will have slightly more 
complex algorithms than with the other non-redundant solution.

Peter

Peter Gietz (CEO)

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 13:31:52 2003

on 8/18/2003 11:21 AM Andrew Newton wrote:

> software in the past.  Otherwise, I would tend to agree with you.

What if we point out that can happen when the extension is used? EG, if
you issue the control in the request, be prepared for very large URLs.

Since the extension data would only need to be provided in those cases
where the control was used, this would protect the regular clients, would
give us per-referral relay bags, etc.

---

From: richard at shockey.us (Richard Shockey)
Date: Mon Aug 18 13:37:22 2003

>I don't really understand this argument: only because there are additional 
>features in LDAP that might have a mere theoretical impact to FIRS 
>features, why does this make LDAP a bad choice. The difference between the 
>IRIS and the FIRS approach is that IRIS is more encapsulated, thus being 
>more a protocol of its own than an addition to an existing protocol, which 
>means using IRIS will give you exactly what IRIS specifies, with FIRS you 
>will get what FIRS specifies and additional LDAP features that might or 
>might not be usefull for crisp.

I disagree and support once again Leslie's position here ... IRIS IMHO is 
sufficiently extensible to add features in the future as demand requires. 
But to the whole point here I'm prepared to stipulate that both protocols 
can deliver the service and protocol requirements though it seems self 
evident that we are looking at  FIRS specific servers and clients ... or am 
I missing something? That again looks like rough equlivancy.

But IRIS gives me what I want,  which is consistent service architecture 
that will permit me to incorporate EPP as well as IRIS in a unified 
platform, hopefully with a consistent transport, that will not require that 
I set up some different foo thing to cover the CRISP requirements, and is 
in rough alignment with modern XML based query response mechanisms in 
general use ..aka SOAP.

Frankly if there was any real interest I'd petition the IESG to lift the 
prohibition on port 80 (HTTP) application protocols and do both EPP and 
CRISP in SOAP but the chances of that are between zero and absolute zero.

to me this is not a Layer 10 issue its Layer 8

reminder

10. Religious
9.   Political
8. Economic

I want to return to the co-chairs principal requests in this discussion period.

######

During this discussion period, the group is expected to discuss
the pros and cons of the two candidate protocol suites, with
two main aims:  identify any remaining requirements which have
not been met by the protocols; assess and comment on the
suitability of the protocols for the task set out in the requirements
document.

It is explicitly in scope for this discussion to consider the effort
in development and deployment of clients and servers; it is
also explicitly in scope to consider the advantages and disadvantages
of reusing specific technologies (LDAP, XML).

#######

My point is, if it is clear that both protocols meet the requirements and 
both will require new clients and servers than IRIS is the logical choice 
because of it consistency with EPP and the current state of the domain name 
industry.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Mon Aug 18 14:06:12 2003

> you issue the control in the request, be prepared for very large URLs.

We could do this, but it would only be effective if FIRS were being 
designed in isolation of LDAP.  What would happen if a regular LDAP 
client got it's grubby, little hands on one of these unwieldy URL's?

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Aug 18 15:03:55 2003

> client got it's grubby, little hands on one of these unwieldy URL's?

First the easy cases:

  Servers that do not support the control will not advertise it.
  Clients that do not support the control will not request it.

In those cases where the server and client are both willing to use the
extension data, there is the option of having the relay-bag data get
generated on-the-fly, or having the server return a relay-referral instead
of the default (non-relay) referral. Both of those options require some
effort to implement. I'm not sure how difficult this would be.

There is another possibility, which is that a server has been statically
linked with a referral that contains an embedded relay-bag extension, and
is the case you appear to be worried about. I don't know what to do here,
but my feeling is that this falls into the "it hurts when I do this"
problem. "Don't do that".