From Internet-Drafts at ietf.org Mon Aug 11 13:31:11 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon Aug 11 12:31:21 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt Message-ID: <200308111631.MAA22222@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Cross Registry Internet Service Protocol (CRISP) Internet Resource Number Requirements Author(s) : V. Listman Filename : draft-ietf-crisp-internet-resource-number-req-00.txt Pages : 26 Date : 2003-8-10 Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of Internet resource number registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-internet-resource-number-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-internet-resource-number-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Peter.Gietz at daasi.de Wed Aug 13 16:37:56 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Wed Aug 13 09:38:19 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS Message-ID: <3F3A3F34.2070805@daasi.de> 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: peter.gietz@daasi.de 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, . 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, . [FIRS-CORE] Hall, E., "The Federated Internet Registry Service: Core Elements", May 2003, . [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: peter.gietz@daasi.de 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 Wed Aug 13 18:35:06 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Aug 13 17:08:59 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3A3F34.2070805@daasi.de> References: <3F3A3F34.2070805@daasi.de> Message-ID: <3F3AAF0A.9020406@ecotroph.net> Peter, What you have defined seems to be fairly straight forward. However, I think it needs further refinement per the requirements. 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". Finally, a question. Is this one bag per referral or one bag per response/result set? -andy From ehall at ehsco.com Wed Aug 13 19:53:33 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 13 19:53:44 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3A3F34.2070805@daasi.de> References: <3F3A3F34.2070805@daasi.de> Message-ID: <3F3ACF7D.7060500@ehsco.com> on 8/13/2003 8:37 AM Peter Gietz wrote: > please find attached a first version of the promissed Draft on FIRS > Relay Bag. > 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. 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 Thu Aug 14 02:05:28 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 14 02:05:40 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3ACF7D.7060500@ehsco.com> References: <3F3A3F34.2070805@daasi.de> <3F3ACF7D.7060500@ehsco.com> Message-ID: <3F3B26A8.5050305@ehsco.com> on 8/13/2003 6:53 PM Eric A. Hall wrote: > on 8/13/2003 8:37 AM Peter Gietz wrote: >> 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. > > 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. 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Thu Aug 14 16:29:30 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Thu Aug 14 09:29:50 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3AAF0A.9020406@ecotroph.net> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> Message-ID: <3F3B8EBA.2010602@daasi.de> 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 > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From ehall at ehsco.com Thu Aug 14 09:42:22 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 14 09:42:29 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3B8EBA.2010602@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> Message-ID: <3F3B91BE.4000909@ehsco.com> on 8/14/2003 8:29 AM Peter Gietz wrote: > 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. What about providing the bag as a URL extension? Each referral target can have its own bag then. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Thu Aug 14 12:03:38 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 14 10:37:23 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3B8EBA.2010602@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> Message-ID: <3F3BA4CA.30203@ecotroph.net> Peter Gietz wrote: > > 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) > > [...snip...] > 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. 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? > 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. I'm not sure how this is better, but I'll take your word for it. >> 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. 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 Thu Aug 14 19:56:39 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Thu Aug 14 12:57:15 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BA4CA.30203@ecotroph.net> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> Message-ID: <3F3BBF47.4020602@daasi.de> Andrew Newton wrote: > Peter Gietz wrote: > >> >> 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) >> >> > [...snip...] > >> 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. > > > 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? 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. > >> 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. > > > I'm not sure how this is better, but I'll take your word for it. see my explanation above > >>> 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. > > > 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. 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 > > -andy > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From shollenbeck at verisign.com Thu Aug 14 14:05:10 2003 From: shollenbeck at verisign.com (Hollenbeck, Scott) Date: Thu Aug 14 13:05:16 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF82B5D1@vsvapostal8.vasrv.verisign.com> > 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. Peter, If the errorMessage is intended to be human readable, how is the language identified? The ASN.1 definitions in 2251 don't appear to include a means for language tagging. I suppose we could require some sort of identifier as the first part of the string, but is that a good practice? -Scott- From Peter.Gietz at daasi.de Thu Aug 14 20:13:06 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Thu Aug 14 13:13:22 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BA4CA.30203@ecotroph.net> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> Message-ID: <3F3BC322.3090508@daasi.de> Oops, I think I didn't really answer Andy's first question: > > 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? 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) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From ehall at ehsco.com Thu Aug 14 13:22:23 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 14 13:22:36 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BBF47.4020602@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> Message-ID: <3F3BC54F.30407@ehsco.com> on 8/14/2003 11:56 AM Peter Gietz wrote: > I call this Solution I here: > 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 > 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. 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Thu Aug 14 14:56:53 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 14 13:30:37 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BBF47.4020602@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> Message-ID: <3F3BCD65.900@ecotroph.net> Peter Gietz wrote: > > 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 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. > > 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): 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. > > 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. This seems rather limiting. I'd rather see Solution I worked out. -andy From Peter.Gietz at daasi.de Thu Aug 14 20:46:05 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Thu Aug 14 13:46:17 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <5BEA6CDB196A4241B8BE129D309AA4AF82B5D1@vsvapostal8.vasrv.verisign.com> References: <5BEA6CDB196A4241B8BE129D309AA4AF82B5D1@vsvapostal8.vasrv.verisign.com> Message-ID: <3F3BCADD.2020902@daasi.de> Hollenbeck, Scott wrote: >>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. > > > Peter, > > If the errorMessage is intended to be human readable, how is the language > identified? The ASN.1 definitions in 2251 don't appear to include a means > for language tagging. I suppose we could require some sort of identifier as > the first part of the string, but is that a good practice? > > -Scott- LDAP errorMessage just an OCTET STRING with no more syntax. I think the rfc2251 people didn't think that any other language than english would be needed here. This is a field in a complex construct which is part of a network protocol. Clients are free to show the contents of this field to the user. I don't think we need to go further and specify language tags for this. I don't even think we really need to use this field for additional information for the FIRS client. I just was saying that if the group thinks a FIRS specific error information should be included it could be included here. I for one don't think it is needed at all and I don't think it is good practice to add additional syntax to such a field. So if we at all use it, it should be English only (just as the specs are English only), may be just an addition like "(Relay Bag)" Cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From mcs at netscape.com Thu Aug 14 15:06:03 2003 From: mcs at netscape.com (Mark C Smith) Date: Thu Aug 14 14:06:12 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BBF47.4020602@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> Message-ID: <3F3BCF8B.2050208@netscape.com> Peter Gietz wrote: > ... > 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. 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 Thu Aug 14 14:30:09 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 14 14:30:19 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BCF8B.2050208@netscape.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> <3F3BCF8B.2050208@netscape.com> Message-ID: <3F3BD531.5020705@ehsco.com> on 8/14/2003 1:06 PM Mark C Smith wrote: > 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. That took an item off my to-do list. I agree with Andy that defining them is the right thing to do. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From April.Marine at nominum.com Thu Aug 14 12:46:30 2003 From: April.Marine at nominum.com (April Marine) Date: Thu Aug 14 14:46:35 2003 Subject: [Ietf-not43] minutes of CRISP in Vienna Message-ID: <20030814114544.L71867@shell-ng.nominum.com> Crisp WG - IETF 57 - July 16 2003 - Vienna CHAIRS: Ted Hardie April Marine SCRIBE: David Knight <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> Message-ID: <3F3BEC93.6040504@thinkingcat.com> 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@thinkingcat.com ------------------------------------------------------------------- From steven.legg at adacel.com.au Fri Aug 15 13:05:18 2003 From: steven.legg at adacel.com.au (Steven Legg) Date: Thu Aug 14 22:05:25 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3ACF7D.7060500@ehsco.com> Message-ID: <001d01c362d1$ad6af260$a518200a@osmium.mtwav.adacel.com.au> Eric & Peter, Eric A. Hall wrote: > on 8/13/2003 8:37 AM Peter Gietz wrote: > > > please find attached a first version of the promissed Draft on FIRS > > Relay Bag. > > > 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. > > 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. 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 > > 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/ _______________________________________________ Ietf-not43 mailing list Ietf-not43@lists.verisignlabs.com https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From steven.legg at adacel.com.au Fri Aug 15 13:49:17 2003 From: steven.legg at adacel.com.au (Steven Legg) Date: Thu Aug 14 22:49:26 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BBF47.4020602@daasi.de> Message-ID: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> Peter, Peter Gietz wrote: > Andrew Newton wrote: > > > Peter Gietz wrote: > >>> 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. > > > > > > 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. > > 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. 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 > > > 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 > > > > > -andy > > > > -- > ______________________________________________________________ > _________ > > Peter Gietz (CEO) > DAASI International GmbH phone: +49 7071 2970336 > Wilhelmstr. 106 Fax: +49 7071 295114 > D-72074 T?bingen email: peter.gietz@daasi.de > Germany Web: www.daasi.de > > Directory Applications for Advanced Security and Information > Management > ______________________________________________________________ > _________ > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From Peter.Gietz at daasi.de Fri Aug 15 18:59:31 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Fri Aug 15 11:59:54 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BCF8B.2050208@netscape.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> <3F3BCF8B.2050208@netscape.com> Message-ID: <3F3D0363.2040006@daasi.de> 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 >> 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. > > > 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. > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From ehall at ehsco.com Fri Aug 15 12:28:52 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 15 12:28:58 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3D0363.2040006@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BA4CA.30203@ecotroph.net> <3F3BBF47.4020602@daasi.de> <3F3BCF8B.2050208@netscape.com> <3F3D0363.2040006@daasi.de> Message-ID: <3F3D0A44.3040205@ehsco.com> on 8/15/2003 10:59 AM Peter Gietz wrote: > 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? 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Fri Aug 15 19:30:56 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Fri Aug 15 12:31:14 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> References: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> Message-ID: <3F3D0AC0.3070607@daasi.de> 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 >> SEQUENCE OF SEQUENCE { >> ldapurl [0] LDAPURL, >> 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: > > > 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 > > >> >>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 >> >> >>>-andy >>> >> >>-- >>______________________________________________________________ >>_________ >> >>Peter Gietz (CEO) >>DAASI International GmbH phone: +49 7071 2970336 >>Wilhelmstr. 106 Fax: +49 7071 295114 >>D-72074 T?bingen email: peter.gietz@daasi.de >>Germany Web: www.daasi.de >> >>Directory Applications for Advanced Security and Information >>Management >>______________________________________________________________ >>_________ >> >>_______________________________________________ >>Ietf-not43 mailing list >>Ietf-not43@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@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From Peter.Gietz at daasi.de Fri Aug 15 19:53:38 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Fri Aug 15 12:53:58 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3BEC93.6040504@thinkingcat.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> Message-ID: <3F3D1012.8050509@daasi.de> Leslie, Thanks for your comments, which I will comment in line: Leslie Daigle wrote: > > > 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. data inside a protocol element. But anyway, I think consensus is to define FIRS specific error codes now, so this issue will be dissolved. > > 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). Agreed, as you see in my last posting, Andy's proposal will be included if Eric won't shout otherwise. > > 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. 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. > >> 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. 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 > > 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 >>> >> > > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From hardie at qualcomm.com Fri Aug 15 12:35:35 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Fri Aug 15 14:35:44 2003 Subject: [Ietf-not43] Discussion Period In-Reply-To: <20030814114544.L71867@shell-ng.nominum.com> References: <20030814114544.L71867@shell-ng.nominum.com> Message-ID: At 11:46 AM -0700 08/14/2003, April Marine wrote: >From the Minutes > The group agreed, then, on the following next steps; > - the FIRS LDAP extensions doc would be written, completing > the specificaions for both protocol choices > - a 3 week discussion period on the list would take place, > starting at the time the last doc was available > - at the end of that 3 weeks, a call for consensus on the protocol > to be recommended would take place. As you'll note from the text in the minutes, the group agreed to a three week discussion period to begin at the publication of the FIRS LDAP extensions doc. With the publication of that document, the chairs believe that it is appropriate to start that discussion period. It will end three weeks from today, on September 5, 2003. 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). The group has so far managed to avoid making its consideration of these topics in the context of ad hominem attacks or religious debate. Once again, let me thank you all for your professionalism in this regard. I urge you, as well, to continue in that vein through this period of consideration. regards, Ted Hardie April Marine Chairs, CRISP From anewton at ecotroph.net Sat Aug 16 13:17:28 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Sat Aug 16 12:17:41 2003 Subject: [Ietf-not43] issues and questions on FIRS Message-ID: <3F3E5918.3000306@ecotroph.net> I have a couple of questions regarding FIRS, some of them being complaince issues. So that the lines between these issues do not blur, I've broken them out: 1) Naming Syntax of inetDnsDomainSyntax (Section 3 in draft-ietf-crisp-firs-dns). 2) The implementation of 3.1.8. 3) The implementation of 3.2.8. 4) Enumeration of error codes. If I have simply overlooked something, I apologize. Please hit me over the head with the pointers. #1 - Naming Syntax of inetDnsDomainSyntax (Section 3 in draft-ietf-crisp-firs-dns). First, I do not understand why the domain name is being specified as UTF-8. I understand that this is being done in consideration of IDN's, but this is a service about the actually registered domain names. While the UTF-8 equivalences are important, the key for the domain names (the rdn in this case) should be the wire equivalence since this about the registration of these domain names. In other words, I think the key should be the 7-bit ASCII versions that show up in zone files and via dig, etc... and not the 8-bit versions. Second, why are the 8-bit versions escaped? Is there an issue with supporting UTF-8 or Unicode? Just curious. Third, point (a) in that section states how the escaped values must be stored. I don't know if this is valid or not. It could be right, but I'm a little concerned that this is making an assumption about how information is stored in a registry/registrar that just doesn't exist. As in, it MUST be this version of the ASCII escaped UTF-8, when what is stored might actually be the ASCII version and the Unicode version (non-escaped). #2 - The implementation of 3.1.8. There was mention of 3.1.8 in the meeting by Peter, but I do not see it addressed in the drafts. Looking through the jabber logs, Peter proposed various methods to do this. These were defined as: using the bind operation, special policy entries, and server-side extended operations. The use of the bind operation would be overloading of LDAP's authentication mechanism and would likely cause confusion. Plus I do not see how it would be tied to a query. The second option of special-purpose policy entries would probably work, but I think the convention for doing it would be hard to coordinate. The third option of an extended server-side operation I do not understand. It would seem that this would be easily done with another control. As in, the control for "only check permissions" is set and then the query is issued. The control is then "released" after the answer. I don't know. This is just me theorizing. Because LDAP supports a generic query syntax and because service providers are likely to deny all queries not explicitly allowed to prevent data mining, this requirement seems more important for the FIRS proposal. #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. #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. -andy From anewton at ecotroph.net Sun Aug 17 09:47:49 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Sun Aug 17 08:47:56 2003 Subject: [Ietf-not43] the jabber logs Message-ID: <3F3F7975.8050005@ecotroph.net> Since I have received two private emails asking for the Jabber logs, I can only guess that there are other people wondering about them. The relevant jabber logs for this past CRISP meeting are here: http://www.jabber.org/ietf/57/logs/crisp@ietf.jabber.at/2003-07-16.html -andy From ehall at ehsco.com Sun Aug 17 11:31:26 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 17 11:31:34 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3D0AC0.3070607@daasi.de> References: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> <3F3D0AC0.3070607@daasi.de> Message-ID: <3F3F9FCE.5040808@ehsco.com> on 8/15/2003 11:30 AM Peter Gietz wrote: > Eric: You being the only one preferring the URL solution, can you live > with this? Or do you see any serious issues? Using the control data seems fine to me, with one caveat. > 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:/// > " 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Sun Aug 17 14:58:47 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 17 14:58:56 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F3E5918.3000306@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> Message-ID: <3F3FD067.5070902@ehsco.com> on 8/16/2003 11:17 AM Andrew Newton wrote: > #1 - Naming Syntax of inetDnsDomainSyntax (Section 3 in > draft-ietf-crisp-firs-dns). > > First, I do not understand why the domain name is being specified as > UTF-8. I understand that this is being done in consideration of IDN's, > but this is a service about the actually registered domain names. While > the UTF-8 equivalences are important, the key for the domain names (the > rdn in this case) should be the wire equivalence since this about the > registration of these domain names. In other words, I think the key > should be the 7-bit ASCII versions that show up in zone files and via > dig, etc... and not the 8-bit versions. This is a complex issue but the simple answer is that the UTF-8 form will be the preferred form eventually, and it will be simpler in the long run to do UTF-8 now rather than try to accomodate two systems later. Now for the complex answer: 1) I had to choose one. It is likely that clients will exist that only accept seven-bit ASCII for input/output, but it is also likely that there will be clients which will use UTF-8, and it is also likely that some clients will require some other local encoding (eg, UCS-2 on Win32). However, protocol efficiency requires that a single canonical form be used for the message data. The "majority" is going to have to do some kind of conversion no matter what. None of them are significantly cheaper at this exact moment in time. All systems are required to do validation anyway. The cost of local conversion is likely to be relatively minor if it done during the validation process, so there's no significant incentive for any format here either. The wire format for LDAP protocol is UTF-8. Since all LDAP libraries already have to support UTF-8 conversion in order to render LDAP data for local input and output (EG, a company name, or a street address), this means that reusing the existing UTF-8 conversion logic is going to be the cheapest for everybody, since they code would have to exist already. Furthermore, non-trivial comparisons are easier using UTF-8 than ACE. Sub-string searches, soundex searches, etc., any of which may already be implemented in LDAP servers for UTF-8, can be reused pretty easily (or extended partially to allow for things like dot-separators between labels). With something like IDNA, however, the servers would need separate searches for all of these, with the first step being to produce a normalized (UCS) instance. Using UTF-8 as the default makes this stuff much much easier, and this is a very compelling argument. 2) i18n domain names have a canonical representation as UCS characters. The IDNA (ASCII-compatible) representation is just one of many possible UCS-to- encodings for IDNs. The RFCs don't hammer this point strong enough for my tastes, but the references to different "slots" makes this clear: applications can use whatever representation of a canonical IDN they wish, including IDNA but also including any other encoding that the application and/or protocol supports. At the CURRENT TIME, delegation entities are seeing IDNA as the dominant encoding, but this is symptomatic rather than deliberate. For example, at this particular moment DNS delegations and nameserver entries are limited to the hostname syntax (letter-digit-hyphen), but that doesn't mean that alternative encodings cannot be used in the future (I've done a fair bit of work in this space, and my research shows that it is possible, and that the problems are political not technological). Similarly, tools like dig are currently constrained to ASCII output, but there is no reason to believe that folks are not going to be developing IDN-aware tools that perform IDNA-to-local conversions for input and output (this would actually be pretty simple). I mean, there's nothing about dig that prevents this; if we expect stuff like web browsers and email clients to perform conversion, then certainly dig and hostname and the like can too. Cumulatively this means that the use of ASCII-compatible sequences for domain name ~management is an artificat of the CURRENT generation of services and tools, and not a restriction of the technology. In all likelihood, the tools and services will adapt, and then sooner or later we'll have local encodings of the canonical IDNs being the default view, rather than IDNA being the default. 3) If FIRS is chosen, and if the directory expands into the edges of the user-to-user space, the use of LDAP tools to manipulate raw data will become more common. This means that more and more people will eventually be exposed to the protocol representation directly (modulo any wholesale conversion that is needed for their platform). People will want to work with the IDN they bought and/or see, not an illegible encoding of that domain name. I mean, we certainly don't expect that people will *want* to work with IDNA encodings in web pages or email addresses, and I think that the CRISP user community is going to have the same kinds of desires for the ~whois service too. With this in mind, the smart play in terms of adoption is to give them what we already know they're going to want, which is internationalized views. Ask your marketing department if they are selling i18n domain names or encoded representations of i18n domain names, and let that answer apply to all of the other domain-based usages that might be plugged into the directory in the long haul. This is true from the user side too. When I get my first IDN spam, I'm going to want to find details about the "ex?mple.com" domain, not "xn--exmple-cua.com". This is also where points 1 and 2 come together. The default UTF-8 encoding is mandatory in all cases and is therefore guaranteed to be supported, while the tools which are currenlty used to manage domain names suffer from version-specific restrictions and are likely to be eventually upgraded so that they provide i18n representations by default. In other words, the tools are likely to catch up to the user's desires and the capabilities of the technology, rather than being a permanent restriction on the entire system. There is another minor point here, which is that the official IAB policy calls for UTF-8 as the preferred encoding. Since we are implicitly hoping for reuse of common data, this is a strong argument in favor of using UTF-8 for (most) directory data regardless of its underlying definition. So given all of that, using the UTF-8 representation makes the most sense both in the short-term and the long-term. On the other side of the coin is the operator convenience issue. Working with a representation of the domain names which is different from the representation used by the current generation of tools and services is admittedly inconvenient. I don't think this is compelling enough to justify forcing all users and layered applications into working with an illegible encoding format by default. The tools will change eventually. Furthermore, as was already stated, all names have to be validated anyway and doing the conversion as part of the validation process (or more likely, as part of populating the database) is not an egregious expense. > Second, why are the 8-bit versions escaped? Is there an issue with > supporting UTF-8 or Unicode? Just curious. DNS uses raw octet values, but there are no "characters" in the UCS repertoire for referencing octet values. Instead, the octet values would refer to other characters which do not represent the values themselves. For example, a valid DNS domain name (not a hostname) can contain the octet value of 0xC4, and this value must be preserved across all instances of that domain name. In UCS, however, the character code C4 refers to uppercase "A" with diaeresis. In many instances, the UCS character would get normalized to lowercase "a" with diaeresis, which has the character code value of E4. If this value is mapped back to DNS, the original domain name would be destroyed. The escape syntax is provided in order to support octet values in domain names while preventing them from being interpreted as characters (so that they aren't normalized, for example). In theory, this could be avoided by limiting the domain name syntax to hostnames, except for a couple of non-trivial issues. First and foremost, there is not a strict definition of what constitutes a valid IDN, so all values have to be allowed anyway. But if all values are allowed then there's nothing to stop the users from entering octet values either, so an escape mechanism of some kind is mandatory in any event. Secondarily, if we want this service to be useful for domain names in the general case (rather than being limited to the narrow purpose of "delegation management") then we need to design for legitimate domain names rather than attempt to enforce an arbitrary restriction tp the hostname subset. > Third, point (a) in that section states how the escaped values must be > stored. I don't know if this is valid or not. It could be right, but > I'm a little concerned that this is making an assumption about how > information is stored in a registry/registrar that just doesn't exist. > As in, it MUST be this version of the ASCII escaped UTF-8, when what is > stored might actually be the ASCII version and the Unicode version > (non-escaped). As to the first part, domain registrations are limited to the hostname subset by definition (the owner and data domain names of an NS RR have to fit in the hosts.txt database). As such, these rules are really provided for usages beyond "delegation management". EG, the inetDnsRR specs implicitly allow the contents of a zone to be stored in the directory (this isn't the stated goal, but a possibility here is out-of-band zone replication, benefiting from ACLs and the other buttons and knobs), and that some of the domain names in a zone are not likely to conform to the hostname rules and will need to be escaped. Whether or not a registry or registrar chooses to offer an ancillary service will probably determine the extent to which they need to be concerned with this kind of stuff. In the usual case, it won't be necessary since input masking filters should keep the extended syntaxes out of the delegation-specific data. I'm not sure I understand the second part. If you're concerned that I'm dictating underlying database formats, that's not the goal, and I can be clearer in the text if you want. The real need here is for the protocol's view of the database to be consistent. However that happens is an operational concern. > #2 - The implementation of 3.1.8. > > There was mention of 3.1.8 in the meeting by Peter, but I do not see it > addressed in the drafts. Looking through the jabber logs, Peter > proposed various methods to do this. These were defined as: using the > bind operation, special policy entries, and server-side extended operations. Peter and I talked about this some in a private exchange. My suggestion was to leave it as described in section 5.3.3 of firs-core-02 (with "unwillingToPerform" as the generic response) for a later point where we could talk about it in sufficient detail. Since we can add "explicit" restrictions at a later point without breaking the implicit default restrictions, there's no immediate rush. However, if folks want to go ahead and start working on this, we certainly can. I'd like to get a better analysis on the objective first though. Are we wanting to provide something like a counter ("50 out of 50 possible queries already performed, try back tomorrow"), a simple tooManyQueries response, or an array of different responses? Note that there are also some possible synchronization issues here, such as the timezone the server is using. > Because LDAP supports a generic query syntax and because service > providers are likely to deny all queries not explicitly allowed to > prevent data mining, this requirement seems more important for the FIRS > proposal. Yeah, I agree. > #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. > #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. I don't mind detailing new codes where necessary either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie at thinkingcat.com Sun Aug 17 23:56:32 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Sun Aug 17 22:58:09 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F3FD067.5070902@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> Message-ID: <3F404060.4000101@thinkingcat.com> Eric, You and I have already disagreed about this off-list, but: Eric A. Hall wrote: > on 8/16/2003 11:17 AM Andrew Newton wrote: > > >>#1 - Naming Syntax of inetDnsDomainSyntax (Section 3 in >>draft-ietf-crisp-firs-dns). >> >>First, I do not understand why the domain name is being specified as >>UTF-8. I understand that this is being done in consideration of IDN's, >>but this is a service about the actually registered domain names. While >>the UTF-8 equivalences are important, the key for the domain names (the >>rdn in this case) should be the wire equivalence since this about the >>registration of these domain names. In other words, I think the key >>should be the 7-bit ASCII versions that show up in zone files and via >>dig, etc... and not the 8-bit versions. > > > This is a complex issue but the simple answer is that the UTF-8 form will > be the preferred form eventually, and it will be simpler in the long run > to do UTF-8 now rather than try to accomodate two systems later. Now for > the complex answer: I disagree that it is appropriate to be architecting the CRISP system such that UTF-8 is sent in a query that is supposed to be about domain names. Today, domain names are still defined as ascii, and the requirements talk about the ability to lookup domain names, not "internationalized domain names". For the very reasons you cite below, the client has to do the normalization, and for DNS that means drilling down to the ascii-encoding. If this working group believes it is important to be able to do queries on the internationlized form of domain names, then that should be added to the requirements documents. Otherwise, IMO, we wind up in a world of hurt. Leslie. > > 1) I had to choose one. It is likely that clients will exist that only > accept seven-bit ASCII for input/output, but it is also likely that there > will be clients which will use UTF-8, and it is also likely that some > clients will require some other local encoding (eg, UCS-2 on Win32). > However, protocol efficiency requires that a single canonical form be used > for the message data. The "majority" is going to have to do some kind of > conversion no matter what. None of them are significantly cheaper at this > exact moment in time. > > All systems are required to do validation anyway. The cost of local > conversion is likely to be relatively minor if it done during the > validation process, so there's no significant incentive for any format > here either. > > The wire format for LDAP protocol is UTF-8. Since all LDAP libraries > already have to support UTF-8 conversion in order to render LDAP data for > local input and output (EG, a company name, or a street address), this > means that reusing the existing UTF-8 conversion logic is going to be the > cheapest for everybody, since they code would have to exist already. > > Furthermore, non-trivial comparisons are easier using UTF-8 than ACE. > Sub-string searches, soundex searches, etc., any of which may already be > implemented in LDAP servers for UTF-8, can be reused pretty easily (or > extended partially to allow for things like dot-separators between > labels). With something like IDNA, however, the servers would need > separate searches for all of these, with the first step being to produce a > normalized (UCS) instance. Using UTF-8 as the default makes this stuff > much much easier, and this is a very compelling argument. > > 2) i18n domain names have a canonical representation as UCS characters. > The IDNA (ASCII-compatible) representation is just one of many possible > UCS-to- encodings for IDNs. The RFCs don't hammer this point > strong enough for my tastes, but the references to different "slots" makes > this clear: applications can use whatever representation of a canonical > IDN they wish, including IDNA but also including any other encoding that > the application and/or protocol supports. > > At the CURRENT TIME, delegation entities are seeing IDNA as the dominant > encoding, but this is symptomatic rather than deliberate. For example, at > this particular moment DNS delegations and nameserver entries are limited > to the hostname syntax (letter-digit-hyphen), but that doesn't mean that > alternative encodings cannot be used in the future (I've done a fair bit > of work in this space, and my research shows that it is possible, and that > the problems are political not technological). Similarly, tools like dig > are currently constrained to ASCII output, but there is no reason to > believe that folks are not going to be developing IDN-aware tools that > perform IDNA-to-local conversions for input and output (this would > actually be pretty simple). I mean, there's nothing about dig that > prevents this; if we expect stuff like web browsers and email clients to > perform conversion, then certainly dig and hostname and the like can too. > > Cumulatively this means that the use of ASCII-compatible sequences for > domain name ~management is an artificat of the CURRENT generation of > services and tools, and not a restriction of the technology. In all > likelihood, the tools and services will adapt, and then sooner or later > we'll have local encodings of the canonical IDNs being the default view, > rather than IDNA being the default. > > 3) If FIRS is chosen, and if the directory expands into the edges of the > user-to-user space, the use of LDAP tools to manipulate raw data will > become more common. This means that more and more people will eventually > be exposed to the protocol representation directly (modulo any wholesale > conversion that is needed for their platform). > > People will want to work with the IDN they bought and/or see, not an > illegible encoding of that domain name. I mean, we certainly don't expect > that people will *want* to work with IDNA encodings in web pages or email > addresses, and I think that the CRISP user community is going to have the > same kinds of desires for the ~whois service too. With this in mind, the > smart play in terms of adoption is to give them what we already know > they're going to want, which is internationalized views. Ask your > marketing department if they are selling i18n domain names or encoded > representations of i18n domain names, and let that answer apply to all of > the other domain-based usages that might be plugged into the directory in > the long haul. > > This is true from the user side too. When I get my first IDN spam, I'm > going to want to find details about the "ex?mple.com" domain, not > "xn--exmple-cua.com". > > This is also where points 1 and 2 come together. The default UTF-8 > encoding is mandatory in all cases and is therefore guaranteed to be > supported, while the tools which are currenlty used to manage domain names > suffer from version-specific restrictions and are likely to be eventually > upgraded so that they provide i18n representations by default. In other > words, the tools are likely to catch up to the user's desires and the > capabilities of the technology, rather than being a permanent restriction > on the entire system. > > There is another minor point here, which is that the official IAB policy > calls for UTF-8 as the preferred encoding. Since we are implicitly hoping > for reuse of common data, this is a strong argument in favor of using > UTF-8 for (most) directory data regardless of its underlying definition. > > So given all of that, using the UTF-8 representation makes the most sense > both in the short-term and the long-term. > > On the other side of the coin is the operator convenience issue. Working > with a representation of the domain names which is different from the > representation used by the current generation of tools and services is > admittedly inconvenient. I don't think this is compelling enough to > justify forcing all users and layered applications into working with an > illegible encoding format by default. The tools will change eventually. > Furthermore, as was already stated, all names have to be validated anyway > and doing the conversion as part of the validation process (or more > likely, as part of populating the database) is not an egregious expense. > > >>Second, why are the 8-bit versions escaped? Is there an issue with >>supporting UTF-8 or Unicode? Just curious. > > > DNS uses raw octet values, but there are no "characters" in the UCS > repertoire for referencing octet values. Instead, the octet values would > refer to other characters which do not represent the values themselves. > > For example, a valid DNS domain name (not a hostname) can contain the > octet value of 0xC4, and this value must be preserved across all instances > of that domain name. In UCS, however, the character code C4 refers to > uppercase "A" with diaeresis. In many instances, the UCS character would > get normalized to lowercase "a" with diaeresis, which has the character > code value of E4. If this value is mapped back to DNS, the original domain > name would be destroyed. > > The escape syntax is provided in order to support octet values in domain > names while preventing them from being interpreted as characters (so that > they aren't normalized, for example). > > In theory, this could be avoided by limiting the domain name syntax to > hostnames, except for a couple of non-trivial issues. First and foremost, > there is not a strict definition of what constitutes a valid IDN, so all > values have to be allowed anyway. But if all values are allowed then > there's nothing to stop the users from entering octet values either, so an > escape mechanism of some kind is mandatory in any event. Secondarily, if > we want this service to be useful for domain names in the general case > (rather than being limited to the narrow purpose of "delegation > management") then we need to design for legitimate domain names rather > than attempt to enforce an arbitrary restriction tp the hostname subset. > > >>Third, point (a) in that section states how the escaped values must be >>stored. I don't know if this is valid or not. It could be right, but >>I'm a little concerned that this is making an assumption about how >>information is stored in a registry/registrar that just doesn't exist. >>As in, it MUST be this version of the ASCII escaped UTF-8, when what is >>stored might actually be the ASCII version and the Unicode version >>(non-escaped). > > > As to the first part, domain registrations are limited to the hostname > subset by definition (the owner and data domain names of an NS RR have to > fit in the hosts.txt database). As such, these rules are really provided > for usages beyond "delegation management". > > EG, the inetDnsRR specs implicitly allow the contents of a zone to be > stored in the directory (this isn't the stated goal, but a possibility > here is out-of-band zone replication, benefiting from ACLs and the other > buttons and knobs), and that some of the domain names in a zone are not > likely to conform to the hostname rules and will need to be escaped. > Whether or not a registry or registrar chooses to offer an ancillary > service will probably determine the extent to which they need to be > concerned with this kind of stuff. In the usual case, it won't be > necessary since input masking filters should keep the extended syntaxes > out of the delegation-specific data. > > I'm not sure I understand the second part. If you're concerned that I'm > dictating underlying database formats, that's not the goal, and I can be > clearer in the text if you want. The real need here is for the protocol's > view of the database to be consistent. However that happens is an > operational concern. > > >>#2 - The implementation of 3.1.8. >> >>There was mention of 3.1.8 in the meeting by Peter, but I do not see it >>addressed in the drafts. Looking through the jabber logs, Peter >>proposed various methods to do this. These were defined as: using the >>bind operation, special policy entries, and server-side extended operations. > > > Peter and I talked about this some in a private exchange. My suggestion > was to leave it as described in section 5.3.3 of firs-core-02 (with > "unwillingToPerform" as the generic response) for a later point where we > could talk about it in sufficient detail. Since we can add "explicit" > restrictions at a later point without breaking the implicit default > restrictions, there's no immediate rush. > > However, if folks want to go ahead and start working on this, we certainly > can. I'd like to get a better analysis on the objective first though. Are > we wanting to provide something like a counter ("50 out of 50 possible > queries already performed, try back tomorrow"), a simple tooManyQueries > response, or an array of different responses? > > Note that there are also some possible synchronization issues here, such > as the timezone the server is using. > > >>Because LDAP supports a generic query syntax and because service >>providers are likely to deny all queries not explicitly allowed to >>prevent data mining, this requirement seems more important for the FIRS >>proposal. > > > Yeah, I agree. > > >>#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. > > >>#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. > > I don't mind detailing new codes where necessary either. > From leslie at thinkingcat.com Mon Aug 18 00:13:14 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Sun Aug 17 23:14:49 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3D1012.8050509@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> Message-ID: <3F40444A.5040209@thinkingcat.com> I think the other issues have been sorted out one way or another, leaving: Peter Gietz wrote: >>> 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. > > > 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 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 ehall at ehsco.com Sun Aug 17 23:42:57 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 17 23:43:04 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F404060.4000101@thinkingcat.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F404060.4000101@thinkingcat.com> Message-ID: <3F404B41.1010204@ehsco.com> on 8/17/2003 9:56 PM Leslie Daigle wrote: > I disagree that it is appropriate to be architecting the CRISP > system such that UTF-8 is sent in a query that is supposed to be > about domain names. > > Today, domain names are still defined as ascii, and the > requirements talk about the ability to lookup domain names, not > "internationalized domain names". These are valid concerns but at the same time, it's important to recognize that it will be much more difficult to graft deep i18n support onto the service later than to build it in up-front. Slapping a facade on it later isn't going to hold up when everybody is poking around at the database innards (and this becomes more likely as more services get layered on), while changing the database contents won't be an option. Much better to bite the bullet now and build in the deep support from the start. That's my vote anyway. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Mon Aug 18 15:05:37 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 08:05:51 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F3E5918.3000306@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> Message-ID: <3F40C111.5060304@daasi.de> Some comments on #2, #3, and #4: Andrew Newton wrote: > I have a couple of questions regarding FIRS, some of them being > complaince issues. > So that the lines between these issues do not blur, I've broken them out: > > 1) Naming Syntax of inetDnsDomainSyntax (Section 3 in > draft-ietf-crisp-firs-dns). > 2) The implementation of 3.1.8. > 3) The implementation of 3.2.8. > 4) Enumeration of error codes. > > If I have simply overlooked something, I apologize. Please hit me over > the head with the pointers. > [...] > > #2 - The implementation of 3.1.8. > > There was mention of 3.1.8 in the meeting by Peter, but I do not see it > addressed in the drafts. Looking through the jabber logs, Peter > proposed various methods to do this. These were defined as: using the > bind operation, special policy entries, and server-side extended > operations. > The first proposed solution (I): > The use of the bind operation would be overloading of LDAP's > authentication mechanism and would likely cause confusion. This would be a control to the bind operation, which could do FIRS version negotiation and be used for the server to tell the client what kind of data it can expect to retrieve. > Plus I do > not see how it would be tied to a query. Yes right, this would be more general information, not information about a special query. But to be honest, I don't understand this requirement in this caser. What is the difference between the two following client server dialogues? 1.) Without feature 3.1.8: client binds to server client makes request server sends back I won't answer you this request 2.) With feature: client binds to server client asks server: will you answer this request server answers no The only difference IMO is that in cas 1 you don't need an additional circle in the case the server wants to answer the request. Thus I think for per request you don't need to check acls. What makes more sence is to generaly ask "will you provide me with this sort of data?" and this could be checked inside an additional control to the bindrequest and response. The second proposed solution (II): > The second option of > special-purpose policy entries would probably work, but I think the > convention for doing it would be hard to coordinate. Again this solution would only give back general rules about which client can expect which kind of data. Such policy could of course be places at many places in the Directory Information Tree using the concept of subtree subentry and thus be less general than solution I. The client could check e.g. the policy of a subtree of the whole tree the server has as naming context, and evaluate itself if it can expect to retrieve data or not. I once wrote a schema for LDAP-crawler policy and would be willing to write something similiar for FIRS. Solution III: > The third option > of an extended server-side operation I do not understand. There are two similiar LDAP protocol extension mechanisms, one is the control, which enhances existing operations, like the control defined for enhancing the search operation with the relay bag feature. The second LDAP protocol extension mechanisms is called extended operation, which is a total new operation with request and response defintions. Since check-ACLs would be a new operation I think, it is better to have an extended operation instead of another search control. extended operations have to be understood by client and server. I am not sure how the "server-side" came into the jabber logs. > > It would seem that this would be easily done with another control. As > in, the control for "only check permissions" is set and then the query > is issued. The control is then "released" after the answer. I don't > know. This is just me theorizing. are you talking about a search extending controll here? > > Because LDAP supports a generic query syntax and because service > providers are likely to deny all queries not explicitly allowed to > prevent data mining, this requirement seems more important for the FIRS > proposal. I still think that a per request granular implementation of this feature is rather useless (see my remarks to solution I) > > #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. Isn't this addressed in section 5.1.4. of http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-02.txt, where three standard LDAP error codes are used, as proposed by me in the meeting? > > #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. My current understanding is that we only need new error codes for the relay bag stuff. All other FIRS errors can be mapped by standard LDAP error codes. That is what Eric said and I have no objections to this. Of course it may be a good thing to have an appendix in firs-core ore firs-arch listing all error codes used in FIRS, but this will produce dependencies with the relay bag draft... Cheers, Peter > > -andy > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@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@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From Peter.Gietz at daasi.de Mon Aug 18 16:12:33 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 09:12:49 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40444A.5040209@thinkingcat.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> Message-ID: <3F40D0C1.8040200@daasi.de> Leslie Daigle wrote: > > I think the other issues have been sorted out one way > or another, leaving: > > Peter Gietz wrote: > >>>> 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. >> >> >> >> 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 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 :-) 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. > > 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. 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 > > Leslie. > > > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From Peter.Gietz at daasi.de Mon Aug 18 16:23:58 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 09:24:08 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3F9FCE.5040808@ehsco.com> References: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> <3F3D0AC0.3070607@daasi.de> <3F3F9FCE.5040808@ehsco.com> Message-ID: <3F40D36E.6030903@daasi.de> Eric, Eric A. Hall wrote: > on 8/15/2003 11:30 AM Peter Gietz wrote: > > >>Eric: You being the only one preferring the URL solution, can you live >>with this? Or do you see any serious issues? > > > Using the control data seems fine to me, with one caveat. > > >>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:/// >>" > > > 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. > 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) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From Peter.Gietz at daasi.de Mon Aug 18 16:40:51 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 09:41:02 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F3ACF7D.7060500@ehsco.com> References: <3F3A3F34.2070805@daasi.de> <3F3ACF7D.7060500@ehsco.com> Message-ID: <3F40D763.7070807@daasi.de> catching up with some older postings: Eric A. Hall wrote: > on 8/13/2003 8:37 AM Peter Gietz wrote: > > >>please find attached a first version of the promissed Draft on FIRS >>Relay Bag. > > >> 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. > > > 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. 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. > > Also, does there need to be any wording on how the data should be > 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) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From ehall at ehsco.com Mon Aug 18 10:34:03 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 10:34:10 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40D36E.6030903@daasi.de> References: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> <3F3D0AC0.3070607@daasi.de> <3F3F9FCE.5040808@ehsco.com> <3F40D36E.6030903@daasi.de> Message-ID: <3F40E3DB.4010408@ehsco.com> on 8/18/2003 8:23 AM Peter Gietz wrote: > 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 Actually my suggestion was if a relay bag exists ignore the referral URL use the relay bag data -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie at thinkingcat.com Mon Aug 18 11:47:08 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Mon Aug 18 10:48:43 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F404B41.1010204@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F404060.4000101@thinkingcat.com> <3F404B41.1010204@ehsco.com> Message-ID: <3F40E6EC.9020107@thinkingcat.com> And I don't think we know (precisely) which bullet we're talking about biting. Which is why it makes sense to me to split it into 2 separate types of query. Note that, were I designing software for an enterprise product, I would probably choose differently. But this is Internet infrastructure -- which changes slowly, and where operators of such services want precision in their requirements because they have systems to run at 5 9's. Leslie. Eric A. Hall wrote: > on 8/17/2003 9:56 PM Leslie Daigle wrote: > > >>I disagree that it is appropriate to be architecting the CRISP >>system such that UTF-8 is sent in a query that is supposed to be >>about domain names. >> >>Today, domain names are still defined as ascii, and the >>requirements talk about the ability to lookup domain names, not >>"internationalized domain names". > > > These are valid concerns but at the same time, it's important to recognize > that it will be much more difficult to graft deep i18n support onto the > service later than to build it in up-front. Slapping a facade on it later > isn't going to hold up when everybody is poking around at the database > innards (and this becomes more likely as more services get layered on), > while changing the database contents won't be an option. Much better to > bite the bullet now and build in the deep support from the start. That's > my vote anyway. > From leslie at thinkingcat.com Mon Aug 18 11:57:57 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Mon Aug 18 10:59:32 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40D0C1.8040200@daasi.de> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> Message-ID: <3F40E975.5050309@thinkingcat.com> A brief reply, as I am (really, truly) heading off to the woods for a few days: Peter Gietz wrote: > 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 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 with controls you intend to disallow? See next comment: > >> >> 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. > > > 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 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 Mon Aug 18 11:01:25 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 11:01:31 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F40E6EC.9020107@thinkingcat.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F404060.4000101@thinkingcat.com> <3F404B41.1010204@ehsco.com> <3F40E6EC.9020107@thinkingcat.com> Message-ID: <3F40EA45.4050808@ehsco.com> on 8/18/2003 9:47 AM Leslie Daigle wrote: > And I don't think we know (precisely) which bullet we're > talking about biting. I personally went back and forth on this subject for many months, being unable to decide if the large list of work items would produce a benefit that was worth the effort (Andy can tell you how late I was). But in the end there is the unavoidable conclusion that it is just easier for everybody to do the work up front. As complex as the rules appear to be (although they aren't any more complex than the existing DNS and LDAP rules, at least in terms of escapes), it is going to be much much more difficult to treat the identifiers differently while still providing the benefits that we know people want. > Which is why it makes sense to me to split it into 2 separate > types of query. It's "two sets of queries". You need separate internationalized queries for inetDnsDomainMatch, but you also need separate queries for inetDnsDomainEqualityMatch, inetDnsDomainSoundexMatch, and all of the other queries that make LDAP useful as a CRISP repository in general. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 11:09:18 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 11:09:25 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40E975.5050309@thinkingcat.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> <3F40E975.5050309@thinkingcat.com> Message-ID: <3F40EC1E.1020809@ehsco.com> on 8/18/2003 9:57 AM Leslie Daigle wrote: > 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. FWIW, I agree with this and stil think that URL extensions represent the least disruption since they are known parts of the core spec. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Mon Aug 18 13:14:21 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 11:47:40 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F3FD067.5070902@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> Message-ID: <3F40FB5D.7060806@ecotroph.net> My comments are in-line: (I now regret not starting a seperate thread for each item) Eric A. Hall wrote: > >>#1 - Naming Syntax of inetDnsDomainSyntax (Section 3 in >>draft-ietf-crisp-firs-dns). >> >>First, I do not understand why the domain name is being specified as >>UTF-8. I understand that this is being done in consideration of IDN's, >>but this is a service about the actually registered domain names. While >>the UTF-8 equivalences are important, the key for the domain names (the >>rdn in this case) should be the wire equivalence since this about the >>registration of these domain names. In other words, I think the key >>should be the 7-bit ASCII versions that show up in zone files and via >>dig, etc... and not the 8-bit versions. > > > This is a complex issue but the simple answer is that the UTF-8 form will > be the preferred form eventually, and it will be simpler in the long run > to do UTF-8 now rather than try to accomodate two systems later. Now for > the complex answer: [...snip...] > > As to the first part, domain registrations are limited to the hostname > subset by definition (the owner and data domain names of an NS RR have to > fit in the hosts.txt database). As such, these rules are really provided > for usages beyond "delegation management". > My concern is that the xn-- 7-bit versions of the domains are the things that will be flying around the Internet and people will need to refer to them, even if some of their software does the Unicode conversion. The fact is, the xn-- 7-bit version is what IS going to be in the zone files, and for troubleshooting purposes we need to be able to refer to them. I have no problem with the protocol also allowing a user to specify the name in Unicode. IRIS takes care of both cases. I just think it is important to also specify it for people mucking around in the 7-bit world. >>#2 - The implementation of 3.1.8. >> >>There was mention of 3.1.8 in the meeting by Peter, but I do not see it >>addressed in the drafts. Looking through the jabber logs, Peter >>proposed various methods to do this. These were defined as: using the >>bind operation, special policy entries, and server-side extended operations. > > > However, if folks want to go ahead and start working on this, we certainly > can. I'd like to get a better analysis on the objective first though. Are > we wanting to provide something like a counter ("50 out of 50 possible > queries already performed, try back tomorrow"), a simple tooManyQueries > response, or an array of different responses? I don't quite follow this. It sounds like you are talking about the first part of 3.2.5., which is something that is already defined in stock LDAP (I think). >>#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@example.com Phone: 555-1212 Contact: lisa-543 Name: Lisa Smith Phone: 121-5555 Contact: charles-777 Name: Charles Taylor Email: president@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!) >>#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. 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 From anewton at ecotroph.net Mon Aug 18 13:21:54 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 11:55:09 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40EC1E.1020809@ehsco.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> <3F40E975.5050309@thinkingcat.com> <3F40EC1E.1020809@ehsco.com> Message-ID: <3F40FD22.6000807@ecotroph.net> Eric A. Hall wrote: > on 8/18/2003 9:57 AM Leslie Daigle wrote: > > >>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. > > > FWIW, I agree with this and stil think that URL extensions represent the > 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 anewton at ecotroph.net Mon Aug 18 13:31:48 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 12:05:02 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F40C111.5060304@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F40C111.5060304@daasi.de> Message-ID: <3F40FF74.1060703@ecotroph.net> Peter, please see my reply to Eric regarding #3 and #4. I think they speak to your points. As for #2: Peter Gietz wrote: >> > Solution III: > > The third option > >> of an extended server-side operation I do not understand. > > There are two similiar LDAP protocol extension mechanisms, one is the > control, which enhances existing operations, like the control defined > for enhancing the search operation with the relay bag feature. > > The second LDAP protocol extension mechanisms is called extended > operation, which is a total new operation with request and response > defintions. Since check-ACLs would be a new operation I think, it is > better to have an extended operation instead of another search control. > > extended operations have to be understood by client and server. I am not > sure how the "server-side" came into the jabber logs. > >> >> It would seem that this would be easily done with another control. As >> in, the control for "only check permissions" is set and then the query >> is issued. The control is then "released" after the answer. I don't >> know. This is just me theorizing. > > > are you talking about a search extending controll here? I believe I am thinking of the former, but it could probably be done using either. I assume by your description that a search extending control (the first protocol mechism you mention) is easier or better, so let's go with that. Could it be done that way? -andy From Peter.Gietz at daasi.de Mon Aug 18 19:13:16 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 12:13:26 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40E3DB.4010408@ehsco.com> References: <001f01c362d7$d2c36fa0$a518200a@osmium.mtwav.adacel.com.au> <3F3D0AC0.3070607@daasi.de> <3F3F9FCE.5040808@ehsco.com> <3F40D36E.6030903@daasi.de> <3F40E3DB.4010408@ehsco.com> Message-ID: <3F40FB1C.9040607@daasi.de> Eric A. Hall wrote: > on 8/18/2003 8:23 AM Peter Gietz wrote: > > > >>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 > > > Actually my suggestion was > > if a relay bag exists > ignore the referral URL > use the relay bag data > 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) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From Peter.Gietz at daasi.de Mon Aug 18 19:19:30 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 12:19:48 2003 Subject: Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS] In-Reply-To: <3F40FB5D.7060806@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> Message-ID: <3F40FC92.4090709@daasi.de> 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@example.com > Phone: 555-1212 > > Contact: lisa-543 > Name: Lisa Smith > Phone: 121-5555 > > Contact: charles-777 > Name: Charles Taylor > Email: president@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@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@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From anewton at ecotroph.net Mon Aug 18 13:58:34 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 12:31:49 2003 Subject: Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS] In-Reply-To: <3F40FC92.4090709@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F40FC92.4090709@daasi.de> Message-ID: <3F4105BA.2050904@ecotroph.net> Peter Gietz wrote: > >> >> 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@example.com >> Phone: 555-1212 >> >> Contact: lisa-543 >> Name: Lisa Smith >> Phone: 121-5555 >> >> Contact: charles-777 >> Name: Charles Taylor >> Email: president@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 When you define them, is it possible that they are accompanied by a list of dn's + attribute names so that the client can correlate which attributes in which entries are being redacted? (see the first question.) Or am I making a false assumption? Can an error code be returned per entry or attribute? On other possible solution is to have the server return a special entry (perhaps last) being a list of dn+attribute name / reason pairs. Again, just theorizing here. -andy From Peter.Gietz at daasi.de Mon Aug 18 20:10:57 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 18 13:11:16 2003 Subject: Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS] In-Reply-To: <3F4105BA.2050904@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F40FC92.4090709@daasi.de> <3F4105BA.2050904@ecotroph.net> Message-ID: <3F4108A1.4060903@daasi.de> Andrew Newton wrote: > Peter Gietz wrote: > >> >>> >>> 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@example.com >>> Phone: 555-1212 >>> >>> Contact: lisa-543 >>> Name: Lisa Smith >>> Phone: 121-5555 >>> >>> Contact: charles-777 >>> Name: Charles Taylor >>> Email: president@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 > > > When you define them, is it possible that they are accompanied by a list > of dn's + attribute names so that the client can correlate which > attributes in which entries are being redacted? (see the first question.) > > Or am I making a false assumption? Can an error code be returned per > entry or attribute? No, you can give back a result set and one error code for he whole request. > > On other possible solution is to have the server return a special entry > (perhaps last) being a list of dn+attribute name / reason pairs. Again, > just theorizing here. This could be done, but would be very FIRS specific and we woulld have to define schema for that. I don't think we really want to go this direction. wouldn't it be enough to tell that more entries would have been returned if authentication were different? That would be indicated by the error code authorizationLimitExceeded. Peter > > -andy > > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From ehall at ehsco.com Mon Aug 18 13:31:46 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 13:31:52 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40FD22.6000807@ecotroph.net> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> <3F40E975.5050309@thinkingcat.com> <3F40EC1E.1020809@ehsco.com> <3F40FD22.6000807@ecotroph.net> Message-ID: <3F410D82.9010404@ehsco.com> on 8/18/2003 11:21 AM Andrew Newton wrote: > 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. 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. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From richard at shockey.us Mon Aug 18 14:36:59 2003 From: richard at shockey.us (Richard Shockey) Date: Mon Aug 18 13:37:22 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F40D0C1.8040200@daasi.de> References: <3F40444A.5040209@thinkingcat.com> <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> Message-ID: <5.2.0.9.2.20030818100806.060dce88@shockey.us> > > >>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. > >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. >Cheers, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From anewton at ecotroph.net Mon Aug 18 15:32:58 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 14:06:12 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F410D82.9010404@ehsco.com> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> <3F40E975.5050309@thinkingcat.com> <3F40EC1E.1020809@ehsco.com> <3F40FD22.6000807@ecotroph.net> <3F410D82.9010404@ehsco.com> Message-ID: <3F411BDA.8060004@ecotroph.net> Eric A. Hall wrote: > on 8/18/2003 11:21 AM Andrew Newton wrote: > > >>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. > > > 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. 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 anewton at ecotroph.net Mon Aug 18 15:45:51 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 14:19:04 2003 Subject: Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS] In-Reply-To: <3F4108A1.4060903@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F40FC92.4090709@daasi.de> <3F4105BA.2050904@ecotroph.net> <3F4108A1.4060903@daasi.de> Message-ID: <3F411EDF.50405@ecotroph.net> Peter Gietz wrote: > >>>> >>>> Let's say I submit a query and get back the following: >>>> >>>> START RESPONSE >>>> >>>> Contact: bob-192 >>>> Name: Bob Smurd >>>> Email: bob@example.com >>>> Phone: 555-1212 >>>> >>>> Contact: lisa-543 >>>> Name: Lisa Smith >>>> Phone: 121-5555 >>>> >>>> Contact: charles-777 >>>> Name: Charles Taylor >>>> Email: president@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!) > > wouldn't it be enough to tell that more entries would have been returned > if authentication were different? That would be indicated by the error > code authorizationLimitExceeded. Well, I'm not sure it is useful otherwise given my example. Besides, 3.2.8 talks about these errors with respect to values not result sets. -andy From davidb at verisignlabs.com Mon Aug 18 15:17:14 2003 From: davidb at verisignlabs.com (David Blacka) Date: Mon Aug 18 14:21:00 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <200308111631.MAA22222@ietf.org> References: <200308111631.MAA22222@ietf.org> Message-ID: <200308181417.14060.davidb@verisignlabs.com> Ginny, I am a little confused by part of the requirements in your draft: 3.2.2.1 Protocol Requirement The protocol MUST contain the following search functions: 1. IPv4 address search given one or more contiguous IP address numbers. This search SHOULD allow for both exact matching and nested matching. 2. IPv6 address search given one or more contiguous IP address numbers. This search SHOULD allow for both exact matching and nested matching. These searches seem sort of vague to me. Maybe it is a terminology problem. When doing a IP address search, what are you looking for? Supernets or subnets? All supernets or all subnets? Is an "exact match" the closest enclosing supernet and a "nested match" all supernets? Wouldn't we want the ability to search for both supernets and subnets? Also, I would sort of think that searching for network blocks (IPv4 or IPv6) would be one of the most basic points of the service, so should the ability to search for them be a SHOULD? -- David Blacka Sr. Engineer Verisign Applied Research From davidb at verisignlabs.com Mon Aug 18 15:26:06 2003 From: davidb at verisignlabs.com (David Blacka) Date: Mon Aug 18 14:29:53 2003 Subject: Requirement 3.2.8. [was: Re: [Ietf-not43] issues and questions on FIRS] In-Reply-To: <3F4108A1.4060903@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F4105BA.2050904@ecotroph.net> <3F4108A1.4060903@daasi.de> Message-ID: <200308181426.06109.davidb@verisignlabs.com> On Monday 18 August 2003 01:10 pm, Peter Gietz wrote: > wouldn't it be enough to tell that more entries would have been returned > if authentication were different? That would be indicated by the error > code authorizationLimitExceeded. Maybe I missed something here, but I thought Andy's question was about various *attributes* being removed (say, for privacy reasons). How, in FIRS, is the client able to tell which attributes were removed and why (why being either "insufficient authorization", "private", or no explanation according to 3.2.8.1)? -- David Blacka Sr. Engineer Verisign Applied Research From anewton at ecotroph.net Mon Aug 18 16:16:44 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 14:49:58 2003 Subject: [Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers Message-ID: <3F41261C.4060908@ecotroph.net> #5 inetDnsDomain attributes for contacts and nameservers At first I thought the attributes for contacts and nameservers in inetDnsDomain were LDAP url's, but after reading the example it would seem they are just strings. Correct me if I'm wrong (reading the OID numbers starts to get confusing for me). If they aren't LDAP URL's, then what is a client to do with them for dereferencing? Are these LDAP aliases? The OID number seems to define their syntax as that of inetDnsDomain (also confusing since an email address is not a domain name). If the client gets an inetDnsDomain entry, what is it to do to follow the information for a nameserver? Does it requiry the same server? Does it start the whole query bootstrapping process again? Either I just don't get it (entirely probable at this point), or these should be LDAP URL's, or there needs to be text defining how a client is to further dereference this information. -andy From ehall at ehsco.com Mon Aug 18 14:50:50 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 14:50:58 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F40FB5D.7060806@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> Message-ID: <3F41200A.7030609@ehsco.com> on 8/18/2003 11:14 AM Andrew Newton wrote: > My concern is that the xn-- 7-bit versions of the domains are the > things that will be flying around the Internet and people will need to > refer to them, even if some of their software does the Unicode > conversion. The fact is, the xn-- 7-bit version is what IS going to be > in the zone files, and for troubleshooting purposes we need to be able > to refer to them. Not to belabor this particular point, but rather the issue as a whole... The format of a domain name in any particular zone file is going to be determined by the feature set of the server in use. Somebody is eventually going to figure out that administrators in ~Japan would prefer to have their zone files use ~Katakana instead of ASCII. There is absolutely no reason that a server cannot convert the data into ACE when the zone data is loaded into memory (exceptions exist for products that ignore the DNS in-band replication service in favor of things like rsynch, but those are also marketing choices). So again all of this stuff is symptomatic of the current state of the products and not a deliberate restriction. We should be planning for where we think we'll be (or where we want to be) in 10 years, not where the last 20 years forced the current offerings to be. > I have no problem with the protocol also allowing a user to specify the > name in Unicode. IRIS takes care of both cases. I just think it is > important to also specify it for people mucking around in the 7-bit > world. I'm not sure we're on the same wavelength. What inputs or outputs are you worried about specifically? In the current model, the client is required to normalize input to the UTF-8 representations of the canonical UCS name, and most of the protocol-level traffic is required to use UTF-8 . That's JUST the protocol-level traffic. The format of the database contents are intended to represent the richest possible view since those can always be down-converted. So for something like an entry name (the cn attribute) that would be the UTF-8 form. However, there are other classes of attributes where this is not going to be an option. For example, the mail and labeledURI attributes are locked to seven-bit syntaxes so they cannot (currently) use UTF-8. Meanwhile, stuff like nameserver attributes would be stored in their rich form, but would not use any of the escape mechanisms given their restrictions from the DNS service. Separately, the client is allowed to convert response domain names into IDNA for local display purposes if necessary. For example, I could add an "--output=idna" switch to firs.pl which would force the client to convert any domain attribute to IDNA for display purposes. That would give users the option of working with IDNA in all cases. For anybody else's client (especially one which is intended to be highly portable), IDNA might even be the default representation of the domain name attributes. So in all cases, the user has the option of working with whatever form they find best suited to their needs. All of this would also be possible if we reversed it around, such that IDNA was used for the protocol messages, the database storage and the default view, except that it would be much more difficult to implement holistically and as deeply (it would require multiple search filters, server-side conversion, etc). Is there some other area of concern that I'm missing? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 15:03:48 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 15:03:55 2003 Subject: [Ietf-not43] First draft on Relay bags in FIRS In-Reply-To: <3F411BDA.8060004@ecotroph.net> References: <3F3A3F34.2070805@daasi.de> <3F3AAF0A.9020406@ecotroph.net> <3F3B8EBA.2010602@daasi.de> <3F3BEC93.6040504@thinkingcat.com> <3F3D1012.8050509@daasi.de> <3F40444A.5040209@thinkingcat.com> <3F40D0C1.8040200@daasi.de> <3F40E975.5050309@thinkingcat.com> <3F40EC1E.1020809@ehsco.com> <3F40FD22.6000807@ecotroph.net> <3F410D82.9010404@ehsco.com> <3F411BDA.8060004@ecotroph.net> Message-ID: <3F412314.1040706@ehsco.com> on 8/18/2003 1:32 PM Andrew Newton wrote: > Eric A. Hall wrote: >>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. > > 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? 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". -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 15:33:04 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 15:33:11 2003 Subject: [Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers In-Reply-To: <3F41261C.4060908@ecotroph.net> References: <3F41261C.4060908@ecotroph.net> Message-ID: <3F4129F0.2030105@ehsco.com> on 8/18/2003 2:16 PM Andrew Newton wrote: > #5 inetDnsDomain attributes for contacts and nameservers > > At first I thought the attributes for contacts and nameservers in > inetDnsDomain were LDAP url's, but after reading the example it would > seem they are just strings. Correct me if I'm wrong (reading the OID > numbers starts to get confusing for me). They used to be URLs, now they're just resource names which the client uses to seed a new query. There is no substantial difference there in terms of the followup activitiy. A URL just provides a pre-packaged query to the client, and the client still has to go through the same basic steps in any event (eg, it has to find the SRV RRs, build the query, etc). However, the pre-packaged URLs can be too static. The URL set may not accurately reflect loading issues, for example, or may direct clients somewhere they shouldn't be going. Making the client start the query with the key value keeps these problems from happening. Architecturally, this is similar to what DNS does. EG, when you get an NS RR, you get a domain name as a value that you have to resolve. > If they aren't LDAP URL's, then what is a client to do with them for > dereferencing? They spawn new queries of the appropriate $resourceType with the attribute value as the search key. > Are these LDAP aliases? No, they are input values for any followup queries that the user may be interested in resolving. None of the attribute values are "automatically" processed (referrals are the only data that get the automatic treatment). > The OID number seems to define > their syntax as that of inetDnsDomain (also confusing since an email > address is not a domain name). Contact entry names use an email-like syntax (user@domain) so that they can overlap with email addresses, but these are not always going to reference existing email addresses. The idea here is that I can publish ehall@ehsco.com as my contact identity and people will be able to remember this since that's what I use for all of my crap anyway. However, if ~netsol assigns a nic handle to me, then that identity can point to their portion of the namespace (eg, something like eh26@registry.netsol.com). Or as another example, I might be eh26@registry.arin.net, where that identity entry holds public information about my role as a hostmaster. In either case, those entries could provide additional information or services (such as forwarding mail to me, or publishing subordinate reference referrals to my real identity, or whatever). Those are feature-adds that are up to the provider. So the idea here is that we have a flexible, universally applicable pointer for contacts, and which may be the same "identity" as I use for things like email, or a registrar-specific identity that provides public delegation-related data. The syntax uses the i18n domain logic for the @domain element for consistency purposes. The localpart@ is also utf8 to allow for the i18n work effort that is ongoing in the email space, but does not define a syntax for that (yet) so the localpart element is technically limited to the existing RFC 2822 syntax rules but is capable of supporting a richer syntax when one becomes available. > If the client gets an inetDnsDomain entry, what is it to do to follow > the information for a nameserver? Does it requiry the same server? > Does it start the whole query bootstrapping process again? It spawns new queries for each of the referenced domain names. If an organization wants to force this, they can return the entries as subordinate reference referrals which the client would then automatically chase down. > Either I just don't get it (entirely probable at this point), or these > should be LDAP URL's, or there needs to be text defining how a client is > to further dereference this information. Probably need clarifications to the text. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Mon Aug 18 17:27:33 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 16:00:46 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals Message-ID: <3F4136B5.2090404@ecotroph.net> #6 inetDnsDomain objects and 2251 referrals From draft-ietf-crisp-firs-dns-02 Section 4 paragraph 1: > If an entry exists as a > referral source, the entry MUST also be defined with the referral > object class, in addition to the above requirements. Most of the attributes described are strings, but the attributes for the registry and registrar seem to be LDAP URL referrals... so this would seem to apply in that the objectclass would be of inetDnsDomain and referral. Did I get the correct? Anyway, I think this will cause problems after reading RFC 2251. From RFC 2251 Section 4.5.3 Paragraph 2: > In the absence of indexing information provided to a server from > servers holding subordinate naming contexts, SearchResultReference > responses are not affected by search filters and are always returned > when in scope. Scope, in this sense, is base object, one level, or subtree. The problem, as I see it, is that there will be policy limits on the number of entries. So, let's say that I have 200 entries beneath dc=com and limit of 50 results per query. And let's say that 100 of them have referrals in them (to the registry or registrar or both). If I do a subtree or one-level search at dc=com, the response will be filled up with the first 50 entries because they have referrals that are in scope. This is true even if the search filter says only give me back domains hosted by nameserver ns1.example.com. It would seem that the referrals eat up the response even when they aren't appropriate to hand back. -andy From ehall at ehsco.com Mon Aug 18 16:18:05 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 16:18:11 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F4136B5.2090404@ecotroph.net> References: <3F4136B5.2090404@ecotroph.net> Message-ID: <3F41347D.9020903@ehsco.com> on 8/18/2003 3:27 PM Andrew Newton wrote: > Most of the attributes described are strings, but the attributes for > the registry and registrar seem to be LDAP URL referrals... No, they're pointers not referrals. They provide a way to point at a registry's web page, for example. This is neccessary to allow registration data to provide a "see also" capability that exceeds the LDAP directory space. If I query for example.com, I want to get information about the registry and registrar, and this is meant to provide that pointer data. It's not a referral and it's not intended to be automatically chased down (the user can click on the URL and see where it goes, but that's the extent). The attributes use the two-part labeledURI syntax, which is "URI text" with the "text" potentially being displayed as a hyperlink with the URI as the link context. > Anyway, I think this will cause problems after reading RFC 2251. I don't think this concern applies in light of the answer above but if you think it still does, let me know. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 16:50:34 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 16:50:42 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F40FB5D.7060806@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> Message-ID: <3F413C1A.8060609@ehsco.com> on 8/18/2003 11:14 AM Andrew Newton wrote: >>> #2 - The implementation of 3.1.8. >>> >>> There was mention of 3.1.8 in the meeting by Peter, but I do not >>> see it addressed in the drafts. Looking through the jabber logs, >>> Peter proposed various methods to do this. These were defined as: >>> using the bind operation, special policy entries, and server-side >>> extended operations. >> >> However, if folks want to go ahead and start working on this, we >> certainly can. I'd like to get a better analysis on the objective >> first though. Are we wanting to provide something like a counter ("50 >> out of 50 possible queries already performed, try back tomorrow"), a >> simple tooManyQueries response, or an array of different responses? > > I don't quite follow this. It sounds like you are talking about the > first part of 3.2.5., which is something that is already defined in > stock LDAP (I think). 3.2.5 talks about maximum results in queries, while my understanding of this particular issue is that it is related to the ability to issue any queries at all, possibly because of rate-limited (too many queries today alredy), or possibly because of some other requirements. The general cases are already defined as bind errors (unwillingToPerform essentially means "just go away"). I'm trying to get a handle on exactly what kind of limits we are trying to express so that I can describe them properly. So, is 3.1.8 specifically about fixed query volume (try again after HH:MM UCT), the query interval rate (wait five minutes), both of these, something else, or what? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Mon Aug 18 18:20:19 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 16:53:36 2003 Subject: [Ietf-not43] #7 Email addresses in contacts Message-ID: <3F414313.5070007@ecotroph.net> #7 Email addresses in contacts FIRS seems to require a contact to have their email address in the DN. From draft-ietf-crips-firs-contact-02: > The inetContactSyntax is unstructured, in that it uses > standardized procedures to produce heavily-normalized email > addresses rather than using structured syntax rules. The principle > reason for this is due to conflicting syntax rules in different > canonical email addressing rules, with these rules preventing the > use of a common syntax. This means that in order to reference the contact, a referral or reference to the contact must expose the email address of the contact. I think this has privacy implications all over it. > The normalization procedure produces UTF-8 [RFC2279] email > addresses as output, with these domain names being suitable for > direct comparisons, substring searches, and other lightweight > comparisons. Servers tend to be more heavily-loaded than clients, > and requiring the data to be normalized before it is used for > comparison operations ensures that a broader range of comparison > operations can be performed with minimal impact on those servers. I assume this is the same escaped Unicode as discussed earlier? Correct? Why do email addresses have to be handled differently? I thought one of the points of IDN was that we wouldn't have to change things like email addresses? Not being an IDN person, I could have this all screwed up. Is the point that the email addresses cannot be the xn-- versions and must be Unicode? -andy From anewton at ecotroph.net Mon Aug 18 18:31:47 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 17:05:01 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F413C1A.8060609@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> Message-ID: <3F4145C3.4040706@ecotroph.net> Eric A. Hall wrote: > > > > 3.2.5 talks about maximum results in queries, while my understanding of > this particular issue is that it is related to the ability to issue any > queries at all, possibly because of rate-limited (too many queries today > alredy), or possibly because of some other requirements. > > The general cases are already defined as bind errors (unwillingToPerform > essentially means "just go away"). I'm trying to get a handle on exactly > what kind of limits we are trying to express so that I can describe them > properly. So, is 3.1.8 specifically about fixed query volume (try again > after HH:MM UCT), the query interval rate (wait five minutes), both of > these, something else, or what? > Think of it as the "dry run" -n switch for rsync or something. The results maybe different depending on the subdirectory/mount point/file permissions you may have, but you will know if it can do what you want it to do without having it do it. Does this make it clearer? -andy From anewton at ecotroph.net Mon Aug 18 18:45:54 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 17:19:07 2003 Subject: [Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers In-Reply-To: <3F4129F0.2030105@ehsco.com> References: <3F41261C.4060908@ecotroph.net> <3F4129F0.2030105@ehsco.com> Message-ID: <3F414912.6070405@ecotroph.net> Eric A. Hall wrote: > > Contact entry names use an email-like syntax (user@domain) so that they > can overlap with email addresses, but these are not always going to > reference existing email addresses. > > The idea here is that I can publish ehall@ehsco.com as my contact identity > and people will be able to remember this since that's what I use for all > of my crap anyway. However, if ~netsol assigns a nic handle to me, then > that identity can point to their portion of the namespace (eg, something > like eh26@registry.netsol.com). Or as another example, I might be > eh26@registry.arin.net, where that identity entry holds public information > about my role as a hostmaster. In either case, those entries could provide > additional information or services (such as forwarding mail to me, or > publishing subordinate reference referrals to my real identity, or > whatever). Those are feature-adds that are up to the provider. > > So the idea here is that we have a flexible, universally applicable > pointer for contacts, and which may be the same "identity" as I use for > things like email, or a registrar-specific identity that provides public > delegation-related data. > > The syntax uses the i18n domain logic for the @domain element for > consistency purposes. The localpart@ is also utf8 to allow for the i18n > work effort that is ongoing in the email space, but does not define a > syntax for that (yet) so the localpart element is technically limited to > the existing RFC 2822 syntax rules but is capable of supporting a richer > syntax when one becomes available. Huh? Email addresses that aren't quite email addresses, and domain names that aren't quite domain names!? Private email addresses assigned by a registry!? Why don't you just call them contact handles and have two separate namespaces for them? Perhaps use uid=contact-handle and mail=email address. I don't get this. Why is this special email address your "identity"? I thought the LDAP DN was the identity. Isn't that the LDAP way? >>If the client gets an inetDnsDomain entry, what is it to do to follow >>the information for a nameserver? Does it requiry the same server? >>Does it start the whole query bootstrapping process again? > > > It spawns new queries for each of the referenced domain names. If an > organization wants to force this, they can return the entries as > subordinate reference referrals which the client would then automatically > chase down. > > >>Either I just don't get it (entirely probable at this point), or these >>should be LDAP URL's, or there needs to be text defining how a client is >>to further dereference this information. > > > Probably need clarifications to the text. Thank you. This makes sense now. I think text describing that the client is to use this to feed new queries would be useful. -andy From anewton at ecotroph.net Mon Aug 18 18:51:21 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 18 17:24:35 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F41347D.9020903@ehsco.com> References: <3F4136B5.2090404@ecotroph.net> <3F41347D.9020903@ehsco.com> Message-ID: <3F414A59.1050100@ecotroph.net> Eric A. Hall wrote: > > No, they're pointers not referrals. They provide a way to point at a > registry's web page, for example. > > This is neccessary to allow registration data to provide a "see also" > capability that exceeds the LDAP directory space. If I query for > example.com, I want to get information about the registry and registrar, > and this is meant to provide that pointer data. It's not a referral and > it's not intended to be automatically chased down (the user can click on > the URL and see where it goes, but that's the extent). > > The attributes use the two-part labeledURI syntax, which is "URI text" > with the "text" potentially being displayed as a hyperlink with the URI as > the link context. Is that how LDAP clients normally handle labeledURI syntax? If not, you should probably include this in the draft. Even if it is, you should probably include it as an informative item (perhaps in an appendix). > >>Anyway, I think this will cause problems after reading RFC 2251. > > > I don't think this concern applies in light of the answer above but if you > think it still does, let me know. Then why do have the following text: DNS domain name entries in FIRS MUST use the inetDnsDomain object class, in addition to the mandatory object classes defined in [FIRS-CORE]. DNS domain name entries MUST be treated as containers capable of holding subordinate entries. If an entry exists as a referral source, the entry MUST also be defined with the referral object class, in addition to the above requirements. Why would they also use the referral objectclass? -andy From ehall at ehsco.com Mon Aug 18 17:46:21 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 17:46:28 2003 Subject: [Ietf-not43] #5 inetDnsDomain attributes for contacts and nameservers In-Reply-To: <3F414912.6070405@ecotroph.net> References: <3F41261C.4060908@ecotroph.net> <3F4129F0.2030105@ehsco.com> <3F414912.6070405@ecotroph.net> Message-ID: <3F41492D.5060906@ehsco.com> on 8/18/2003 4:45 PM Andrew Newton wrote: > Huh? Email addresses that aren't quite email addresses, and domain > names that aren't quite domain names!? Private email addresses > assigned by a registry!? Heh. Are IP addresses domain names? Does the dot-separator confuse you? They aren't email addresses, they are contact identity pointers. Whether they are also usable as email addresses is up to the provider. They use the same representation as IDN transformation, just like email addresses will commonly appear if IDNA conversion takes hold. > Why don't you just call them contact handles and have two separate > namespaces for them? Perhaps use uid=contact-handle and mail=email > address. Just like URIs break when they are too explicit, DNs also break when they are too explicit. ehall@ehsco.com would get mapped into cn=ehall@ehsco.com,cn=... just like ns1.example.com would get mapped into cn=ns1.example.com,cn=... > I don't get this. Why is this special email address your "identity"? > I thought the LDAP DN was the identity. Isn't that the LDAP way? That works fine for locally-constrained and managed apps within a fixed namespace. It has a lot of implications out in the wild. Why don't MX RRs just return the IP address? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 17:55:12 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 17:55:19 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F414A59.1050100@ecotroph.net> References: <3F4136B5.2090404@ecotroph.net> <3F41347D.9020903@ehsco.com> <3F414A59.1050100@ecotroph.net> Message-ID: <3F414B40.1040609@ehsco.com> on 8/18/2003 4:51 PM Andrew Newton wrote: > Is that how LDAP clients normally handle labeledURI syntax? It's the prescribed behavior. > Then why do have the following text: > > DNS domain name entries in FIRS MUST use the inetDnsDomain object > class, in addition to the mandatory object classes defined in > [FIRS-CORE]. DNS domain name entries MUST be treated as containers > capable of holding subordinate entries. If an entry exists as a > referral source, the entry MUST also be defined with the referral > object class, in addition to the above requirements. > > Why would they also use the referral objectclass? It's either-or, not also. The referrals are for use whenever a domain entry needs to exist as an alias for some other entry. An easy example is when www.example.com is really a set of web pages hosted by an isp. In that case, a query for the www.example.com domain entry would just return a referral to host.example.net. Another example that we discussed recently would be variants for i18n domain names, where all of the variants exist as entries but only exist as referral entries. This allows a query for a variant to match the right entry, and still get shunted off to the canonical entry. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 18 18:09:03 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 18:09:11 2003 Subject: [Ietf-not43] #7 Email addresses in contacts In-Reply-To: <3F414313.5070007@ecotroph.net> References: <3F414313.5070007@ecotroph.net> Message-ID: <3F414E7F.4030703@ehsco.com> on 8/18/2003 4:20 PM Andrew Newton wrote: > #7 Email addresses in contacts > > FIRS seems to require a contact to have their email address in the DN. That's incorrect. The syntax mimics email so that it is POSSIBLE for a contact to accept email, but this is not a requirement. Maybe this is too abstract > This means that in order to reference the contact, a referral or > reference to the contact must expose the email address of the contact. > I think this has privacy implications all over it. What privacy does eh26@registry.netsol.com expose that any other pointer mechanism to that portion of the namespace wouldn't? If I choose to publish my actual email address as part of a supplemental layered service, that's my option. If I don't want to do so, I can use admins@ehsco.com instead. If anybody sends email to any of those addresses, it's a crapshoot as to whether the mail actually goes anywhere. >> The normalization procedure produces UTF-8 [RFC2279] email addresses >> as output, with these domain names being suitable for direct >> comparisons, substring searches, and other lightweight comparisons. >> Servers tend to be more heavily-loaded than clients, and requiring >> the data to be normalized before it is used for comparison operations >> ensures that a broader range of comparison operations can be >> performed with minimal impact on those servers. > > I assume this is the same escaped Unicode as discussed earlier? > Correct? Yes > Why do email addresses have to be handled differently? I thought one > of the points of IDN was that we wouldn't have to change things like > email addresses? Not being an IDN person, I could have this all > screwed up. What do you mean by differently? The domain elements are the same. The localpart elements are undeclared since nothing has emerged from that work as of yet. > Is the point that the email addresses cannot be the xn-- versions and > must be Unicode? The domain element can be rendered locally as IDNA if the client chooses. The localpart element shouldn't exist as anything other than RFC 2822 syntax rules at the moment, since nothing else has been defined (note that the liberal rules in the contact syntax are there for whenever the new syntax shows up, but at the moment the only rules are RFC 2822). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From davidb at verisignlabs.com Mon Aug 18 20:18:51 2003 From: davidb at verisignlabs.com (David Blacka) Date: Mon Aug 18 19:22:38 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F414B40.1040609@ehsco.com> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> Message-ID: <200308181918.51561.davidb@verisignlabs.com> On Monday 18 August 2003 05:55 pm, Eric A. Hall wrote: > > on 8/18/2003 4:51 PM Andrew Newton wrote: > > > Is that how LDAP clients normally handle labeledURI syntax? > > It's the prescribed behavior. > > > Then why do have the following text: > > > > DNS domain name entries in FIRS MUST use the inetDnsDomain object > > class, in addition to the mandatory object classes defined in > > [FIRS-CORE]. DNS domain name entries MUST be treated as containers > > capable of holding subordinate entries. If an entry exists as a > > referral source, the entry MUST also be defined with the referral > > object class, in addition to the above requirements. > > > > Why would they also use the referral objectclass? > > It's either-or, not also. The referrals are for use whenever a domain > entry needs to exist as an alias for some other entry. Huh? You've lost me. It seems you are saying that the object is *either* a inetDnsDomain object *or* a referral object. But that is not how the quoted paragraph reads: "If an entry exists as a referral source, the entry MUST *also* be defined with the referral object class, *in addition to the above requirements*." [emphasis mine] says that some objects are *both* inetDnsDomain objects and referral objects. Or have I misunderstood? -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Mon Aug 18 19:47:45 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 19:47:53 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <200308181918.51561.davidb@verisignlabs.com> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> <200308181918.51561.davidb@verisignlabs.com> Message-ID: <3F4165A1.1030505@ehsco.com> on 8/18/2003 6:18 PM David Blacka wrote: > On Monday 18 August 2003 05:55 pm, Eric A. Hall wrote: >>> DNS domain name entries in FIRS MUST use the inetDnsDomain object >>> class, in addition to the mandatory object classes defined in >>> [FIRS-CORE]. DNS domain name entries MUST be treated as containers >>> capable of holding subordinate entries. If an entry exists as a >>> referral source, the entry MUST also be defined with the referral >>> object class, in addition to the above requirements. >>> >>>Why would they also use the referral objectclass? >> >>It's either-or, not also. The referrals are for use whenever a domain >>entry needs to exist as an alias for some other entry. > > Huh? You've lost me. > > It seems you are saying that the object is *either* a inetDnsDomain object > *or* a referral object. But that is not how the quoted paragraph reads: > "If an entry exists as a referral source, the entry MUST *also* be defined > with the referral object class, *in addition to the above requirements*." > [emphasis mine] says that some objects are *both* inetDnsDomain objects > and referral objects. > > Or have I misunderstood? Object classes are different from attributes. The object classes that define the entry must always be defined. This is needed so that the matching process works as expected ("please give me all of the resources like name X of object class Z"). If an entry is a referral source, then the only attributes should be defined inside the entry are the objectlass= attributes themselves, the naming attribute (cn=), and the ref attribute. If an entry is terminal, then it may have any of the attributes from any of the object classes that are defined. A terminal entry: cn=host1.example.net,cn=inetResources,dc=... cn: host1.example.net objectClass: top objectClass: inetResources objectClass: inetDnsDomain o: example.net ISP description: the example.net hosting server : ... A referral entry: cn=www.example.com,cn=... cn: www.example.com objectClass: top objectClass: inetResources objectClass: inetDnsDomain objectClass: referral ref: ldap:///cn=host1.example.net,cn=inetResources,dc=... [No other attributes allowed.] A query for cn=www.example.com && objectClass=inetDnsDomain would match against the appropriate entry, and the resulting referral data would kick the client over to the canonical target entry. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From davidb at verisignlabs.com Mon Aug 18 21:26:43 2003 From: davidb at verisignlabs.com (David Blacka) Date: Mon Aug 18 20:30:31 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F4165A1.1030505@ehsco.com> References: <3F4136B5.2090404@ecotroph.net> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> Message-ID: <200308182026.43073.davidb@verisignlabs.com> On Monday 18 August 2003 07:47 pm, Eric A. Hall wrote: > > on 8/18/2003 6:18 PM David Blacka wrote: > > > On Monday 18 August 2003 05:55 pm, Eric A. Hall wrote: > > >>> DNS domain name entries in FIRS MUST use the inetDnsDomain > >>> object class, in addition to the mandatory object classes > >>> defined in [FIRS-CORE]. DNS domain name entries MUST be treated > >>> as containers capable of holding subordinate entries. If an > >>> entry exists as a referral source, the entry MUST also be > >>> defined with the referral object class, in addition to the > >>> above requirements. > > Huh? You've lost me. > > > > It seems you are saying that the object is *either* a > > inetDnsDomain object *or* a referral object. But that is not how > > the quoted paragraph reads: "If an entry exists as a referral > > source, the entry MUST *also* be defined with the referral object > > class, *in addition to the above requirements*." [emphasis mine] > > says that some objects are *both* inetDnsDomain objects and > > referral objects. > > > > Or have I misunderstood? > > Object classes are different from attributes. I see. The paragraph is referring to what objectclass's these objects must declare in their objectclass attributes, which pretty much follows from the rules for referrals laid out in FIRS-core. However, this paragraph is confusing. Specifically the phrase: "...in addition to the above requirements." One of the "above requirements" is that "DNS domain name entries MUST be treated as containers..." Which is, of course, explictly disallowed in firs-core (4.3): Referral sources MUST NOT contain any user-definable attributes (other than the mandatory naming attribute), and MUST NOT have any subordinate child entries. Hence the confusion. I believe that this paragraph (the first paragraph of section 4 of firs-dns, for those keeping score at home) is unclear, because to me it appears to contradict firs-core, which I am positive you do not intend. -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Mon Aug 18 20:53:29 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 20:53:36 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <200308182026.43073.davidb@verisignlabs.com> References: <3F4136B5.2090404@ecotroph.net> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> <200308182026.43073.davidb@verisignlabs.com> Message-ID: <3F417509.8080300@ehsco.com> on 8/18/2003 7:26 PM David Blacka wrote: > However, this paragraph is confusing. Specifically the phrase: "...in > addition to the above requirements." One of the "above requirements" > is that "DNS domain name entries MUST be treated as containers..." > Which is, of course, explictly disallowed in firs-core (4.3): Yeah that's an error, and one I meant to call out earlier. Sorry. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From richard at shockey.us Mon Aug 18 22:10:13 2003 From: richard at shockey.us (Richard Shockey) Date: Mon Aug 18 21:10:21 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: References: <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> Message-ID: <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> over a more substantive discussion of the meta issues involved in FIRS vs IRIS. I'll say it again folks ... I oppose FIRS on the merits for the reasons I outlined previously and I would like my colleagues in the Domain Name Industry and RIR's to please come out of the closet and make your views known. In the closed environment we are dealing with which means the Domain Name Industry and the RIR's will be directly affected by the protocols adopted here I think it is prudent to evaluate these proposals based on their economic impact on our operations as well as the merits of their conformance to the requirements. and yes I will freely admit I prefer XML query response mechanisms to LDAP on a purely Layer 10 basis. >As you'll note from the text in the minutes, the group agreed >to a three week discussion period to begin at the publication >of the FIRS LDAP extensions doc. With the publication >of that document, the chairs believe that it is appropriate to >start that discussion period. It will end three weeks from >today, on September 5, 2003. > >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). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From ehall at ehsco.com Mon Aug 18 21:34:12 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 18 21:34:20 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F4145C3.4040706@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> Message-ID: <3F417E94.5000603@ehsco.com> on 8/18/2003 4:31 PM Andrew Newton wrote: > Eric A. Hall wrote: >>The general cases are already defined as bind errors (unwillingToPerform >>essentially means "just go away"). I'm trying to get a handle on exactly >>what kind of limits we are trying to express so that I can describe them >>properly. So, is 3.1.8 specifically about fixed query volume (try again >>after HH:MM UCT), the query interval rate (wait five minutes), both of >>these, something else, or what? > > Think of it as the "dry run" -n switch for rsync or something. The > results maybe different depending on the subdirectory/mount point/file > permissions you may have, but you will know if it can do what you want > it to do without having it do it. > > Does this make it clearer? Not really. As it stands, it seems like the requirement is already being satisfied. Quoting section 3.1.8.1 of reqs-5: | 3.1.8.1 Protocol Requirement | | The protocol MUST provide a mechanism allowing a client to determine | if a query will be denied before the query is submitted according to | the appropriate policies of the operator. There are already several bind error responses that tell a client that they won't get service before they issue the query, so the requirement is already being satisfied by the protocol (Peter said as much during his presentation as well, and talked about other mechanisms as alternative mechanisms). The alternatives have other costs, and I can imagine some other mechanisms that could be useful for specific situations (like hit-counters), but I'd like to hear what the operators think is needed before I start extending the protocol even more. Maybe we can revisit this at a later time. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From wessorh at ar.com Mon Aug 18 21:39:25 2003 From: wessorh at ar.com (Rick Wesson) Date: Mon Aug 18 23:39:18 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> Message-ID: hi rich, > I'll say it again folks ... I oppose FIRS on the merits for the reasons I > outlined previously and I would like my colleagues in the Domain Name > Industry and RIR's to please come out of the closet and make your views known. i like xml, does this mean i'm out now? I even told my parents -- i like XML! -rick From shane at ripe.net Tue Aug 19 10:51:10 2003 From: shane at ripe.net (Shane Kerr) Date: Tue Aug 19 03:51:16 2003 Subject: [Ietf-not43] #7 Email addresses in contacts In-Reply-To: <3F414313.5070007@ecotroph.net> References: <3F414313.5070007@ecotroph.net> Message-ID: <3F41D6EE.5070908@ripe.net> Andrew Newton wrote: > #7 Email addresses in contacts > > FIRS seems to require a contact to have their email address in the DN. > > From draft-ietf-crips-firs-contact-02: > >> The inetContactSyntax is unstructured, in that it uses >> standardized procedures to produce heavily-normalized email >> addresses rather than using structured syntax rules. The principle >> reason for this is due to conflicting syntax rules in different >> canonical email addressing rules, with these rules preventing the >> use of a common syntax. > > > This means that in order to reference the contact, a referral or > reference to the contact must expose the email address of the contact. I > think this has privacy implications all over it. Plus in our (RIPE NCC) schema, e-mail address is an optional attribute for contacts, and role contacts can have multiple e-mail addresses. We cannot elegantly use a system where e-mail is the lookup key. -- Shane Kerr RIPE NCC From ehall at ehsco.com Tue Aug 19 04:06:42 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 04:06:49 2003 Subject: [Ietf-not43] #7 Email addresses in contacts In-Reply-To: <3F41D6EE.5070908@ripe.net> References: <3F414313.5070007@ecotroph.net> <3F41D6EE.5070908@ripe.net> Message-ID: <3F41DA92.8020204@ehsco.com> on 8/19/2003 2:51 AM Shane Kerr wrote: > Plus in our (RIPE NCC) schema, e-mail address is an optional attribute > for contacts, and role contacts can have multiple e-mail addresses. > We cannot elegantly use a system where e-mail is the lookup key. "Email addresses" are optional here too. Take a deep breath. Every entry of every type has a name which is qualified enough to allow a client to build a fully-formed query, using just the name and type values. In the case of domain resources, the entry key name is a fully-qualified domain name. In the case of IP addresses, it's an address/prefix pair. Okay, so we need a key name for contacts, and one that provides enough qualifier data to be fully-resolvable by just the key name and type... Golly, how about we use the identifiers that everybody uses for everything on the Internet, that thing with localpart@domain syntax. Then we can find the servers for the @domain, we can use identifiers that may have meaning to people who want to use them, we can layer indirection into the service so that providers can manage @their.own.freaking.domain entries, and so forth. These are just identifiers for contact entries within distributed partitions, nothing more. They use a friendly syntax for those places where people want to reuse the identifier for other things, such as email, or for publishing a public key associated with that identifer, or whatever. If you look at the contents of the schema, you'll see that there's an explicit attribute for email addresses. The identifier is just an identifier which is globally resolvable. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shane at ripe.net Tue Aug 19 13:00:04 2003 From: shane at ripe.net (Shane Kerr) Date: Tue Aug 19 06:00:10 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <200308181417.14060.davidb@verisignlabs.com> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> Message-ID: <3F41F524.3010808@ripe.net> David Blacka wrote: > Ginny, > > I am a little confused by part of the requirements in your draft: > > 3.2.2.1 Protocol Requirement > > The protocol MUST contain the following search functions: > > 1. IPv4 address search given one or more contiguous IP address > numbers. This search SHOULD allow for both exact matching and > nested matching. > > 2. IPv6 address search given one or more contiguous IP address > numbers. This search SHOULD allow for both exact matching and > nested matching. > > These searches seem sort of vague to me. Maybe it is a terminology > problem. When doing a IP address search, what are you looking for? > Supernets or subnets? All supernets or all subnets? Is an "exact match" > the closest enclosing supernet and a "nested match" all supernets? > Wouldn't we want the ability to search for both supernets and subnets? For us (RIPE NCC), nested matching means: - Given a range, find all the networks that contain that range; "-L" in RIPE-land, or "all supernets" in your terminology - Given a range, find only the most specific network that contains that range (could be multiple networks, but usually single); "-l" in RIPE-land, and the default for our servers, or "supernets" in your terminology - Given a range, find all the networks that are fully within that range; "-M" in RIPE-land, or "all subnets" in your terminology - Given a range, find only the least specific networks that are fully within that range; "-m" in RIPE-land, or "subnets" in your terminology Exact matching means: - Given a range, find the network that begins and ends on the same IP addresses as the range; "-x" in RIPE-land More details: -x is networks where: (start(network) = start(search)) AND (end(network) = end(search)) For us, a "less-specific" search can return a network that is an exact match, as well as the encompassing networks: -L is networks where: (start(network) <= start(search)) AND (end(network) >= end(search)) -l is all of the networks from -L, with the provisio that: no other network in the return set is contained by the network However, a "more-specific" search must not be an exact match: -M is networks where: (start(network) >= start(search)) AND (end(network) <= end(search)) AND NOT ((start(network) = start(search)) AND (end(network) = end(search))) -m is all of the networks from -M, with the provisio that: no other network in the return set contains the network (Note that the definition is not the best way to find the answer.) Any replacement for WHOIS would have to have at *least* this much expressiveness. > Also, I would sort of think that searching for network blocks (IPv4 or > IPv6) would be one of the most basic points of the service, so should the > ability to search for them be a SHOULD? Agreed. -- Shane Kerr RIPE NCC From Peter.Gietz at daasi.de Tue Aug 19 13:47:01 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Tue Aug 19 06:47:14 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F414A59.1050100@ecotroph.net> References: <3F4136B5.2090404@ecotroph.net> <3F41347D.9020903@ehsco.com> <3F414A59.1050100@ecotroph.net> Message-ID: <3F420025.2070905@daasi.de> Andrew Newton wrote: > Eric A. Hall wrote: > >> >> No, they're pointers not referrals. They provide a way to point at a >> registry's web page, for example. >> >> This is neccessary to allow registration data to provide a "see also" >> capability that exceeds the LDAP directory space. If I query for >> example.com, I want to get information about the registry and registrar, >> and this is meant to provide that pointer data. It's not a referral and >> it's not intended to be automatically chased down (the user can click on >> the URL and see where it goes, but that's the extent). >> >> The attributes use the two-part labeledURI syntax, which is "URI text" >> with the "text" potentially being displayed as a hyperlink with the >> URI as >> the link context. > > > Is that how LDAP clients normally handle labeledURI syntax? If not, you > should probably include this in the draft. Even if it is, you should > probably include it as an informative item (perhaps in an appendix). > THis is LDAP standard behaviour for URIs. LabeledURI syntax is specified in RFC 2079, which is included in the normative references of FIRS-core. Cheers, Peter >> >>> Anyway, I think this will cause problems after reading RFC 2251. >> >> >> >> I don't think this concern applies in light of the answer above but if >> you >> think it still does, let me know. > > > Then why do have the following text: > > DNS domain name entries in FIRS MUST use the inetDnsDomain object > class, in addition to the mandatory object classes defined in > [FIRS-CORE]. DNS domain name entries MUST be treated as containers > capable of holding subordinate entries. If an entry exists as a > referral source, the entry MUST also be defined with the referral > object class, in addition to the above requirements. > > Why would they also use the referral objectclass? > > -andy > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@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@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From shane at ripe.net Tue Aug 19 15:22:34 2003 From: shane at ripe.net (Shane Kerr) Date: Tue Aug 19 08:22:38 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> References: <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> Message-ID: <3F42168A.6090004@ripe.net> Richard Shockey wrote: > > over a more substantive discussion of the meta issues involved in FIRS > vs IRIS. > > I'll say it again folks ... I oppose FIRS on the merits for the reasons > I outlined previously and I would like my colleagues in the Domain Name > Industry and RIR's to please come out of the closet and make your views > known. > > In the closed environment we are dealing with which means the Domain > Name Industry and the RIR's will be directly affected by the protocols > adopted here I think it is prudent to evaluate these proposals based on > their economic impact on our operations as well as the merits of their > conformance to the requirements. > > and yes I will freely admit I prefer XML query response mechanisms to > LDAP on a purely Layer 10 basis. Personally, I prefer XML based mechanisms. We use XML here, and XML maps in a straightforward way to our schema. We could probably use LDAP, but a lot of our problem space is either: - not hierarchical - searches not lookups LDAP is not really a technology we're familiar with, so the cost would probably be higher here than for XML. I expect we'll have to do some software development on our side no matter what, and not having to learn a new paradigm would be a huge cost savings. I know LDAP has authentication baked-in, but I don't really know how it applies to the FIRS universe. This could be a win for the LDAP implementation. To be honest, I haven't read all of the drafts, and the information may be there. But there are 151 pages of draft for FIRS and 173 pages of draft for IRIS. I have read the 26 pages of requirements from the RIR's though. :) -- Shane Kerr RIPE NCC From Peter.Gietz at daasi.de Tue Aug 19 16:22:41 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Tue Aug 19 09:22:52 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <3F42168A.6090004@ripe.net> References: <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> Message-ID: <3F4224A1.3020808@daasi.de> Ok by now we had some general postings saying "I like XML better", one explicitly on layer 10 (religion). This one is a bit more concrete: Shane Kerr wrote: > Richard Shockey wrote: > >> >> over a more substantive discussion of the meta issues involved in FIRS >> vs IRIS. >> >> I'll say it again folks ... I oppose FIRS on the merits for the >> reasons I outlined previously and I would like my colleagues in the >> Domain Name Industry and RIR's to please come out of the closet and >> make your views known. >> >> In the closed environment we are dealing with which means the Domain >> Name Industry and the RIR's will be directly affected by the protocols >> adopted here I think it is prudent to evaluate these proposals based >> on their economic impact on our operations as well as the merits of >> their conformance to the requirements. >> >> and yes I will freely admit I prefer XML query response mechanisms to >> LDAP on a purely Layer 10 basis. > > > Personally, I prefer XML based mechanisms. We use XML here, and XML > maps in a straightforward way to our schema. > > We could probably use LDAP, but a lot of our problem space is either: > > - not hierarchical > - searches not lookups LDAP is designed for searches, in fact a lookup is just a sub case of search. You don't neccessarily have to stgructure the Directory Information Tree with a deep hierarchy. Anyway the possibility to do so, is IMHO one of the arguments for LDAP: The mapping of the domain names with DomainComponant naming is so intuitive. Ok: I admit: being familiar with that technology for quite a while: I like LDAP. I hope my reasons are not (only) on layer 10. I BTW like XML as well, and for each use case there are cons anfd pros on both sides. > > LDAP is not really a technology we're familiar with, so the cost would > probably be higher here than for XML. I expect we'll have to do some > software development on our side no matter what, and not having to learn > a new paradigm would be a huge cost savings. Yes there are differences and in some respect (mainly on the actual protocol side with ASN.1 and DER-encoding) LDAP tends to be a bit more complex. But as user or application developper, you don't have to deal with that complicated stuff since it is handled by the many available LDAP libraries for almost any programming language you want to use (C, Java, Perl, Python, PHP come into my mind right now, there will be more languages with LDAP support). So what remains for you to get familiar with is the schema paradigm and that is quite intuitive and can basically be described in a couple of sentences: - information is stored in entries that are nodes in a tree - entries consists of attributetype/value pairs - attributetypes are specified with an attribute syntax and matching rules - Matching rules specify behavior, in comparisions and ordering (e.g. caseexact vs. caseIgnore) - there is one (or more) special attributetype/value pair that forms the name of an entry - there is one or more special attributetypes called objectclass that describe the structure, main characteristics and secondary characteristics of an entry - Thus object classes specify which other attributes MAY or MUST be used in an entry - an objectclass can inherite qualities from another objectclass, e.g. organizationalPerson inherits from person - an attributetype can be inherited from another attributetype, e.g. common name is inherited from name I think this paradigm is quite easy and intuitive and makes a lot of sence, when you want to store informations about real world entities. Especially the inheritance mechanisms are extremly useful. > > I know LDAP has authentication baked-in, but I don't really know how it > applies to the FIRS universe. This could be a win for the LDAP > implementation. Yes you can even choose between a number of authentication mechanisms, e.g. userpassword via an encrypted TLS session, MD5 chalenge response (no password goes through the wire) via SASL, any other SASL mechanism. Authentication is not the only inbuilt feature of LDAP that can be used for crisp (FIRS): all implementations have granular access control, and replication mechanisms. Distribution of the data on several servers is already defined in the standard. The implementations are stable and reliable, some are capable of storing tens of millions of entries in one server. But you would not need to store all data of, e.g. a .com registry in one server, you can have one (referral) server pointing to any number of (data) servers. As the discussion about FIRS has shown and will show, all features needed can be specified by the extension mechanisms inherent in LDAP. By now the XML database technology is not near as mature and well established as LDAP. You don't even have a single standardized acces protocol, but competing ones (Xquery, XMLquery, Xpath, XQL, ...). I don't know of any native XML database implementation that has inbuilt features like authentication, access control, replication. Most implementations use an SQL backend to an XML frontend. The mapping of the (hierarchical!) XML information model to the (non hierarchical) relational model is not very intuitive. BTW there is a proposal called XML enabled Directory wihcb uses LDAP as datastore for XML applications. See http://www.ietf.org/internet-drafts/draft-legg-xed-roadmap-00.txt and the docs quoted therein. This could even be the base of an IRIS implementation with an LDAP database. I hope this made sence on technical levels as well. Cheers, Peter > > To be honest, I haven't read all of the drafts, and the information may > be there. But there are 151 pages of draft for FIRS and 173 pages of > draft for IRIS. > > I have read the 26 pages of requirements from the RIR's though. :) > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From davidb at verisignlabs.com Tue Aug 19 11:04:50 2003 From: davidb at verisignlabs.com (David Blacka) Date: Tue Aug 19 10:08:39 2003 Subject: [Ietf-not43] =?iso-8859-1?q?I-D=09ACTION=3Adraft-ietf-crisp-internet-resource-number-re?= =?iso-8859-1?q?q-00=2Etxt?= In-Reply-To: <3F41F524.3010808@ripe.net> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> Message-ID: <200308191004.50617.davidb@verisignlabs.com> On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote: Excellent response, Shane. Thanks. My comments are in-line. > For us (RIPE NCC), nested matching means: > > - Given a range, find all the networks that contain that range; "-L" > in RIPE-land, or "all supernets" in your terminology > > - Given a range, find only the most specific network that contains > that range (could be multiple networks, but usually single); "-l" in > RIPE-land, and the default for our servers, or "supernets" in your > terminology I called this "the closest enclosing supernet", but your description is quite clear. > - Given a range, find all the networks that are fully within that > range; "-M" in RIPE-land, or "all subnets" in your terminology > > - Given a range, find only the least specific networks that are fully > within that range; "-m" in RIPE-land, or "subnets" in your terminology Ok, is "least specific" the same thing as largest, in this context? I guess I'm not sure how to define this search. > Exact matching means: > > - Given a range, find the network that begins and ends on the same IP > addresses as the range; "-x" in RIPE-land > More details: > > -x is networks where: > (start(network) = start(search)) AND > (end(network) = end(search)) > > For us, a "less-specific" search can return a network that is an exact > match, as well as the encompassing networks: > > -L is networks where: > (start(network) <= start(search)) AND > (end(network) >= end(search)) > > -l is all of the networks from -L, with the provisio that: > no other network in the return set is contained by the network > > However, a "more-specific" search must not be an exact match: > > -M is networks where: > (start(network) >= start(search)) AND > (end(network) <= end(search)) AND > NOT ((start(network) = start(search)) AND > (end(network) = end(search))) > -m is all of the networks from -M, with the provisio that: > no other network in the return set contains the network Sorry, couldn't parse that last sentence. "no other network in the return set contains the network"? which network? huh? > (Note that the definition is not the best way to find the answer.) > > Any replacement for WHOIS would have to have at *least* this much > expressiveness. I realize that this is currently what the RIPE WHOIS servers do, but are there specific reasons why some of these rules exist? For instance, if the "more-specific" supernet search (-l) was able to return exact matches, would you even need (-x)? > > Also, I would sort of think that searching for network blocks (IPv4 or > > IPv6) would be one of the most basic points of the service, so should the > > ability to search for them be a SHOULD? > > Agreed. This information, in some form, needs to make it into the requirements document as MUSTs. Or maybe some subset of these searches are MUSTs and some are SHOULDs. -- David Blacka Sr. Engineer Verisign Applied Research From anewton at ecotroph.net Tue Aug 19 13:00:51 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 19 11:34:01 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <3F4224A1.3020808@daasi.de> References: <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> <3F4224A1.3020808@daasi.de> Message-ID: <3F4249B3.7060109@ecotroph.net> Peter Gietz wrote: >> >> I know LDAP has authentication baked-in, but I don't really know how >> it applies to the FIRS universe. This could be a win for the LDAP >> implementation. > > > Yes you can even choose between a number of authentication mechanisms, > e.g. userpassword via an encrypted TLS session, MD5 chalenge response > (no password goes through the wire) via SASL, any other SASL mechanism. As a point of comparison, IRIS uses BEEP which has SASL as well. I'd also like to point out that if you have a custom data store on your LDAP server, all that built-in authorization stuff goes out the window. This is a point that keeps getting glossed over by the LDAP crowd here. Most of us already have our own databases and loading and replication procedures. RIPE has this nifty software that does incredibly fast radix indexing specifically to solve their unique problems. We have a couple of million dollars invested in custom global replication technology. I know our competitors have also spent tons of money fine tuning their systems for their operations. The point is, that for the people standing up these servers, LDAP is only a protocol. The implementations are nice, but they don't help us. > By now the XML database technology is not near as mature and well > established as LDAP. You don't even have a single standardized acces > protocol, but competing ones (Xquery, XMLquery, Xpath, XQL, ...). I > don't know of any native XML database implementation that has inbuilt > features like authentication, access control, replication. Most > implementations use an SQL backend to an XML frontend. The mapping of > the (hierarchical!) XML information model to the (non hierarchical) > relational model is not very intuitive. As mentioned above, the question isn't about generic XML database technology vs. generic LDAP technology. I suspect that I would end up making some of the same criticisms about generalized XML database implementation as I would about LDAP implementations. And there are certainly a few of those wacky X* standards that are nothing but trouble. To address Richard's point about economics: one of the things that we must take into consideration is reuse of expertise of our technical staff. Even if we don't reuse a single line of custom code, we still have to find people with expertise. Most of us already have people very familiar with XML. We know which XML parsers work for us and we know how to marshal it back and forth between our existing databases. -andy From davidb at verisignlabs.com Tue Aug 19 12:34:03 2003 From: davidb at verisignlabs.com (David Blacka) Date: Tue Aug 19 11:37:55 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F4249B3.7060109@ecotroph.net> References: <20030814114544.L71867@shell-ng.nominum.com> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> Message-ID: <200308191134.03307.davidb@verisignlabs.com> In the hope that this will be useful, I thought I would describe the intellectual journey that led me (and Mr. Newton) to IRIS. I thought it might be useful to give this story a slightly more personal spin, although Andy has pretty much documented everything in his draft describing our LDAP project (http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt) and some of the conclusions drawn from it (appendix C of the IRIS core draft). Feel free correct any inaccuracies you feel that I've made. -- In the beginning (I am thinking 1999 or so), when my group started looking into WHOIS alternatives, LDAP was a tough sell. A number of us (with one exception) were avowed LDAP haters. As folks used to dealing with prosaic protocols like SMTP and NNTP, LDAP's BER encoding was hard to swallow (We can't see what is going on with tcpdump! I can't use telnet as my client!). LDAP itself was a confusing array of alien terminology. It was really hard for us to get through an LDAP RFC. Ultimately, however, we got over it, due to our one persistent team member who knew better. In 2000 (I think, I could have the dates wrong), we started looking very seriously at using LDAP to replace WHOIS. After all, it had a bunch of bits that we wanted: granular ACLs, referrals, and a fair amount of existing software. We realized that LDAP had a lot to offer and our previous complaints were superficial at best. Our first approach was to see if we could find an existing LDAP server that could handle our existing WHOIS data load and query rates. We had about 20 million objects all told (domains, hosts, and contacts. It is more than that now). I don't really remember the query rates, but we were hoping for hundreds of queries per second. We spent about a year looking. That is when we learned our first lesson: * LDAP servers are hard to scale. A provocative statement, I'm sure. All of the advertising literature we got for every LDAP server said that it would handle "millions" of objects. We didn't do exhaustive testing, so it is quite possible that some other set of millions of objects might actually work with those servers. But not ours (and by extension, any other domain registry/registrar's). We couldn't even load a significant fraction of our data into many of them. We were drawn to the few LDAP servers that were ultimately based on RDBMSs. On those, we could load the data (if I remember correctly), but the query speeds were not good, and the database sizes were huge. Our 3 GB database turned into a 60 GB database, just by loading into the LDAP server. Lesson 2: * Forcing data into a generic LDAP DIT causes significant data bloat. You could easily slow the whole system by asking 'hard' questions (i.e., any subtree searches rooted at a TLD). The servers didn't do referrals well (at least one so-called LDAP v3 compliant server didn't actually do LDAP v3 referrals!). Then we ran into our show stopper: a compliant LDAP server must return all referrals in scope. As we were trying to have registry domain objects refer to their registrar entry, this was a serious problem. Keep in mind that automatically followed registry to registrar referrals was one of the motivating factors in trying to replace WHOIS in the first place. This rule essentially made subtree searches against our DIT useless. You see, any subtree query rooted at a tld (or higher in the DIT) would immediately have to return all of the referrals contained within that subtree. Or (at the registry level) one for every domain. In other words, millions of referrals. Lesson 3: * LDAP referrals are for gluing DITs together, and thus are not generally useful for registry-registrar referrals. We needed them to work more like DNS referrals: only referrals that matched the search criteria (or whose parents matched the search criteria) would be returned. During this process, we believed in LDAP. But it was slowly dawning on us that "stock" LDAP servers weren't going to work. However, we were determined to make LDAP work. So, we moved on to the next approach: a custom datastore plugin. This would allow us to control the database size (indeed, we would use our source database), and control when referrals would be returned (even though this technically violated the spec.) Then we learned Lesson 4: * LDAP datastore plugins take a lot of work. Our plugin would map a more naturally normalized database of domain information into a DIT. It would translate queries into SQL. It would translate result rows into LDAP objects. Initially our plan was to create sort of a generic mapper that would take arbitrary LDAP searches and translate them into SQL. We learned that all sorts of horribly inefficient queries would result. (RDBMS-based LDAP servers essentially index every attribute-value to handle this.) We decided to allow a number of specific queries that matched our known use cases. All other queries were explicitly disallowed. The number of allowed queries was pretty small when compared to the number of disallowed queries. Thus Lesson 5 was learned: * The LDAP query language (generally) must be severely constrained when using a custom datastore. Our work on the client side is less familiar to me, but I do know that it became quickly apparent that 'ldapsearch' was not at all sufficient as a client of this service. Custom client code using LDAP libraries was necessary. We did find pretty good LDAP client libraries. I remember particularly liking Netscape's Java LDAP SDK. Lesson 6: * This problem domain requires custom clients. Generic LDAP clients are not sufficient. In the end, we got this to work. The results are still available at http://rldap.verisignlabs.com. You may wish to keep in mind that the RLDAP project was far more heavily focused on reuse than FIRS: it strove to not introduce any new objectclasses, attributes, controls or extended matching rules. But when we finished, we realized that if we had to 1) essentially create a custom LDAP server and 2) create custom clients, reusing LDAP was losing its appeal. Creating a WHOIS replacement using LDAP was requiring a fair amount of "bending", and even when we were done, the solution was far from ideal. We started to realize that real, global directory service applications were going to always be essentially custom directory applications. Real directory service clients were going to be custom clients. Why not define a directory service protocol that lent itself to being *good* at custom directory services. This led us to a philosophy that, ultimately, led to IRIS. -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Tue Aug 19 11:47:46 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 11:47:54 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <3F4249B3.7060109@ecotroph.net> References: <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> Message-ID: <3F4246A2.4060806@ehsco.com> on 8/19/2003 11:00 AM Andrew Newton wrote: > This is a point that keeps getting glossed over by the LDAP crowd here. > Most of us already have our own databases and loading and replication > procedures. RIPE has this nifty software that does incredibly fast > radix indexing specifically to solve their unique problems. We have a > couple of million dollars invested in custom global replication > technology. I know our competitors have also spent tons of money fine > tuning their systems for their operations. > > The point is, that for the people standing up these servers, LDAP is > only a protocol. The implementations are nice, but they don't help us. The other point that keeps getting glossed is that there are a huge number of potential providers in a directory of Internet resources, not all of whom are going to be affected by these restrictions. If we start getting into things like having organizations run public directory partitions for things like public keys or mail-routing data or whatever, then it doesn't make sense to REQUIRE that these people also pay the costs required for your line-of-business in particular, but that's what you're advocating. Essentially your argument is "my business makes me build and manage complex distributed database so everybody else should too, dammit!", which is not only ridiculous and obscene but is ultimately going to be a major hurdle towards the directory actually getting used for a whole lot more than what we've got today. Look, I'm all for Direct Democracy and having constituents vote their interests, but that decision process depends heavily on the constituents accurately representing the affected community and being informed about the choices. IMO, we have satisfied neither of these considerations at this point. Instead, we have a vocal mob from a demographically-tiny group, most of whom apparently haven't even read the specs. My feeling at this point is that we'd be best off by going with some representative democracy. Let's recruit some people who we know can think beyond their immediate benefits and who have the technical chops to understand the longer term issues. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Tue Aug 19 12:10:20 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 12:10:28 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <200308191134.03307.davidb@verisignlabs.com> References: <20030814114544.L71867@shell-ng.nominum.com> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> <200308191134.03307.davidb@verisignlabs.com> Message-ID: <3F424BEC.2050104@ehsco.com> on 8/19/2003 10:34 AM David Blacka wrote: I don't doubt that you ran into the difficulties you did as a result of trying to pursue the course you chose. > You may wish to keep in mind that the RLDAP project was far more > heavily focused on reuse than FIRS: it strove to not introduce any new > objectclasses, attributes, controls or extended matching rules. Exactly right. A couple of the problems you encountered would still exist with FIRS, but for the most part, starting with a different objective (optimizing the application space accordingly) would have produced some significantly different result. As you allude to in the text above (and which would probably have been more helpful as intro text rather than outro by-the-way), your path doesn't really say much about how well the FIRS approach would work. > But when we finished, we realized that if we had to 1) essentially > create a custom LDAP server and 2) create custom clients, reusing LDAP > was losing its appeal. Yes, FIRS optimizes the client and server. Whether or not this diminishes the primary benefit depends on how you define the benefit. If your target was to reuse LDAP browsers, I can see how the evidence would support that conclusion. On the other hand, if the target is general data-availability and reuse, then I would argue that the objective was proven once the assumptions were adjusted. > This led us to a philosophy that, ultimately, led to IRIS. Could you possibly clarify how IRIS addresses either of the targets described above? I mean, there are a whole lot less clients and servers out there, so reusing technology isn't a benefit, nor is reusing data. Perhaps you redefined your objectives along the way? And if so, what are they now? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From richard at shockey.us Tue Aug 19 13:39:30 2003 From: richard at shockey.us (Richard Shockey) Date: Tue Aug 19 12:39:51 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <3F4246A2.4060806@ehsco.com> References: <3F4249B3.7060109@ecotroph.net> <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> Message-ID: <5.2.0.9.2.20030819122304.03b62e88@shockey.us> A > > > > The point is, that for the people standing up these servers, LDAP is > > only a protocol. The implementations are nice, but they don't help us. > >The other point that keeps getting glossed is that there are a huge number >of potential providers in a directory of Internet resources, not all of >whom are going to be affected by these restrictions. If we start getting >into things like having organizations run public directory partitions for >things like public keys or mail-routing data or whatever, then it doesn't >make sense to REQUIRE that these people also pay the costs required for >your line-of-business in particular, but that's what you're advocating. >Essentially your argument is "my business makes me build and manage >complex distributed database so everybody else should too, dammit!", which >is not only ridiculous and obscene but is ultimately going to be a major >hurdle towards the directory actually getting used for a whole lot more >than what we've got today. You are zeroing in on a key disconnect here ..is CRISP a database or a directory? I think its a database. The semantical difference is fine but it defines the perspective some have on the CRISP problem statement in general. The excellent historical perspective from David Blacka completely re-confirms my judgement and reinforces my opposition to a FIRS solution. Oh and last but not least ... irrespective of my employer, where we do manage two TLD's. I'm also the co-chair of the ENUM WG and if Verisign has trouble scaling LDAP to 20M entries what would we do with the 230M entries in the North American Numbering Plan, for instance?? It has been my high hope from the beginning of this WG that a CRISP solution could be reused by the various National ENUM administrations sprouting up all over the planet. We are already getting requirements thrown at us for a database of technical contacts for the FQDN's RFC 2916 defines. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From ehall at ehsco.com Tue Aug 19 12:54:49 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 12:54:56 2003 Subject: [Ietf-not43] scope Message-ID: <3F425659.1030006@ehsco.com> It seems to me that the fundamental question continues to be one of service scope: do we believe that the service will ultimately be measured by the existing ~whois providers, or by user-to-user edge deployments. Let's consider DNS as an analagous service. The core functionality (name resolution) started as a tightly-centralized service (HOSTS.TXT), evolved into a distributed service (this is the junction where we are with CRISP), but eventually became dominated by edge-based deployments, with orgs running their own servers, and with user-to-user schema dominating the query traffic. In my opinion, we are heading down that same path with CRISP. We already know that there are currently-deployed applications out there that need a lookup-plus-search service which supports ACLs, large messages (larger than the DNS maximum of 64k anyway), comprehensive searches, and several other features. We already know that there is a pent-up demand for as-yet-uninvented applications that require the pre-existence of such a service before the applications themselves can be developed. And looking at the history of services like DNS (and SMTP, and so forth), we also know the user community has a willingness to deploy edge solutions. That's what I think we're talking about as the ultimate target here. The central-service community is certainly important, but it's not more important than the ultimate objective. Furthermore, we won't get another chance at this for a very long time, if ever. What makes this work so important is that it is moving the central data into a distributed model, which is the necessary step towards moving towards a heavily-distributed mesh of edges. There probably won't be another chance at this. So again I ask you to consider the central issue, which is ultimately about the potential scope of the service. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From davidb at verisignlabs.com Tue Aug 19 13:56:04 2003 From: davidb at verisignlabs.com (David Blacka) Date: Tue Aug 19 12:59:53 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F424BEC.2050104@ehsco.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> Message-ID: <200308191256.04400.davidb@verisignlabs.com> On Tuesday 19 August 2003 12:10 pm, Eric A. Hall wrote: > > on 8/19/2003 10:34 AM David Blacka wrote: > > I don't doubt that you ran into the difficulties you did as a result of > trying to pursue the course you chose. > > > You may wish to keep in mind that the RLDAP project was far more > > heavily focused on reuse than FIRS: it strove to not introduce any new > > objectclasses, attributes, controls or extended matching rules. > > Exactly right. A couple of the problems you encountered would still exist > with FIRS, but for the most part, starting with a different objective > (optimizing the application space accordingly) would have produced some > significantly different result. As you allude to in the text above (and > which would probably have been more helpful as intro text rather than > outro by-the-way), your path doesn't really say much about how well the > FIRS approach would work. As far as I can tell, FIRS would be harder to implement at our level, not easier. Which of the problems that I described would be alleviated by FIRS? I will admit that I don't entirely grok FIRS. It certainly looks like the client side would be harder (than RLDAP clients). One of the main things that I wanted to show through my story was that we ultimately rejected LDAP for actual, valid, non-religious reasons. > > But when we finished, we realized that if we had to 1) essentially > > create a custom LDAP server and 2) create custom clients, reusing LDAP > > was losing its appeal. > > Yes, FIRS optimizes the client and server. Whether or not this diminishes > the primary benefit depends on how you define the benefit. If your target > was to reuse LDAP browsers, I can see how the evidence would support that > conclusion. On the other hand, if the target is general data-availability > and reuse, then I would argue that the objective was proven once the > assumptions were adjusted. Our target was to use technology that would reduce implementation costs on both the client and server sides. And the project proved to us that LDAP (in this case) did not do that. And honestly, from what I can tell (and again, I might be wrong), FIRS is a move in the opposite direction from that target. > > This led us to a philosophy that, ultimately, led to IRIS. > > Could you possibly clarify how IRIS addresses either of the targets > described above? I mean, there are a whole lot less clients and servers > out there, so reusing technology isn't a benefit, nor is reusing data. I think I don't know what you are talking about when you say "reusing data". What data? The move towards IRIS was a move towards doing software reuse at a different level. IRIS certainly reuses technology, just not an entire application substrate. There aren't many FIRS clients and servers out there either. One of the points I hoped folks might draw from my little story was that for those organizations that will *have* to stand up a CRISP service, they aren't any closer to implementing a FIRS solution than an IRIS one. > Perhaps you redefined your objectives along the way? And if so, what are > they now? I don't think we redefined our objectives at all. Fundamentally what we did was change our engineering approach. And I, at least, changed my underlying directory service philosophy. -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Tue Aug 19 13:02:20 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 13:02:27 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <5.2.0.9.2.20030819122304.03b62e88@shockey.us> References: <3F4249B3.7060109@ecotroph.net> <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> <5.2.0.9.2.20030819122304.03b62e88@shockey.us> Message-ID: <3F42581C.2070602@ehsco.com> on 8/19/2003 11:39 AM Richard Shockey wrote: > The excellent historical perspective from David Blacka completely > re-confirms my judgement and reinforces my opposition to a FIRS solution. That's too bad, since he admits that their experience doesn't represent the FIRS approach. > Oh and last but not least ... irrespective of my employer, where we do > manage two TLD's. I'm also the co-chair of the ENUM WG and if Verisign has > trouble scaling LDAP to 20M entries what would we do with the 230M entries > in the North American Numbering Plan, for instance?? > > It has been my high hope from the beginning of this WG that a CRISP > solution could be reused by the various National ENUM administrations > sprouting up all over the planet. We are already getting requirements > thrown at us for a database of technical contacts for the FQDN's RFC 2916 > defines. I'm glad you brought up ENUM, because I didn't want to. That service has actually been in the back of my mind while doing this work, and I think it's a fine illustration of the canonical issues. First of all, there is a question of whether or not a centralized database of phone/contact data is even the right approach. I'm not going to argue either way right now, but there is plenty of evidence to suggest that trying to support billions of phones looking up billions of phone numbers isn't practical in a central model, even using lightweight DNS datagrams. Secondarily, the technology deployment curves also suggest that the long-term use will be distributed directories of locally-manged numbers and data, with gateways publishing their own details rather than trying to synchronize with a centralized repository. Along the same lines, being able to manage things like ACLs is going to require pushing the service closer to the user (EG, ~I want my boss to have my home phone, but not any of the other employees, while my wife gets the cell and everything else). So there is some argument that a service like ENUM (if not that service itself) would eventually be best served by a distributed directory rather than a central database. We need to be planning for this eventuality. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Tue Aug 19 14:58:07 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 19 13:31:13 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F4165A1.1030505@ehsco.com> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> Message-ID: <3F42652F.3010609@ecotroph.net> Eric A. Hall wrote: 1 > A referral entry: 2 > 3 > cn=www.example.com,cn=... 4 > cn: www.example.com 5 > objectClass: top 6 > objectClass: inetResources 7 > objectClass: inetDnsDomain 8 > objectClass: referral 9 > ref: ldap:///cn=host1.example.net,cn=inetResources,dc=... 10 > 11 > [No other attributes allowed.] I think the confusion is over lines 7 & 8. How could it be either-or when your text says "also"? Anyway, I believe I understand what you are saying. I believe this comes down to a difference between 2251 style referrals and the named subordinate references in 3296. After reading 3296, it would seem my original point is still somewhat valid because your draft does not mention the use of the manageDsaIT control. You should add text requiring the recognition of it by the server and the use of it by the client. Otherwise, all those domain variants you mentioned will fill up the result set before any valid response. I also do not see where the thin registry model referral/reference is defined. But that should be a simple addition, correct? -andy From ehall at ehsco.com Tue Aug 19 14:00:59 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 14:01:18 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <200308191256.04400.davidb@verisignlabs.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> Message-ID: <3F4265DB.8070808@ehsco.com> on 8/19/2003 11:56 AM David Blacka wrote: >> Exactly right. A couple of the problems you encountered would still >> exist with FIRS, but for the most part, starting with a different >> objective (optimizing the application space accordingly) would have >> produced some significantly different result. As you allude to in the >> text above (and which would probably have been more helpful as intro >> text rather than outro by-the-way), your path doesn't really say much >> about how well the FIRS approach would work. > > As far as I can tell, FIRS would be harder to implement at our level, > not easier. Which of the problems that I described would be alleviated > by FIRS? It seems to me that most of the problems you encountered on the way to a working solution would have been avoided by a recognition that generic tools weren't going to do the job. The FIRS approach would have moved you to what eventually did work for you. The central theme with FIRS is to populate the data substrate, but to optimize the application space. In particular, "FIRS" is just a stovepipe vertical application into the data substrate. The idea is that once the substrate is populated, other stovepipes will poke into it, sucking data out and putting new data in. The degree to which any of those may require application-specific logic will depend on the application. Some of them will need some local logic and no server logic -- "give me the host certificate for this mail server/user" would only require client processing -- while others will require additional back-end logic. FIRS the service focuses on high volume, centralized delegation data, so it falls into the latter in the general case, but it also off-loads significant processing onto the front-end to minimize the back-end burden (normalization of i18n domain names being an obvious example of this, where back-end normalization would crush the servers). There are also a couple of areas in FIRS where the client does all of the work; contact lookups are equality matches, for example, with the client doing all of the prep work. > I will admit that I don't entirely grok FIRS. It certainly > looks like the client side would be harder (than RLDAP clients). It is necessarily more tuned, but I don't see this as an indictment. Any client that is part of a distributed system require custom clients. This even applies to legacy WHOIS, for example, where either the client has to perform local processing, or it uses an application proxy which is essentially a remote client. > Our target was to use technology that would reduce implementation costs > on both the client and server sides. And the project proved to us that > LDAP (in this case) did not do that. How is IRIS cheaper on the client side for this specific application? You have to do even more work, given the lower availability of tools (no BEEP perl module, for example). For the same reasons, I don't see how IRIS could possibly be cheaper for lightweight (edge-distributed) servers that do not require additional processing (eg, publishing certificate data), given that there are numerous servers available to choose from which could do the job as soon as the schema were installed. Andy said in another message that the server deployments for ~this applicaiton were relatively equal. Meanwhile, the learning-curve costs you describe were essentially amortized on the back of RLDAP. You didn't have to make the same mistakes with IRIS, and had better expectations going into it, so it would be expected to have been cheaper and faster. As noted multiple times, however, these costs are not globally applicable. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Tue Aug 19 15:57:39 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 19 14:30:45 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F4265DB.8070808@ehsco.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> <3F4265DB.8070808@ehsco.com> Message-ID: <3F427323.5020204@ecotroph.net> Eric A. Hall wrote: > > How is IRIS cheaper on the client side for this specific application? You > have to do even more work, given the lower availability of tools (no BEEP > perl module, for example). Quit attacking BEEP. If you cruise on over to http://beepcore.org you will see there are plenty of BEEP implementations out there, most of them are open source. There are probably more open source versions of BEEP than there are open source LDAP client libraries. This also brings up another point of comparison. If we decide that BEEP is not the correct answer, we can slide in another application transport because IRIS is a layered protocol. See my drafts on IRIS LWZ. > For the same reasons, I don't see how IRIS could possibly be cheaper for > lightweight (edge-distributed) servers that do not require additional > processing (eg, publishing certificate data), given that there are > numerous servers available to choose from which could do the job as soon > as the schema were installed. Again, you are blurring the lines between protocol and implementation. Flowerbed is cheap and lightweight. > Andy said in another message that the server deployments for ~this > applicaiton were relatively equal. No, I said LDAP did not offer an advantage. You are the one who equated them. -andy From hardie at qualcomm.com Tue Aug 19 11:25:35 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Tue Aug 19 14:38:48 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F417E94.5000603@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> Message-ID: At 8:34 PM -0500 08/18/2003, Eric A. Hall wrote: >Not really. As it stands, it seems like the requirement is already being >satisfied. Quoting section 3.1.8.1 of reqs-5: > >| 3.1.8.1 Protocol Requirement >| >| The protocol MUST provide a mechanism allowing a client to determine >| if a query will be denied before the query is submitted according to >| the appropriate policies of the operator. > >There are already several bind error responses that tell a client that >they won't get service before they issue the query, so the requirement is >already being satisfied by the protocol (Peter said as much during his >presentation as well, and talked about other mechanisms as alternative >mechanisms). The alternatives have other costs, and I can imagine some >other mechanisms that could be useful for specific situations (like >hit-counters), but I'd like to hear what the operators think is needed >before I start extending the protocol even more. There seem to me too different cases here: 1) Server needs to say "I won't provide $YOU with service" and 2)Server needs to say "I won't return results to $QUERY to $YOU". I understand how the bind mechanisms apply to 1. The question, as I understand it, is how to satisfy 2. If there are multiple ways it could be solved in FIRS, could you please pick any one of them and describe it in medium-level detail, so that we can move past the question of whether this requirement is met? thanks, Ted Hardie From ehall at ehsco.com Tue Aug 19 14:50:03 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 14:50:09 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <20030819183028.GB1568@verisignlabs.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> <3F4265DB.8070808@ehsco.com> <20030819183028.GB1568@verisignlabs.com> Message-ID: <3F42715B.7050109@ehsco.com> on 8/19/2003 1:30 PM Mark Kosters wrote: > On Tue, Aug 19, 2003 at 01:00:59PM -0500, Eric A. Hall wrote: > >> The central theme with FIRS is to populate the data substrate, but to >> optimize the application space. In particular, "FIRS" is just a >> stovepipe vertical application into the data substrate. The idea is >> that once the substrate is populated, other stovepipes will poke into >> it, sucking data out and putting new data in. > > This is the holy grail that we all hope to achieve with a better > protocol. Unfortunately, all past efforts failed (X.500, RWhois, > whois++) given they tried to point too high trying to achieve the holy > grail and did not solve the immediate problem first. I think if set our > sites a bit lower and can do the best we can do in having a protocol > that solves the registry problems, we may have something that can usurp > whois. I think that's what has me hot: Nobody has said this won't do it, and instead are looking at religion and short-term interests. But let's be positive. Could somebody from the other camp give some discussion on how they see IRIS satisfying the longer-term issues. AFAICT there's no focus on unified substrate in IRIS. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From markk at verisignlabs.com Tue Aug 19 15:30:28 2003 From: markk at verisignlabs.com (Mark Kosters) Date: Tue Aug 19 14:58:48 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F4265DB.8070808@ehsco.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> <3F4265DB.8070808@ehsco.com> Message-ID: <20030819183028.GB1568@verisignlabs.com> On Tue, Aug 19, 2003 at 01:00:59PM -0500, Eric A. Hall wrote: > The central theme with FIRS is to populate the data substrate, but to > optimize the application space. In particular, "FIRS" is just a stovepipe > vertical application into the data substrate. The idea is that once the > substrate is populated, other stovepipes will poke into it, sucking data > out and putting new data in. This is the holy grail that we all hope to achieve with a better protocol. Unfortunately, all past efforts failed (X.500, RWhois, whois++) given they tried to point too high trying to achieve the holy grail and did not solve the immediate problem first. I think if set our sites a bit lower and can do the best we can do in having a protocol that solves the registry problems, we may have something that can usurp whois. Mark From anewton at ecotroph.net Tue Aug 19 16:41:18 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 19 15:14:25 2003 Subject: [Ietf-not43] out of scope In-Reply-To: <3F425659.1030006@ehsco.com> References: <3F425659.1030006@ehsco.com> Message-ID: <3F427D5E.1010105@ecotroph.net> Actually, I'd like to declare this out of scope. We have no requirements for unified data substrates, edge-to-edge services, user-to-user schemas, life, the universe, everything, etc... These are all Layer 10 (Religious) issues. We could yell at each other all day long, but at the end of the day I doubt any hearts or minds will have been swayed. Plus, we have that warning from April. -andy Eric A. Hall wrote: > It seems to me that the fundamental question continues to be one of > service scope: do we believe that the service will ultimately be measured > by the existing ~whois providers, or by user-to-user edge deployments. > > Let's consider DNS as an analagous service. The core functionality (name > resolution) started as a tightly-centralized service (HOSTS.TXT), evolved > into a distributed service (this is the junction where we are with CRISP), > but eventually became dominated by edge-based deployments, with orgs > running their own servers, and with user-to-user schema dominating the > query traffic. > > In my opinion, we are heading down that same path with CRISP. We already > know that there are currently-deployed applications out there that need a > lookup-plus-search service which supports ACLs, large messages (larger > than the DNS maximum of 64k anyway), comprehensive searches, and several > other features. We already know that there is a pent-up demand for > as-yet-uninvented applications that require the pre-existence of such a > service before the applications themselves can be developed. And looking > at the history of services like DNS (and SMTP, and so forth), we also know > the user community has a willingness to deploy edge solutions. > > That's what I think we're talking about as the ultimate target here. The > central-service community is certainly important, but it's not more > important than the ultimate objective. > > Furthermore, we won't get another chance at this for a very long time, if > ever. What makes this work so important is that it is moving the central > data into a distributed model, which is the necessary step towards moving > towards a heavily-distributed mesh of edges. There probably won't be > another chance at this. > > So again I ask you to consider the central issue, which is ultimately > about the potential scope of the service. > From ehall at ehsco.com Tue Aug 19 15:29:25 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 15:29:32 2003 Subject: [Ietf-not43] out of scope In-Reply-To: <3F427D5E.1010105@ecotroph.net> References: <3F425659.1030006@ehsco.com> <3F427D5E.1010105@ecotroph.net> Message-ID: <3F427A95.5050400@ehsco.com> on 8/19/2003 2:41 PM Andrew Newton wrote: > Actually, I'd like to declare this out of scope. There's a shocker > We have no requirements for unified data substrates, We certainly had this at the beginning when the requirements were for domains, addresses and users in a universal service, before this was whittled down to just domains by the IESG (not by us). > edge-to-edge services, user-to-user schemas Is it out of scope to expect the obvious? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From April.Marine at nominum.com Tue Aug 19 13:33:00 2003 From: April.Marine at nominum.com (April Marine) Date: Tue Aug 19 15:33:04 2003 Subject: [Ietf-not43] out of scope In-Reply-To: <3F427A95.5050400@ehsco.com> References: <3F425659.1030006@ehsco.com> <3F427D5E.1010105@ecotroph.net> <3F427A95.5050400@ehsco.com> Message-ID: <20030819123105.S88206@shell-ng.nominum.com> Just to be clear, we are considering our candidate protocols as to how well they conform to the requirements in the requirements doc. That's why we took so much time and care on that doc, cuz it makes this stage of the process so much easier! ;) thanks, April From richard at shockey.us Tue Aug 19 16:34:55 2003 From: richard at shockey.us (Richard Shockey) Date: Tue Aug 19 15:35:08 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F42715B.7050109@ehsco.com> References: <20030819183028.GB1568@verisignlabs.com> <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> <3F4265DB.8070808@ehsco.com> <20030819183028.GB1568@verisignlabs.com> Message-ID: <5.2.0.9.2.20030819150402.03919eb0@shockey.us> > > >> The central theme with FIRS is to populate the data substrate, but to > >> optimize the application space. In particular, "FIRS" is just a > >> stovepipe vertical application into the data substrate. The idea is > >> that once the substrate is populated, other stovepipes will poke into > >> it, sucking data out and putting new data in. > > > > This is the holy grail that we all hope to achieve with a better > > protocol. Unfortunately, all past efforts failed (X.500, RWhois, > > whois++) given they tried to point too high trying to achieve the holy > > grail and did not solve the immediate problem first. I think if set our > > sites a bit lower and can do the best we can do in having a protocol > > that solves the registry problems, we may have something that can usurp > > whois. > >I think that's what has me hot: Nobody has said this won't do it, and >instead are looking at religion and short-term interests. Well we have stipulated that for all practical purposes the two proposed protocols _on paper_ will meet the requirements its just that we don't want to use FIRS for very very practical and economic reasons as well as the technical reasons David Blaka has demonstrated to my satisfaction. That is not a short term view it is the reality of the Domain Name business. In case you had not heard its a highly competitive, mature business that is still trying to recover from the irrational exuberance of the past few years. Lots of TLD's are struggling to financially survive. If it is technically "challenging" or expensive to implement a protocol the registry community will not do it or delay its implementation. ( DNSSEC ..sorry :-) ) Especially among those of us that actually have to A. go capital expenditure budget meetings or B. actually have to do the work. From our perspective Mark Kosters is entirely correct ..I'm not interested in "holy grail" solutions either I want to see the existing problems in WHOIS corrected and made more flexible and extensible. IRIS meets those tests and integrates very nicely with the other XML query response platforms under construction. I'm sold. I personally apologize to the WG chairs who I know would have preferred a more technically oriented discussion but .... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 or ; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From wessorh at ar.com Tue Aug 19 13:47:19 2003 From: wessorh at ar.com (Rick Wesson) Date: Tue Aug 19 15:47:16 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <5.2.0.9.2.20030819150402.03919eb0@shockey.us> Message-ID: I definately agree with Rich here. I fer specify overly complex protocols registrars and registries wil drag their feet or just down rite ignore it until ICANN puts it as a requirement in a contract. As long as we are dealing with domains we MUST recognize that adoption is a real issue and if the spec is overly complex its not gonna get implemented till ICANN enforces its mandate. I'd prefer the specifications be compelling enough that registrars would adopt them because they soleve problems with :43 -rick Rick Wesson CTO, DNSO Registrars Constituency CEO, Alice's Registry > That is not a short term view it is the reality of the Domain Name > business. In case you had not heard its a highly competitive, mature > business that is still trying to recover from the irrational exuberance of > the past few years. Lots of TLD's are struggling to financially survive. > > If it is technically "challenging" or expensive to implement a protocol the > registry community will not do it or delay its implementation. ( DNSSEC > ..sorry :-) ) Especially among those of us that actually have to A. go > capital expenditure budget meetings or B. actually have to do the work. > > From our perspective Mark Kosters is entirely correct ..I'm not interested > in "holy grail" solutions either I want to see the existing problems in > WHOIS corrected and made more flexible and extensible. IRIS meets those > tests and integrates very nicely with the other XML query response > platforms under construction. I'm sold. > From hardie at qualcomm.com Tue Aug 19 15:00:59 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Tue Aug 19 17:01:30 2003 Subject: [Ietf-not43] Is it just me or is there a desire here to avoid the chair's request.. In-Reply-To: <5.2.0.9.2.20030819122304.03b62e88@shockey.us> References: <3F4249B3.7060109@ecotroph.net> <20030814114544.L71867@shell-ng.nominum.com> <20030814114544.L71867@shell-ng.nominum.com> <5.2.0.9.2.20030818172656.035e4cd8@shockey.us> <3F42168A.6090004@ripe.net> <3F4224A1.3020808@daasi.de> <3F4249B3.7060109@ecotroph.net> <5.2.0.9.2.20030819122304.03b62e88@shockey.us> Message-ID: At 12:39 PM -0400 08/19/2003, Richard Shockey wrote: > >You are zeroing in on a key disconnect here ..is CRISP a database or >a directory? I think its a database. The semantical difference is >fine but it defines the perspective some have on the CRISP problem >statement in general. Perhaps a quick quote of the salient charter text would be useful here: The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for finding authoritative information associated with a label, a protocol to transport queries and responses for accessing that information, and a first profile (schema & queries) to support commonly-required queries for domain registration information. Backwards compatibility with existing administrative directory services such as WHOIS is not a goal of this effort. Provisioning of data into registry or registrar systems is likewise out of scope -- CRISP provides a uniform access to and view of data that may be held in disparate backend servers. While the framework created will hopefully be sufficiently flexible to allow re-use by other registries/services with related design criteria, those uses will be deferred to the creation of appropriate schema & query profiles at some future date. The statement in what CRISP is not is probably the most concise: CRISP provides a uniform access to and view of data that may be held in disparate backed servers. Because the focus is on access, CRISP might be said to be a directory service (though not strictly a directory); and it may rely on (but is not) a database. regards, Ted Hardie From ehall at ehsco.com Tue Aug 19 17:54:52 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 19 17:54:59 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> Message-ID: <3F429CAC.4080206@ehsco.com> on 8/19/2003 12:25 PM hardie@qualcomm.com wrote: > There seem to me too different cases here: > > 1) Server needs to say "I won't provide $YOU with service" > > and > > 2)Server needs to say "I won't return results to $QUERY to $YOU". > > I understand how the bind mechanisms apply to 1. The question, > as I understand it, is how to satisfy 2. If there are multiple ways > it could be solved in FIRS, could you please pick any one of them > and describe it in medium-level detail, so that we can move past > the question of whether this requirement is met? I have added the following sentence to the discussion on the firsVersion control in core-03 (not-yet published): Servers MAY adjust the list of supported resource types as necessary or desirable. This essentially means that a server can tell client-X that a particular resource is supported while telling client-Y that the exact same resource is not supported. Since the firsVersion control is encouraged to be returned in response to a successful bind, this mechanism imposes no additional mandatory round-trips. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From hardie at qualcomm.com Tue Aug 19 20:32:45 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Tue Aug 19 22:33:02 2003 Subject: [Ietf-not43] a perspective on LDAP v IRIS. In-Reply-To: <3F42715B.7050109@ehsco.com> References: <20030814114544.L71867@shell-ng.nominum.com> <200308191134.03307.davidb@verisignlabs.com> <3F424BEC.2050104@ehsco.com> <200308191256.04400.davidb@verisignlabs.com> <3F4265DB.8070808@ehsco.com> <20030819183028.GB1568@verisignlabs.com> <3F42715B.7050109@ehsco.com> Message-ID: At 1:50 PM -0500 08/19/2003, Eric A. Hall wrote: >on 8/19/2003 1:30 PM Mark Kosters wrote: > >> On Tue, Aug 19, 2003 at 01:00:59PM -0500, Eric A. Hall wrote: >> >>> The central theme with FIRS is to populate the data substrate, but to >>> optimize the application space. In particular, "FIRS" is just a >>> stovepipe vertical application into the data substrate. The idea is >>> that once the substrate is populated, other stovepipes will poke into >>> it, sucking data out and putting new data in. >> >> This is the holy grail that we all hope to achieve with a better >> protocol. Unfortunately, all past efforts failed (X.500, RWhois, >> whois++) given they tried to point too high trying to achieve the holy >> grail and did not solve the immediate problem first. I think if set our >> sites a bit lower and can do the best we can do in having a protocol >> that solves the registry problems, we may have something that can usurp >> whois. > >I think that's what has me hot: Nobody has said this won't do it, and >instead are looking at religion and short-term interests. > >But let's be positive. Could somebody from the other camp give some >discussion on how they see IRIS satisfying the longer-term issues. AFAICT >there's no focus on unified substrate in IRIS. I'm not from the other camp, but let me join my co-chair in trying to refocus this discussion on the matter at hand. Unified substrates, efforts to have other stovepipes poking into that substrate, and holy grails are not our business here. Our goal is to meet our charter and develop a protocol that satisfies the items set out in our requirements document. Openness to extensibility is one of the things mentioned in the charter, but it is subordinate to meeting the needs of the chartered work items. On a more personal note, I'm sorry that you're feeling hot over this; I had hoped we would be able to avoid heat in this discussion and could focus on the technical issues at hand. I encourage everyone involved to take a moment and cool down. There are serious differences in the technical approaches brought forward in FIRS and IRIS, and I appreciate the effort that has been made to explore the development, deployment, and related costs associated with them. But we need to do that while focusing on our task, not on what might be built on top of the data store associated with our task or on tasks which may come up in the future. If it is not in the charter or requirements, please set it aside. As I said in the meeting in Vienna, it is also clear that each of these approaches will require custom clients and at least some work on servers (schemas if not extensions). We do not have the option of rapid deployment by allowing "standard" clients to access this application. Given that, we are fundamentally discussing two issues: how well suited are the building blocks in one approach to this task for reasons of scale, data model, accumulated experience (or cruft), and is what has been built out of those building blocks meeting the requirements that have been set forward? To be very clear, this is not LDAP vs. XML. This is "How do FIRS and IRIS meet the needs set out in the requirements, and what are the deployment scenarios, costs, advantages and disadvantages for this application?" Everyone participating in this discussion needs to read the documents, consider the question, and put forward your best engineering judgement on behalf of the Internet as a whole. That's the work of this working group, and, indeed, the IETF. regards, Ted Hardie From ehall at ehsco.com Wed Aug 20 06:44:10 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 20 06:44:17 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F42652F.3010609@ecotroph.net> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> <3F42652F.3010609@ecotroph.net> Message-ID: <3F4350FA.2090704@ehsco.com> on 8/19/2003 12:58 PM Andrew Newton wrote: > Eric A. Hall wrote: > 1 > A referral entry: > 2 > > 3 > cn=www.example.com,cn=... > 4 > cn: www.example.com > 5 > objectClass: top > 6 > objectClass: inetResources > 7 > objectClass: inetDnsDomain > 8 > objectClass: referral > 9 > ref: ldap:///cn=host1.example.net,cn=inetResources,dc=... > 10 > > 11 > [No other attributes allowed.] > > I think the confusion is over lines 7 & 8. How could it be either-or > when your text says "also"? Anyway, I believe I understand what you are > saying. As I said in the other message, that part of the text was in error and is already fixed in the -03 drafts. The modified text says that referrals must not be containers, must not have additional attributes, blah blah. It's explicitly either-or in the -03 texts. > I believe this comes down to a difference between 2251 style referrals > and the named subordinate references in 3296. After reading 3296, it > would seem my original point is still somewhat valid because your draft > does not mention the use of the manageDsaIT control. You should add > text requiring the recognition of it by the server and the use of it by > the client. That's not necessary. In the case of deployments that use packaged servers, the control would need to be provided as part of the referral service. In the case of servers that are going to be manipulating data in a private back-end, LDAP isn't going to be used for editing the referral data, but even if it is, RFC 3296 is the governing spec here not FIRS. In any event, I don't think it's appropriate or necessary to restate RFC 3296 requirements in the FIRS specs. > Otherwise, all those domain variants you mentioned will > fill up the result set before any valid response. I'm not sure what you mean by this. The manageDsaIT control provides a way for clients to edit an entry that contains referral data (in the default case, a request for the entry would cause the server to generate the referral, while the control says "no no, I want to change the entry not read it"). It doesn't have anything to do with the "size" of the result set to my knowledge. Am I misunderstanding you here? > I also do not see where the thin registry model referral/reference is > defined. But that should be a simple addition, correct? Something like that should probably go in the architecture guide rather than in the technical spec. I have some other text that I want to put in there already so this would be a good time to include anything else along those lines. What exactly do you think needs to be said here? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Wed Aug 20 14:41:09 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Wed Aug 20 07:41:27 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F429CAC.4080206@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> Message-ID: <3F435E55.7040705@daasi.de> Eric A. Hall wrote: > on 8/19/2003 12:25 PM hardie@qualcomm.com wrote: > > >>There seem to me too different cases here: >> >>1) Server needs to say "I won't provide $YOU with service" >> >>and >> >>2)Server needs to say "I won't return results to $QUERY to $YOU". >> >>I understand how the bind mechanisms apply to 1. The question, >>as I understand it, is how to satisfy 2. If there are multiple ways >>it could be solved in FIRS, could you please pick any one of them >>and describe it in medium-level detail, so that we can move past >>the question of whether this requirement is met? > > > I have added the following sentence to the discussion on the firsVersion > control in core-03 (not-yet published): > > Servers MAY adjust the list of supported resource types as necessary > or desirable. > > This essentially means that a server can tell client-X that a particular > resource is supported while telling client-Y that the exact same resource > is not supported. Since the firsVersion control is encouraged to be > returned in response to a successful bind, this mechanism imposes no > additional mandatory round-trips. > Either the client has to include the query it wants to send in the bind control, or Ted's 2) is not fulfilled. I still don't really understand 2) anyway. What is the difference between: 2a) client sends $QUERY in a search request; server says "I won't return results to $QUERY to $YOU" 2b) client asks what would you do if I send $QUERY; server says "I won't return results to $QUERY to $YOU" That is why I thought 2b would make more sence if the client can retrieve general server policy published as LDAP data (Solution A). A search control with the function "don't perform the search, just tell me, if you would answer this request" as alternative is even easier to specify. (Solution B) It would sort of be the same as specifying this in the bind control, with intended query data given by the client with the bind request. But then the answer would be only for one specific query, or the client would send a list of all intended queries. (Solution C1) Or and this seems to be the path Eric wants to follow, the server gives back a general answer together with the bind response to the client what kind of queries it is willing to answer to this particular client. (Solution C2) This would be similiar to the policy publishing solution, but not expressed in LDAP data, but in the bind control response. What I want to say here is - However 3.1.8. is to be interpreted, there are several solutions to fulfil it - Solution C2, as Eric seems to propose is doable, but it needs a detailed specification of what kind of entries (defined by object class) and what kind of attributes (defined by an attribute list) will be returned to this particular client. If there are different policies for different subtrees, the DN of the subtree has to be specified as well. So an answer could be something like: dn: x=y, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3$oc: inetIpv6Network$at: attr4, attr5, attr6 dn: x=z, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3 With this, a client can compute, which kind of queries will be serverd and which won't. Cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From anewton at ecotroph.net Wed Aug 20 08:58:08 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Aug 20 07:58:20 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F435E55.7040705@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> <3F435E55.7040705@daasi.de> Message-ID: <3F436250.9000100@ecotroph.net> Peter Gietz wrote: > > > Either the client has to include the query it wants to send in the bind > control, or Ted's 2) is not fulfilled. > > I still don't really understand 2) anyway. What is the difference between: > > 2a) client sends $QUERY in a search request; server says "I won't return > results to $QUERY to $YOU" > > 2b) client asks what would you do if I send $QUERY; server says "I won't > return results to $QUERY to $YOU" > > That is why I thought 2b would make more sence if the client can > retrieve general server policy published as LDAP data (Solution A). > > A search control with the function "don't perform the search, just tell > me, if you would answer this request" as alternative is even easier to > specify. (Solution B) I agree. Solution 2 seems to be the easiest thing to do. I'm not sure why it is so difficult. > - Solution C2, as Eric seems to propose is doable, but it needs a > detailed specification of what kind of entries (defined by object class) > and what kind of attributes (defined by an attribute list) will be > returned to this particular client. If there are different policies for > different subtrees, the DN of the subtree has to be specified as well. > So an answer could be something like: > > dn: x=y, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3$oc: > inetIpv6Network$at: attr4, attr5, attr6 > dn: x=z, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3 > > With this, a client can compute, which kind of queries will be serverd > and which won't. This is an interesting approach. It would probably need to be worked out more thoroughly on paper first. However, you would also need to include the qualifying matching rules and search scope. -andy From Peter.Gietz at daasi.de Wed Aug 20 16:13:27 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Wed Aug 20 09:13:43 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F436250.9000100@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> <3F435E55.7040705@daasi.de> <3F436250.9000100@ecotroph.net> Message-ID: <3F4373F7.3040608@daasi.de> Andrew Newton wrote: > Peter Gietz wrote: > >> >> >> Either the client has to include the query it wants to send in the >> bind control, or Ted's 2) is not fulfilled. >> >> I still don't really understand 2) anyway. What is the difference >> between: >> >> 2a) client sends $QUERY in a search request; server says "I won't >> return results to $QUERY to $YOU" >> >> 2b) client asks what would you do if I send $QUERY; server says "I >> won't return results to $QUERY to $YOU" >> >> That is why I thought 2b would make more sence if the client can >> retrieve general server policy published as LDAP data (Solution A). >> >> A search control with the function "don't perform the search, just >> tell me, if you would answer this request" as alternative is even >> easier to specify. (Solution B) > > > I agree. Solution 2 seems to be the easiest thing to do. I'm not sure > why it is so difficult. > >> - Solution C2, as Eric seems to propose is doable, but it needs a >> detailed specification of what kind of entries (defined by object >> class) and what kind of attributes (defined by an attribute list) will >> be returned to this particular client. If there are different policies >> for different subtrees, the DN of the subtree has to be specified as >> well. So an answer could be something like: >> >> dn: x=y, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3$oc: >> inetIpv6Network$at: attr4, attr5, attr6 >> dn: x=z, dc=xxx, dc=yyy$oc: inetOrgPerson$at: attr1, attr2, attr3 >> >> With this, a client can compute, which kind of queries will be serverd >> and which won't. > > > This is an interesting approach. It would probably need to be worked > out more thoroughly on paper first. However, you would also need to > include the qualifying matching rules and search scope. Why matching rules? Do you want to distinguish between string and substring search here? With scope I am not so sure either, since the policy should rule for whole subtrees. It shouldn't matter if the client makes basedn, onelevel or subtree searches, the access policy should be the same. I don't want to get this too complex. What might be added is the server side sizelimit (the maximum of entries a server will be willing to give back to the client), which should be one number for all naming contexts of the server. Cheers, Peter > > -andy > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From anewton at ecotroph.net Wed Aug 20 10:59:42 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Aug 20 09:32:47 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F4373F7.3040608@daasi.de> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> <3F435E55.7040705@daasi.de> <3F436250.9000100@ecotroph.net> <3F4373F7.3040608@daasi.de> Message-ID: <3F437ECE.6020501@ecotroph.net> Peter Gietz wrote: > >> This is an interesting approach. It would probably need to be worked >> out more thoroughly on paper first. However, you would also need to >> include the qualifying matching rules and search scope. > > > Why matching rules? Do you want to distinguish between string and > substring search here? > > With scope I am not so sure either, since the policy should rule for > whole subtrees. It shouldn't matter if the client makes basedn, onelevel > or subtree searches, the access policy should be the same. > > I don't want to get this too complex. What might be added is the server > side sizelimit (the maximum of entries a server will be willing to give > back to the client), which should be one number for all naming contexts > of the server. People will be attempting to mine data from these servers. That is a fact of life. I know our service will not allow somebody to do a subtree search in the contacts DIT. For RLDAP, we excluded any partial string matching if they didn't give use the first three letters of the name (e.g. cn=*, cn=b*, and cn=bob*). Therefore matching rules, search filters, and scope will be allowed and disallowed depending on what the person is attempting to do. -andy From anewton at ecotroph.net Wed Aug 20 11:22:11 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Aug 20 09:55:13 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F4350FA.2090704@ehsco.com> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> <3F42652F.3010609@ecotroph.net> <3F4350FA.2090704@ehsco.com> Message-ID: <3F438413.2010603@ecotroph.net> Eric A. Hall wrote: >>I believe this comes down to a difference between 2251 style referrals >>and the named subordinate references in 3296. After reading 3296, it >>would seem my original point is still somewhat valid because your draft >>does not mention the use of the manageDsaIT control. You should add >>text requiring the recognition of it by the server and the use of it by >>the client. > > > That's not necessary. In the case of deployments that use packaged > servers, the control would need to be provided as part of the referral > service. In the case of servers that are going to be manipulating data in > a private back-end, LDAP isn't going to be used for editing the referral > data, but even if it is, RFC 3296 is the governing spec here not FIRS. In > any event, I don't think it's appropriate or necessary to restate RFC 3296 > requirements in the FIRS specs. > > >>Otherwise, all those domain variants you mentioned will >>fill up the result set before any valid response. > > > I'm not sure what you mean by this. The manageDsaIT control provides a way > for clients to edit an entry that contains referral data (in the default > case, a request for the entry would cause the server to generate the > referral, while the control says "no no, I want to change the entry not > read it"). It doesn't have anything to do with the "size" of the result > set to my knowledge. Am I misunderstanding you here? I'm not sure why there is confusion on this topic. 3296 makes it plainly obvious what is going on. I reread 3296 for the 3rd time this morning and feel no closer to the answer. It seems to be talking about two completely separate things: named subordinate references and a control to manage DSE entries. From what I can tell, the manageDsaIt control simply allows the client to tell the server to treat these referral objectclass entries as normal results as opposed to a referral. The side-effect is that you can edit them. If that is not the case, how is the distinction made between: a: continue searching over there and b: the specific entry you are looking for is over there These are completely seperate things to a client. Also, if the manageDsaIT control does not counteract the 2251 specified behaviour of including referrals/references in a response regardless of search filter, then what does? >>I also do not see where the thin registry model referral/reference is >>defined. But that should be a simple addition, correct? > > > Something like that should probably go in the architecture guide rather > than in the technical spec. I have some other text that I want to put in > there already so this would be a good time to include anything else along > those lines. What exactly do you think needs to be said here? The inetDnsDomain objectclass should contain an attribute that is an LDAP URL named subordinate reference/referral/whatever to the entry in the registrar's LDAP server for that specific domain. Atleast that's how I think it would be done, unless there is a better or more elegant method. -andy From shane at ripe.net Wed Aug 20 19:42:03 2003 From: shane at ripe.net (Shane Kerr) Date: Wed Aug 20 12:42:08 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <200308191004.50617.davidb@verisignlabs.com> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> Message-ID: <3F43A4DB.2060608@ripe.net> David Blacka wrote: > On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote: > > Excellent response, Shane. Thanks. My comments are in-line. > > >>For us (RIPE NCC), nested matching means: >> >>- Given a range, find all the networks that contain that range; "-L" >>in RIPE-land, or "all supernets" in your terminology >> >>- Given a range, find only the most specific network that contains >>that range (could be multiple networks, but usually single); "-l" in >>RIPE-land, and the default for our servers, or "supernets" in your >>terminology > > > I called this "the closest enclosing supernet", but your description is > quite clear. > > >>- Given a range, find all the networks that are fully within that >>range; "-M" in RIPE-land, or "all subnets" in your terminology >> >>- Given a range, find only the least specific networks that are fully >>within that range; "-m" in RIPE-land, or "subnets" in your terminology > > > Ok, is "least specific" the same thing as largest, in this context? I > guess I'm not sure how to define this search. Well, it includes the largest networks. For instance, given this query: 193.0.0.0 - 193.0.31.255 "least-specific" is: 193.0.0.0 - 193.0.7.255 193.0.8.0 - 193.0.11.255 193.0.14.0 - 193.0.14.255 . . . And so on. Note that the networks here are a /21, a /22, and a /24. It should not find: 193.0.0.0 - 193.0.3.255 Even though this is a /22, and larger than the /24 (if you count IP's in the range). Size matters, but it's not the only thing. ;) You could say it is the "child networks" of the network, although that begs the question of what a child is in this context (the definition below is relatively formal and complete, IMHO). >>Exact matching means: >> >>- Given a range, find the network that begins and ends on the same IP >>addresses as the range; "-x" in RIPE-land > > >>More details: >> >>-x is networks where: >> (start(network) = start(search)) AND >> (end(network) = end(search)) >> >>For us, a "less-specific" search can return a network that is an exact >>match, as well as the encompassing networks: >> >>-L is networks where: >> (start(network) <= start(search)) AND >> (end(network) >= end(search)) >> >>-l is all of the networks from -L, with the provisio that: >> no other network in the return set is contained by the network >> >>However, a "more-specific" search must not be an exact match: >> >>-M is networks where: >> (start(network) >= start(search)) AND >> (end(network) <= end(search)) AND >> NOT ((start(network) = start(search)) AND >> (end(network) = end(search))) > > >>-m is all of the networks from -M, with the provisio that: >> no other network in the return set contains the network > > > Sorry, couldn't parse that last sentence. "no other network in the return > set contains the network"? which network? huh? Maybe a diagram: X Y A |------------------| B |--------------------| C |-------------------------| D |--------| E |-------| F |---------| Given these networks, if you searched with "-m" for "X - Y", you would get A, B, and C. You would not get D (contained by A), E (contained by B) or F (contained by C). Or look at some code: @results = $db->selectall_arrayref(qq" SELECT lo_ip, hi_ip FROM networks WHERE (lo_ip <= $search_lo_ip) AND (hi_ip >= $search_ip_ip) AND NOT ((lo_ip == $search_lo_ip) AND hi_ip == $search_hi_ip)) "); for ($i=0; $i<@results; $i++) { for ($j=$i+1; $j<@results; $j++) { if (contains($results[j], $results[i])) { # remove network that is contained by the other splice(@results, $i, 1); } } } sub contains { my ($a, $b) = @_; return ($a->[0] <= $b->[0]) && ($a->[1] >= $b[1]) && !(($a->[0] == $b->[0]) && ($a->[1] == $b->[1])); } >>(Note that the definition is not the best way to find the answer.) >> >>Any replacement for WHOIS would have to have at *least* this much >>expressiveness. > > > I realize that this is currently what the RIPE WHOIS servers do, but are > there specific reasons why some of these rules exist? For instance, if > the "more-specific" supernet search (-l) was able to return exact matches, > would you even need (-x)? It's currently used in the RIPE database to do lookups (versus searches). I guess there's no real need if we have intelligent clients, but it could reduce bandwidth consumption if nothing else in the case where you know what you are looking for. Note that if you have -l return exact matches, then you MUST have a -L flag. Otherwise you can't know who the parent of a given network is, except by trying both of these: -l (lo_ip-1) - hi_ip -l lo_ip - (hi_ip+1) :) >>>Also, I would sort of think that searching for network blocks (IPv4 or >>>IPv6) would be one of the most basic points of the service, so should > > the > >>>ability to search for them be a SHOULD? >> >>Agreed. > > > This information, in some form, needs to make it into the requirements > document as MUSTs. Or maybe some subset of these searches are MUSTs and > some are SHOULDs. We absolutely cannot live without: -l (one level less specific) -m (one level more specific) The client can do the -x checking on its side. You can build -L (all less specific) and -M (all more specific) with these, although I don't know if it makes sense. You'll also end up sending the same objects in some cases if you build them from the others, due to overlapping networks. -L is a lightweight query (going up a tree doesn't give you much data), but -M can be very, very heavyweight (somebody does "-M 0.0.0.0/0" every day on our server). So perhaps: -l => MUST -m => MUST -L => SHOULD -M => MAY -x => SHOULD I like -x because it's efficient. Note that you can do more funky things, like "2nd level more specific" and so on. I don't know if these are useful, especially if they can be constructed through use of the -l/-m operators. -- Shane Kerr RIPE NCC From ehall at ehsco.com Wed Aug 20 14:19:07 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 20 14:19:13 2003 Subject: [Ietf-not43] Re: Requirement 3.1.8 In-Reply-To: <3F436250.9000100@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> <3F435E55.7040705@daasi.de> <3F436250.9000100@ecotroph.net> Message-ID: <3F43BB9B.4090400@ehsco.com> > I agree. Solution 2 seems to be the easiest thing to do. I'm not sure > why it is so difficult. Something more comprehensive than "act like rsynch" will probably get a more direct solution. Right now, the mechanism is modelled after the CAPABILITY output in the various email protocols. The server returns a list of suported features, and which can vary based on the user identity (this is returned after auth). Clients don't have to burn session-setup time by probing for the server's feature set ("do you support F1? how about F2?"), but instead can just look at the list of features in the CAPABILITY output. It's faster since it eliminates round-trips for distinct probes, and it's cumulatively easier on the server than having to issue errors for every failed command from every distinct client. > People will be attempting to mine data from these servers. That is a > fact of life. I know our service will not allow somebody to do a > subtree search in the contacts DIT. For RLDAP, we excluded any partial > string matching if they didn't give use the first three letters of the > name (e.g. cn=*, cn=b*, and cn=bob*). Therefore matching rules, search > filters, and scope will be allowed and disallowed depending on what the > person is attempting to do. One thing I've been considering is changing the list output to reflect available query types instead of or in addition to object class versions, and this seems to indicate a desire for similar effect. Perhaps an additional bind control (instead of overloading this one) can do that the best while still preserving the efficiencies of the CAPABILITY model. I'll start looking into this. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Wed Aug 20 17:45:25 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 20 17:45:34 2003 Subject: [Ietf-not43] #6 inetDnsDomain objects and 2251 referrals In-Reply-To: <3F438413.2010603@ecotroph.net> References: <3F4136B5.2090404@ecotroph.net> <3F414A59.1050100@ecotroph.net> <3F414B40.1040609@ehsco.com> <200308181918.51561.davidb@verisignlabs.com> <3F4165A1.1030505@ehsco.com> <3F42652F.3010609@ecotroph.net> <3F4350FA.2090704@ehsco.com> <3F438413.2010603@ecotroph.net> Message-ID: <3F43EBF5.2050807@ehsco.com> on 8/20/2003 9:22 AM Andrew Newton wrote: > Eric A. Hall wrote: > >> Andrew Newton wrote: >> >>> I believe this comes down to a difference between 2251 style >>> referrals and the named subordinate references in 3296. > I reread 3296 for the 3rd time this morning and feel no closer to the > answer. It seems to be talking about two completely separate things: > named subordinate references and a control to manage DSE entries. > > From what I can tell, the manageDsaIt control simply allows the client > to tell the server to treat these referral objectclass entries as > normal results as opposed to a referral. The side-effect is that you > can edit them. We may be having some confusion with the technology (I hope I don't make it worse here). 2251 defines the LDAP message structure and not the database structures. As part of a positive response, 2251 allows entry sets in an answer to contain "continuation references", which is a long way of saying "soft referral", meaning "here is some data but you should also start additional queries at/with ". The search succeeded, but some of the database entries that matched the query exist as referrals, and those will need to be chased down. 2251 doesn't say where this data comes from, only what it looks like in the message. 3296 defines "subordinate references", aka "hard referrals", or "you must restart the query at/with ". These essentially use response messages that have zero answers. Generally speaking, this means that the search failed because the searchbase specifies an entry that only exists as a referral stub. With FIRS, this usually only happen if the inetResources container only exists as a pointer to an inetResources container in a different partition, although it can also happen if the searchbase of a query specified a child entry that was a referral stub (this is uncommon but is not entirely unexpected). 3296 also defines the object class and attribute schema and a control that allows the referral stubs to be managed via the protocol. None of this stuff is used by FIRS directly, although the practices are mandated so everything works as expected with existing LDAP tools. On the subject of variant domain names... These should exist as referral stub entries within the inetResources container of a registry's partition (eg, cn=variant.dom,cn=inetResources,dc=registry,dc=com). In the usual scenario, queries for that domain name would use the inetDnsDomainMatch filter, and the inetResources container as the searchbase, resulting in the variant's stub entry being returned as a continuation reference referral (other domain entries in the domain's delegation path that also existed on the queried server would also be returned, but that's not particularly relevant to this point). The variant referral data would likely point to another entry in the same container on the same server. If somebody used a generic matching filter with wildcards or soundex filters or something, and the server found 100 matching variants before shutting off the lookup, the server could theoretically return 100 continuation referencereferrals as matches, and the client would have to deal with that. This isn't the prescribed behavior; the specs define the inetDnsDomainMatch filter specifically to avoid this kind of scenario. > The inetDnsDomain objectclass should contain an attribute that is an > LDAP URL named subordinate reference/referral/whatever to the entry in > the registrar's LDAP server for that specific domain. Atleast that's > how I think it would be done, unless there is a better or more elegant > method. That's pretty much the way it's supposed to work: input: example.com client: find LDAP servers for com domain registry submit inetDnsDomainMatch query for example.com registry: search for all inetDnsDomain entries in example.com path return answer containing { local entry for com (the delegation parent) local entry for example.com continuation reference to registrar } client: find LDAP servers for named registrar submit inetDnsDomainMatch query for example.com registrar: search for all inetDnsDomain entries in example.com path return answer containing { local entry for example.com continuation reference to operator (policy issues) } I seemed to have misplaced some crucial text in the specs during one of the subsequent rewrites. Since the continuation references cannot coexist at the same leaf as the answer entries, additional entries are required in order for the registry and registrar to return answers and soft referrals simultaneously. In order for these entries to be located by the inetDnsDomainMatch, they must have names which are in the delegation path of the resource. This means having a referral stub entry as a child entry, with a name like cn=referral,cn=example.com,cn=inetResources,dc=... I'll add that discussion to the arch draft and a mention in each of the resource drafts. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Wed Aug 20 18:34:39 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 20 18:34:46 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F43A4DB.2060608@ripe.net> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> Message-ID: <3F43F77F.7030909@ehsco.com> on 8/20/2003 11:42 AM Shane Kerr wrote: > David Blacka wrote: >> On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote: >>> - Given a range, find all the networks that are fully within that >>> range; "-M" in RIPE-land, or "all subnets" in your terminology >>> >>> - Given a range, find only the least specific networks that are >>> fully within that range; "-m" in RIPE-land, or "subnets" in your >>> terminology >> >> Ok, is "least specific" the same thing as largest, in this context? >> I guess I'm not sure how to define this search. > > Well, it includes the largest networks. For instance, given this > query: > > 193.0.0.0 - 193.0.31.255 [...] I'm going to guess that David is having some of the same problems I had when Ed Lewis was describing the same kind of syntax, which is that specifying the range as the query value is just strange. I'm not entirely sure if there isn't a disconnect here. For WHOIS queries this kind of syntax is okay since the dumb-terminal client is talking to a front-end parser that is part of a monolithic back-end. In distributed models, however, the client is supposed to be the front-end parser that maps the input to a canonical value and the server's role is reduced to handling the database lookup. In that regard, having the client pass raw input to the server negates the benefits of the model, and feels wrong. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shane at ripe.net Thu Aug 21 11:09:19 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Aug 21 04:09:25 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F43F77F.7030909@ehsco.com> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> Message-ID: <3F447E2F.5090501@ripe.net> Eric A. Hall wrote: > on 8/20/2003 11:42 AM Shane Kerr wrote: > > >>David Blacka wrote: > > >>>On Tuesday 19 August 2003 06:00 am, Shane Kerr wrote: > > >>>>- Given a range, find all the networks that are fully within that >>>>range; "-M" in RIPE-land, or "all subnets" in your terminology >>>> >>>>- Given a range, find only the least specific networks that are >>>>fully within that range; "-m" in RIPE-land, or "subnets" in your >>>>terminology >>> >>>Ok, is "least specific" the same thing as largest, in this context? >>>I guess I'm not sure how to define this search. >> >>Well, it includes the largest networks. For instance, given this >>query: >> >>193.0.0.0 - 193.0.31.255 > > > [...] > > I'm going to guess that David is having some of the same problems I had > when Ed Lewis was describing the same kind of syntax, which is that > specifying the range as the query value is just strange. I would guess you think it's strange because you're a domain person. ;) > I'm not entirely sure if there isn't a disconnect here. For WHOIS queries > this kind of syntax is okay since the dumb-terminal client is talking to a > front-end parser that is part of a monolithic back-end. In distributed > models, however, the client is supposed to be the front-end parser that > maps the input to a canonical value and the server's role is reduced to > handling the database lookup. In that regard, having the client pass raw > input to the server negates the benefits of the model, and feels wrong. Syntax is irrelevant: 3238002688 3238010879 Whatever. (Textual IP's are easier when debugging, of course.) I only use the syntax I did because that's what we use now. But maybe that's not what you mean. Is the problem specifying the range and doing a search rather than a simple lookup? The address space is not the same as the domain space. We actually need to be able to have the semantics that I described in terms of looking for parent/child relationships and having abritrary values for searches. -- Shane Kerr RIPE NCC From davidb at verisignlabs.com Thu Aug 21 09:33:35 2003 From: davidb at verisignlabs.com (David Blacka) Date: Thu Aug 21 08:37:30 2003 Subject: [Ietf-not43] =?iso-8859-1?q?I-D=09ACTION=3Adraft-ietf-crisp-internet-resource-number-re?= =?iso-8859-1?q?q-00=2Etxt?= In-Reply-To: <3F43F77F.7030909@ehsco.com> References: <200308111631.MAA22222@ietf.org> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> Message-ID: <200308210833.35693.davidb@verisignlabs.com> On Wednesday 20 August 2003 06:34 pm, Eric A. Hall wrote: > >> Ok, is "least specific" the same thing as largest, in this context? > >> I guess I'm not sure how to define this search. > > > > Well, it includes the largest networks. For instance, given this > > query: > > > > 193.0.0.0 - 193.0.31.255 > > [...] > > I'm going to guess that David is having some of the same problems I had > when Ed Lewis was describing the same kind of syntax, which is that > specifying the range as the query value is just strange. Actually, no. I don't find using IP ranges especially strange, since I know that they are the basic units of identity for a network block. In this thread, my main concern is that the word "search" in the address space is hopelessly vague. Shane has managed to express quite precisely what he (or RIPE) wants in an address-space WHOIS replacement. In this particular case, I was having trouble understanding what the search parameters for RIPE's "-m" search were. Shane's explanation was great. If I were to try and put it in English, I might say: All networks enclosed by this range that are not themselves enclosed by other networks in the result set. Still pretty clumsy, I admit. > I'm not entirely sure if there isn't a disconnect here. For WHOIS queries > this kind of syntax is okay since the dumb-terminal client is talking to a > front-end parser that is part of a monolithic back-end. In distributed > models, however, the client is supposed to be the front-end parser that > maps the input to a canonical value and the server's role is reduced to > handling the database lookup. In that regard, having the client pass raw > input to the server negates the benefits of the model, and feels wrong. I expect the real disconnect is that those of us outside this space don't really have a handle on the use cases that a WHOIS replacement would need to support. -- David Blacka Sr. Engineer Verisign Applied Research From davidb at verisignlabs.com Thu Aug 21 09:44:17 2003 From: davidb at verisignlabs.com (David Blacka) Date: Thu Aug 21 08:48:10 2003 Subject: =?iso-8859-1?q?=5BIetf-not43=5D=09I-D=09ACTION=3Adraft-ietf-crisp-internet?= =?iso-8859-1?q?-resource-number-req-00=2Etxt?= In-Reply-To: <3F447E2F.5090501@ripe.net> References: <200308111631.MAA22222@ietf.org> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> Message-ID: <200308210844.17556.davidb@verisignlabs.com> On Thursday 21 August 2003 04:09 am, Shane Kerr wrote: > But maybe that's not what you mean. Is the problem specifying the > range and doing a search rather than a simple lookup? The address > space is not the same as the domain space. We actually need to be > able to have the semantics that I described in terms of looking for > parent/child relationships and having abritrary values for searches. Shane, how important is it that *all* of those searches are done with arbitrary ranges? In particular, I am wondering if the "-m" query, for instance, could be started with a known network block (identified by handle, for instance) instead of an arbitrary range? It occurs to me that if "-m" where queries by network block handle, implementations could pre-calculate the results. A followup question might be: would it be useful for any of the IP searches to start with a network block identifier, in addition? -- David Blacka Sr. Engineer Verisign Applied Research From shane at ripe.net Thu Aug 21 16:31:30 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Aug 21 09:31:33 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <200308210844.17556.davidb@verisignlabs.com> References: <200308111631.MAA22222@ietf.org> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> <200308210844.17556.davidb@verisignlabs.com> Message-ID: <3F44C9B2.6040505@ripe.net> David Blacka wrote: > On Thursday 21 August 2003 04:09 am, Shane Kerr wrote: > > >>But maybe that's not what you mean. Is the problem specifying the >>range and doing a search rather than a simple lookup? The address >>space is not the same as the domain space. We actually need to be >>able to have the semantics that I described in terms of looking for >>parent/child relationships and having abritrary values for searches. > > > Shane, how important is it that *all* of those searches are done with > arbitrary ranges? In particular, I am wondering if the "-m" query, for > instance, could be started with a known network block (identified by > handle, for instance) instead of an arbitrary range? It occurs to me that > if "-m" where queries by network block handle, implementations could > pre-calculate the results. These don't always match. For instance, if I want to find all of the allocations from 210.0.0.0/7 I would probably have to do a search for 210.0.0.0/8 and 211.0.0.0/8 if those were the entries in the database. It's not *strictly* necessary, but we don't really have performance problems so I'd prefer not to limit the protocol unnecessarily. > A followup question might be: would it be useful for any of the IP searches > to start with a network block identifier, in addition? That's possibly useful. Unfortunately we don't have (unique) identifiers for network blocks except for the start/end IP. -- Shane Kerr RIPE NCC From timc at arin.net Thu Aug 21 10:36:54 2003 From: timc at arin.net (Tim Christensen) Date: Thu Aug 21 09:37:00 2003 Subject: =?iso-8859-1?q?=5BIetf-not43=5D=09I-D=09ACTION=3Adraft-ietf-crisp-internet?= =?iso-8859-1?q?-resource-number-req-00=2Etxt?= In-Reply-To: <200308210844.17556.davidb@verisignlabs.com> Message-ID: Hi, David- On Thu, 21 Aug 2003, David Blacka wrote: > On Thursday 21 August 2003 04:09 am, Shane Kerr wrote: > > > But maybe that's not what you mean. Is the problem specifying the > > range and doing a search rather than a simple lookup? The address > > space is not the same as the domain space. We actually need to be > > able to have the semantics that I described in terms of looking for > > parent/child relationships and having abritrary values for searches. > > Shane, how important is it that *all* of those searches are done with > arbitrary ranges? In particular, I am wondering if the "-m" query, for > instance, could be started with a known network block (identified by > handle, for instance) instead of an arbitrary range? It occurs to me that > if "-m" where queries by network block handle, implementations could > pre-calculate the results. > > A followup question might be: would it be useful for any of the IP searches > to start with a network block identifier, in addition? > Just as likely (maybe even more) that queries would be issued with either the start of the block or the _network_block_identifier_, when the query issuer is clueful regarding the network block in question. e.g. if I were the responsible maintainer for the block, I would most likely look up the block by either its starting point or by a unique identifier to find out what information was registered about it. I am not clued into RIPE '-m' and can't answer to that, but there are (historically anyway) many :43 queries today (in the ARIN region) which are looked up via the unique network block identifier or by the network's start point. (disclaimer: ARIN's :43 service does not support range queries at this time, but supports 'wildcard' queries which, while not replicating the behavior, can be crafted to simulate it is some cases. These account for a very small percentage of total queries. 'Why' is left to speculation of the reader.) ARIN's most recent incarnation of :43 service permits the queryant (new word?) to use flags to force a return of next-level-down subnets (though not a cascading tree) or a next-level-up supernet when the query returns 1 network. Important to note is that this is _not_ achievable with an IP query alone in the current code -- a network block identifier must be used. I am (personal opinion here) in favor of a search which by default returns the 'most close network'. This can be painfully difficult to define, but Shane's is the closest I have seen and I concur, with the caveat that most of the time, queryants (there it is again!) *seem* to want to see _only_ the most-close network most of the time; so returning the supernets/subnets about the range (or single IP for that matter, a range of 1) would IMO be best served with flags. Note that the current version of the draft does not address a network block identifier beyond a range (which does not necessarily uniquely define a network -- a network can be subdelegated in its entirety). So it is not a 'MUST' according to the existing document. This _may_ hamper certain uses of CRISP protocol in an implementation if said implementation were to explicitly ignore the (IMO common) desire to get 1 network response back for 1 query in many cases. Tim From timc at arin.net Thu Aug 21 10:45:44 2003 From: timc at arin.net (Tim Christensen) Date: Thu Aug 21 09:46:00 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F44C9B2.6040505@ripe.net> Message-ID: Hi Shane, On Thu, 21 Aug 2003, Shane Kerr wrote: > David Blacka wrote: > > Shane, how important is it that *all* of those searches are done with > > arbitrary ranges? In particular, I am wondering if the "-m" query, for > > instance, could be started with a known network block (identified by > > handle, for instance) instead of an arbitrary range? It occurs to me that > > if "-m" where queries by network block handle, implementations could > > pre-calculate the results. > > These don't always match. For instance, if I want to find all of the > allocations from 210.0.0.0/7 I would probably have to do a search for > 210.0.0.0/8 and 211.0.0.0/8 if those were the entries in the database. > It's not *strictly* necessary, but we don't really have performance > problems so I'd prefer not to limit the protocol unnecessarily. > Agreed. The database is not always aggregated; to presume that a query ought to _ONLY_ be dealt with on an aggregated basis is undesirable. > > A followup question might be: would it be useful for any of the IP searches > > to start with a network block identifier, in addition? > > That's possibly useful. Unfortunately we don't have (unique) identifiers > for network blocks except for the start/end IP. Which is not to say that it's not desirable to be able to uniquely identify a network block (and indeed, when two networks match, which one is the supernet and which one is the subnet). While the query language might not NEED (read: MUST) to permit a unique query to that level, for me it is a desired benefit of the protocol that it allow such definition and a way to get to it. Tim From shane at ripe.net Thu Aug 21 17:01:43 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Aug 21 10:01:47 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: References: Message-ID: <3F44D0C7.1020607@ripe.net> Tim Christensen wrote: > Hi Shane, > > On Thu, 21 Aug 2003, Shane Kerr wrote: > > >>David Blacka wrote: >> >>>A followup question might be: would it be useful for any of the IP searches >>>to start with a network block identifier, in addition? >> >>That's possibly useful. Unfortunately we don't have (unique) identifiers >>for network blocks except for the start/end IP. > > > Which is not to say that it's not desirable to be able to uniquely > identify a network block (and indeed, when two networks match, which one > is the supernet and which one is the subnet). We do not allow this. In fact, our schema is backwords. Our begin/end IP are unique, but our network names are not. :( Don't blame me, I didn't design the schema. ;) > While the query language might not NEED (read: MUST) to permit a unique > query to that level, for me it is a desired benefit of the protocol that > it allow such definition and a way to get to it. It does make sense to allow lookup by handle for any record, IMHO. -- Shane Kerr RIPE NCC From anewton at ecotroph.net Thu Aug 21 11:32:27 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 21 10:05:23 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: References: Message-ID: <3F44D7FB.6020503@ecotroph.net> Tim Christensen wrote: > > Which is not to say that it's not desirable to be able to uniquely > identify a network block (and indeed, when two networks match, which one > is the supernet and which one is the subnet). How do you get two network blocks with the same starting and ending addresses? And how do they have a relationship other than equivalence? Or is there a temporal relationship? -andy From anewton at ecotroph.net Thu Aug 21 11:40:27 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 21 10:13:20 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F44D7FB.6020503@ecotroph.net> References: <3F44D7FB.6020503@ecotroph.net> Message-ID: <3F44D9DB.5070004@ecotroph.net> Andrew Newton wrote: > Tim Christensen wrote: > >> >> Which is not to say that it's not desirable to be able to uniquely >> identify a network block (and indeed, when two networks match, which one >> is the supernet and which one is the subnet). > > > How do you get two network blocks with the same starting and ending > addresses? And how do they have a relationship other than equivalence? > Or is there a temporal relationship? Ignore this. You answered the question. -andy From shane at ripe.net Thu Aug 21 17:16:47 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Aug 21 10:16:51 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F44D7FB.6020503@ecotroph.net> References: <3F44D7FB.6020503@ecotroph.net> Message-ID: <3F44D44F.9030702@ripe.net> Andrew Newton wrote: > Tim Christensen wrote: > >> >> Which is not to say that it's not desirable to be able to uniquely >> identify a network block (and indeed, when two networks match, which one >> is the supernet and which one is the subnet). > > > How do you get two network blocks with the same starting and ending > addresses? And how do they have a relationship other than equivalence? > Or is there a temporal relationship? Say I have received a /17 and a /19 from ARIN, disjoint. One of my customers is now big enough that they can use an entire /19. I want to assign the entire block to them. Therefore I create an entry in the database reflecting this. We still have: IANA -> ARIN -> ISP -> User And want to reflect this relationship, but the block to the ISP and the User are the sam, in terms of start/end address. -- Shane Kerr RIPE NCC From ehall at ehsco.com Thu Aug 21 10:35:28 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 21 10:35:36 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F447E2F.5090501@ripe.net> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> Message-ID: <3F44D8B0.1090402@ehsco.com> on 8/21/2003 3:09 AM Shane Kerr wrote: > Syntax is irrelevant: > > > > > 3238002688 > 3238010879 > > > > > Whatever. (Textual IP's are easier when debugging, of course.) I > only use the syntax I did because that's what we use now. > But maybe that's not what you mean. Is the problem specifying the > range and doing a search rather than a simple lookup? The address > space is not the same as the domain space. We actually need to be > able to have the semantics that I described in terms of looking for > parent/child relationships and having abritrary values for searches. Using the netblock syntax would be the most efficient for the holistic system, for several reasons. Using the range syntax would be the least efficient. For one thing, the "back-end" of the system actually consists of multiple back-ends, each of which manage portions of the delegated hierarchy. This is somewhat different from the existing model of independent systems. We aren't going to be having clients query ~RIPE when the address falls into a certain range, but instead the idea is that the client will start with zero knowledge and rely on the distributed back-ends to redirect them to the appropriate server. The two choices for this are an index of all entries or a series of delegation referrals. We've already chosen the delegation referral model since the super-index approach has too many problems. Now we need to think about how the database partitions and entries are keyed so that the delegation hierarchy can be efficiently followed. Using ranges as key values has a lot of problematic issues. It's certainly possible to combine multiple attributes into an entry name, but it's not very efficient. Furthermore, all delegations are required to be netblocks that fall on CIDR boundaries, which is a single value, and is therefore going to be highly efficient in terms of key-based referrals. In terms of server processing, it helps a lot if the most-common query uses these same values. Having the client issue a query for a range of addresses would mean that the server would have to convert either the query value or the database contents into a form that will match against the other form. Meanwhile, on the client side, preparing a single value is simpler than preparing a range (need to do a lot more validation and preparation for ranges), and since the server and namespace would both prefer the netblock syntax (a single value) that is what it should be producing anyway. So cumulatively, it is overall most efficient to use netblocks as the primary naming syntax for navigation, searches and queries. It's still entirely possible to search by other values, but in the distributed back-end model we've got, value-based searches necessarily have to be restrictred to specific servers, and cannot follow the delegation hierarchy. For example, things like network handles can still be supported (and there's an attribute in FIRS for this), and can still be searched for, but the client either has to know which server has that data and start the search there, or the client has to ask an index server and hope that the index is up to date, is accurate, etc. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From timc at arin.net Thu Aug 21 12:18:28 2003 From: timc at arin.net (Tim Christensen) Date: Thu Aug 21 11:18:35 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0 0.txt In-Reply-To: <3F44D8B0.1090402@ehsco.com> References: <3F447E2F.5090501@ripe.net> <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> Message-ID: <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> Comments inline but I left the entire thread here since there are several reference points. Sorry for length. At 8/21/2003 10:35 AM, Eric A. Hall wrote: >on 8/21/2003 3:09 AM Shane Kerr wrote: > > > Syntax is irrelevant: > > > > > > > > > > 3238002688 > > 3238010879 > > > > > > > > > > Whatever. (Textual IP's are easier when debugging, of course.) I > > only use the syntax I did because that's what we use now. > > > But maybe that's not what you mean. Is the problem specifying the > > range and doing a search rather than a simple lookup? The address > > space is not the same as the domain space. We actually need to be > > able to have the semantics that I described in terms of looking for > > parent/child relationships and having abritrary values for searches. > >Using the netblock syntax would be the most efficient for the holistic >system, for several reasons. Using the range syntax would be the least >efficient. Most efficient, yes, I agree. Not practical, unfortunately, see below. >Furthermore, all delegations are required to be netblocks >that fall on CIDR boundaries, which is a single value, and is therefore >going to be highly efficient in terms of key-based referrals. Not true. All delegations are _not_ required to be netblocks that fall on CIDR boundaries. As it happens, not only can direct delegations be off-bit, but subdelegations also can (and frequently are). ARIN made a choice at its last database redesign to store networks in CIDR chunks. But that in no way infers that networks (as a discrete, defined, delegated resource) are necessarily constrained to exist on a tidy bit boundary. >So cumulatively, it is overall most efficient to use netblocks as the >primary naming syntax for navigation, searches and queries. IMO this unnecessarily limits the querying ability that the protocol supports. To presume that someone would want to query only on CIDR bit boundaries is erroneous and ignores the fact that many network delegations span multiple cidr-espressed blocks. While it's true that you _could_ choose to look at this another way -- to consider that a multi-cidr-block delegation is really just contiguous cidr-represented networks, and that in and of itself means that the (single-CIDR-addressable block) is unique -- I see 2 problems with this approach: - seems to me that most folks want to know the size&shape of the delegated block - it still doesn't address full-subdelegation of the cidr block (and indeed, creates an even larger problem in this area) To exemplify, assume that we have a network delegation from 10.10.254.2 to 10.10.254.254 (this is close to a real world example in ARIN's database, details modified somewhat). It requires 13 CIDR blocks to represent this single network resource (resource from the perspective of a single allocation instance). If I were to issue a query for 10.10.254.64, or even for the range 10.10.254.64 -> 10.10.254.240, I would want to know that this range is encompassed by the delegated network 10.10.254.2->254. Using the 'netblock' query model above does not permit the latter query (since itself is a multi-cidr range), and the further discussion seemed to preclude identification of the network as a single database entry (again not reflective of reality and undesirable IMO) Tim From ehall at ehsco.com Thu Aug 21 11:29:15 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 21 11:29:27 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-00.txt In-Reply-To: <3F41F524.3010808@ripe.net> References: <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> Message-ID: <3F44E54B.5090807@ehsco.com> Answering for myself here. on 8/19/2003 5:00 AM Shane Kerr wrote: > For us (RIPE NCC), nested matching means: > > - Given a range, find all the networks that contain that range; "-L" > in RIPE-land, or "all supernets" in your terminology That's the default with FIRS' address-specific matching filter. Each parent netblock is returned as they are encountered, until either an exact match for the query value is found. If no exact match was found, the user still gets to see all of the parent netblocks. Issue a whois query to goose.ehsco.com with the value of 192.168.11.1 to see this. There is no entry for the queried /32 address but the delegation parents are returned. > - Given a range, find only the most specific network that contains > that range (could be multiple networks, but usually single); "-l" in > RIPE-land, and the default for our servers, or "supernets" in your > terminology There are two ways to do this with the FIRS approach. First way would be to have the client filter the output, so that only the matching entry was displayed, and all of the parent entries were discarded. Less workable but still functional would be to have the client use an equality match, but this would require the client to have prior knowledge about which server was authoritative for the netblock in question. > - Given a range, find all the networks that are fully within that > range; "-M" in RIPE-land, or "all subnets" in your terminology This is kind of supported with the default matching filter, although its possible to do more than this by defining another filter. Right now, entries are encouraged to contain attribute values that itemize the "related" netblocks, and the user could chase down any of those in particular by issuing new queries for any of those entries. You can see this in the output to 192.168.0.0/16 in the demonstration server, which lists 192.168.11.0/24 and 192.168.12.0/24 as associated networks. The client could issue new queries for either of these. It would also be possible to define a separate filter that didn't stop at the matching entry, although there are some fairly hard questions that need to be answered first, given the distributed model. In a monolithis model, you can do this because all of the data is contained within your server, but its pretty nasty when the subordinate entries all refer to other systems. I mean, if there are ~20 subordinate delegations, each of which have referrals that point to different subordinate management bodies and servers, should all of them be queried? How far down does this fan-out need to go? I mean, should every /32 in every delegated subnet be pursued with new queries? We're not in mono-ville anymore... > - Given a range, find only the least specific networks that are fully > within that range; "-m" in RIPE-land, or "subnets" in your terminology I don't understand this one. > Exact matching means: > > - Given a range, find the network that begins and ends on the same IP > addresses as the range; "-x" in RIPE-land Ranges are heavily disfavored by me. Too weird. > For us, a "less-specific" search can return a network that is an exact > match, as well as the encompassing networks: That's the default for FIRS. > However, a "more-specific" search must not be an exact match: > > -M is networks where: > (start(network) >= start(search)) AND > (end(network) <= end(search)) AND > NOT ((start(network) = start(search)) AND > (end(network) = end(search))) So all subordinate entries, but not the matching entry. Again, this introduces all kinds of weirdness in a distributed system. > -m is all of the networks from -M, with the provisio that: > no other network in the return set contains the network > Any replacement for WHOIS would have to have at *least* this much > expressiveness. I don't think expression is the problem so much as making sure that the queries are reasonably efficient for the distributed environment. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Thu Aug 21 11:50:25 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 21 11:50:34 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0 0.txt In-Reply-To: <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> References: <3F447E2F.5090501@ripe.net> <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> Message-ID: <3F44EA41.5040803@ehsco.com> on 8/21/2003 10:18 AM Tim Christensen wrote: > At 8/21/2003 10:35 AM, Eric A. Hall wrote: >> Furthermore, all delegations are required to be netblocks that fall >> on CIDR boundaries, which is a single value, and is therefore going >> to be highly efficient in terms of key-based referrals. > > Not true. All delegations are _not_ required to be netblocks that fall > on CIDR boundaries. I'm perfectly aware that organizations allocate addres space, where the space may span multiple netblocks, but the components themselves are still required to be netblocks right? Also, my understanding is that the component netblocks are the discrete entries, while the address space is just administrative. For example, routing uses netblocks not the whole space. > As it happens, not only can direct delegations be off-bit, but > subdelegations also can (and frequently are). These are space assignments, not the netblock delegations right? > IMO this unnecessarily limits the querying ability that the protocol > supports. To presume that someone would want to query only on CIDR bit > boundaries is erroneous and ignores the fact that many network > delegations span multiple cidr-espressed blocks. There is no such presumption. The effort is to find an efficient means of representation so that the hierarchical delegatin system actually works. We can support additional representations but those are by definition going to be search-by-value and thus limited to target servers. Also, don't forget that we have the ASN namespace as a separate hierarchy. Each of the partitions and entries in that hierarchy would naturally reference administrative groups, any of which could also provide pointers to discontiguous network blocks as associated resources. > While it's true that you _could_ choose to look at this another way -- > to consider that a multi-cidr-block delegation is really just > contiguous cidr-represented networks, and that in and of itself means > that the (single-CIDR-addressable block) is unique -- I see 2 problems > with this approach: > > - seems to me that most folks want to know the size&shape of the > delegated block - it still doesn't address full-subdelegation of the > cidr block (and indeed, creates an even larger problem in this area) > > To exemplify, assume that we have a network delegation from 10.10.254.2 > to 10.10.254.254 (this is close to a real world example in ARIN's > database, details modified somewhat). It requires 13 CIDR blocks to > represent this single network resource (resource from the perspective > of a single allocation instance). If I were to issue a query for > 10.10.254.64, or even for the range 10.10.254.64 -> 10.10.254.240, I > would want to know that this range is encompassed by the delegated > network 10.10.254.2->254. Using the 'netblock' query model above does > not permit the latter query (since itself is a multi-cidr range), and > the further discussion seemed to preclude identification of the network > as a single database entry (again not reflective of reality and > undesirable IMO) The example you cited is supported in the default (with FIRS anyway). Each parent netblock in the delegation path would be returned as it was encountered during the chase-down to the query value. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From timc at arin.net Thu Aug 21 14:58:40 2003 From: timc at arin.net (Tim Christensen) Date: Thu Aug 21 13:58:46 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0 0.txt In-Reply-To: <3F44EA41.5040803@ehsco.com> References: <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> <3F447E2F.5090501@ripe.net> <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> Message-ID: <5.2.1.1.0.20030821132855.01f72148@192.149.252.141> Hi Eric, At 8/21/2003 11:50 AM, Eric A. Hall wrote: >on 8/21/2003 10:18 AM Tim Christensen wrote: > > All delegations are _not_ required to be netblocks that fall > > on CIDR boundaries. > >I'm perfectly aware that organizations allocate addres space, where the >space may span multiple netblocks, but the components themselves are still >required to be netblocks right? To the extent that even a /32 is a one-node netblock, yes, I suppose. >Also, my understanding is that the component netblocks are the discrete >entries, while the address space is just administrative. For example, >routing uses netblocks not the whole space. "Just administrative" might be an oversimplification, but yes. > > As it happens, not only can direct delegations be off-bit, but > > subdelegations also can (and frequently are). > >These are space assignments, not the netblock delegations right? Terminology confusion on my part. When I read "delegation" I think "space that has been provided from an entity holding space to another entity". The unit of provision is measured in nodes, and can be measured in CIDR-prefix-size(s). When I read "assignment" it has special meaning to me about the use of the delegation, so I am confused. If what you are meaning is "These are named aggregates-of-netblocks [CIDR-expressed blocks], not the [individual] netblocks themselves", I would agree with that. > > To exemplify, assume that we have a network delegation from 10.10.254.2 > > to 10.10.254.254 (this is close to a real world example in ARIN's > > database, details modified somewhat). It requires 13 CIDR blocks to > > represent this single network resource (resource from the perspective > > of a single allocation instance). If I were to issue a query for > > 10.10.254.64, or even for the range 10.10.254.64 -> 10.10.254.240, I > > would want to know that this range is encompassed by the delegated > > network 10.10.254.2->254. Using the 'netblock' query model above does > > not permit the latter query (since itself is a multi-cidr range), and > > the further discussion seemed to preclude identification of the network > > as a single database entry (again not reflective of reality and > > undesirable IMO) > >The example you cited is supported in the default (with FIRS anyway). Each >parent netblock in the delegation path would be returned as it was >encountered during the chase-down to the query value. Could you amplify your response further? Let me provide context. In the example above of the range 10.10.254.2 to 10.10.254.254, the proper way to describe this 'network' in CIDR is: 10.10.254.2/31 + 10.10.254.4/30 + 10.10.254.8/29 + 10.10.254.16/28 + 10.10.254.32/27 + 10.10.254.64/26 + 10.10.254.128/26 + 10.10.254.192/27 + 10.10.254.224/28 + 10.10.254.240/29 + 10.10.254.248/30 + 10.10.254.252/31 + 10.10.254.254/32 Now, if I search for the range 10.10.254.64 -> 10.10.254.240, I am only hitting nodes in cidr-sections 6,7,8,9, and 10 in my list of 13.... My assertion is that the protocol should be defined such that it returns the network 10.10.254.2->254, because that was the closest aggregated network delegation. It should _not_ only return the cidr blocks represented by cidr-sections 6 thru 10 above, because that is an incomplete expression of the delegation that was delegated by the upstream. Similarly, if I used a single-term query such as 10.10.254.64, it would still return the network 10.10.254.2->254, because that node is encompassed in that delegated network, and to return only 10.10.254.64/26 mischaracterizes the delegation. In the context above, what would FIRS return? More to the point, what should the CRISP protocol call for $CRISP_IMPLEMENTATION demand? I believe it's more 'correct' to return the entire 'delegation', not just its closest CIDR sub-component. Moving on, how would I have queried the first search above in the following [strawman] query models (from earlier in the thread): >> > >> > >> > >> > 3238002688 >> > 3238010879 >> > >> > >> > The first 2 are intuitive but the last, I struggle with. Would it be ...? Ew, that's cumbersome. And requires the queryant to have better-than-average clue about how to express networks in CIDR notation. Expressing a range as a range (and not in CIDR notation) is far preferable, IMO. Tim From ehall at ehsco.com Thu Aug 21 23:29:40 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 21 23:29:47 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-internet-resource-number-req-0 0.txt In-Reply-To: <5.2.1.1.0.20030821132855.01f72148@192.149.252.141> References: <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> <3F447E2F.5090501@ripe.net> <200308111631.MAA22222@ietf.org> <200308181417.14060.davidb@verisignlabs.com> <3F41F524.3010808@ripe.net> <200308191004.50617.davidb@verisignlabs.com> <3F43A4DB.2060608@ripe.net> <3F43F77F.7030909@ehsco.com> <3F447E2F.5090501@ripe.net> <5.2.1.1.0.20030821104858.01dc5540@192.149.252.141> <5.2.1.1.0.20030821132855.01f72148@192.149.252.141> Message-ID: <3F458E24.3000908@ehsco.com> on 8/21/2003 12:58 PM Tim Christensen wrote: > If what you are meaning is "These are named aggregates-of-netblocks > [CIDR-expressed blocks], not the [individual] netblocks themselves", I > would agree with that. Yeah, that's what I mean. >>> To exemplify, assume that we have a network delegation from >>> 10.10.254.2 to 10.10.254.254 (this is close to a real world example >>> in ARIN's database, details modified somewhat). It requires 13 >>> CIDR blocks to represent this single network resource (resource >>> from the perspective of a single allocation instance). If I were >>> to issue a query for 10.10.254.64, or even for the range >>> 10.10.254.64 -> 10.10.254.240, I would want to know that this range >>> is encompassed by the delegated network 10.10.254.2->254. Using >>> the 'netblock' query model above does not permit the latter query >>> (since itself is a multi-cidr range), and the further discussion >>> seemed to preclude identification of the network as a single >>> database entry (again not reflective of reality and undesirable >>> IMO) >> >> The example you cited is supported in the default (with FIRS anyway). >> Each parent netblock in the delegation path would be returned as it >> was encountered during the chase-down to the query value. > > Could you amplify your response further? Let me provide context. > > In the example above of the range 10.10.254.2 to 10.10.254.254, the > proper way to describe this 'network' in CIDR is: > > 10.10.254.2/31 + 10.10.254.4/30 + 10.10.254.8/29 + > 10.10.254.16/28 + 10.10.254.32/27 + 10.10.254.64/26 + > 10.10.254.128/26 + 10.10.254.192/27 + 10.10.254.224/28 + > 10.10.254.240/29 + 10.10.254.248/30 + 10.10.254.252/31 + > 10.10.254.254/32 > > Now, if I search for the range 10.10.254.64 -> 10.10.254.240, I am only > hitting nodes in cidr-sections 6,7,8,9, and 10 in my list of 13.... > > My assertion is that the protocol should be defined such that it > returns the network 10.10.254.2->254, because that was the closest > aggregated network delegation. It should _not_ only return the cidr > blocks represented by cidr-sections 6 thru 10 above, because that is an > incomplete expression of the delegation that was delegated by the > upstream. > > Similarly, if I used a single-term query such as 10.10.254.64, it would > still return the network 10.10.254.2->254, because that node is > encompassed in that delegated network, and to return only > 10.10.254.64/26 mischaracterizes the delegation. Okay I see what you're seeing, and this is different than what I thought you were saying earlier. > In the context above, what would FIRS return? The inetIpvNetworkMatch query doesn't match against entries that exceed a netblock so if you gave it 10.10.254.64 it would find the 10.10.254.64/26 entry and none of the siblings. It would find any parent netblocks that had been created (eg 10.10.254.0/24), but since your example uses an administrative grouping and not a netblock delegation, the matching entry is the only one that would be returned in a fully-distributed query. Note that the sibling entries could be returned as attribute values which identified the other netblocks. You could also do a targetted search against the server for the administratively grouped data. But in the default distributed query (where the client has zero knowledge apart from an input address), the associated entries wouldn't be located in the distributed system using the "normal" query syntax. As a demonstration of this, I've added the entries to goose.ehsco.com. Point a whois client to that and issue a query for 10.10.254.64/26 (or any address within that specific netblock), and you'll get back that entry alone, but the data contains pointers to all of the siblings, which you can requery for through the same interface. You can point an LDAP client to that same server and issue a query with the searchbase of cn=inetResources,dc=ntrg,dc=com and with the assertion value of (&(objectclass=inetIpv4Network)(inetPrivateIdentifier=TC-NET-00)) to find all of the netblocks associated with "TC-NET-00" private identifier. Although it would be possible to automate such a query, it's important to point out again that identifiers like "TC-NET-00" don't have any hierarchy in their naming, so they cannot be used as seed values for searches against distributed partititions. Unless the RIRs want to setup a branch of governance to allocate identifiers (which you hopefully don't want), that won't ever work. > More to the point, what should the CRISP protocol call for > $CRISP_IMPLEMENTATION demand? I believe it's more 'correct' to return > the entire 'delegation', not just its closest CIDR sub-component. Return all 13 detailed entries or just a pointer to the siblings? If the latter then that's working now. It could probably stand to be cleaned up some -- there need to be explicit sibling, parent and child attributes to fully present what's registered, rather than relying on a generic "associated" attribute -- but the latter part more or less works now. > Moving on, how would I have queried the first search above in the > following [strawman] query models (from earlier in the thread): > >>>> >>>> >>>> 3238002688 3238010879 >>>> >>>> >>>> > > The first 2 are intuitive but the last, I struggle with. Would it be > VAL="10.10.254.128"/>... VAL="32"/>? In FIRS, it's just a single unit of "10.10.254.64/26". > Ew, that's cumbersome. And requires the queryant to have > better-than-average clue about how to express networks in CIDR > notation. Don't get UI stuff confused with this. It's possible to represent a netblock by any number of mechanisms. The firs.pl demonstration client (the one listening on goose:43) will take an address without a prefix and take an educated guess at the appropriate network, for example. It also handles the various hex/octal notations. Its not hard to imagine another client having two fields: start: [___.___.___.___] end: [___.___.___.___] and then try to figure out what the user wants. The format of the vallue in the protocol message is what's important, not the data-entry format. > Expressing a range as a range (and not in CIDR notation) is far > preferable, IMO. That format also assumes that the queryant knows what the full administrative assignment looks like. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Internet-Drafts at ietf.org Fri Aug 22 11:00:54 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Fri Aug 22 10:01:02 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-06.txt Message-ID: <200308221400.KAA24690@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Cross Registry Internet Service Protocol (CRISP) Requirements Author(s) : A. Newton Filename : draft-ietf-crisp-requirements-06.txt Pages : 32 Date : 2003-8-22 Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-requirements-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-requirements-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-requirements-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From ehall at ehsco.com Fri Aug 22 12:05:15 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 12:05:24 2003 Subject: [Ietf-not43] address issues Message-ID: <3F463F3B.70803@ehsco.com> I'm going to try and summarize the issues we've talked about so far. Feel free to correct/criticize these statements. 1] Netblocks (address/prefix) should be the atomic units of data in the distributed database, for several reasons. Netblocks have embedded hierarchical information which is sufficiently usable as key values for distributed lookups. Administrative ranges (start.addr - end.addr) also seem to provide sufficent detail for this, but netblocks use a single value which is substantially easier to work with in general. Netblocks are what actually get delegated. When a netblock is allocated, an associated range may get created or expanded. When the last netblock from a range is de-allocated, the range is destroyed. Granted, the need for a netblock is driven by a need for address space, but the space is actually managed through netblocks and not ranges (eg, multiple ranges used when contiguous netblocks aren't available). Netblocks are always the smallest unit of data; an adress range can never be smaller than a netblock. Furthermore, netblocks are often the largest unit of data (but not always). EG, address ranges can have gaps, meaning that they cannot always be used to represent contiguous address space. Furthermore, netblocks can be transferred between operators as discrete units of data (modulo policy considerations for doing so), potentially resulting in (additional) gaps within an administrative range. As a result, netblocks are always the smallest (atomic) unit of data, and are often the largest unit of data. Since netblocks are the most-atomic, they are generally going to be the most-useful for external systems (including existing layered applications and new ones alike). There are some UI factors here (eg, the format of a control file), but in the general case, a netblock is going to be more useful as the canonical representation of a network. Entry names that use netblocks represent superiority in the hierarchy through relatively simple comparisons of bitmasks that are easy to compute, while address ranges require multiple operations for these same comparisons. EG, a netblock entry name of 10.0.0.0/8 has a single-comparison superiority to 10.1.0.0/16, although the same relationship would require multiple operations when using address ranges. At a minimum, an address range would require that all of the addresses from both ranges be verified as valid, and for the ending addresses to be verified as greater than the starting addresses, and so forth (this is going to be even more intensive for IPv6 networks). Cumulatively, this means that netblocks are probably the best choice as the atomic records in the distributed database. They are simple to use, they are mandatory from a delegation perspective and are often needed for layered applications, they are always the smallest unit of data and are often the largest unit of data, and they are easy to use as lookup key values and thus easy to reference. 2] There needs to be a way to represent larger associations (ranges) in the system as a whole. Currently this is handled by listing the related netblocks. My suspicion is that there needs to be different kinds of attributes for parent, sibling and child associations in order to adequately represent the relationships between the networks, and to provide sufficient pointers to the users. Is there agreement on this point? There is a caveat here that these relationships are only going to have meaning within a specific partition of the database. EG, ARIN is only going to know about the sibling netblocks that it has assigned to an organization, not about the netblocks that RIPE may have also assigned, nor any child netblocks that may have been defined by the operator of the netblock itself. ASN data can unify some of this data, in those cases where an ASN is actually being used and where views of the ASN routing data is available, but those are probably going to be exceptions instead of the norm. 3] There probably needs to be some kind of well-known client algorithm for mapping ranges to netblock syntaxes, particularly in those cases where an input range does not match a single netblock. This is technically outside the scope of the protocol, but it will probably happen often enough that we will want to have some kind of public preference for dealing with it. >From my perspective, the easiest way to handle a mismatch like this would be to ignore the erroneous range and just use the starting address since that would produce all of the parent netblock delegations (and would list all of the related netblocks), but maybe something along the lines of trying to determine the constituent netblocks and issuing OR queries for all of them could be made to work. This is difficult work. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From hardie at qualcomm.com Fri Aug 22 10:53:48 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Fri Aug 22 12:53:59 2003 Subject: [Ietf-not43] address issues In-Reply-To: <3F463F3B.70803@ehsco.com> References: <3F463F3B.70803@ehsco.com> Message-ID: At 11:05 AM -0500 08/22/2003, Eric A. Hall wrote: > >Netblocks are always the smallest unit of data; an adress range can never >be smaller than a netblock. Furthermore, netblocks are often the largest >unit of data (but not always). EG, address ranges can have gaps, meaning >that they cannot always be used to represent contiguous address space. This is a critical point from my experience. I worked on a proposal with a couple of other folks a while back to limit how longest-match processing applied to "covered" addresses*, and it turns out one of the hardest things to deal with is the reality that some of those longer prefixes were not deliverable *at all* by the entities advertising the covered address. That is, someone advertising a /16 may have alienated a /24 within it so completely that they do not deliver traffic to that /24; the successful delivery of traffic *depends* on the existence of the longer prefix being in the routing table. I think that we need to be very careful in structuring this data model so that we can deal with that reality. I also suspect that, that, despite the temptation alluded to here: (Eric again) >Netblocks have embedded hierarchical information which is sufficiently >usable as key values for distributed lookups. we need to be very careful to separate the identifiers used for distributed lookups from the data itself. That will give us added flexibility to handle the different types of relationships which may pertain between objects over times. regards, Ted Hardie *draft-grow-bounded-longest-match-00.txt is a descendent of that work, but Russ White has been the key to the work for so long I am not even sure why my name is still on it. From ehall at ehsco.com Fri Aug 22 12:54:22 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 12:54:27 2003 Subject: [Ietf-not43] traditional searches Message-ID: <3F464ABE.3010909@ehsco.com> In the message I sent last night, I gave an example of finding all of the netblocks in a range by having the client query for TC-NET-00. This is a traditional search-by-value query, and those have several inter-related issues. The obvious issue is that these are scope-restrained to a specific partition. In other words, the client has to know which partition the query is for (eg, arin.net, or netsol.com, or whatever), find a server that is capable of processing queries for that partition, and then issue the query to the selected server. Cumulatively this is all described as part of the "targetted" model in the current specs. Since these queries use standard LDAP matching filters, they do not require any special support by servers that support LDAP. However, Andy made a case for limiting these, and if we're going to be publishing capability lists that indicate whether or not any of these are going to be supported on a particular server, this means that some discussion in the specs is going to be required. The current specs allow clients to issue any query-by-value that they desire, but does not encourage any of them. If we're going to be talking about the capabilities (above), then we may want to itemize some of the queries that clients should expect to be able to support, and that servers should be making available to clients. For example, should we say that servers SHOULD support equality matches for the private identifier sequences (the TC-NET-00 example from earlier)? What about soundex queris for other attributes like company name or whatever? Or should we just leave it that clients can issue any search-by-value they want/need, according to the capabilities of the current server? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Fri Aug 22 13:14:49 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 13:14:57 2003 Subject: [Ietf-not43] address issues In-Reply-To: References: <3F463F3B.70803@ehsco.com> Message-ID: <3F464F89.1030903@ehsco.com> on 8/22/2003 11:53 AM hardie@qualcomm.com wrote: > we need to be very careful to separate the identifiers used for > distributed lookups from the data itself. That will give us added > flexibility to handle the different types of relationships which may > pertain between objects over times. Abstracting things like part numbers sepate from the parts themselves is certainly an important principle in database design. On the other hand, abstracting social-security numbers in a database of SSNs is usually counter-productive. Addressing data falls into the latter camp, I think, just like domain names are self-referential to the point where DNS benefits from using them as the key values. While we're on the subject of abstracting identifiers, I was going to make the point that netblocks make better identifiers because they are provider-independent, but that's not always going to be true. While it is true that netblocks can easily move between providers (or more likely, between operators within a provider's realm), the same is also true for ranges albeit it less likely. Both identifiers can be bought/sold in the scope of where such transfers are allowed. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 22 14:45:07 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 22 13:17:51 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F464ABE.3010909@ehsco.com> References: <3F464ABE.3010909@ehsco.com> Message-ID: <3F4656A3.1040001@ecotroph.net> Eric A. Hall wrote: > > Since these queries use standard LDAP matching filters, they do not > require any special support by servers that support LDAP. However, Andy > made a case for limiting these, and if we're going to be publishing > capability lists that indicate whether or not any of these are going to be > supported on a particular server, this means that some discussion in the > specs is going to be required. I am not following this very well. So I don't know what it is you are claiming I said should be limited. However, the idea of publishing capability lists is yours, and in the case of LDAP I think it is a bad solution to 3.1.8, if that is what you referencing. > The current specs allow clients to issue any query-by-value that they > desire, but does not encourage any of them. If we're going to be talking > about the capabilities (above), then we may want to itemize some of the > queries that clients should expect to be able to support, and that servers > should be making available to clients. For example, should we say that > servers SHOULD support equality matches for the private identifier > sequences (the TC-NET-00 example from earlier)? What about soundex queris > for other attributes like company name or whatever? Or should we just > leave it that clients can issue any search-by-value they want/need, > according to the capabilities of the current server? By current specs, I assume you are talking about FIRS. This is already true for IRIS by its very nature. -andy From anewton at ecotroph.net Fri Aug 22 14:46:12 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 22 13:18:56 2003 Subject: [Ietf-not43] address issues In-Reply-To: References: <3F463F3B.70803@ehsco.com> Message-ID: <3F4656E4.4000608@ecotroph.net> hardie@qualcomm.com wrote: > > we need to be very careful to separate the identifiers used for distributed > lookups from the data itself. That will give us added flexibility to > handle > the different types of relationships which may pertain between objects > over times. I totally agree. -andy From ehall at ehsco.com Fri Aug 22 13:23:17 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 13:23:23 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F4656A3.1040001@ecotroph.net> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> Message-ID: <3F465185.5050603@ehsco.com> on 8/22/2003 12:45 PM Andrew Newton wrote: > Eric A. Hall wrote: > >> Since these queries use standard LDAP matching filters, they do not >> require any special support by servers that support LDAP. However, >> Andy made a case for limiting these, and if we're going to be >> publishing capability lists that indicate whether or not any of these >> are going to be supported on a particular server, this means that >> some discussion in the specs is going to be required. > > I am not following this very well. So I don't know what it is you are > claiming I said should be limited. I took it from the examples you cited that you wanted to be able to refuse things like substring and approximate matching unless the user was known to be authorized to do those. > However, the idea of publishing capability lists is yours, and in the > case of LDAP I think it is a bad solution to 3.1.8, if that is what you > referencing. Perhaps you could honor us with a counter-proposal that doesn't introduce outrageous costs on every search. >> The current specs allow clients to issue any query-by-value that they >> desire, but does not encourage any of them. If we're going to be >> talking about the capabilities (above), then we may want to itemize >> some of the queries that clients should expect to be able to support, >> and that servers should be making available to clients. For example, >> should we say that servers SHOULD support equality matches for the >> private identifier sequences (the TC-NET-00 example from earlier)? >> What about soundex queris for other attributes like company name or >> whatever? Or should we just leave it that clients can issue any >> search-by-value they want/need, according to the capabilities of the >> current server? > > By current specs, I assume you are talking about FIRS. This is already > true for IRIS by its very nature. Yes, FIRS already works this way. I'm trying to accomodate the additional restraint mechanisms you indicated were necessary. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 22 15:06:35 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 22 13:39:19 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F465185.5050603@ehsco.com> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> Message-ID: <3F465BAB.3040202@ecotroph.net> Eric A. Hall wrote: >>However, the idea of publishing capability lists is yours, and in the >>case of LDAP I think it is a bad solution to 3.1.8, if that is what you >>referencing. > > > Perhaps you could honor us with a counter-proposal that doesn't introduce > outrageous costs on every search. > Solution 2 mentioned here: > http://lists.verisignlabs.com/pipermail/ietf-not43/2003-August/000767.html Now, maybe you could honor us with a reason why it can't/shouldn't be done that way. -andy From ehall at ehsco.com Fri Aug 22 13:46:50 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 13:47:02 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F465BAB.3040202@ecotroph.net> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> <3F465BAB.3040202@ecotroph.net> Message-ID: <3F46570A.8010808@ehsco.com> on 8/22/2003 1:06 PM Andrew Newton wrote: > Eric A. Hall wrote: > >>> However, the idea of publishing capability lists is yours, and in >>> the case of LDAP I think it is a bad solution to 3.1.8, if that is >>> what you referencing. >> >> Perhaps you could honor us with a counter-proposal that doesn't >> introduce outrageous costs on every search. > > Solution 2 mentioned here: > >> http://lists.verisignlabs.com/pipermail/ietf-not43/2003-August/000767.html > > Now, maybe you could honor us with a reason why it can't/shouldn't be > done that way. Presumably the reference to (2) are a reference to the (2b) in the original. As I've already said, that approach has excessive costs. For the same amount of time spent on the probe, the original query could have just been issued and rejected, with the exact same results. By comparison, a capability list would have been returned before the client even got the chance to issue either the probe or the query, and would have already moved on to the recovery steps. In short, the capability model is faster and has significantly lower processing requirements for all parties. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 22 15:53:43 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 22 14:26:27 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F46570A.8010808@ehsco.com> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> <3F465BAB.3040202@ecotroph.net> <3F46570A.8010808@ehsco.com> Message-ID: <3F4666B7.4010001@ecotroph.net> Eric A. Hall wrote: > > Presumably the reference to (2) are a reference to the (2b) in the > original. As I've already said, that approach has excessive costs. For the > same amount of time spent on the probe, the original query could have just > been issued and rejected, with the exact same results. By comparison, a > capability list would have been returned before the client even got the > chance to issue either the probe or the query, and would have already > moved on to the recovery steps. In short, the capability model is faster > and has significantly lower processing requirements for all parties. No publicly-facing server is going to trust that the client obeys a capabilities list and it will always do an authorization check on a query. A 'dry run' switch simply stops the trip to the data store, which is probably more expensive than the authorization check. -andy From ehall at ehsco.com Fri Aug 22 14:55:04 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 14:55:13 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F4666B7.4010001@ecotroph.net> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> <3F465BAB.3040202@ecotroph.net> <3F46570A.8010808@ehsco.com> <3F4666B7.4010001@ecotroph.net> Message-ID: <3F466708.9040400@ehsco.com> on 8/22/2003 1:53 PM Andrew Newton wrote: > No publicly-facing server is going to trust that the client obeys a > capabilities list and it will always do an authorization check on a > query. The benefits of a capabilities model go to both the client and the server (the client benefits are arguably higher in some scenarios). I'm not calling this a guarantee of use, just pointing out the motivation. On the other hand, there is absolutely zero motivation for a client to use a probe. This is illustrated below. > A 'dry run' switch simply stops the trip to the data store, > which is probably more expensive than the authorization check. Here are some examples. First, a basic rejection of a submitted query due to permission failures of the query context does not require a trip to the mail store: client: bind server: okay client: query server: permission denied client: bye This is identical to a probe that gets rejected. There are zero savings in this scenario, and the client would have gotten the same mileage from just issuing the original query: client: bind server: okay client: probe server: rejected due to permissions client: bye Worse are successes. Here's a non-probe success: client: bind server: okay client: query server: answer data... client: bye Here's a probe success. Again, the client would have been better off by just issuing the damn query: client: bind server: okay client: probe server: okay client: query server: answer data... client: bye Variations on those themes such as recovery probes/queries follow the same basic math. Here's what failure with the capabilities model looks like: client: bind server: okay; capabilities client: bye Here's what success with the capabilities model looks like: client: bind server: okay; capabilities client: query <--known valid server: answer data... client: bye So, probes are always of equal or higher cost than just issuing the original query, while the capabilities model is always faster and cheaper. This is demonstrably better for the servers, but is also better for clients since latency is cumulative, and the cumulative penalty goes against the client. EG, if the client gets directed to a resource entry on a server that is three or four levels deep (domain.isp.co.uk, or a netblock that is reallocated multiple times), then the extra round trips really start adding up, especially if they are coming via a high-latency link (eg, a cellular PDA). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 22 17:59:44 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 22 16:32:27 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F466708.9040400@ehsco.com> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> <3F465BAB.3040202@ecotroph.net> <3F46570A.8010808@ehsco.com> <3F4666B7.4010001@ecotroph.net> <3F466708.9040400@ehsco.com> Message-ID: <3F468440.2050108@ecotroph.net> Eric A. Hall wrote: > > So, probes are always of equal or higher cost than just issuing the > original query, while the capabilities model is always faster and cheaper. > This is demonstrably better for the servers, but is also better for > clients since latency is cumulative, and the cumulative penalty goes > against the client. EG, if the client gets directed to a resource entry on > a server that is three or four levels deep (domain.isp.co.uk, or a > netblock that is reallocated multiple times), then the extra round trips > really start adding up, especially if they are coming via a high-latency > link (eg, a cellular PDA). Admittedly, the use cases are vague. However, a probe is not guaranteed to be as expensive as the query. Also, a probe is at the client's discretion on a per query basis, where as a capabilities list is something always done. Finally, how do you handle granularity with authorization based on the user's relationship with the data. Is your capabilities list going to list all 1000 domains a tech contact is related to? Not only is that bandwidth entensive, it causes a massive search on the server during the authentication step and could be totally useless if the user were looking up a domain to which they have no relationship. -andy From ehall at ehsco.com Fri Aug 22 17:25:31 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 17:25:37 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <3F468440.2050108@ecotroph.net> References: <3F464ABE.3010909@ehsco.com> <3F4656A3.1040001@ecotroph.net> <3F465185.5050603@ehsco.com> <3F465BAB.3040202@ecotroph.net> <3F46570A.8010808@ehsco.com> <3F4666B7.4010001@ecotroph.net> <3F466708.9040400@ehsco.com> <3F468440.2050108@ecotroph.net> Message-ID: <3F468A4B.5060101@ehsco.com> on 8/22/2003 3:59 PM Andrew Newton wrote: > Finally, how do you handle granularity with authorization based on the > user's relationship with the data. Numerous combinations are possible, but again, it would be very useful to get a description of what is actually needed. Here's the full text of the addtional requirements presented so far: Andrew Newton wrote in <3F437ECE.6020501@ecotroph.net> | I know our service will not allow somebody to do a subtree search in | the contacts DIT. For RLDAP, we excluded any partial string matching | if they didn't give use the first three letters of the name (e.g. | cn=*, cn=b*, and cn=bob*). Therefore matching rules, search filters, | and scope will be allowed and disallowed depending on what the | person is attempting to do. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From davidb at verisignlabs.com Fri Aug 22 19:34:11 2003 From: davidb at verisignlabs.com (David Blacka) Date: Fri Aug 22 18:38:07 2003 Subject: [Ietf-not43] traditional =?iso-8859-1?q?searches=0A=0A?= In-Reply-To: <3F468A4B.5060101@ehsco.com> References: <3F464ABE.3010909@ehsco.com> <3F468440.2050108@ecotroph.net> <3F468A4B.5060101@ehsco.com> Message-ID: <200308221834.11136.davidb@verisignlabs.com> On Friday 22 August 2003 05:25 pm, Eric A. Hall wrote: > > on 8/22/2003 3:59 PM Andrew Newton wrote: > > > Finally, how do you handle granularity with authorization based on the > > user's relationship with the data. > > Numerous combinations are possible, but again, it would be very useful to > get a description of what is actually needed. Heh. Here you go: 3.1.8.1 Protocol Requirement The protocol MUST provide a mechanism allowing a client to determine if a query will be denied before the query is submitted according to the appropriate policies of the operator. > Here's the full text of the addtional requirements presented so far: Those weren't requirements. That was just an example. The problem here is that the CRISP service is expected to be able to support various detailed, nuanced, and, from the perspective of the protocol, *arbitrary* policies. It is hard for me to see how a capabilities list could possibly handle that. In reality, it is likely that the policies enacted by the service operators will be common and possibly easily enumerable, but we don't know what they are now and don't want to constrain them. However, given the session state and the query, it will *always* be possible to determine whether or not policy will allow it. I can totally understand the difficulty you are having understanding *why* this requirement exists, as I don't really understand why either: why not just issue the query and see if it fails? Maybe those folks who argued for the requirement in the first place could enlighten us. Or maybe it is somewhere in the list archives. I do agree that if the policy in question is based on the data the the query would return, it is totally useless from an efficiency standpoint: the query is going to actually have to be run, so why not just actually issue the query? But if the policy is based on the session state and query itself (thus avoiding a trip to the datastore), I can see how it might be useful. Note that I'm not saying that a capabilities list is a bad thing in and of itself. In fact, I believe that it satisfies the language of 3.1.8.1. But in order to actually do it, you will have to enumerate all of the policy types as part of the protocol, which might be seen as limiting. Also, since the WG hasn't gone through the exercise of enumerating the types of policies (and I don't think it should), it will be hard to come up with the list. -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Fri Aug 22 19:40:39 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 22 19:40:47 2003 Subject: [Ietf-not43] traditional searches In-Reply-To: <200308221834.11136.davidb@verisignlabs.com> References: <3F464ABE.3010909@ehsco.com> <3F468440.2050108@ecotroph.net> <3F468A4B.5060101@ehsco.com> <200308221834.11136.davidb@verisignlabs.com> Message-ID: <3F46A9F7.40806@ehsco.com> on 8/22/2003 5:34 PM David Blacka wrote: > I do agree that if the policy in question is based on the data the the > query would return, it is totally useless from an efficiency > standpoint: the query is going to actually have to be run, so why not > just actually issue the query? But if the policy is based on the > session state and query itself (thus avoiding a trip to the datastore), > I can see how it might be useful. That's pretty much what I'm focusing on. If you're going to refuse a query because of syntax (not because of data), then telling the user what they can expect is useful (to the extent that this is possible). If you're going to error a query because of data, then the query has to run anyway so why bother running it in advance. Right now I'm thinking that the capability list should itemize the FIRS objectclasses and the filters that are supported for each objectclass. EG, something like "inetDnsDomain:inetDnsDomainMatch;equalityMatch" would mean that the swerver will let you use either the inetDnsDomainMatch or equalityMatch filters to search for domain name resources, but don't bother submitting substringMatch, approxMatch, or any of the others. In the case where the server allowed any of the supported queries through, then the database ACLs are where any additional rejections should happen, so there is no sense in specifying any of that stuff. Another more obscure condition would be the contact restrictions Andy cited, which allowed substringMatch, but only if the assertion value contained three characters. I'm not sure I want to try and specify something like that, so that condition should probably be handled with a private error (text, not code). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Sun Aug 24 11:36:53 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 24 11:37:12 2003 Subject: [Ietf-not43] inetResourcesControl text Message-ID: <3F48DB95.7030304@ehsco.com> This is the new text on the control (renamed to reflect broader use). If anybody sees any problems with this let me know. 5.3.1. The inetResourcesControl server control The inetResourcesControl server control is the master control object for the FIRS service, and provides the version of each object class that is available for use on the current server, and also lists the matching filters that the server is willing to use for each of the listed object classes. The OID for inetResourcesControl is 1.3.6.1.4.1.7161.1.0.0. This value MUST be provided in the OID field of the control. The value section of the inetResourcesControl contains nested sequences of data. The first element in each sequence identifies an class, while the remainder of each sequence identifies the matching filters. The structure of the value section of inetResourcesControl is illustrated by the following ASN.1 definition: inetResourcesControlValue ::= SEQUENCE { objectClass LDAPOID, matchingFilters SEQUENCE OF matchingFilter } matchingFilter ::= LDAPSTRING Each object class and matching filter MUST be presented as a string. Object classes MUST be listed as OIDs so that clients can determine the supported object classes according to their version. Matching filters MUST also be provided as OIDs, except for the "stock" matching filter operators defined in [RFC2251], which MUST be presented with the textual identifiers shown therein. At a minimum, servers MUST support the equalityMatch and extensibleMatch filters from [RFC2251] for every object class listed, and SHOULD always declare these filters. The Asterisk character ("*") MAY be provided as a wildcard in the list of matching filters to indicate that the server will accept any matching filter for the associated object class. Servers MUST allow any supported matching filter to be used as part of an extensibleMatch operation, and clients MAY assume that any allowed operation will be acceptable as part of an extensibleMatch. An example of an inetResourcesControl server control is shown below for illustration purposes: { 1.3.6.1.4.1.7161.1.0.0, FALSE, { 1.3.6.1.4.1.7161.1.3.1 { 1.3.6.1.4.1.7161.1.0.3, equalityMatch, substringMatch, extensibleMatch } }, { 2.16.840.1.113730.3.2.2 { equalityMatch, extensibleMatch } } } Figure 4: An example inetResourcesControl server control. In the example shown in Figure 4, the inetResourcesControl type is identified by the OID of 1.3.6.1.4.1.7161.1.0.0, while the criticality field is set to FALSE, as per the requirements in [RFC2251]. The contents of the control value identify the current OID for the inetDnsDomain object class, along with the OID for the inetDnsDomainMatch and the [RFC2251] textual identifiers for the equalityMatch, substringMatch and extensibleMatch operators, and also identifies the OID for the inetOrgPerson object class along with the [RFC2251] textual identifiers of the equalityMatch and extensibleMatch operators. FIRS-compliant servers SHOULD return the inetResourcesControl server control as an unsolicited response to a successful bind request. Clients MUST use the OID of the inetResourcesControl for the purpose of validating the contents of the control, and MUST use the OIDs of the listed object classes to discover schema versioning information. Servers MAY restrict the contents of the inetResourcesControl value according to the authenticated identity of the client. For example, servers can choose to enable computationally-intense searches for authorized users while refusing to provide the same searches for anonymous users. If a client does not receive a usable inetResourcesControl control as part of the bind response, the client SHOULD issue a request for the control before proceeding. If a client is still unable to obtain a usable inetResourcesControl server control, the client MAY choose a different server for the partition, or MAY choose to assume that the equalityMatch matching filter will be supported for any of the known types, or MAY choose to undergo any other recovery efforts. In any event, clients SHOULD NOT use the absence or contents of the control to completely abort query processing unless all of the servers for a partition have refused to provide service to the client. For example, if the server advertises support for the inetDnsDomain object class but does not advertise support for the inetDnsDomainMatch matching filter, the client MAY issue discrete equality searches for each of the specific domain name resources (note that this kind of query can fail to produce referrals in some cases, but will usually produce at least some answers). In all cases, if any given server advertises support for a particular object class or matching filter, the client MUST make use of the server-provided service. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Mon Aug 25 17:18:18 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Mon Aug 25 10:18:30 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] Message-ID: <3F4A1AAA.1020409@daasi.de> Oops, I forgot to include the list in my reply. Thanks Andrew to make me aware of this. Cheers, Peter -------- Original Message -------- Subject: Re: [Ietf-not43] Re: Requirement 3.1.8 Date: Mon, 25 Aug 2003 14:58:05 +0200 From: Peter Gietz Organization: DAASI International GmbH To: Andrew Newton References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F413C1A.8060609@ehsco.com> <3F4145C3.4040706@ecotroph.net> <3F417E94.5000603@ehsco.com> <3F429CAC.4080206@ehsco.com> <3F435E55.7040705@daasi.de> <3F436250.9000100@ecotroph.net> <3F4373F7.3040608@daasi.de> <3F437ECE.6020501@ecotroph.net> Andrew Newton wrote: > Peter Gietz wrote: > >> >>> This is an interesting approach. It would probably need to be worked >>> out more thoroughly on paper first. However, you would also need to >>> include the qualifying matching rules and search scope. >> >> >> >> Why matching rules? Do you want to distinguish between string and >> substring search here? >> >> With scope I am not so sure either, since the policy should rule for >> whole subtrees. It shouldn't matter if the client makes basedn, >> onelevel or subtree searches, the access policy should be the same. >> >> I don't want to get this too complex. What might be added is the >> server side sizelimit (the maximum of entries a server will be willing >> to give back to the client), which should be one number for all naming >> contexts of the server. > > > People will be attempting to mine data from these servers. That is a > fact of life. I know our service will not allow somebody to do a > subtree search in the contacts DIT. For RLDAP, we excluded any partial > string matching if they didn't give use the first three letters of the > name (e.g. cn=*, cn=b*, and cn=bob*). Therefore matching rules, search > filters, and scope will be allowed and disallowed depending on what the > person is attempting to do. I still think that it is easier to prevent mining by a serverside size limit than by specifying policy rules with parameters like scope and matching rule. As I said, including such paramenters will make the policy definition and interpretation quite complex. To get the functionality of your example, we would notonly have to specify if substringmatch is allowed and additionally the minimum length of the substirng. The latter would have to be implemented as dedicated FIRS feature since there i s no standard way of specifying substring length. Is there another opinion on this in the group besides Andrew's and mine? Cheers, Peter > > -andy > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From anewton at ecotroph.net Mon Aug 25 11:55:36 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Mon Aug 25 10:27:59 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] In-Reply-To: <3F4A1AAA.1020409@daasi.de> References: <3F4A1AAA.1020409@daasi.de> Message-ID: <3F4A2368.2000807@ecotroph.net> Peter Gietz wrote: > > > I still think that it is easier to prevent mining by a serverside size > limit than by specifying policy rules with parameters like scope and > matching rule. As I said, including such paramenters will make the > policy definition and interpretation quite complex. To get the > functionality of your example, we would notonly have to specify if > substringmatch is allowed and additionally the minimum length of the > substirng. The latter would have to be implemented as dedicated FIRS > feature since there i s no standard way of specifying substring length. You can count on size limits by the server. For the record, I do not favor the capabilities list. I was just stating what it would need to express to be account for the policies of the server operator. -andy From ehall at ehsco.com Mon Aug 25 11:10:05 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 25 11:10:14 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] In-Reply-To: <3F4A1AAA.1020409@daasi.de> References: <3F4A1AAA.1020409@daasi.de> Message-ID: <3F4A26CD.8050308@ehsco.com> on 8/25/2003 9:18 AM Peter Gietz wrote: > I still think that it is easier to prevent mining by a serverside size > limit than by specifying policy rules with parameters like scope and > matching rule. Mining-prevention is provided through a variety of mechanisms. Section 5.3.2 of firs-core identifies some query-level restrictions. [...] The size limit field specifies the maximum number of entries that a server should return. For the FIRS service, this setting SHOULD be set to a value between 25 and 100. [...] Servers MAY truncate answer sets if the client specifies a larger value. [...] The time limit field specifies the maximum number of seconds that a server should process the search. For the FIRS service, this setting SHOULD be set to a value between 10 and 60 seconds. [...] Servers MAY stop processing queries after the time limit if the client specifies a larger value. Section 5.3.3 identifies some volume restrictions: Specifically, server operators MAY restrict the amount of information provided to specific clients and/or users over a given amount of time, within reason. For example, servers MAY restrict clients to an arbitrary number of queries per-hour or per-day, or may impose mandatory time intervals between queries, and so forth. Servers which refuse to process a query due to volume policy SHOULD reject the connection and/or query using the "unwillingToPerform" response code ("53"), and SHOULD provide explanatory text in the error message. Clients MUST be prepared for connection requests and queries to be denied for any reason, and MUST treat these conditions as non-permanent failures. Clients MAY retry the operations if a known error condition is corrected (such as authentication errors), but SHOULD NOT automatically generate retry attempts. Then there is the new control text, which provides a way for a server to tell a client which syntaxes are going to be allowed in the query. So basically, servers have a lot of options for mining-prevention and operators have a lot of buttons and knobs for preventing excess queries. > As I said, including such paramenters will make the > policy definition and interpretation quite complex. I don't see any reason to include these right now. If at some time we discover a specific need for this kind of stuff, we can update the inetResourcesControl and change its OID accordingly. The versioning text was specifically provided to allow that -- eg, if the server returns a newer control (with a new OID) the client can issue an explicit query for the version it understands. To get the > functionality of your example, we would notonly have to specify if > substringmatch is allowed and additionally the minimum length of the > substirng. The latter would have to be implemented as dedicated FIRS > feature since there i s no standard way of specifying substring length. I'm not worried about this at the moment. If it becomes a universal, we can try to accomodate it at a later date. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 25 12:00:26 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 25 12:00:33 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] In-Reply-To: <3F4A26CD.8050308@ehsco.com> References: <3F4A1AAA.1020409@daasi.de> <3F4A26CD.8050308@ehsco.com> Message-ID: <3F4A329A.2000108@ehsco.com> on 8/25/2003 10:10 AM Eric A. Hall wrote: > Mining-prevention is provided through a variety of mechanisms. BTW, the reason I've got an ARCH document separate from a CORE document is so that concepts can be described separately from the frobs. This is a good example area, where the numerous frobs scattered throughout CORE can lose their unity, and so should be discussed holistically in ARCH. As such, I've added the following text to ARCH to clarify the frobs that are available in CORE. Are there any other frobs that any of the operators feels they need to have, and which are missing from this list? 6.5. Query Restriction Mechanisms [FIRS-CORE] defines several discrete rules that can be employed by server operators to limit the quantity and rate of queries from any particular client. Some of these restrictions include: * [5.3.3] Servers MAY refuse service to any client. * [5.3.3] Servers MAY impose arbitrary maximum limits on the number of queries issued by any particular client for any given time period, such as limiting clients to 50 queries- per-day or five queries-per-hour. * [5.3.3] Servers MAY impose arbitrary time intervals between successive queries from any particular client, such as requiring clients to wait five minutes between each query. * [5.3.1] Servers MAY restrict the object classes that any particular client can query for, and MAY restrict the matching filters that any particular client uses for any of the object classes that they are allowed to query. * [5.3.2] Servers MAY restrict the maximum length of time they spend on any particular query before terminating the query. * [5.3.2] Servers MAY restrict the maximum number of matches that will be returned before terminating the query. * [5.3.4] Server operators MAY define ACLs on entries and attributes in the database that restrict the data that is matched for any particular client. Any of these restrictions MAY be defined by the operators of the server in question, according to the policies deemed necessary by the operators of that. For example, operators MAY apply different restrictions on ranges of client addresses, or authenticated identity, or any other necessary metric, or any combination thereof. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Mon Aug 25 13:49:34 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 25 13:49:40 2003 Subject: [Ietf-not43] where are explicit result codes needed Message-ID: <3F4A4C2E.8080403@ehsco.com> I'm trying to finish up edits on the -03 drafts, and I'd appreciate it if those folks who think we need explicit result codes would point out where they feel the codes are needed. I don't want to enumerate everything, because that has the potential of keeping implementations from adopting new codes that might evolve over time. Thanks -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From davidb at verisignlabs.com Mon Aug 25 15:00:46 2003 From: davidb at verisignlabs.com (David Blacka) Date: Mon Aug 25 14:04:50 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] In-Reply-To: <3F4A329A.2000108@ehsco.com> References: <3F4A1AAA.1020409@daasi.de> <3F4A26CD.8050308@ehsco.com> <3F4A329A.2000108@ehsco.com> Message-ID: <200308251400.47079.davidb@verisignlabs.com> On Monday 25 August 2003 12:00 pm, Eric A. Hall wrote: > > on 8/25/2003 10:10 AM Eric A. Hall wrote: > > > Mining-prevention is provided through a variety of mechanisms. > > BTW, the reason I've got an ARCH document separate from a CORE document is > so that concepts can be described separately from the frobs. This is a > good example area, where the numerous frobs scattered throughout CORE can > lose their unity, and so should be discussed holistically in ARCH. > > As such, I've added the following text to ARCH to clarify the frobs that > are available in CORE. > > Are there any other frobs that any of the operators feels they need to > have, and which are missing from this list? Arbitrary maximum limits on the number of result objects for any given time period for a particular client. IMHO, this is the core of mining prevention, as it is actually directly measuring the correct thing (response objects per unit time). I think that it should be possible to count some result objects and not others towards the limit. -- David Blacka Sr. Engineer Verisign Applied Research From ehall at ehsco.com Mon Aug 25 23:57:26 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Mon Aug 25 23:57:34 2003 Subject: [Ietf-not43] extended attributes for privacy crap Message-ID: <3F4ADAA6.2070303@ehsco.com> I'm trying to get a handle on what exactly we're looking for with the extended privacy data. The most liberal reading of section 3.2.8 in req-06 essentially says that versions of the attributes should exist that have negative flags for privacy and access. These special attributes should be returned (instead of null responses) if the user is not authorized to view the actual data. Meanwhile, the new requirements in section 3.1.14 essentially says that if the user is authorized to view the underlying data, then versions of the attribute may be returned that have positive flags which indicate that the data is sensitive and shouldn't be shared. So that means we essentially have three classes of attribute values: attribute: data1 (here's the public data) attribute: (maybe there's data here, maybe not) attribute: data2 (here's the private data) We also have the null set of problems: attribute: 0 (was left empty and everybody knows it) attribute: 1 (you're not allowed to find out it's really empty) attribute: 2 (you're allowed to find out, but don't tell anybody) Is that right? I'm thinking I'm going to deal with this by defining attribute descriptions (similar to the language tags), and possibly make clients use a control during the query. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shane at ripe.net Tue Aug 26 12:58:53 2003 From: shane at ripe.net (Shane Kerr) Date: Tue Aug 26 05:58:58 2003 Subject: [Fwd: Re: [Ietf-not43] Re: Requirement 3.1.8] In-Reply-To: <200308251400.47079.davidb@verisignlabs.com> References: <3F4A1AAA.1020409@daasi.de> <3F4A26CD.8050308@ehsco.com> <3F4A329A.2000108@ehsco.com> <200308251400.47079.davidb@verisignlabs.com> Message-ID: <3F4B2F5D.6060102@ripe.net> David Blacka wrote: > On Monday 25 August 2003 12:00 pm, Eric A. Hall wrote: > >>on 8/25/2003 10:10 AM Eric A. Hall wrote: >> >> >>>Mining-prevention is provided through a variety of mechanisms. >> >>BTW, the reason I've got an ARCH document separate from a CORE document > > is > >>so that concepts can be described separately from the frobs. This is a >>good example area, where the numerous frobs scattered throughout CORE can >>lose their unity, and so should be discussed holistically in ARCH. >> >>As such, I've added the following text to ARCH to clarify the frobs that >>are available in CORE. >> >>Are there any other frobs that any of the operators feels they need to >>have, and which are missing from this list? > > > Arbitrary maximum limits on the number of result objects for any given time > period for a particular client. > > IMHO, this is the core of mining prevention, as it is actually directly > measuring the correct thing (response objects per unit time). > > I think that it should be possible to count some result objects and not > others towards the limit. We use this today, and would be sad to see this go. For instance, users can query the database to determine if space has been allocated, but may not care to see contact information. We only count contact information against our rate limits - you can get all the AS information you want from the database. :) -- Shane Kerr RIPE NCC From leslie at thinkingcat.com Tue Aug 26 13:14:49 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Tue Aug 26 12:17:34 2003 Subject: [Ietf-not43] issues and questions on FIRS References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> Message-ID: <3F4B8779.5060103@thinkingcat.com> Catching up on a couple of threads: Eric A. Hall wrote: > Not to belabor this particular point, but rather the issue as a whole... > The format of a domain name in any particular zone file is going to be > determined by the feature set of the server in use. Somebody is eventually > going to figure out that administrators in ~Japan would prefer to have > their zone files use ~Katakana instead of ASCII. There is absolutely no > reason that a server cannot convert the data into ACE when the zone data > is loaded into memory (exceptions exist for products that ignore the DNS > in-band replication service in favor of things like rsynch, but those are > also marketing choices). So again all of this stuff is symptomatic of the > current state of the products and not a deliberate restriction. We should > be planning for where we think we'll be (or where we want to be) in 10 > years, not where the last 20 years forced the current offerings to be. What we are chartered to address is a protocol for a core infrastructure service -- i.e., we have to define something that is usable by the registrars & registries (which will be the backbone providers of data) to provide a clear, uniform service globally. By uniform, I mean that it is possible to write clients that have expectations set appropriately. Taking an example from another area -- there were far more brilliant hypertext systems implemented long before the world wide web, none of which would have succeeded at the scale of the Web. Essentially, http's simplicity & uniformity made it possible for completely unrelated systems to be built and interoperate as a servICE, not just a protocol. And then the Web blossomed, driven (indeed) by edge-user demand and creativity. Without that simplicity & uniformity, we would have had islands of connectivity (pretty much like the more brilliant hypertext systems). My point: we know we have to serve domain names properly, today. We believe we will have to handle IDNs properly, but we don't yet (entirely) know what that will mean (more on that below). While we need flexibility in the protocol, speculation, infinite extensibility and configurability by individual operators will be the death of global deployment and interoperation as a servICE. > In the current model, the client is required to normalize input to the > UTF-8 representations of the canonical UCS name, and most of the > protocol-level traffic is required to use UTF-8 . That's JUST the > protocol-level traffic. > > The format of the database contents are intended to represent the richest > possible view since those can always be down-converted. So for something > like an entry name (the cn attribute) that would be the UTF-8 form. > However, there are other classes of attributes where this is not going to > be an option. For example, the mail and labeledURI attributes are locked > to seven-bit syntaxes so they cannot (currently) use UTF-8. Meanwhile, > stuff like nameserver attributes would be stored in their rich form, but > would not use any of the escape mechanisms given their restrictions from > the DNS service. > > Separately, the client is allowed to convert response domain names into > IDNA for local display purposes if necessary. For example, I could add an > "--output=idna" switch to firs.pl which would force the client to convert > any domain attribute to IDNA for display purposes. That would give users > the option of working with IDNA in all cases. > > For anybody else's client (especially one which is intended to be highly > portable), IDNA might even be the default representation of the domain > name attributes. IMO, a globally-deployed servICE is going to have to have a uniform policy on what format domains are expressed in to the servers. It makes little sense, then, to overload the attribute's characteristics in the protocol. > > So in all cases, the user has the option of working with whatever form > they find best suited to their needs. > > All of this would also be possible if we reversed it around, such that > IDNA was used for the protocol messages, the database storage and the > default view, except that it would be much more difficult to implement > holistically and as deeply (it would require multiple search filters, > server-side conversion, etc). > > Is there some other area of concern that I'm missing? IDNs have a lot of (as-yet-unfinalized) baggage in terms of variants. Therefore, I suspect that "matching" for an IDN is going to have to be looser than for 7-bit ascii. I.e., doing exact-match on UTF-8 bytes is going to be unsatisfying as a search tool (requiring the client to generate all possible variants seems unwieldy, generates unnecessary queries to the servers, and besides, the server may well have a better notion of what "local" variants are allowed, etc). My point: no matter how you slice it, domain names and IDNs have different characteristics and different matching/searching requirements. Handling IDNs as UTF-8 domain names will, I believe, do a disservice to IDNs. If we need to handle both, fine -- but let's separate them out explicitly. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From ehall at ehsco.com Tue Aug 26 13:46:45 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 13:46:53 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4B8779.5060103@thinkingcat.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> Message-ID: <3F4B9D05.3040503@ehsco.com> This discussion is going all over the map, so I'm going to focus on specific issues. Personally I'd rather talk about larger considerations, like whether we should be more externally-focused than internally-focused and putting user-side considerations above operator considerations. How does IRIS intend to satisfy the actor-specific requirements for substring searching within an IDNA-encoded name? How does IRIS justify the imposition of IDNA-encoded naming when the community space of an edge-based application consists of native language speakers who would prefer to work with resources in the representation they paid for, instead of the represntation that is convenient for the operators of a supposed "service"? on 8/26/2003 11:14 AM Leslie Daigle wrote: > What we are chartered to address is a protocol for a core > infrastructure service -- i.e., we have to define something that is > usable by the registrars & registries (which will be the backbone > providers of data) to provide a clear, uniform service globally. By > uniform, I mean that it is possible to write clients that have > expectations set appropriately. FIRS provides exactly that: all identifiers (including netblocks for that matter) are collapsed and normalized to their absolute canonical form, and no other forms are allowed INSIDE THE PROTOCOL. What happens between the protocol and a local presentation subsystem is a matter of preference for each particular client. The real area of concern (and where all the real work is done) is ensuring that the names are properly formed when they are put into the system (either inserted into the database, or generated as a query value). The current specs describe a mandatory double-transformation mechanism that ensures that the data can only exist in a single canonical form. There is nothing better than this. For example, it produces stricter output than "just use ASCII" for IDNs, but also in those cases where the domain names are not IDNs. Not only is the canonical domain name validated (which wouldn't be the case with reusing the ASCII fields), but the ASCII representation is also validated more strictly than it would be in the normal case since the ASCII representation doesn't accurately account for all of the STD13 rules but which are represented in the stricter rules. So by every measure, the rules that require absolute normalization produce the best formed domain names possible, even in those cases where the domain names aren't IDNs. In short, edge-based strict normalization delivers exactly what you are asking for, and delivers it better than any other mechanism. It also happens to be the cheapest to implement. For example, all implementations have different presentation targets (UCS-2, IDNA, whatever), but all implementations also have to support UTF-8 in order to use the underlying technology, so using UTF-8 at the back and allowing client-specific local transformations is the exact same behavior that the applications ALREADY SUPPORT for all of the other attributes that contain non-ASCII text. This says nothing about the cost of having servers perform conversion for comparison purposes, or having to build and support multiple search filters, or having to maintain 2x the entries (one for IDNA and one for "other"), or... Trying to avoid the "problem" only makes the damages worse, and the cost of repairing the resulting damage is multiples more expensive. Meanwhile, using the canonical form is cheaper and more efficient, and produces stricter output for legacy domain names as well. That's what led me to this design, and without hard evidence to the contrary... I'd be lying to myself if I said that supporting two weakly-formed representations made any kind of sense for anybody. > Taking an example from another area -- there were far more brilliant > hypertext systems implemented long before the world wide web, none of > which would have succeeded at the scale of the Web. Essentially, > http's simplicity & uniformity made it possible for completely > unrelated systems to be built and interoperate as a servICE, not just a > protocol. And then the Web blossomed, driven (indeed) by edge-user > demand and creativity. Without that simplicity & uniformity, we would > have had islands of connectivity (pretty much like the more brilliant > hypertext systems). This is a bad analogy for several reasons ("are you referring to HTTP .9, 1.0, or 1.1 as successful?"...). I think we're all trying to deliver on functional and scalable and simple but taking different tacts. > My point: we know we have to serve domain names properly, today. We > believe we will have to handle IDNs properly, but we don't yet > (entirely) know what that will mean (more on that below). While we > need flexibility in the protocol, speculation, infinite extensibility > and configurability by individual operators will be the death of global > deployment and interoperation as a servICE. My rules would produce the least amount of variance. > IMO, a globally-deployed servICE is going to have to have a uniform > policy on what format domains are expressed in to the servers. It > makes little sense, then, to overload the attribute's characteristics > in the protocol. I don't know where you got that. My rules are entirely about producing a single canonical form within the protocol. Different clients have different requirements for local presentation, but that's beyond the scope of the protocol, other than the fact that a heavily normalized canonical form is the easiest to work with. > IDNs have a lot of (as-yet-unfinalized) baggage in terms of variants. > Therefore, I suspect that "matching" for an IDN is going to have to be > looser than for 7-bit ascii. I.e., doing exact-match on UTF-8 bytes is > going to be unsatisfying as a search tool (requiring the client to > generate all possible variants seems unwieldy, generates unnecessary > queries to the servers, and besides, the server may well have a better > notion of what "local" variants are allowed, etc). How do you plan to do this with IDNA, given that substring matching with IDNA is impossible in many cases? No matter what you're answer is, it's going to be easier with UTF-8. > My point: no matter how you slice it, domain names and IDNs have > different characteristics and different matching/searching > requirements. Handling IDNs as UTF-8 domain names will, I believe, do > a disservice to IDNs. If we need to handle both, fine -- but let's > separate them out explicitly. That is twice the work to guarantee strict normalizations, twice the storage, twice the filters, and in the end doesn't provide users with the domain names they actually paid for. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie at thinkingcat.com Tue Aug 26 15:42:33 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Tue Aug 26 14:45:16 2003 Subject: [Ietf-not43] issues and questions on FIRS References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> Message-ID: <3F4BAA19.9050108@thinkingcat.com> Hmm. Eric A. Hall wrote: > > This discussion is going all over the map, so I'm going to focus on > specific issues. Personally I'd rather talk about larger considerations, > like whether we should be more externally-focused than internally-focused > and putting user-side considerations above operator considerations. Then you fundamentally and utterly missed my point. If we don't build the core properly (and that is the part that is intimately entwined with operator considerations you so determinedly brush off) there won't BE any useful user-side services because there will be no interoperable infrastructure service for them to use: there will be pockets of cute data systems. YOU do not know the half of the universe of potential user side applications any more than the next person, or this group collectively. That's one reason why we aren't spec'ing for it. > > How does IRIS intend to satisfy the actor-specific requirements for > substring searching within an IDNA-encoded name? > > How does IRIS justify the imposition of IDNA-encoded naming when the > community space of an edge-based application consists of native language > speakers who would prefer to work with resources in the representation > they paid for, instead of the represntation that is convenient for the > operators of a supposed "service"? I don't really know why you're bringing IRIS into this. And I didn't bring up the issue from the standpoint of what is more convenient for the operator. I brought up the point because I don't believe you, or anyone else, adequately understands what "match" is going to mean for IDNs. That's going to bite users as much as service operators. With respect to my point on variants, which I think you also missed, I was referring to the language-specific variant tables currently under discussion in Taiwan, China, Japan and CENTR, and the possibility (probability?) that registering one IDN is going to necessarily block out a *set* of IDNs. You can normalize user input all day long, but if they've entered a recognized variant of the IDN, is it appropriate to return "no match" or a fuzzy match? So, my point is: conflating domain name and internationalized domain name in the protocol is a mistake, because these things will have inherently different handling requirements. Leslie. > > on 8/26/2003 11:14 AM Leslie Daigle wrote: > > >>What we are chartered to address is a protocol for a core >>infrastructure service -- i.e., we have to define something that is >>usable by the registrars & registries (which will be the backbone >>providers of data) to provide a clear, uniform service globally. By >>uniform, I mean that it is possible to write clients that have >>expectations set appropriately. > > > FIRS provides exactly that: all identifiers (including netblocks for that > matter) are collapsed and normalized to their absolute canonical form, and > no other forms are allowed INSIDE THE PROTOCOL. What happens between the > protocol and a local presentation subsystem is a matter of preference for > each particular client. > > The real area of concern (and where all the real work is done) is ensuring > that the names are properly formed when they are put into the system > (either inserted into the database, or generated as a query value). The > current specs describe a mandatory double-transformation mechanism that > ensures that the data can only exist in a single canonical form. > > There is nothing better than this. For example, it produces stricter > output than "just use ASCII" for IDNs, but also in those cases where the > domain names are not IDNs. Not only is the canonical domain name validated > (which wouldn't be the case with reusing the ASCII fields), but the ASCII > representation is also validated more strictly than it would be in the > normal case since the ASCII representation doesn't accurately account for > all of the STD13 rules but which are represented in the stricter rules. > > So by every measure, the rules that require absolute normalization produce > the best formed domain names possible, even in those cases where the > domain names aren't IDNs. In short, edge-based strict normalization > delivers exactly what you are asking for, and delivers it better than any > other mechanism. > > It also happens to be the cheapest to implement. For example, all > implementations have different presentation targets (UCS-2, IDNA, > whatever), but all implementations also have to support UTF-8 in order to > use the underlying technology, so using UTF-8 at the back and allowing > client-specific local transformations is the exact same behavior that the > applications ALREADY SUPPORT for all of the other attributes that contain > non-ASCII text. > > This says nothing about the cost of having servers perform conversion for > comparison purposes, or having to build and support multiple search > filters, or having to maintain 2x the entries (one for IDNA and one for > "other"), or... > > Trying to avoid the "problem" only makes the damages worse, and the cost > of repairing the resulting damage is multiples more expensive. Meanwhile, > using the canonical form is cheaper and more efficient, and produces > stricter output for legacy domain names as well. That's what led me to > this design, and without hard evidence to the contrary... I'd be lying to > myself if I said that supporting two weakly-formed representations made > any kind of sense for anybody. > > >>Taking an example from another area -- there were far more brilliant >>hypertext systems implemented long before the world wide web, none of >>which would have succeeded at the scale of the Web. Essentially, >>http's simplicity & uniformity made it possible for completely >>unrelated systems to be built and interoperate as a servICE, not just a >>protocol. And then the Web blossomed, driven (indeed) by edge-user >>demand and creativity. Without that simplicity & uniformity, we would >>have had islands of connectivity (pretty much like the more brilliant >>hypertext systems). > > > This is a bad analogy for several reasons ("are you referring to HTTP .9, > 1.0, or 1.1 as successful?"...). > > I think we're all trying to deliver on functional and scalable and simple > but taking different tacts. > > >>My point: we know we have to serve domain names properly, today. We >>believe we will have to handle IDNs properly, but we don't yet >>(entirely) know what that will mean (more on that below). While we >>need flexibility in the protocol, speculation, infinite extensibility >>and configurability by individual operators will be the death of global >>deployment and interoperation as a servICE. > > > My rules would produce the least amount of variance. > > >>IMO, a globally-deployed servICE is going to have to have a uniform >>policy on what format domains are expressed in to the servers. It >>makes little sense, then, to overload the attribute's characteristics >>in the protocol. > > > I don't know where you got that. My rules are entirely about producing a > single canonical form within the protocol. > > Different clients have different requirements for local presentation, but > that's beyond the scope of the protocol, other than the fact that a > heavily normalized canonical form is the easiest to work with. > > >>IDNs have a lot of (as-yet-unfinalized) baggage in terms of variants. >>Therefore, I suspect that "matching" for an IDN is going to have to be >>looser than for 7-bit ascii. I.e., doing exact-match on UTF-8 bytes is >>going to be unsatisfying as a search tool (requiring the client to >>generate all possible variants seems unwieldy, generates unnecessary >>queries to the servers, and besides, the server may well have a better >>notion of what "local" variants are allowed, etc). > > > How do you plan to do this with IDNA, given that substring matching with > IDNA is impossible in many cases? No matter what you're answer is, it's > going to be easier with UTF-8. > > >>My point: no matter how you slice it, domain names and IDNs have >>different characteristics and different matching/searching >>requirements. Handling IDNs as UTF-8 domain names will, I believe, do >>a disservice to IDNs. If we need to handle both, fine -- but let's >>separate them out explicitly. > > > That is twice the work to guarantee strict normalizations, twice the > storage, twice the filters, and in the end doesn't provide users with the > domain names they actually paid for. > -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From anewton at ecotroph.net Tue Aug 26 16:31:00 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 26 15:03:18 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4B9D05.3040503@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> Message-ID: <3F4BB574.2010602@ecotroph.net> Eric A. Hall wrote: > > This discussion is going all over the map, so I'm going to focus on > specific issues. Personally I'd rather talk about larger considerations, > like whether we should be more externally-focused than internally-focused > and putting user-side considerations above operator considerations. What user-side considerations are we putting aside? I don't understand the concern. > How does IRIS intend to satisfy the actor-specific requirements for > substring searching within an IDNA-encoded name? Good question! First, I'll be the first one to admit we do not fully understand all the IDN implications. So if anything is not quite right, I'm sure we can change it for the better. One the search side, IRIS defines two separate searches: 1) find domains by name () and 2) find domains by internationalized name (). I realize that it could be one search with a modifier switch, but for the sake of simplified server code paths I thought this might be better. Anyway... The first search wants a 7-bit ASCII domain name. The second search is wants UTF-8 and allows for optional language tags. Because each registry will be defining its own rules for the registering of IDN's, the language tags allow the client to hint to the server about any special normalization/canonicalization/transformation processes that might need to take place during the search. Finally, there is a search too wide error () which allows the server to tell the client, "I would return something if you'd narrow your search." On the lookup side, entity names can be UTF-8, so a registry can allow lookup by either the 7-bit ASCII name, the 8-bit UTF-8 name, or both. Its their choice. For results, there are two types of results. The first is the obvious domain object () and the second is the domain variant object (). The decision to use the domain variant object is up to the policies of the registry. Some will have them, some won't. Some might have them but not show them. That's cool too. IRIS allows them to express a difference between the two if they so desire. -andy From ehall at ehsco.com Tue Aug 26 15:14:11 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 15:14:18 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BAA19.9050108@thinkingcat.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BAA19.9050108@thinkingcat.com> Message-ID: <3F4BB183.1060008@ehsco.com> on 8/26/2003 1:42 PM Leslie Daigle wrote: > If we don't build the core properly (and that is the part that > is intimately entwined with operator considerations you so determinedly > brush off) I'm not brushing it off, I'm trying to point out a fundamental principle that continues to be ignored: the demands of an operator-to-operator service are different from the demands of an operator-to-user or user-to-user service, and the technologies which may be appropriate for the former are not necessarily suitable to the latter. The demand to use IDNA because it's the same as the data in the ~com. zone file is a pure example of this in action: the community doesn't give a flying crap about what bits are in that specific text file. It's the wrong focus point. > there won't BE any useful user-side services because > there will be no interoperable infrastructure service for them > to use: there will be pockets of cute data systems. That's obviously a given, but it doesn't apply to this case much. We're talking about the canonical format of the data and (related) where the normalization and validation should occur, which is a trivial point of argument given the clarity of the choices: two unrelated hierarchies with independent filters and rules versus a single canonical format that everybody has to support anyway? If we could keep the extra-protocol interests out of this debate we'd have been finished with it by now. >>How does IRIS intend to satisfy the actor-specific requirements for >>substring searching within an IDNA-encoded name? >> >>How does IRIS justify the imposition of IDNA-encoded naming when the >>community space of an edge-based application consists of native language >>speakers who would prefer to work with resources in the representation >>they paid for, instead of the represntation that is convenient for the >>operators of a supposed "service"? > > I don't really know why you're bringing IRIS into this. It seems apropos to the discussion at hand given the direction you are arguing, and it's on my list of IRIS issues anyway. I can change it: How do you propose to satisfy the actor-specific requirements for substring searching with an IDNA-encoded name? This is unsolvable using IDNs, and running parrallel systems is outrageously expensive and makes the whole thing fragile. Using a single canonical form for everything makes it cheap, efficient, and gives people what they paid for anyway. What was your argument again? > With respect to my point on variants, which I think you also > missed, I was referring to the language-specific variant tables > currently under discussion in Taiwan, China, Japan and CENTR, > and the possibility (probability?) that registering one IDN > is going to necessarily block out a *set* of IDNs. You can > normalize user input all day long, but if they've entered > a recognized variant of the IDN, is it appropriate to return > "no match" or a fuzzy match? As you describe it, each variant would get an entry, which would exist as a referral to the canonical entry. The variant query would match the variant registration and get redirected. > So, my point is: conflating domain name and internationalized > domain name in the protocol is a mistake, because these things > will have inherently different handling requirements. I disagree. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Tue Aug 26 15:47:08 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 15:47:16 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BB574.2010602@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> Message-ID: <3F4BB93C.6000902@ehsco.com> on 8/26/2003 2:31 PM Andrew Newton wrote: > Eric A. Hall wrote: >> How does IRIS intend to satisfy the actor-specific requirements for >> substring searching within an IDNA-encoded name? > > Good question! First, I'll be the first one to admit we do not fully > understand all the IDN implications. So if anything is not quite > right, I'm sure we can change it for the better. > > One the search side, IRIS defines two separate searches: 1) find > domains by name () and 2) find domains by > internationalized name (). I realize that it > could be one search with a modifier switch, but for the sake of > simplified server code paths I thought this might be better. Anyway... So we have two searches against two data-stores, where all of the entries and search values require edge normalization. I don't see any algorithms for normalizing or validating data. Are errors supposed to be blocked at the client, caught by the server's query parser, or bounced off the data-store (aka, where should data be normalized and validated)? I don't see any requirements for synchronizing the contents of the entries, or for synchronizing indexes across a shared pool of entries. Is it okay if a server doesn't return the same answer data for two different query forms? Is it okay if a server doesn't support one of the query forms at all? > On the lookup side, entity names can be UTF-8, so a registry can allow > lookup by either the 7-bit ASCII name, the 8-bit UTF-8 name, or both. > Its their choice. How does the client know which form is acceptable as user input? On the other hand, if the client is supposed to normalize regardless of input, then there needs to be an algorithm. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From leslie at thinkingcat.com Tue Aug 26 16:56:38 2003 From: leslie at thinkingcat.com (Leslie Daigle) Date: Tue Aug 26 15:59:21 2003 Subject: [Ietf-not43] issues and questions on FIRS References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BAA19.9050108@thinkingcat.com> <3F4BB183.1060008@ehsco.com> Message-ID: <3F4BBB76.6070706@thinkingcat.com> Eric, Eric A. Hall wrote: > on 8/26/2003 1:42 PM Leslie Daigle wrote: > > >>If we don't build the core properly (and that is the part that >>is intimately entwined with operator considerations you so determinedly >>brush off) > > > I'm not brushing it off, I'm trying to point out a fundamental principle > that continues to be ignored: the demands of an operator-to-operator > service are different from the demands of an operator-to-user or > user-to-user service, and the technologies which may be appropriate for > the former are not necessarily suitable to the latter. The demand to use > IDNA because it's the same as the data in the ~com. zone file is a pure > example of this in action: the community doesn't give a flying crap about > what bits are in that specific text file. It's the wrong focus point. Ah. I didn't realize you were not responding to the points I had raised. I was neither focused on operator-operator nor was I urging the strict use of IDNA formats (let alone for ~com zone convenience). >>>How does IRIS intend to satisfy the actor-specific requirements for >>>substring searching within an IDNA-encoded name? >>> >>>How does IRIS justify the imposition of IDNA-encoded naming when the >>>community space of an edge-based application consists of native language >>>speakers who would prefer to work with resources in the representation >>>they paid for, instead of the represntation that is convenient for the >>>operators of a supposed "service"? >> >>I don't really know why you're bringing IRIS into this. > > > It seems apropos to the discussion at hand given the direction you are > arguing, and it's on my list of IRIS issues anyway. I can change it: How > do you propose to satisfy the actor-specific requirements for substring > searching with an IDNA-encoded name? This is unsolvable using IDNs, and > running parrallel systems is outrageously expensive and makes the whole > thing fragile. Using a single canonical form for everything makes it > cheap, efficient, and gives people what they paid for anyway. What was > your argument again? I believe you'll have read Andy's response by now -- separation in protocol doesn't necessarily mean duplication of representation in the database. What was yours, again? > > >>With respect to my point on variants, which I think you also >>missed, I was referring to the language-specific variant tables >>currently under discussion in Taiwan, China, Japan and CENTR, >>and the possibility (probability?) that registering one IDN >>is going to necessarily block out a *set* of IDNs. You can >>normalize user input all day long, but if they've entered >>a recognized variant of the IDN, is it appropriate to return >>"no match" or a fuzzy match? > > > As you describe it, each variant would get an entry, which would exist as > a referral to the canonical entry. The variant query would match the > variant registration and get redirected. That is one way to implement a fuzzy match for this problem. > >>So, my point is: conflating domain name and internationalized >>domain name in the protocol is a mistake, because these things >>will have inherently different handling requirements. > > > I disagree. > Ain't nothin' I can do about that :-) Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From anewton at ecotroph.net Tue Aug 26 17:32:18 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 26 16:04:34 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BB93C.6000902@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> Message-ID: <3F4BC3D2.9060507@ecotroph.net> Eric A. Hall wrote: > > So we have two searches against two data-stores, where all of the entries > and search values require edge normalization. Why two data stores? We certainly put both in a single data store. > I don't see any algorithms for normalizing or validating data. > > Are errors supposed to be blocked at the client, caught by the server's > query parser, or bounced off the data-store (aka, where should data be > normalized and validated)? Admittedly, the specification for the IDN's is not quite complete... but I stated that before. We do not know all the issues right now. I good client should stop the user from entering malformed data. > I don't see any requirements for synchronizing the contents of the > entries, or for synchronizing indexes across a shared pool of entries. Is > it okay if a server doesn't return the same answer data for two different > query forms? Is it okay if a server doesn't support one of the query forms > at all? Shared pools? Synchronization? Why do we need to specify this? How the operator stores, synchronizes, backs-up, etc is up to them. -andy From ehall at ehsco.com Tue Aug 26 16:11:20 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 16:11:27 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BBB76.6070706@thinkingcat.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BAA19.9050108@thinkingcat.com> <3F4BB183.1060008@ehsco.com> <3F4BBB76.6070706@thinkingcat.com> Message-ID: <3F4BBEE8.2060808@ehsco.com> on 8/26/2003 2:56 PM Leslie Daigle wrote: > Eric A. Hall wrote: > >>on 8/26/2003 1:42 PM Leslie Daigle wrote: >> >>>If we don't build the core properly (and that is the part that >>>is intimately entwined with operator considerations you so determinedly >>>brush off) >> >>I'm not brushing it off, I'm trying to point out a fundamental principle >>that continues to be ignored: the demands of an operator-to-operator >>service are different from the demands of an operator-to-user or >>user-to-user service, and the technologies which may be appropriate for >>the former are not necessarily suitable to the latter. The demand to use >>IDNA because it's the same as the data in the ~com. zone file is a pure >>example of this in action: the community doesn't give a flying crap about >>what bits are in that specific text file. It's the wrong focus point. > > Ah. I didn't realize you were not responding to the points > I had raised. I did respond to your other points, as well as this one ("brush off"). > I was neither focused on operator-operator nor > was I urging the strict use of IDNA formats (let alone > for ~com zone convenience). You were arguing that registry adoption is critical (which we agree on), and the implicit statement that ~IDNA is critical to registry adoption (which we certainly don't agree on). I'm still interested in hearing how parallel systems are supposed to be more efficient towards this particular point, or towards broader adoption outside the peer-club in general. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Tue Aug 26 16:17:22 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 16:17:29 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BC3D2.9060507@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> Message-ID: <3F4BC052.3000406@ehsco.com> on 8/26/2003 3:32 PM Andrew Newton wrote: > Eric A. Hall wrote: > >> So we have two searches against two data-stores, where all of the >> entries and search values require edge normalization. > > Why two data stores? We certainly put both in a single data store. Unless you mandate two indexes against one data-store, it will be two data-stores. >> I don't see any algorithms for normalizing or validating data. >> >> Are errors supposed to be blocked at the client, caught by the >> server's query parser, or bounced off the data-store (aka, where >> should data be normalized and validated)? > > Admittedly, the specification for the IDN's is not quite complete... > but I stated that before. We do not know all the issues right now. Do you consider this to be a requirements miss? The other subordinate issue is probably a bigger one. If servers are allowed to arbitrarily choose not to support the UTF-8 searches, then substring searches are not possible from all clients against all servers (modulo the natural issues of ACLs and permissions). > I good client should stop the user from entering malformed data. What is malformed for one client would be legitimate for another if you don't specify the algorithm. My discussion on escape syntaxes for octet values is a demonstration of this; in some cases, octet values could be considered as legitimate charset-codepoints. >> I don't see any requirements for synchronizing the contents of the >> entries, or for synchronizing indexes across a shared pool of >> entries. Is it okay if a server doesn't return the same answer data >> for two different query forms? Is it okay if a server doesn't support >> one of the query forms at all? > > Shared pools? Synchronization? Why do we need to specify this? How > the operator stores, synchronizes, backs-up, etc is up to them. I'm asking if the same answer data must be returned for both queries. This isn't stated anywhere either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Tue Aug 26 18:31:05 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 26 17:03:19 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BC052.3000406@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> Message-ID: <3F4BD199.3070500@ecotroph.net> Eric A. Hall wrote: > > Unless you mandate two indexes against one data-store, it will be two > data-stores. I do not presume to know how all registries/registrars store their IDN data. Some may store both the originating Unicode and the 7-bit version. Some may store only one and calculate variants. Some may not support IDN's at all. >>I good client should stop the user from entering malformed data. > > > What is malformed for one client would be legitimate for another if you > don't specify the algorithm. Specifying that the input should be punycode/nameprepped/whatever should give client writers enough direction. > My discussion on escape syntaxes for octet values is a demonstration of > this; in some cases, octet values could be considered as legitimate > charset-codepoints. Why are they escaped if the field is UTF-8 capable? > I'm asking if the same answer data must be returned for both queries. This > isn't stated anywhere either. If you ask for something that is a domain variant, then you get a domain variant. If you ask for something that is a domain, you get a domain. I don't understand the issue here? -andy From ehall at ehsco.com Tue Aug 26 17:18:13 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 17:18:21 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BD199.3070500@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> Message-ID: <3F4BCE95.3080205@ehsco.com> on 8/26/2003 4:31 PM Andrew Newton wrote: > Eric A. Hall wrote: > >> Unless you mandate two indexes against one data-store, it will be two >> data-stores. > > I do not presume to know how all registries/registrars store their IDN > data. Some may store both the originating Unicode and the 7-bit > version. Some may store only one and calculate variants. Some may not > support IDN's at all. That's fine, except where some people want to get the contacts for ex?mple.com and others want to get the contacts for xn--exmple-cua.com. I'm not saying you need to dictate operational behavioral, but AFAICT you haven't specified whether or not the queries should even return the same data, which is the point here not the operational stuff. >>> I good client should stop the user from entering malformed data. >> >> What is malformed for one client would be legitimate for another if >> you don't specify the algorithm. > > Specifying that the input should be punycode/nameprepped/whatever > should give client writers enough direction. It's a start, but it won't guarantee consistent results. You need to require two-pass conversions for all input to guarantee that all of the data in the system is in a consistent form. >> My discussion on escape syntaxes for octet values is a demonstration >> of this; in some cases, octet values could be considered as >> legitimate charset-codepoints. > > Why are they escaped if the field is UTF-8 capable? Again, octet values are legal in domain names. Secondarily, the user side of the client has a high probability of using something else (UCS-2, 8859-1, 2022-JP, whatever). Cumulatively, the user can enter an octet value in a local charset which will get mapped to UTF-8 as part of the canonicalization routines, so data that is explicitly an octet value (rather than a character at that codepoint) needs to be protected. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Tue Aug 26 19:28:08 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 26 18:00:22 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BCE95.3080205@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> <3F4BCE95.3080205@ehsco.com> Message-ID: <3F4BDEF8.1000304@ecotroph.net> Eric A. Hall wrote: > > I'm not saying you need to dictate operational behavioral, but AFAICT you > haven't specified whether or not the queries should even return the same > data, which is the point here not the operational stuff. If the client is doing a lookup and sends in the punycode, they will get a consistent answer. > It's a start, but it won't guarantee consistent results. You need to > require two-pass conversions for all input to guarantee that all of the > data in the system is in a consistent form. See above. -andy From ehall at ehsco.com Tue Aug 26 18:09:40 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 18:09:46 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BDEF8.1000304@ecotroph.net> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> <3F4BCE95.3080205@ehsco.com> <3F4BDEF8.1000304@ecotroph.net> Message-ID: <3F4BDAA4.7070003@ehsco.com> on 8/26/2003 5:28 PM Andrew Newton wrote: > Eric A. Hall wrote: > >> I'm not saying you need to dictate operational behavioral, but AFAICT >> you haven't specified whether or not the queries should even return >> the same data, which is the point here not the operational stuff. > > If the client is doing a lookup and sends in the punycode, they will > get a consistent answer. Back to square one then. IDNA doesn't work for substring comparisons. At a minimum, You must specify complete normalization and validation rules, and you must specify where they will be used. If you want to have two namespaces, searches, etc., you need to specify all of this stuff twice. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From hardie at qualcomm.com Tue Aug 26 16:31:01 2003 From: hardie at qualcomm.com (hardie@qualcomm.com) Date: Tue Aug 26 18:31:15 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BDAA4.7070003@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> <3F4BCE95.3080205@ehsco.com> <3F4BDEF8.1000304@ecotroph.net> <3F4BDAA4.7070003@ehsco.com> Message-ID: Eric, Doesn't this text in firs-contact indicate the same problem: 5. Query Processing Rules Queries for contact entries have several special requirements, as discussed in the following sections. Refer to [FIRS-CORE] for general information about FIRS queries. 5.1. Query Pre-Processing Clients MUST ensure that the query input is normalized according to the rules specified in section 3 before the input is used as the assertion value to the resulting LDAP query. The authoritative partition for a contact entry is determined by mapping the domain element of a normalized email address to a sequence of domainComponent labels. Since the domainComponent attribute is restricted to seven-bit characters, the domain element MUST be converted to its IDNA form using the "ToASCII" conversion operation specified in [ RFC3490 ], with the "UseSTD3ASCIIRules" flag disabled (FIRS applications MAY reuse the output from the conversion performed in step 3.c if the entire conversion process is known to have completed successfully). The resulting sequence of ASCII labels are used to form the domainComponent sequence which represents the authoritative partition for the email address. As a simple example, "admins@example.com" would be mapped to the "dc=example,dc=com" authoritative partition, with this partition being used to seed the query process. In other words, if the query pre-processing requires normalization to the IDNA form using ToASCII, aren't we limited to using matching forms that work on IDNA for contacts? Sorry if I'm missing something obvious here. regards, Ted Hardie At 5:09 PM -0500 08/26/2003, Eric A. Hall wrote: >on 8/26/2003 5:28 PM Andrew Newton wrote: > >> Eric A. Hall wrote: >> >>> I'm not saying you need to dictate operational behavioral, but AFAICT >>> you haven't specified whether or not the queries should even return >>> the same data, which is the point here not the operational stuff. >> >> If the client is doing a lookup and sends in the punycode, they will >> get a consistent answer. > >Back to square one then. IDNA doesn't work for substring comparisons. > >At a minimum, You must specify complete normalization and validation >rules, and you must specify where they will be used. > >If you want to have two namespaces, searches, etc., you need to specify >all of this stuff twice. > >-- >Eric A. Hall http://www.ehsco.com/ >Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > >_______________________________________________ >Ietf-not43 mailing list >Ietf-not43@lists.verisignlabs.com >https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 From anewton at ecotroph.net Tue Aug 26 20:02:41 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Tue Aug 26 18:34:55 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: <3F4BDAA4.7070003@ehsco.com> References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> <3F4BCE95.3080205@ehsco.com> <3F4BDEF8.1000304@ecotroph.net> <3F4BDAA4.7070003@ehsco.com> Message-ID: <3F4BE711.90808@ecotroph.net> Eric A. Hall wrote: > > Back to square one then. IDNA doesn't work for substring comparisons. > > At a minimum, You must specify complete normalization and validation > rules, and you must specify where they will be used. Yes. So it would seem that the search should specify that the input is nameprep, not just utf-8. I think that is your point. In addition, it should allow the option for exact match (something I noticed). I'll make this change in the next rev. Thanks. -andy From ehall at ehsco.com Tue Aug 26 19:17:47 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 19:17:53 2003 Subject: [Ietf-not43] issues and questions on FIRS In-Reply-To: References: <3F3E5918.3000306@ecotroph.net> <3F3FD067.5070902@ehsco.com> <3F40FB5D.7060806@ecotroph.net> <3F41200A.7030609@ehsco.com> <3F4B8779.5060103@thinkingcat.com> <3F4B9D05.3040503@ehsco.com> <3F4BB574.2010602@ecotroph.net> <3F4BB93C.6000902@ehsco.com> <3F4BC3D2.9060507@ecotroph.net> <3F4BC052.3000406@ehsco.com> <3F4BD199.3070500@ecotroph.net> <3F4BCE95.3080205@ehsco.com> <3F4BDEF8.1000304@ecotroph.net> <3F4BDAA4.7070003@ehsco.com> Message-ID: <3F4BEA9B.8020507@ehsco.com> on 8/26/2003 5:31 PM hardie@qualcomm.com wrote: > Eric, > Doesn't this text in firs-contact indicate the same problem: > 5.1. Query Pre-Processing No. The pre-processing is where the query value gets mapped to a partition, so that the SRV RRs for the target partition can be located. The UTF-8 form of the query value is still used for the LDAP queries. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Tue Aug 26 22:41:01 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Tue Aug 26 22:41:07 2003 Subject: [Ietf-not43] -03 drafts in the pipe Message-ID: <3F4C1A3D.2080009@ehsco.com> Refreshes of the core drafts were submitted today which addressed all of the resolvable issues, and should be published soon. There were a couple of hefty changes. Most noticably, the cleanup on the use of referrals reopened some holes. The biggest change resulting from this is that the contact and ASN classes now have their own matching filters, instead of reusing the generic equalityMatch filters. All of the entries are still searchable with equalityMatch of course, but for the purpose of ensuring that all of the stubs are found, the specialized filters are preferred (there is some flakiness with matching against dn components that is best avoided). You know about the inetResourcesControl already. I added and extended it so that it's now objectClass(matchingFilter(attribute))), which gives tighter control over the syntax (can restrict clients to only allowing contact substring matches for cn" attributes, for example). Added the inetExtAcl- family of attribute options and the inetExtAcl client control for the funky privacy filters. This needs work. The DNS syntax rules were replaced with a more-better set (same basic results, just better text). Added the inetIpv*ParentNetworks, *SiblingNetworks and *ChildNetworks attributes for explicit cross-references. Provided example matching behaviors for domain names and IPv4 networks. Clarified the partitioning navigation rules in the IP specs. Bunches of minor edits. I believe that all of the outstanding issues are sufficiently addressed. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From ehall at ehsco.com Wed Aug 27 00:49:53 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 27 00:50:00 2003 Subject: [Ietf-not43] organization searches Message-ID: <3F4C3871.7010907@ehsco.com> Reading through draft-ietf-crisp-internet-resource-number-req-00.txt, there is a call for mandatory support for organization searches. This was in the early versions of the domain requirements too, but was watered down to a MAY since org searches weren't part of the existing service. This is somewhat difficult to implement in a distributed system given that there is no centralized registry of organizations. On this same note, whatever data gets returned is going to be specific to a partition, which may either be the organization itself, or which may be a provider's data about a particular organization. These are the same kinds of problems we had with contacts, and will require the same kind of solution. The first problem that needs to be solved is what the global identifier for an organization should look like. The data needs to provide an organization identifier, and also needs to provide partition hinting data that will get the query to the right provider. With contacts, this was relatively easy (modulo the misinterpretations), just use the email addressing syntax. With organizations, however, there is no obvious syntax. Domain names will take you through the domain delegation by default, which isn't what you want. Email addresses are already overloaded. IP addressing obviously doesn't work to identify the org. So we're pretty much left with coming up a globally satisfactory organizational identification syntax. Something like orghandle%partition or orghandle!partition would be easy except for the slight syntactical overloading. If anybody has a preference on these, please speak up. For clarity of thought, some examples here: ExampleWidgets%arin.net ExampleWidgets!example.com ExampleWidgets$netsol.com (bad for keyboards without "$") etc. Remember that since we don't have a global index, the identifier has to provide enough hints to get to the right partition. That or the requirement has to be reduced to being non-global. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From shane at ripe.net Wed Aug 27 13:29:13 2003 From: shane at ripe.net (Shane Kerr) Date: Wed Aug 27 06:29:17 2003 Subject: [Ietf-not43] organization searches In-Reply-To: <3F4C3871.7010907@ehsco.com> References: <3F4C3871.7010907@ehsco.com> Message-ID: <3F4C87F9.6080201@ripe.net> Eric A. Hall wrote: > Reading through draft-ietf-crisp-internet-resource-number-req-00.txt, > there is a call for mandatory support for organization searches. This was > in the early versions of the domain requirements too, but was watered down > to a MAY since org searches weren't part of the existing service. > > This is somewhat difficult to implement in a distributed system given that > there is no centralized registry of organizations. On this same note, > whatever data gets returned is going to be specific to a partition, which > may either be the organization itself, or which may be a provider's data > about a particular organization. These are the same kinds of problems we > had with contacts, and will require the same kind of solution. How is this any more difficult than searching for contact data? It's the exact same problem, IM(ns)HO. I don't like using e-mail syntax for contact data, but if you are using it for that purpose, why is it any problem to do a similar hack for organisations? -- Shane Kerr RIPE NCC From ehall at ehsco.com Wed Aug 27 08:30:23 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 27 08:30:31 2003 Subject: [Ietf-not43] organization searches In-Reply-To: <3F4C87F9.6080201@ripe.net> References: <3F4C3871.7010907@ehsco.com> <3F4C87F9.6080201@ripe.net> Message-ID: <3F4CA45F.8020105@ehsco.com> on 8/27/2003 5:29 AM Shane Kerr wrote: > How is this any more difficult than searching for contact data? It's > the exact same problem, IM(ns)HO. I don't like using e-mail syntax for > contact data, but if you are using it for that purpose, why is it any > problem to do a similar hack for organisations? That's what I was asking: choose a syntax. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Internet-Drafts at ietf.org Wed Aug 27 11:25:07 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:25:18 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-asn-03.txt Message-ID: <200308271425.KAA01230@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-asn-03.txt Pages : 12 Date : 2003-8-27 This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-asn-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-asn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-asn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:11 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:25:35 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-contact-03.txt Message-ID: <200308271425.KAA01249@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Contact Information in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-contact-03.txt Pages : 12 Date : 2003-8-27 This document defines LDAP schema and searching rules for contact persons, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-contact-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-contact-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-contact-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:16 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:25:49 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dns-03.txt Message-ID: <200308271425.KAA01276@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating DNS Domains in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dns-03.txt Pages : 18 Date : 2003-8-27 This document defines LDAP schema and searching rules for DNS domain names, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dns-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-dns-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-dns-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:21 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:26:02 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv4-03.txt Message-ID: <200308271425.KAA01293@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv4-03.txt Pages : 16 Date : 2003-8-27 This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv4-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv4-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-ipv4-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:37 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:26:18 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-arch-03.txt Message-ID: <200308271425.KAA01358@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service:Architecture and Implementation Guide Author(s) : E. Hall Filename : draft-ietf-crisp-firs-arch-03.txt Pages : 34 Date : 2003-8-27 This document describes the architectural framework for the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-arch-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-arch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-arch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:28 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:26:32 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv6-03.txt Message-ID: <200308271425.KAA01310@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv6-03.txt Pages : 15 Date : 2003-8-27 This document defines LDAP schema and searching rules for IPv6 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv6-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv6-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-ipv6-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:33 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 10:26:45 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-core-03.txt Message-ID: <200308271425.KAA01335@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service: Core Elements Author(s) : E. Hall Filename : draft-ietf-crisp-firs-core-03.txt Pages : 48 Date : 2003-8-27 This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-core-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-core-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:21 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 11:00:11 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv4-03.txt Message-ID: <200308271425.KAA01293@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv4-03.txt Pages : 16 Date : 2003-8-27 This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv4-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv4-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-ipv4-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:11 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 11:00:45 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-contact-03.txt Message-ID: <200308271425.KAA01249@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Contact Information in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-contact-03.txt Pages : 12 Date : 2003-8-27 This document defines LDAP schema and searching rules for contact persons, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-contact-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-contact-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-contact-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:07 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 11:01:02 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-asn-03.txt Message-ID: <200308271425.KAA01230@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-asn-03.txt Pages : 12 Date : 2003-8-27 This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-asn-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-asn-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-asn-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed Aug 27 11:25:33 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed Aug 27 11:01:19 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-core-03.txt Message-ID: <200308271425.KAA01335@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service: Core Elements Author(s) : E. Hall Filename : draft-ietf-crisp-firs-core-03.txt Pages : 48 Date : 2003-8-27 This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-core-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-firs-core-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From ehall at ehsco.com Wed Aug 27 11:04:33 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 27 11:04:40 2003 Subject: [Ietf-not43] [Fwd: I-D ACTION:draft-hall-firs-svc-01.txt] Message-ID: <3F4CC881.6070001@ehsco.com> This is an update to the service-locator spec. This is external to the CRISP effort but is a necessary component of a global directory, given that the principle elements are relationship(device|user|service). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -------------- next part -------------- An embedded message was scrubbed... From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-hall-firs-svc-01.txt Date: Wed, 27 Aug 2003 10:25:46 -0400 Size: 3632 Url: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030827/cd57a6b8/draft-hall-firs-svc-01.eml From anewton at ecotroph.net Wed Aug 27 18:24:26 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed Aug 27 17:24:38 2003 Subject: [Ietf-not43] IDN's and IRIS Message-ID: <3F4D218A.9020904@ecotroph.net> The discussion yesterday on IDN's proved quite useful and from it there probably need to be a few tweaks to the IDN support in IRIS. But first, some basic assumptions (I am not an IDN expert, so forgive when I mess this up): 1) The IDN process, in simple terms, goes from it's Unicode orginal form through a process called nameprep and then a second process called punycode. The punycode process outputs 7-bit domains that are compatible with legacy software. So... Unicode ---------> Nameprep ----------> Punycode (lossy) (lossless) At the output of nameprep is where certain judgements are made with regard to code point equivalences, thus creating these things called domain variants. Domain variants are perfectly legal according to the IDN specs. The big difference is that a domain variant may end up in the registration system, but will not end up in a zone file (intentionally). 2) The data stored by the registration system for IDN's maybe the original unicode, the nameprep output, and the legacy 7-bit domain (produced by punycode in this case). Or any combination of the three. 3) Some registrations will be IDN-aware while some will function in a legacy capacity. The major difference being that IDN-aware registration systems undertake special process of xn--* domain names, while legacy systems will not. This does not mean an IDN cannot be registered in a legacy registration system. All that being said, IRIS accounts for all of these assumptions but could use some tightening up on the specification and a few tweaks. 1) The (and )object should contain an optional (or something) element for domains showing the nameprepped name. 2) The search should incorporate an qualifier for finding exactly the matching and objects associated with a nameprepped name. 3) The cardinality on the references to the objects in the object should not be restricted one since it is possible to have multiple variations that are registered. 4) Add a new entity class for IDN's specifically, and specify that the intended format of entity names in the domain-name entity class is 7-bit legacy while the intended format of entity names in the idn and domain-variant entity classes is nameprepped utf-8. I know there is probably something else I forgot... Any comments? -andy From ehall at ehsco.com Wed Aug 27 22:39:08 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed Aug 27 22:39:15 2003 Subject: [Ietf-not43] IRIS updates/adds Message-ID: <3F4D6B4C.3050201@ehsco.com> I don't see any discussion on in-band modifications to the data-store. There doesn't appear to be any definition of the necessary verbs nor any discussion on update responses (record exists, attribute missing, etc) or anything else. I know the requirements state that updates are out-of-scope, but a read-only directory service won't be useful in the long run (dynamic registration is going to be critical to many layered services). I guess I'm guessing what your plan is here. Also, in light of the dual-mode i18n approach, updates would need to modify the separate ASCII and UTF-8 indexes|stores simultaneously as part of a single update/add operation. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From wessorh at ar.com Wed Aug 27 22:03:40 2003 From: wessorh at ar.com (Rick Wesson) Date: Thu Aug 28 00:03:49 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <3F4D6B4C.3050201@ehsco.com> Message-ID: not a problem, its an implementation issue. just as whois is served from many different types data stores (mkdb, ldap, sql, gigabase) they all implement the same publishing protocol. CRISP isn't about updating its about publishing, updating is for the implementations not IRIS. -rick On Wed, 27 Aug 2003, Eric A. Hall wrote: > > I don't see any discussion on in-band modifications to the data-store. > There doesn't appear to be any definition of the necessary verbs nor any > discussion on update responses (record exists, attribute missing, etc) or > anything else. > > I know the requirements state that updates are out-of-scope, but a > read-only directory service won't be useful in the long run (dynamic > registration is going to be critical to many layered services). I guess > I'm guessing what your plan is here. > > Also, in light of the dual-mode i18n approach, updates would need to > modify the separate ASCII and UTF-8 indexes|stores simultaneously as part > of a single update/add operation. > > -- > Eric A. Hall http://www.ehsco.com/ > Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ > > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From ehall at ehsco.com Thu Aug 28 00:37:53 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 28 00:37:59 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: References: Message-ID: <3F4D8721.1020405@ehsco.com> on 8/27/2003 11:03 PM Rick Wesson wrote: > not a problem, its an implementation issue. just as whois is served > from many different types data stores (mkdb, ldap, sql, gigabase) they > all implement the same publishing protocol. > > CRISP isn't about updating its about publishing, updating is for the > implementations not IRIS. I'm specifically referring to in-line updates. EG, user is the verified/authenticated owner of the resource in question and needs to change the phone number. This will require protocol support at the same level as lookup and search. It's not an implementation issue anyway -- that would mean having different verbs and syntaxes for every server. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From kent at songbird.com Thu Aug 28 01:07:35 2003 From: kent at songbird.com (kent@songbird.com) Date: Thu Aug 28 03:07:50 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <3F4D8721.1020405@ehsco.com> References: <3F4D8721.1020405@ehsco.com> Message-ID: <20030828070735.GG2133@owl.songbird.com> On Wed, Aug 27, 2003 at 11:37:53PM -0500, Eric A. Hall wrote: > > on 8/27/2003 11:03 PM Rick Wesson wrote: > > > not a problem, its an implementation issue. just as whois is served > > from many different types data stores (mkdb, ldap, sql, gigabase) they > > all implement the same publishing protocol. > > > > CRISP isn't about updating its about publishing, updating is for the > > implementations not IRIS. > > I'm specifically referring to in-line updates. As I understand Rick's point, support of updates, in-line or not, is not a requirement, and, I suspect, lack of that ability is actually a desirable feature. Whois, and presumably it's replacement, is purely a publishing mechanism. If you add update mechanisms you inevitably complicate the protocol far past what is either required or desired. -- Kent Crispin "Be good, and you will be crispin@icann.org,kent@songbird.com lonesome." p: +1 310 823 9358 f: +1 310 823 8649 -- Mark Twain From shane at ripe.net Thu Aug 28 11:27:56 2003 From: shane at ripe.net (Shane Kerr) Date: Thu Aug 28 04:28:01 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <20030828070735.GG2133@owl.songbird.com> References: <3F4D8721.1020405@ehsco.com> <20030828070735.GG2133@owl.songbird.com> Message-ID: <3F4DBD0C.90503@ripe.net> kent@songbird.com wrote: > On Wed, Aug 27, 2003 at 11:37:53PM -0500, Eric A. Hall wrote: > >>on 8/27/2003 11:03 PM Rick Wesson wrote: >> >> >>>not a problem, its an implementation issue. just as whois is served >>>from many different types data stores (mkdb, ldap, sql, gigabase) they >>>all implement the same publishing protocol. >>> >>>CRISP isn't about updating its about publishing, updating is for the >>>implementations not IRIS. >> >>I'm specifically referring to in-line updates. > > > As I understand Rick's point, support of updates, in-line or not, is not > a requirement, and, I suspect, lack of that ability is actually a > desirable feature. Whois, and presumably it's replacement, is purely a > publishing mechanism. If you add update mechanisms you inevitably > complicate the protocol far past what is either required or desired. I'll go further and say this is an anti-requirement for us. -- Shane Kerr RIPE NCC From ehall at ehsco.com Thu Aug 28 08:06:03 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 28 08:06:14 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <20030828070735.GG2133@owl.songbird.com> References: <3F4D8721.1020405@ehsco.com> <20030828070735.GG2133@owl.songbird.com> Message-ID: <3F4DF02B.6030509@ehsco.com> on 8/28/2003 2:07 AM kent@songbird.com wrote: > On Wed, Aug 27, 2003 at 11:37:53PM -0500, Eric A. Hall wrote: >> I'm specifically referring to in-line updates. > As I understand Rick's point, support of updates, in-line or not, is > not a requirement, and, I suspect, lack of that ability is actually a > desirable feature. Whois, and presumably it's replacement, is purely a > publishing mechanism. There's a scale here. Allowing the registry data for ~com to be updated is probably not desirable. However, registrars should be able to do whatever they want, including mail-from, https, or updates via CRISP if they want to offer that option. The current requirements don't make that distinction. Also, the current requirements are for domains and not the service as a whole. Other uses in a directory service -- which is what we're going after -- will absolutely have other requirements. EG, SIP phones need to be able to update my profile in the directory once I authenticate is an example of mandatory read-write support. So like I said the first time, I'm curious what the plan is. At the very least, read-write support should be an option for the registrars and operators of domains, and its going to be mandatory anyway eventually. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Thu Aug 28 11:22:44 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 28 09:54:50 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <3F4DF02B.6030509@ehsco.com> References: <3F4D8721.1020405@ehsco.com> <20030828070735.GG2133@owl.songbird.com> <3F4DF02B.6030509@ehsco.com> Message-ID: <3F4E1034.7080805@ecotroph.net> Eric A. Hall wrote: > on 8/28/2003 2:07 AM kent@songbird.com wrote: > > >>On Wed, Aug 27, 2003 at 11:37:53PM -0500, Eric A. Hall wrote: > > >>>I'm specifically referring to in-line updates. > > >>As I understand Rick's point, support of updates, in-line or not, is >>not a requirement, and, I suspect, lack of that ability is actually a >>desirable feature. Whois, and presumably it's replacement, is purely a >>publishing mechanism. > > > There's a scale here. > > Allowing the registry data for ~com to be updated is probably not > desirable. However, registrars should be able to do whatever they want, > including mail-from, https, or updates via CRISP if they want to offer > that option. The current requirements don't make that distinction. > > Also, the current requirements are for domains and not the service as a > whole. Other uses in a directory service -- which is what we're going > after -- will absolutely have other requirements. EG, SIP phones need to > be able to update my profile in the directory once I authenticate is an > example of mandatory read-write support. > > So like I said the first time, I'm curious what the plan is. At the very > least, read-write support should be an option for the registrars and > operators of domains, and its going to be mandatory anyway eventually. > From the charter: > Provisioning of data into registry or registrar > systems is likewise out of scope -- CRISP provides a uniform > access to and view of data that may be held in disparate backend > servers. -andy From ehall at ehsco.com Thu Aug 28 10:04:22 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu Aug 28 10:04:29 2003 Subject: [Ietf-not43] IRIS updates/adds In-Reply-To: <3F4E1034.7080805@ecotroph.net> References: <3F4D8721.1020405@ehsco.com> <20030828070735.GG2133@owl.songbird.com> <3F4DF02B.6030509@ehsco.com> <3F4E1034.7080805@ecotroph.net> Message-ID: <3F4E0BE6.2030701@ehsco.com> on 8/28/2003 9:22 AM Andrew Newton wrote: > From the charter: > >>Provisioning of data into registry or registrar >>systems is likewise out of scope -- CRISP provides a uniform >>access to and view of data that may be held in disparate backend >>servers. Perhaps the charter and the IRIS specs need to s/directory/query Directories are read-mostly, not read-only -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Thu Aug 28 22:06:38 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu Aug 28 21:06:49 2003 Subject: [Ietf-not43] Suggested improvements for IRIS Message-ID: <3F4EA71E.1020706@ecotroph.net> We have been upgrading our implementation of IRIS -03 (from -00) to help find the rough spots in the protocol and have found a few things that need tightening up. I'll leave out the IDN relevant stuff as that was in yesterday's email. Please comment if you have an opinion. dreg: 1) Add elements in object to hold a list of base domains. This better aids the user in understanding the responsibilities of a registry/registrar. core: 1) Create an attribute group to hold privacy attributes to satisfy the new privacy tagging requirement. 2) Add an to the object. 3) Place the element in the search set before the element. This allows servers doing event driven parsing (such as SAX) the ability to evaluate the bag and take appropriate action before executing the query. 4) Place the element in the response as a peer to so that they may be normalized across all result sets, not just results in a particular result set. 5) Change the control/reaction interactions to be passed in/out with the queries and results. The separate protocol interaction causes the server to keep state above the transport layer. This also simplifies the code paths on the server. beep: 1) Relax the TLS server authentication rules to be more like those found in RFC 2595. This will allow the reuse of certificates purchased for other services. -andy From ehall at ehsco.com Fri Aug 29 01:11:46 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 29 01:11:53 2003 Subject: [Ietf-not43] IRIS contact lookups Message-ID: <3F4EE092.8010109@ehsco.com> It seems that contact lookups are embedded in the domain lookups, and thus aren't independently searachable. I say this because there doesn't appear to be any sort of indicator about the partition that is authoritative for the contact identifier(s), meaning that the query data must contain the identifier as well as the location information. Ergo, a contact identifier must always be passed around as part of a URI, and has no meaning outside of the URI context. If all of that is true, then do you consider the URI to be part of the "contact reference" from the requirements?: | 3.2.1.1 Protocol Requirement | 1. Contact lookup given a unique reference to a contact of a | resource. This is why I use fully self-descriptive identifiers for all the lookup keys. For example, fqdn.domain.dom self-identifies as a domain name, and provides embedded information about the governing partition hierarchy. While that is also feasible with IRIS, you aren't doing the same with contact identifiers, whereas FIRS uses handle@fqdn.domain.dom to self-identify as a contact key value, and to provide embedded hinting information about the governing partition hierarchy. Also, I notice that you aren't providing an i18n for the email address, which is likely to be necessary when mail clients start transforming IDNA addresses more frequently. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 29 03:36:28 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 29 02:36:41 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4EE092.8010109@ehsco.com> References: <3F4EE092.8010109@ehsco.com> Message-ID: <3F4EF46C.2050409@ecotroph.net> Eric A. Hall wrote: > It seems that contact lookups are embedded in the domain lookups, and thus > aren't independently searachable. I say this because there doesn't appear > to be any sort of indicator about the partition that is authoritative for > the contact identifier(s), meaning that the query data must contain the > identifier as well as the location information. Ergo, a contact identifier > must always be passed around as part of a URI, and has no meaning outside > of the URI context. If all of that is true, then do you consider the URI > to be part of the "contact reference" from the requirements?: > > | 3.2.1.1 Protocol Requirement > > | 1. Contact lookup given a unique reference to a contact of a > | resource. > > This is why I use fully self-descriptive identifiers for all the lookup > keys. For example, fqdn.domain.dom self-identifies as a domain name, and > provides embedded information about the governing partition hierarchy. > While that is also feasible with IRIS, you aren't doing the same with > contact identifiers, whereas FIRS uses handle@fqdn.domain.dom to > self-identify as a contact key value, and to provide embedded hinting > information about the governing partition hierarchy. In the domain registry, they are directly searchable by the search. In addition, contacts have their own entity class of 'contact-handle' for doing direct lookups. The entity names in this entity class could be of the form handle@fqdn.domain.dom if the registry wants to do that. However, I think most will stick to the handles they have instead of creating new ones. A contact reference is like any other entity reference. It consists of all but one of the components in an IRIS URI (the scheme). It is purposefully decomposed into XML attributes to allow servers doing hosting of multiple authorities to manipulate the authority component on the fly (useful for implementations using things like DOM trees). > Also, I notice that you aren't providing an i18n for the email address, > which is likely to be necessary when mail clients start transforming IDNA > addresses more frequently. Well, the schema does allow for 2 email addresses per contact. Which part of the email address are you concerned with being internationalized, the display name or the smtp address? -andy From ehall at ehsco.com Fri Aug 29 03:38:36 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 29 03:38:44 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4EF46C.2050409@ecotroph.net> References: <3F4EE092.8010109@ehsco.com> <3F4EF46C.2050409@ecotroph.net> Message-ID: <3F4F02FC.20603@ehsco.com> on 8/29/2003 1:36 AM Andrew Newton wrote: > In the domain registry, they are directly searchable by the > search. You need the partition context though, and that's external, not part of "the identifier" (the identifier "eh26" is meaningless by itself, and doesn't tell you if this is for netsol or for arin). So this is basically a search-by-value, constrained to a partition. > In addition, contacts have their own entity > class of 'contact-handle' for doing direct lookups. Again, you need fore knowledge or external hinting data for the auth partition right? Unless you always have the URI, this is actually another search-by-value constrained to a partition, rather than a global lookup. > The entity names in > this entity class could be of the form handle@fqdn.domain.dom if the > registry wants to do that. However, I think most will stick to the > handles they have instead of creating new ones. The @partition syntax doesn't affect the handle@ management, it just makes the handle global, self-contained and self-identifying. Plus it's useful for layered edge services like ~"give me the PGP key for ehall@ehsco.com" or ~"dial the sip phone for anewton@ecotroph.net", in that the most commonly-used identifier for persons is reusable. >>Also, I notice that you aren't providing an i18n for the email address, >>which is likely to be necessary when mail clients start transforming IDNA >>addresses more frequently. > > Well, the schema does allow for 2 email addresses per contact. Which > part of the email address are you concerned with being > internationalized, the display name or the smtp address? I was referring to the transformed @domain. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 29 08:04:01 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 29 07:04:15 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4F02FC.20603@ehsco.com> References: <3F4EE092.8010109@ehsco.com> <3F4EF46C.2050409@ecotroph.net> <3F4F02FC.20603@ehsco.com> Message-ID: <3F4F3321.5060308@ecotroph.net> Eric A. Hall wrote: > >>In addition, contacts have their own entity >>class of 'contact-handle' for doing direct lookups. > > > Again, you need fore knowledge or external hinting data for the auth > partition right? Unless you always have the URI, this is actually another > search-by-value constrained to a partition, rather than a global lookup. Like a URI, an entity reference contains the necessary data to make the lookup global. > The @partition syntax doesn't affect the handle@ management, it just makes > the handle global, self-contained and self-identifying. Plus it's useful > for layered edge services like ~"give me the PGP key for ehall@ehsco.com" > or ~"dial the sip phone for anewton@ecotroph.net", in that the most > commonly-used identifier for persons is reusable. The contact handle is not intended to be overloaded as a universal key for all applications as a uniform naming mechanism. There are other standards for that, such as URN's. >>Well, the schema does allow for 2 email addresses per contact. Which >>part of the email address are you concerned with being >>internationalized, the display name or the smtp address? > > > I was referring to the transformed @domain. Email addresses are defined in RFC 2822. -andy From sanz at denic.de Fri Aug 29 14:50:07 2003 From: sanz at denic.de (Marcos Sanz/Denic) Date: Fri Aug 29 07:50:16 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4EF46C.2050409@ecotroph.net> Message-ID: Andy, On 29.08.2003 08:36 Andrew Newton wrote: > > Well, the schema does allow for 2 email addresses per contact. We currently support N email addresses per contact. The same goes for fax and phone. I suggest leaving maxOccurs for these three elements in the contact result unbounded. Regards, Marcos From anewton at ecotroph.net Fri Aug 29 09:28:28 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 29 08:28:36 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: References: Message-ID: <3F4F46EC.9020708@ecotroph.net> Marcos Sanz/Denic wrote: > We currently support N email addresses per contact. The same goes for fax > and phone. I suggest leaving maxOccurs for these three elements in the > contact result unbounded. That sounds good. Should we add fax and sip as separate elements, also unbounded? -andy From sanz at denic.de Fri Aug 29 16:08:23 2003 From: sanz at denic.de (Marcos Sanz/Denic) Date: Fri Aug 29 09:08:28 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4F46EC.9020708@ecotroph.net> Message-ID: On 29.08.2003 14:28 Andrew Newton wrote: > > That sounds good. Should we add fax and sip as separate elements, also > unbounded? That can't be harmful. Regards, Marcos From ehall at ehsco.com Fri Aug 29 10:42:27 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri Aug 29 10:42:34 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4F3321.5060308@ecotroph.net> References: <3F4EE092.8010109@ehsco.com> <3F4EF46C.2050409@ecotroph.net> <3F4F02FC.20603@ehsco.com> <3F4F3321.5060308@ecotroph.net> Message-ID: <3F4F6653.2050001@ehsco.com> on 8/29/2003 6:04 AM Andrew Newton wrote: > Eric A. Hall wrote: >> Again, you need fore knowledge or external hinting data for the auth >> partition right? Unless you always have the URI, this is actually >> another search-by-value constrained to a partition, rather than a >> global lookup. > > Like a URI, an entity reference contains the necessary data to make the > lookup global. Right, the identifiers are meaningless without the support attributes, so all of the attributes have to be specifically enumerated and then bundled with the identifier as support data. > The contact handle is not intended to be overloaded as a universal key > for all applications as a uniform naming mechanism. There are other > standards for that, such as URN's. How is a URN to a contact handle not an overloaded universal key? >> I was referring to the transformed @domain. > > Email addresses are defined in RFC 2822. I take it that this means you don't plan on supporting IDNA transformed mail domain syntaxes period. Again, you need to specify the normalization routines if you expect the client to always force a drop-down. Substring matching for contact email addresses will break as well, again. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri Aug 29 13:16:55 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri Aug 29 11:48:55 2003 Subject: [Ietf-not43] IRIS contact lookups In-Reply-To: <3F4F6653.2050001@ehsco.com> References: <3F4EE092.8010109@ehsco.com> <3F4EF46C.2050409@ecotroph.net> <3F4F02FC.20603@ehsco.com> <3F4F3321.5060308@ecotroph.net> <3F4F6653.2050001@ehsco.com> Message-ID: <3F4F7C77.7000000@ecotroph.net> Eric A. Hall wrote: > >>The contact handle is not intended to be overloaded as a universal key >>for all applications as a uniform naming mechanism. There are other >>standards for that, such as URN's. > > > How is a URN to a contact handle not an overloaded universal key? A URN is not overloaded for this purpose because that is the intent of a URN. The contact handles in IRIS are not specified as URN's or any other type of universal key because that is also not their intent. However, if a registry wants to specify contact handles as URN's (or any other type of universal key), then so be it. IRIS doesn't stop them. > I take it that this means you don't plan on supporting IDNA transformed > mail domain syntaxes period. > > Again, you need to specify the normalization routines if you expect the > client to always force a drop-down. Substring matching for contact email > addresses will break as well, again. If that is the consensus of the working group, but I personally question the utility of substring matches on email addresses. IRIS DREG currently provides two types of email matching: 1) you know the exact email address, or 2) you know the domain name of the email address. Other than that, I do not see how it is practical. Why would you want to search for domains or contacts by every person with an email address that starts with 'an' such as an*@ecotroph.net? Or anewton@*troph.net? Or anewton@*.*? This starts to become a data-miners dream. Just my opinion. -andy From ehall at ehsco.com Sat Aug 30 09:49:34 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sat Aug 30 09:49:47 2003 Subject: [Ietf-not43] IRIS general attribute searching and fetching Message-ID: <3F50AB6E.30203@ehsco.com> IRIS seems to only provide pre-defined 'named' searches, and does not appear to provide a generalized "search this attribute for this value" syntax. Is this correct? EG, ~finding all entries with a particular Post Office Box as the registrant address is not possible unless and until a 'named' search for that is defined, and the nodes are extended to support that search-type. If this is correct, then searches for dynamic schema won't be feasible. For example, a registrar cannot unilaterally offer value-added data until everybody agrees on the 'named' searches that should be supported for the class of data (even if the schema were extended, the data could not be searched, so what's the point). This would be a fairly strict imposition, since it would effectively prohibit registrars and registries (not to mention resource operators) from offering their own sub-schema. Also, IRIS does not appear to provide any syntax for a client to identify a specific subset of attributes that should be returned in an answer set. All answer data must always be provided, so there is no for (EG) a government flunky to request ~only the domain name and email address for all operators in Sweden. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Sat Aug 30 17:01:23 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Sat Aug 30 16:01:33 2003 Subject: [Ietf-not43] IRIS general attribute searching and fetching In-Reply-To: <3F50AB6E.30203@ehsco.com> References: <3F50AB6E.30203@ehsco.com> Message-ID: <3F510293.50603@ecotroph.net> Eric A. Hall wrote: > IRIS seems to only provide pre-defined 'named' searches, and does not > appear to provide a generalized "search this attribute for this value" > syntax. Is this correct? EG, ~finding all entries with a particular Post > Office Box as the registrant address is not possible unless and until a > 'named' search for that is defined, and the nodes are extended to support > that search-type. This is correct. IRIS does not support a general query syntax. That is not to say it cannot support a general query syntax, it is just that none has been defined. Now for the philosophy: most of th reasons why IRIS takes the approach it does are laid out in Appendix C. of the IRIS Core draft. But here's the condensed version: 1) generalized query languages lend themselves to abuse and server operators tend to severly restrict which part of the language will be accepted and which will not, and 2) clients created for the specific problem domain often end up doing a considerable amount of translation between the user interface and the lowest-common denominator effect of a general query language. This is laid out better in Appendix C. > If this is correct, then searches for dynamic schema won't be feasible. > For example, a registrar cannot unilaterally offer value-added data until > everybody agrees on the 'named' searches that should be supported for the > class of data (even if the schema were extended, the data could not be > searched, so what's the point). This would be a fairly strict imposition, > since it would effectively prohibit registrars and registries (not to > mention resource operators) from offering their own sub-schema. It is always possible that if they were to define their own new schema, they could also define their own new searches taylored to their own set of problems. Is this a strict imposition? I can create a draft describing a generalized registry and we can see if there is demand for it. > Also, IRIS does not appear to provide any syntax for a client to identify > a specific subset of attributes that should be returned in an answer set. > All answer data must always be provided, so there is no for (EG) a > government flunky to request ~only the domain name and email address for > all operators in Sweden. If the working group feels that such a feature is needed, it could easily be added. -andy From ehall at ehsco.com Sun Aug 31 00:12:18 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 31 00:12:28 2003 Subject: [Ietf-not43] IRIS general attribute searching and fetching In-Reply-To: <3F510293.50603@ecotroph.net> References: <3F50AB6E.30203@ehsco.com> <3F510293.50603@ecotroph.net> Message-ID: <3F5175A2.2000206@ehsco.com> on 8/30/2003 3:01 PM Andrew Newton wrote: > the condensed version: 1) generalized query languages lend themselves to > abuse and server operators tend to severly restrict which part of the > language will be accepted and which will not, It's a lot easier to put limitations on the end-points than to remove limitations from the protocol after-the-fact. > and 2) clients created for > the specific problem domain often end up doing a considerable amount of > translation between the user interface and the lowest-common denominator > effect of a general query language. Provide a default query for simple clients to use, like a default "find domain-by-name" (or whatever), and let the power tools worry about the complex syntax stuff. Difficulty can be selective. >>For example, a registrar cannot unilaterally offer value-added data until >>everybody agrees on the 'named' searches that should be supported for the >>class of data (even if the schema were extended, the data could not be >>searched, so what's the point). This would be a fairly strict imposition, >>since it would effectively prohibit registrars and registries (not to >>mention resource operators) from offering their own sub-schema. > > It is always possible that if they were to define their own new schema, > they could also define their own new searches taylored to their own set > of problems. And then what? I don't see any text on how clients and servers would negotiate over the extension queries. If you're really serious about a query-service-that-isn't-really-a-query-service you'll need to provide mechanisms for extension negotiation. Then you'll need to convince client developers that it's in their best interest to follow the development cycle at all ~250 top-level registries, and that every named query should have a local implementation that is only enabled when the associated TLD is hit. Don't forget the 2LDs! OTOH, you could remove the arbitrary limitations and allow the nodes to negotiate the supported syntax. If you were pursuing efficiency, that would lead you to the CAPABILITIES model you dislike, but still, that's more efficient than having each provider and server use different queries and making clients track each of them separately. Another concern that is probably more applicable to the folks who are actually here is that the deployment difficulties make deployment a waste of effort. Assume that some providers wants to provide something like an expiration date attribute (or anything that isn't part of the core schema anyway). If nobody can search against that data, then by definition the data is only useful as supplementary information, and any value it does end up having will be entirely accidental. That's no business case for schema extension as a competitive tool. This topic becomes much uglier once you get into other services. We know that some domain/ip registries have different requirements (and will want to maximize them) but this difference is nothing compared to the other (potential) layered services. Who's going to work on directory-based blacklists that can't be searched? >>Also, IRIS does not appear to provide any syntax for a client to identify >>a specific subset of attributes that should be returned in an answer set. >>All answer data must always be provided, so there is no for (EG) a >>government flunky to request ~only the domain name and email address for >>all operators in Sweden. > > If the working group feels that such a feature is needed, it could > easily be added. I guess it depends on what you think the value proposition is with XML. >From a client perspective, the value is supposedly about the benefits that are yielded from being able to integrate disparate data sources through a (relatively) common syntax. Being able to limit query output to a few precise columns and rows would further that benefit, in that it would be easier to integrate the resulting data. From a provider perspective, using the same tools is the value, but that doesn't demonstrably benefit the user. I've said this before: the focus on short-term provider benefit is ultimately the wrong area. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Sun Aug 31 06:48:09 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Sun Aug 31 05:56:54 2003 Subject: [Ietf-not43] IRIS general attribute searching and fetching In-Reply-To: <3F5175A2.2000206@ehsco.com> References: <3F50AB6E.30203@ehsco.com> <3F510293.50603@ecotroph.net> <3F5175A2.2000206@ehsco.com> Message-ID: <3F51C459.3000902@ecotroph.net> Eric A. Hall wrote: > > Provide a default query for simple clients to use, like a default "find > domain-by-name" (or whatever), and let the power tools worry about the > complex syntax stuff. Difficulty can be selective. Like I said: I can create a proposal for a general query syntax and we can see if there is demand for it. > And then what? I don't see any text on how clients and servers would > negotiate over the extension queries. If you're really serious about a > query-service-that-isn't-really-a-query-service you'll need to provide > mechanisms for extension negotiation. Schema versions are negotiated via BEEP profiles. > OTOH, you could remove the arbitrary limitations and allow the nodes to > negotiate the supported syntax. If you were pursuing efficiency, that > would lead you to the CAPABILITIES model you dislike, but still, that's > more efficient than having each provider and server use different queries > and making clients track each of them separately. A capabilities list is not enough. It will not provide a client the proper knowledge to rearrange dialog boxes or retool command line switches. At best it will just allow them to grey-out entire categories of queries. -andy From ehall at ehsco.com Sun Aug 31 12:48:15 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sun Aug 31 12:48:22 2003 Subject: [Ietf-not43] IRIS general attribute searching and fetching In-Reply-To: <3F51C459.3000902@ecotroph.net> References: <3F50AB6E.30203@ehsco.com> <3F510293.50603@ecotroph.net> <3F5175A2.2000206@ehsco.com> <3F51C459.3000902@ecotroph.net> Message-ID: <3F5226CF.5070602@ehsco.com> on 8/31/2003 4:48 AM Andrew Newton wrote: >>And then what? I don't see any text on how clients and servers would >>negotiate over the extension queries. If you're really serious about a >>query-service-that-isn't-really-a-query-service you'll need to provide >>mechanisms for extension negotiation. > > Schema versions are negotiated via BEEP profiles. We're talking about extension negotiation, which is different from the schema-version negotiation, and which is not discussed in the specs. You are advocating the position that each server "can" define its own searches, but you haven't described how clients are supposed to discover the availability of these extensions on a per-partition or (more importantly) a per-server basis. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/