From mailman-bounces@ietf.org Fri Oct 1 06:07:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13001 for ; Fri, 1 Oct 2004 06:07:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKS2-0003P3-Rq for crisp-web-archive@ietf.org; Fri, 01 Oct 2004 06:15:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJYl-0006l2-Vh for crisp-web-archive@ietf.org; Fri, 01 Oct 2004 05:18:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: crisp-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:04:09 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for crisp-web-archive@ietf.org: List Password // URL ---- -------- crisp@ietf.org awwuin https://www1.ietf.org/mailman/options/crisp/crisp-web-archive%40ietf.org From crisp-bounces@ietf.org Tue Oct 5 08:05:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20140 for ; Tue, 5 Oct 2004 08:05:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEoDu-0007ox-Ev for crisp-web-archive@ietf.org; Tue, 05 Oct 2004 08:15:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEo14-0006O8-7Y; Tue, 05 Oct 2004 08:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEnuC-00057U-Ln for crisp@megatron.ietf.org; Tue, 05 Oct 2004 07:54:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18844 for ; Tue, 5 Oct 2004 07:54:55 -0400 (EDT) Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEo3T-000604-VE for crisp@ietf.org; Tue, 05 Oct 2004 08:04:32 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 4C1B9143DAF; Tue, 5 Oct 2004 07:54:09 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 97BEF143CE2 for ; Tue, 5 Oct 2004 07:54:08 -0400 (EDT) Received: from caesium.arin.net (host-136-34.arin.net [192.136.136.34]) by mercury.arin.net (Postfix) with ESMTP id 259D11FE5E for ; Tue, 5 Oct 2004 07:54:22 -0400 (EDT) Message-Id: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> X-Sender: timc@192.149.252.131 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 05 Oct 2004 07:54:10 -0400 To: crisp@ietf.org From: Tim Christensen Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Subject: [Crisp] Nesting queries redux X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 All, Here is another thought about rounding out the nested queries set. Recall this diagram: 0 255 |----------------------------A----------------------------------------| 32 127 128 239240 255 |-----------B-----------| |-----------------C-------------||---J--| 32 63 80 95 128 239 |----D----| |--E--| |-----------------F-------------| 32 35 60 63 83 87 216 255 |-G-| |-H-| |-I-| |--------K-------| I previously made a case for the utility of a 'Lowest Level of Authority" query which would return, essentially, the first-line-responsible network(s) for a given query (or range). My rationale was that it was useful for the server to provide a query that returns all "exposed-at-the-leaf-or-branch" networks for a range (looking from the bottom up). If a client wanted to get that information and a query that returns something like my proposal isn't available at the server, then it creates a multi-round-trip problem that will create too much back-and-forth between client and server to answer the question, "what network(s) are the first-line authority for network range x -> y". Specifically, the number of round trips varies, and increases, consistent with the depth of re-subdelegation in the tree (deeper trees create many, many round trips to answer the question.) The following proposal is another approach to that same problem. Today, we have a "less specific" query, which essentially returns (mathematically) "higher" networks in a network hierarchy. This query however is constrained to return only networks which fully contain the query (range). Using the example above, if a query were [start=34, end=61], the query would return networks D, B, and A (since they all fully enclose the range) but not G or H, because they do not fully enclose the range; indeed, G and H "overlap" the range, in that with G starting at 32, it has nodes outside the starting point of 34, etc. If this "less specific" query were expressed with a modifier that would make non-fully-enclosed networks (or, networks that overlap the beginning or end of the query range) appear in the result set as well, then we'd have (at least) all the components of the original LLA query but without the (perhaps difficult?) server-side work. For discussion, I will use the modifier "overlaps/no-overlaps", although feel free to use some other verbage (inclusive/exclusive, etc.) In a "less specific overlaps" query for 34 -> 61, the server would return D, B, and A, because they fully enclose the query range, AND, G and H, because they partially-enclose (or, overlap) the range. If the client gets A, B, D, G, and H all back in this type of query, it's now simple math to determine which networks are 'exposed' at the lowest level of the hierarchy. Server does easier work, Client does a little more work, but only 1 network trip is required. The client would be able to figure out that: G is the first-line-authority for the network part from 34 to 35 D is the first-line-authority for the network part from 36 to 59 H is the first-line-authority for the network part from 60 to 61 and that A and B can be 'discarded' by the client as extraneous server results because they have no leaf-or-branch 'exposure' and aren't first-line-authoritative for any portion of the query range. That's easily mathematically determined. This technique would (also) be able to remove higher-in-hierarchy exact-matches by examining the parentage (where parentage exists, dependent on registry). It seems to me that "less specific no-overlaps" still has good utility since the lowest-level network returned in such a query is the original "most specific" as proposed by Engin originally, which has usefulness as discussed previously on-list and in session. Thus the suggestion for adding the overlaps/no-overlaps modifier rather than changing the default behavior of "less specific". Feedback invited. Thanks to Andy, Shane, Engin, and David for their thoughts on this idea. _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Tue Oct 5 15:52:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01834 for ; Tue, 5 Oct 2004 15:52:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEvW4-0001wa-JL for crisp-web-archive@ietf.org; Tue, 05 Oct 2004 16:02:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvGJ-00078j-LE; Tue, 05 Oct 2004 15:46:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEv9s-0004Wh-Pa; Tue, 05 Oct 2004 15:39:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00889; Tue, 5 Oct 2004 15:39:34 -0400 (EDT) Message-Id: <200410051939.PAA00889@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 05 Oct 2004 15:39:34 -0400 Cc: crisp@ietf.org Subject: [Crisp] I-D ACTION:draft-ietf-crisp-iris-areg-07.txt X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart 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 : IRIS - An Address Registry (areg) Type for the Internet Registry Information Service Author(s) : A. Newton, E. Gunduz Filename : draft-ietf-crisp-iris-areg-07.txt Pages : 45 Date : 2004-10-5 This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries.. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iris-areg-07.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-iris-areg-07.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-5160419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-iris-areg-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-iris-areg-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-5160419.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp --NextPart-- From crisp-bounces@ietf.org Wed Oct 6 06:52:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10654 for ; Wed, 6 Oct 2004 06:52:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF9YQ-0000Se-QZ for crisp-web-archive@ietf.org; Wed, 06 Oct 2004 07:01:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9NO-00015g-Cp; Wed, 06 Oct 2004 06:50:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CF9JD-0000NK-OQ for crisp@megatron.ietf.org; Wed, 06 Oct 2004 06:46:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10368 for ; Wed, 6 Oct 2004 06:46:08 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CF9Sg-0008Ur-Cf for crisp@ietf.org; Wed, 06 Oct 2004 06:55:59 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 7D69655C5A; Wed, 6 Oct 2004 12:44:08 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 0AC0155C4C for ; Wed, 6 Oct 2004 12:44:08 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i96Ai8rL019766 for ; Wed, 6 Oct 2004 12:44:08 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id i96Ai8CF017660 for crisp@ietf.org; Wed, 6 Oct 2004 12:44:08 +0200 Date: Wed, 6 Oct 2004 12:44:07 +0200 From: Engin Gunduz To: crisp@ietf.org Subject: Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-areg-07.txt Message-ID: <20041006104407.GD10474@x47.ripe.net> References: <200410051939.PAA00889@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <200410051939.PAA00889@ietf.org> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Status: N 0.138829 / 0.0 / 0.0 / disabled X-RIPE-Signature: 9af6cf4a62e2cc3833e763decea174ed X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Hi, Here are the modifications made (diff between versions areg-06 and areg-07): * element and names searches for networks and ASNs put back, as Cathy requested. * Added search, with hierarcy (specificity) and taken out autonomous-system query (not needed in the presense of findASNByNumber> search) * Added element to and searches. Also added the following statement to the respective sections: The client SHOULD pass the names unchanged to the server, and the implementation of the server decides if the search is case sensitive or not. * Taken out 'closest-match' specificity query, as it is covered by less-specific query with 'allowEquivalences' set to true. * Put and back into , , , queries. * Added search to find ASNs, networks, organisations by contact. * Added search (mainly to figure out parentage relations) * Changed formal XML syntax section to match the other changes. * in, , , and out in Result. * element in result. * Changed URI resolution. It now says: 7.2 Top-Down Resolution The top-down alternative resolution method MUST be identified as 'top' in IRIS URI's. The client SHOULD start every query from the CRISP server crisp.nro.org and follow the referrals to find the authoritative server to actually query. Todo: * if decided so, put Tim's network seach. * add specificity examples as appendix. * editorial (split informative/normative refs, etc) * improve 'nesting terminology' section (sec.4) [done in my local copy] It would be verry nice if we could settle these before 25 Oct, the cut-off date of drafts. regards, -engin On 2004-10-05 15:39:34 -0400, Internet-Drafts@ietf.org wrote: > 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 : IRIS - An Address Registry (areg) Type for the > Internet Registry Information Service > Author(s) : A. Newton, E. Gunduz > Filename : draft-ietf-crisp-iris-areg-07.txt > Pages : 45 > Date : 2004-10-5 > > This document describes an IRIS registry schema for IP address and > Autonomous System Number information. The schema extends the > necessary query and result operations of IRIS to provide the > functional information service needs for syntaxes and results used by > Internet Protocol address registries.. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-07.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-iris-areg-07.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 > > [...] _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 8 16:19:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04887 for ; Fri, 8 Oct 2004 16:19:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG1N9-0000mM-Hv for crisp-web-archive@ietf.org; Fri, 08 Oct 2004 16:29:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0w5-0004Xl-04; Fri, 08 Oct 2004 16:01:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0WS-0006Ft-Is; Fri, 08 Oct 2004 15:35:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28254; Fri, 8 Oct 2004 15:35:22 -0400 (EDT) Message-Id: <200410081935.PAA28254@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Oct 2004 15:35:22 -0400 Cc: crisp@ietf.org Subject: [Crisp] I-D ACTION:draft-ietf-crisp-iris-dchk-01.txt X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --NextPart 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 : A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) Author(s) : A. Newton Filename : draft-ietf-crisp-iris-dchk-01.txt Pages : 18 Date : 2004-10-8 This document describes a lightweight domain availability service using the IRIS framework and the data model of the IRIS Domain Registry service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-dchk-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iris-dchk-01.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-iris-dchk-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-8160027.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-iris-dchk-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-iris-dchk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8160027.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp --NextPart-- From crisp-bounces@ietf.org Fri Oct 8 16:24:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05500 for ; Fri, 8 Oct 2004 16:24:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG1Rn-0000ys-A4 for crisp-web-archive@ietf.org; Fri, 08 Oct 2004 16:34:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0wC-0004gp-Ek; Fri, 08 Oct 2004 16:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG0Wq-0006Pf-74; Fri, 08 Oct 2004 15:35:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28274; Fri, 8 Oct 2004 15:35:46 -0400 (EDT) Message-Id: <200410081935.PAA28274@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 08 Oct 2004 15:35:46 -0400 Cc: crisp@ietf.org Subject: [Crisp] I-D ACTION:draft-ietf-crisp-iris-lwz-00.txt X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart 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 : A Lightweight UDP Transport for the the Internet Registry Information Service Author(s) : A. Newton Filename : draft-ietf-crisp-iris-lwz-00.txt Pages : 19 Date : 2004-10-8 This document describes a lightweight UDP transport for the Internet Registry Information Service (IRIS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-lwz-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iris-lwz-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-iris-lwz-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-8160033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-iris-lwz-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-iris-lwz-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-8160033.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp --NextPart-- From crisp-bounces@ietf.org Wed Oct 13 14:03:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20262 for ; Wed, 13 Oct 2004 14:03:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHndx-0001sG-QM for crisp-web-archive@ietf.org; Wed, 13 Oct 2004 14:14:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHnIO-0004Bw-Cw; Wed, 13 Oct 2004 13:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHn90-00024k-9o for crisp@megatron.ietf.org; Wed, 13 Oct 2004 13:42:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18596 for ; Wed, 13 Oct 2004 13:42:32 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHnJw-0001Qq-Ni for crisp@ietf.org; Wed, 13 Oct 2004 13:53:53 -0400 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Wed, 13 Oct 2004 13:41:59 -0400 id 0042006B.416D68E7.0000495A Message-ID: <416D68E0.9010106@verisignlabs.com> Date: Wed, 13 Oct 2004 13:41:52 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Christensen Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> In-Reply-To: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Tim Christensen wrote: > All, > > Here is another thought about rounding out the nested queries set. > > Recall this diagram: > > 0 255 > |----------------------------A----------------------------------------| > > 32 127 128 239240 255 > |-----------B-----------| |-----------------C-------------||---J--| > > 32 63 80 95 128 239 > |----D----| |--E--| |-----------------F-------------| > > 32 35 60 63 83 87 216 255 > |-G-| |-H-| |-I-| |--------K-------| > > > I previously made a case for the utility of a 'Lowest Level of > Authority" query which would return, essentially, the > first-line-responsible network(s) for a given query (or range). First, I would like to say that I continue to think that this (LLA) is a very useful query. To help clarify my comments, I would like to try and put your original "LLA" query in more mathematical terms. I see the LLA query as equivalent to: UNION( Q(one-level-less, qstart..qend) ) That is, the union of the results of "one-level-less" queries for each of the individual addresses contained between the query start address and the query end address, inclusive. So, using your diagram, the LLA for qstart=32, qend=85, would be (G, D, H, B, E, and I). The LLA for your example below, qstart=34, qend=61 would be (G, D, H). > The following proposal is another approach to that same problem. To my mind, the only reason for attempting another approach is to attempt to get a query that is easier to implement that your original LLA query. Is that correct? Clearly, my mathematical description of LLA does not lend itself to an efficient solution, on either the client or server side. However, that doesn't mean that there is no efficient way to implement this query. But no one has described one yet. > Today, we have a "less specific" query, which essentially returns > (mathematically) "higher" networks in a network hierarchy. This query > however is constrained to return only networks which fully contain the > query (range). Using the example above, if a query were [start=34, > end=61], the query would return networks D, B, and A (since they all > fully enclose the range) but not G or H, because they do not fully > enclose the range; indeed, G and H "overlap" the range, in that with G > starting at 32, it has nodes outside the starting point of 34, etc. > > If this "less specific" query were expressed with a modifier that would > make non-fully-enclosed networks (or, networks that overlap the > beginning or end of the query range) appear in the result set as well, > then we'd have (at least) all the components of the original LLA query > but without the (perhaps difficult?) server-side work. For discussion, > I will use the modifier "overlaps/no-overlaps", although feel free to > use some other verbage (inclusive/exclusive, etc.) I would not want to make this a modifier unless it makes sense to use with all specificities. If it only makes sense for the "less" specificity, then it should probably be a separate specificity scope (say, "less-with-overlaps", to be ugly and verbose). > In a "less specific overlaps" query for 34 -> 61, the server would > return D, B, and A, because they fully enclose the query range, AND, G > and H, because they partially-enclose (or, overlap) the range. This only gets you what you want because your query range is small enough that their aren't any more specific networks for that range. Take my other example, above: 32 -> 85. "less specific overlaps" would return B, I, and E. It would not return G, H, or D because they are neither overlaps nor less specific (they are more specific). I believe that you are correct in thinking that this is easier to implement on the server side than LLA. You can (I believe) express this "less specific overlaps" operation as returning all network blocks that contain either qstart, qend, or both, which at minimum, means that it is: UNION(Q(less, qstart), Q(less, qend)). Only two queries. > If the client gets A, B, D, G, and H all back in this type of query, > it's now simple math to determine which networks are 'exposed' at the > lowest level of the hierarchy. Server does easier work, Client does a > little more work, but only 1 network trip is required. The client > would be able to figure out that: > > G is the first-line-authority for the network part from 34 to 35 > D is the first-line-authority for the network part from 36 to 59 > H is the first-line-authority for the network part from 60 to 61 > > and that A and B can be 'discarded' by the client as extraneous server > results because they have no leaf-or-branch 'exposure' and aren't > first-line-authoritative for any portion of the query range. That's > easily mathematically determined. > > This technique would (also) be able to remove higher-in-hierarchy > exact-matches by examining the parentage (where parentage exists, > dependent on registry). As a matter of principle, if there is a discard process that you know that client will do, then doing it on the server makes more sense (well, as long as it isn't terribly expensive). > It seems to me that "less specific no-overlaps" still has good utility > since the lowest-level network returned in such a query is the original > "most specific" as proposed by Engin originally, which has usefulness as > discussed previously on-list and in session. Thus the suggestion for > adding the overlaps/no-overlaps modifier rather than changing the > default behavior of "less specific". The only time that "less specific no-overlaps" (i.e., "less") will return the "most specific" network is when your query range just happens to have no actual more specific networks. This is, of course, always true when qstart == qend. -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 14 11:54:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01895 for ; Thu, 14 Oct 2004 11:54:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI86z-0005Ap-84 for crisp-web-archive@ietf.org; Thu, 14 Oct 2004 12:05:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7ow-0003Ov-La; Thu, 14 Oct 2004 11:47:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI7k1-0001x1-SZ for crisp@megatron.ietf.org; Thu, 14 Oct 2004 11:42:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01147 for ; Thu, 14 Oct 2004 11:42:07 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI7vC-0004x5-I2 for crisp@ietf.org; Thu, 14 Oct 2004 11:53:44 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 9B1FA51C4A; Thu, 14 Oct 2004 17:40:42 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 1D65B6DD03; Thu, 14 Oct 2004 17:40:42 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9EFegx1001491; Thu, 14 Oct 2004 17:40:42 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id i9EFefXK032314; Thu, 14 Oct 2004 17:40:41 +0200 Date: Thu, 14 Oct 2004 17:40:41 +0200 From: Engin Gunduz To: David Blacka Subject: Re: [Crisp] Nesting queries redux Message-ID: <20041014154041.GM22821@x47.ripe.net> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <416D68E0.9010106@verisignlabs.com> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Status: N 0.002875 / 0.0 / 0.0 / disabled X-RIPE-Signature: fcdefb4cd2049b589352953b8f679907 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Tim Christensen , crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hi, On 2004-10-13 13:41:52 -0400, David Blacka wrote: > Tim Christensen wrote: > >All, > > > >Here is another thought about rounding out the nested queries set. > > > >Recall this diagram: > > > >0 255 > >|----------------------------A----------------------------------------| > > > > 32 127 128 239240 255 > > |-----------B-----------| |-----------------C-------------||---J--| > > > > 32 63 80 95 128 239 > > |----D----| |--E--| |-----------------F-------------| > > > > 32 35 60 63 83 87 216 255 > > |-G-| |-H-| |-I-| |--------K-------| > > > > > >I previously made a case for the utility of a 'Lowest Level of > >Authority" query which would return, essentially, the > >first-line-responsible network(s) for a given query (or range). > > First, I would like to say that I continue to think that this (LLA) is a > very useful query. > > To help clarify my comments, I would like to try and put your original > "LLA" query in more mathematical terms. I see the LLA query as > equivalent to: > > UNION( Q(one-level-less, qstart..qend) ) > > That is, the union of the results of "one-level-less" queries for each > of the individual addresses contained between the query start address > and the query end address, inclusive. > > So, using your diagram, the LLA for qstart=32, qend=85, would be (G, D, > H, B, E, and I). The LLA for your example below, qstart=34, qend=61 > would be (G, D, H). > > >The following proposal is another approach to that same problem. > > To my mind, the only reason for attempting another approach is to > attempt to get a query that is easier to implement that your original > LLA query. Is that correct? > > Clearly, my mathematical description of LLA does not lend itself to an > efficient solution, on either the client or server side. However, that > doesn't mean that there is no efficient way to implement this query. > But no one has described one yet. Let me try: All networks that satisfy the following criteria: ( start(network) >= start(query)) AND ( end(network)) >= end(query) ) OR ( start(query) >= start(network)) AND ( end(query)) >= end(network) ) If we take the union of the above networks, all less specifics, and all more specifics, then we will need to delete the ones that are not exposed looking from the bottom up. That last bit I'm not sure how to do right now :) [...] > > > >If this "less specific" query were expressed with a modifier that would > >make non-fully-enclosed networks (or, networks that overlap the > >beginning or end of the query range) appear in the result set as well, > >then we'd have (at least) all the components of the original LLA query > >but without the (perhaps difficult?) server-side work. For discussion, > >I will use the modifier "overlaps/no-overlaps", although feel free to > >use some other verbage (inclusive/exclusive, etc.) > > I would not want to make this a modifier unless it makes sense to use > with all specificities. If it only makes sense for the "less" > specificity, then it should probably be a separate specificity scope > (say, "less-with-overlaps", to be ugly and verbose). I agree that it must be yet another specificity scope, mainly because it actually does not fit into the logic of "less specifics", but it is something else by itself... [...] > > > >G is the first-line-authority for the network part from 34 to 35 > >D is the first-line-authority for the network part from 36 to 59 > >H is the first-line-authority for the network part from 60 to 61 > > > >and that A and B can be 'discarded' by the client as extraneous server > >results because they have no leaf-or-branch 'exposure' and aren't > >first-line-authoritative for any portion of the query range. That's > >easily mathematically determined. > > > >This technique would (also) be able to remove higher-in-hierarchy > >exact-matches by examining the parentage (where parentage exists, > >dependent on registry). > > As a matter of principle, if there is a discard process that you know > that client will do, then doing it on the server makes more sense (well, > as long as it isn't terribly expensive). I agree again. None of the other specificity scopes require the client to do any filtering, so when possible, the server would do any processing. -engin > >It seems to me that "less specific no-overlaps" still has good utility > >since the lowest-level network returned in such a query is the original > >"most specific" as proposed by Engin originally, which has usefulness as > >discussed previously on-list and in session. Thus the suggestion for > >adding the overlaps/no-overlaps modifier rather than changing the > >default behavior of "less specific". > > The only time that "less specific no-overlaps" (i.e., "less") will > return the "most specific" network is when your query range just happens > to have no actual more specific networks. This is, of course, always > true when qstart == qend. > > -- > David Blacka > Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 14 12:57:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07083 for ; Thu, 14 Oct 2004 12:57:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI95z-0006h0-K8 for crisp-web-archive@ietf.org; Thu, 14 Oct 2004 13:08:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8sa-0005dF-U5; Thu, 14 Oct 2004 12:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI8eE-0002nr-Sh for crisp@megatron.ietf.org; Thu, 14 Oct 2004 12:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05949 for ; Thu, 14 Oct 2004 12:40:12 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI8pQ-0006L5-HC for crisp@ietf.org; Thu, 14 Oct 2004 12:51:49 -0400 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 14 Oct 2004 12:39:43 -0400 id 0042039E.416EABCF.00003424 Message-ID: <416EABC7.5040306@verisignlabs.com> Date: Thu, 14 Oct 2004 12:39:35 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Engin Gunduz Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> In-Reply-To: <20041014154041.GM22821@x47.ripe.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-9; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Tim Christensen , crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Engin Gunduz wrote: >>Clearly, my mathematical description of LLA does not lend itself to an >>efficient solution, on either the client or server side. However, that >>doesn't mean that there is no efficient way to implement this query. >>But no one has described one yet. > > > Let me try: > > All networks that satisfy the following criteria: > > ( start(network) >= start(query)) AND ( end(network)) >= end(query) ) > OR > ( start(query) >= start(network)) AND ( end(query)) >= end(network) ) > > If we take the union of the above networks, all less specifics, and > all more specifics, then we will need to delete the ones that are > not exposed looking from the bottom up. That last bit I'm not sure > how to do right now :) I may be misunderstanding your notation, but wouldn't your query terms return networks that have nothing to do with your query? That is (to take the first term) if a result network's start address is greater than your query start address, is also may be greater than your query end address, and thus be utterly irrelevant to your query. Actually, I think that your query returns every network that isn't a more specific network than the query, which is a bit much. I think what you are getting at is to first assemble all the networks that are less specific, more specific and overlap the query range. (Basically all networks that contains any of the IP address in the query range). A possibly more compact way to get this is to union the results of: Q(all-less-specific, qstart), Q(all-less-specific, qend), Q(all-more-specific, qstart -> qend). (Note that the all of the results returned by Q(all-less-specific, qstart -> qend) will be included in the above union, as those networks are the ones in the results of both of the two all-less-specific queries). The hard part is seeing how to efficiently winnow down this list into the correct subset. Tim's description is essentially a paper description, and I haven't figured out how to do this computationally. Ideally it should be at least O(n) + O(nlog(n)) (n being the number of results). -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 14 13:49:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11289 for ; Thu, 14 Oct 2004 13:49:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI9ul-0007qS-UZ for crisp-web-archive@ietf.org; Thu, 14 Oct 2004 14:01:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9hp-0001A1-Mu; Thu, 14 Oct 2004 13:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9fU-0000kV-Ar for crisp@megatron.ietf.org; Thu, 14 Oct 2004 13:45:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11003 for ; Thu, 14 Oct 2004 13:45:34 -0400 (EDT) Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI9qg-0007kj-U2 for crisp@ietf.org; Thu, 14 Oct 2004 13:57:11 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id C5B0E143E32; Thu, 14 Oct 2004 13:45:02 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id E7A3A143E27; Thu, 14 Oct 2004 13:45:01 -0400 (EDT) Received: from caesium.arin.net (caesium.arin.net [192.136.136.36]) by mercury.arin.net (Postfix) with ESMTP id 075CF1FE94; Thu, 14 Oct 2004 13:45:02 -0400 (EDT) Message-Id: <6.1.0.6.0.20041013150055.036243c8@192.149.252.131> X-Sender: timc@192.149.252.131 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 14 Oct 2004 13:45:01 -0400 To: David Blacka From: Tim Christensen Subject: Re: [Crisp] Nesting queries redux In-Reply-To: <416D68E0.9010106@verisignlabs.com> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 At 10/13/2004 01:41 PM, David Blacka wrote: >Tim Christensen wrote: >>All, >>Here is another thought about rounding out the nested queries set. >>Recall this diagram: >>0 255 >>|----------------------------A----------------------------------------| >> 32 127 128 239240 255 >> |-----------B-----------| |-----------------C-------------||---J--| >> 32 63 80 95 128 239 >> |----D----| |--E--| |-----------------F-------------| >> 32 35 60 63 83 87 216 255 >> |-G-| |-H-| |-I-| |--------K-------| >> >>I previously made a case for the utility of a 'Lowest Level of Authority" >>query which would return, essentially, the first-line-responsible >>network(s) for a given query (or range). > >First, I would like to say that I continue to think that this (LLA) is a >very useful query. > >To help clarify my comments, I would like to try and put your original >"LLA" query in more mathematical terms. I see the LLA query as equivalent to: > > UNION( Q(one-level-less, qstart..qend) ) > >That is, the union of the results of "one-level-less" queries for each of >the individual addresses contained between the query start address and the >query end address, inclusive. Yes, it can certainly be approached that way, and that's accurate. >So, using your diagram, the LLA for qstart=32, qend=85, would be (G, D, H, >B, E, and I). The LLA for your example below, qstart=34, qend=61 would be >(G, D, H). Correct. >>The following proposal is another approach to that same problem. > >To my mind, the only reason for attempting another approach is to attempt >to get a query that is easier to implement that your original LLA >query. Is that correct? Yes, which grew out of concerns of the LLA query's inability to be implemented without great network cost, for various values of great. Similar to what you state below, I have server-side cost concerns about the "look up every /32 or /128" appraoch. >Clearly, my mathematical description of LLA does not lend itself to an >efficient solution, on either the client or server side. > However, that doesn't mean that there is no efficient way to implement > this query. But no one has described one yet. > >>Today, we have a "less specific" query, which essentially returns >>(mathematically) "higher" networks in a network hierarchy. This query >>however is constrained to return only networks which fully contain the >>query (range). Using the example above, if a query were [start=34, >>end=61], the query would return networks D, B, and A (since they all >>fully enclose the range) but not G or H, because they do not fully >>enclose the range; indeed, G and H "overlap" the range, in that with G >>starting at 32, it has nodes outside the starting point of 34, etc. >>If this "less specific" query were expressed with a modifier that would >>make non-fully-enclosed networks (or, networks that overlap the beginning >>or end of the query range) appear in the result set as well, then we'd >>have (at least) all the components of the original LLA query but without >>the (perhaps difficult?) server-side work. For discussion, I will use >>the modifier "overlaps/no-overlaps", although feel free to use some other >>verbage (inclusive/exclusive, etc.) > >I would not want to make this a modifier unless it makes sense to use with >all specificities. If it only makes sense for the "less" specificity, >then it should probably be a separate specificity scope (say, >"less-with-overlaps", to be ugly and verbose). Ew, but, I definitely see that point... okay. >>In a "less specific overlaps" query for 34 -> 61, the server would return >>D, B, and A, because they fully enclose the query range, AND, G and H, >>because they partially-enclose (or, overlap) the range. > >This only gets you what you want because your query range is small enough >that their aren't any more specific networks for that range. > >Take my other example, above: 32 -> 85. "less specific overlaps" would >return B, I, and E. It would not return G, H, or D because they are >neither overlaps nor less specific (they are more specific). Yes, that would be correct, they are 'more specific' than the query, and would not be included. Mea culpa in my description, and you are correct to think that they SHOULD appear in the result set. I intended them to be but described it incorrectly. >I believe that you are correct in thinking that this is easier to >implement on the server side than LLA. You can (I believe) express >this "less specific overlaps" operation as returning all network blocks >that contain either qstart, qend, or both Yes, that's what we really want... minus any "fully subdelegated" less-specific blocks (such as, not returning "C" if you're returning "F", since C's space is fully subdelegated) as you perceive correctly below... >which at minimum, means that it is: UNION(Q(less, qstart), Q(less, >qend)). Only two queries. > >>If the client gets A, B, D, G, and H all back in this type of query, it's >>now simple math to determine which networks are 'exposed' at the lowest >>level of the hierarchy. Server does easier work, Client does a little >>more work, but only 1 network trip is required. The client would be >>able to figure out that: >>G is the first-line-authority for the network part from 34 to 35 >>D is the first-line-authority for the network part from 36 to 59 >>H is the first-line-authority for the network part from 60 to 61 >>and that A and B can be 'discarded' by the client as extraneous server >>results because they have no leaf-or-branch 'exposure' and aren't >>first-line-authoritative for any portion of the query range. That's >>easily mathematically determined. >>This technique would (also) be able to remove higher-in-hierarchy >>exact-matches by examining the parentage (where parentage exists, >>dependent on registry). > >As a matter of principle, if there is a discard process that you know that >client will do, then doing it on the server makes more sense (well, as >long as it isn't terribly expensive). Agreed, if we can derive no other usefulness for knowing "ALL" networks that touch a range (as opposed to the LLA concept). I don't really see usefulness for an "ALL" at this point. Does anyone else? >>It seems to me that "less specific no-overlaps" still has good utility >>since the lowest-level network returned in such a query is the original >>"most specific" as proposed by Engin originally, which has usefulness as >>discussed previously on-list and in session. Thus the suggestion for >>adding the overlaps/no-overlaps modifier rather than changing the default >>behavior of "less specific". > >The only time that "less specific no-overlaps" (i.e., "less") will return >the "most specific" network is when your query range just happens to have >no actual more specific networks. This is, of course, always true when >qstart == qend. Correct. Tim _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 14 14:05:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12163 for ; Thu, 14 Oct 2004 14:05:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIA9U-00086z-GI for crisp-web-archive@ietf.org; Thu, 14 Oct 2004 14:16:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9wT-0004DY-4s; Thu, 14 Oct 2004 14:03:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9vZ-00040D-Qv for crisp@megatron.ietf.org; Thu, 14 Oct 2004 14:02:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12016 for ; Thu, 14 Oct 2004 14:02:12 -0400 (EDT) Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIA6m-000833-D0 for crisp@ietf.org; Thu, 14 Oct 2004 14:13:49 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id C04F614409B; Thu, 14 Oct 2004 14:01:41 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 313BC144093; Thu, 14 Oct 2004 14:01:41 -0400 (EDT) Received: from caesium.arin.net (caesium.arin.net [192.136.136.36]) by mercury.arin.net (Postfix) with ESMTP id 4AFF21FE50; Thu, 14 Oct 2004 14:01:41 -0400 (EDT) Message-Id: <6.1.0.6.0.20041014134616.030f6a00@192.149.252.131> X-Sender: timc@192.149.252.131 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Thu, 14 Oct 2004 14:01:40 -0400 To: David Blacka , Engin Gunduz From: Tim Christensen Subject: Re: [Crisp] Nesting queries redux In-Reply-To: <416EABC7.5040306@verisignlabs.com> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c At 10/14/2004 12:39 PM, David Blacka wrote: >Engin Gunduz wrote: > >>>Clearly, my mathematical description of LLA does not lend itself to an >>>efficient solution, on either the client or server side. However, that >>>doesn't mean that there is no efficient way to implement this query. But >>>no one has described one yet. >> >>Let me try: >>All networks that satisfy the following criteria: >> ( start(network) >= start(query)) AND ( end(network)) >= end(query) ) >> OR >> ( start(query) >= start(network)) AND ( end(query)) >= end(network) ) >>If we take the union of the above networks, all less specifics, and >>all more specifics, then we will need to delete the ones that are >>not exposed looking from the bottom up. That last bit I'm not sure >>how to do right now :) > >I may be misunderstanding your notation, but wouldn't your query terms >return networks that have nothing to do with your query? That is (to take >the first term) if a result network's start address is greater than your >query start address, is also may be greater than your query end address, >and thus be utterly irrelevant to your query. >Actually, I think that your query returns every network that isn't a more >specific network than the query, which is a bit much. That's what I see, too. Commonly we accomplish the first part (before the "OR") with start(network) >= start(query) AND start(network) <= end(query) AND end(network) >= start(query) AND end(network) <= end(query) which yields all the networks that match or fully enclose the query string and then we could union that with the concept of overlaps by asking for networks that contain the exact start point or end point in their network: ... UNION start(query) >= start(network) AND start(query) <= end(network) UNION end(query) >= start(network) AND end(query) <= end(network) there are networks that will fall into more than one of these query subcomponents but those are easily eliminated. >I think what you are getting at is to first assemble all the networks that >are less specific, more specific and overlap the query range. (Basically >all networks that contains any of the IP address in the query range). A >possibly more compact way to get this is to union the results of: >Q(all-less-specific, qstart), Q(all-less-specific, qend), >Q(all-more-specific, qstart -> qend). Same thing, correct? Tim _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 14 23:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04887 for ; Thu, 14 Oct 2004 23:43:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIJBp-0004Vr-Sj for crisp-web-archive@ietf.org; Thu, 14 Oct 2004 23:55:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIIyn-00066C-Ap; Thu, 14 Oct 2004 23:42:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIIxi-000602-Ap for crisp@megatron.ietf.org; Thu, 14 Oct 2004 23:41:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04748 for ; Thu, 14 Oct 2004 23:40:59 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIJ8w-0004TT-8S for crisp@ietf.org; Thu, 14 Oct 2004 23:52:42 -0400 Received: from [192.168.1.10] ([::ffff:68.48.24.54]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 14 Oct 2004 23:40:22 -0400 id 00420021.416F46A6.00001CB0 Message-ID: <416F46FA.9050200@verisignlabs.com> Date: Thu, 14 Oct 2004 23:41:46 -0400 From: David Blacka User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Christensen Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <6.1.0.6.0.20041014134616.030f6a00@192.149.252.131> In-Reply-To: <6.1.0.6.0.20041014134616.030f6a00@192.149.252.131> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org, Engin Gunduz X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Tim Christensen wrote: > At 10/14/2004 12:39 PM, David Blacka wrote: >> I may be misunderstanding your notation, but wouldn't your query terms >> return networks that have nothing to do with your query? That is (to >> take the first term) if a result network's start address is greater >> than your query start address, is also may be greater than your query >> end address, and thus be utterly irrelevant to your query. >> Actually, I think that your query returns every network that isn't a >> more specific network than the query, which is a bit much. > > > That's what I see, too. Commonly we accomplish the first part (before > the "OR") with > > start(network) >= start(query) AND > start(network) <= end(query) AND > end(network) >= start(query) AND > end(network) <= end(query) > > which yields all the networks that match or fully enclose the query string > and then we could union that with the concept of overlaps by asking for > networks that contain the exact start point or end point in their network: > > ... > UNION > start(query) >= start(network) AND > start(query) <= end(network) > UNION > end(query) >= start(network) AND > end(query) <= end(network) > > there are networks that will fall into more than one of these query > subcomponents but those are easily eliminated. >> I think what you are getting at is to first assemble all the networks >> that are less specific, more specific and overlap the query range. >> (Basically all networks that contains any of the IP address in the >> query range). A possibly more compact way to get this is to union the >> results of: Q(all-less-specific, qstart), Q(all-less-specific, qend), >> Q(all-more-specific, qstart -> qend). > > > Same thing, correct? Correct. We've both described the query that will give us all of the networks that contain any address that is part of the query range, which is a superset of the LLA query. We can call this the "all" query. I don't think that you will get a large number of duplicates with this query. Networks that will appear more than once will be networks that are properly less specific than the query range (i.e., qstart and qend both are within the result network). The number of these for any particular query will be limited by the depth of the allocation hierarchy. There may be plenty of networks in this result that are not part of the LLA query result, however. Now we just need to figure out how to get from the results of this query to the results of the LLA query. My current guess is that it can be done relatively efficiently by ordering the "all" results by start address, ascending, and end address ascending. This will give you the networks in sort of left-to-right order (looking at the diagram), sorting shorter, more specific networks before larger networks with the same start address. As you iterate over this sorted list, you can assign address ranges to each network, occasionally backtracking to the previous network to shorten its range (or eliminate it) in favor of a smaller network. I *think* that you will only have to backtrack one position, but I'm not positive. -- David Blacka Sr. Engineer Verisign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 15 07:31:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19042 for ; Fri, 15 Oct 2004 07:31:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIQUN-0004er-F2 for crisp-web-archive@ietf.org; Fri, 15 Oct 2004 07:43:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIQHd-0002cL-QV; Fri, 15 Oct 2004 07:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIQH7-0002Uu-Da for crisp@megatron.ietf.org; Fri, 15 Oct 2004 07:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18960 for ; Fri, 15 Oct 2004 07:29:32 -0400 (EDT) Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIQST-0004bs-OJ for crisp@ietf.org; Fri, 15 Oct 2004 07:41:18 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 42F43144319; Fri, 15 Oct 2004 07:29:00 -0400 (EDT) Received: from mercury.arin.net (mercury.arin.net [192.149.252.131]) by smtp2.arin.net (Postfix) with ESMTP id 904DA144316; Fri, 15 Oct 2004 07:28:59 -0400 (EDT) Received: from caesium.arin.net (caesium.arin.net [192.136.136.36]) by mercury.arin.net (Postfix) with ESMTP id B3DF21FE50; Fri, 15 Oct 2004 07:28:59 -0400 (EDT) Message-Id: <6.1.0.6.0.20041015071658.01ce3ec0@192.149.252.131> X-Sender: timc@192.149.252.131 X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Fri, 15 Oct 2004 07:28:58 -0400 To: David Blacka From: Tim Christensen Subject: Re: [Crisp] Nesting queries redux In-Reply-To: <416F46FA.9050200@verisignlabs.com> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <6.1.0.6.0.20041014134616.030f6a00@192.149.252.131> <416F46FA.9050200@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Status: No, hits=-8.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: crisp@ietf.org, Engin Gunduz X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c At 10/14/2004 11:41 PM, David Blacka wrote: >Tim Christensen wrote: >>At 10/14/2004 12:39 PM, David Blacka wrote: > > >We've both described the query that will give us all of the networks that >contain any address that is part of the query range, which is a superset >of the LLA query. We can call this the "all" query. Ok, dead horse beaten. :) >There may be plenty of networks in this result that are not part of the >LLA query result, however. > >Now we just need to figure out how to get from the results of this query >to the results of the LLA query. > >My current guess is that it can be done relatively efficiently by ordering >the "all" results by start address, ascending, and end address >ascending. This will give you the networks in sort of left-to-right order >(looking at the diagram), sorting shorter, more specific networks before >larger networks with the same start address. As you iterate over this >sorted list, you can assign address ranges to each network, occasionally >backtracking to the previous network to shorten its range (or eliminate >it) in favor of a smaller network. I *think* that you will only have to >backtrack one position, but I'm not positive. One thing I see as a (minor) challenge in your current 'guess' is that, at a registry that permits full subdelegation (e.g. full-on duplicates of start/end), you need to look at the parentage to determine which network is the child (and therefore, the first-line authority for the number resource). This can't really be accomplished mathematically, unless you start making assumptions about things like the block's create-date or something like that (which is not a good assumption). I have come up with scenarios which require more work than just one backtrack, but I am working on some kind of approach (which admittedly is an implementation detail, but a proof-of-concept would be useful before we run headlong down this path). My intuition is that this would be relatively efficient for any reasonable query. The numbers are all at hand once you've done the 'all' query. Tim _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 15 08:20:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22448 for ; Fri, 15 Oct 2004 08:20:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIRFS-0005mo-5e for crisp-web-archive@ietf.org; Fri, 15 Oct 2004 08:31:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIR1M-0000dL-WD; Fri, 15 Oct 2004 08:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIQyI-0000KK-UP for crisp@megatron.ietf.org; Fri, 15 Oct 2004 08:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22198 for ; Fri, 15 Oct 2004 08:14:09 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIR9f-0005gK-DD for crisp@ietf.org; Fri, 15 Oct 2004 08:25:55 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 8245F4E5A0; Fri, 15 Oct 2004 14:13:39 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 265C74E56D; Fri, 15 Oct 2004 14:13:39 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9FCDdx1023640; Fri, 15 Oct 2004 14:13:39 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id i9FCDc9B019174; Fri, 15 Oct 2004 14:13:38 +0200 Date: Fri, 15 Oct 2004 14:13:38 +0200 From: Engin Gunduz To: David Blacka Subject: Re: [Crisp] Nesting queries redux Message-ID: <20041015121338.GE16659@x47.ripe.net> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <416EABC7.5040306@verisignlabs.com> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Status: N 0.001587 / 0.0 / 0.0 / disabled X-RIPE-Signature: 40716becee6c2265668bdd3fc96cde0d X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Tim Christensen , crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 On 2004-10-14 12:39:35 -0400, David Blacka wrote: > Engin Gunduz wrote: > > >>Clearly, my mathematical description of LLA does not lend itself to an > >>efficient solution, on either the client or server side. However, that > >>doesn't mean that there is no efficient way to implement this query. > >>But no one has described one yet. > > > > > >Let me try: > > > >All networks that satisfy the following criteria: > > > > ( start(network) >= start(query)) AND ( end(network)) >= end(query) ) > > OR > > ( start(query) >= start(network)) AND ( end(query)) >= end(network) ) > > > >If we take the union of the above networks, all less specifics, and > >all more specifics, then we will need to delete the ones that are > >not exposed looking from the bottom up. That last bit I'm not sure > >how to do right now :) > > I may be misunderstanding your notation, but wouldn't your query terms > return networks that have nothing to do with your query? That is (to > take the first term) if a result network's start address is greater than > your query start address, is also may be greater than your query end > address, and thus be utterly irrelevant to your query. > > Actually, I think that your query returns every network that isn't a > more specific network than the query, which is a bit much. Oops, right. The above criteria was supposed to find the overlapping networks. It is missing two expressions. It should have been this: ( start(network) >= start(query)) AND ( end(network)) >= end(query) AND (end(query) >= start(network) ) OR ( start(query) >= start(network)) AND ( end(query)) >= end(network) AND (end(network) >= start(query) ) > I think what you are getting at is to first assemble all the networks > that are less specific, more specific and overlap the query range. > (Basically all networks that contains any of the IP address in the query > range). A possibly more compact way to get this is to union the results > of: Q(all-less-specific, qstart), Q(all-less-specific, qend), > Q(all-more-specific, qstart -> qend). Yes, I think this would be more compact. Although it contains more than only the overlapping networks(*), I would get a union of these with Q(all-less-specific, qstart -> qend) and Q(all-more-specific, qstart -> qend) so the end result would be the same. > (Note that the all of the results returned by Q(all-less-specific, > qstart -> qend) will be included in the above union, as those networks > are the ones in the results of both of the two all-less-specific queries). Right. -engin (*)What I mean with overlapping is this: Network |---------------------------| Query |---------------------------| But NOT Network |---------------------------| Query |------| NOR Network |---------------------------| Query |--------------------------------| > The hard part is seeing how to efficiently winnow down this list into > the correct subset. Tim's description is essentially a paper > description, and I haven't figured out how to do this computationally. > Ideally it should be at least O(n) + O(nlog(n)) (n being the number of > results). > > -- > David Blacka > Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 15 16:14:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08189 for ; Fri, 15 Oct 2004 16:14:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYel-00017C-NQ for crisp-web-archive@ietf.org; Fri, 15 Oct 2004 16:26:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIYHf-0000ld-8y; Fri, 15 Oct 2004 16:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIY0M-0006i0-4X for crisp@megatron.ietf.org; Fri, 15 Oct 2004 15:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03448 for ; Fri, 15 Oct 2004 15:44:43 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIYBc-0007r4-Ab for crisp@ietf.org; Fri, 15 Oct 2004 15:56:34 -0400 Received: from [10.131.244.218] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 15 Oct 2004 15:44:28 -0400 id 001AB692.4170289D.0000211C Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.131.244.218]; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:216.168.239.87; remotehost=; helo=[10.131.244.218]; receiver=zak.ecotroph.net; Mime-Version: 1.0 In-Reply-To: <20041015121338.GE16659@x47.ripe.net> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> Message-Id: <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> From: Andrew Newton Subject: Re: [Crisp] Nesting queries redux Date: Fri, 15 Oct 2004 15:44:26 -0400 To: crisp@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0908219326==" Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0908219326== Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="=_zak.ecotroph.net-8476-1097869471-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zak.ecotroph.net-8476-1097869471-0001-2 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit First, thanks to Shane, Engin, David, and Tim for working through this problem. I think we are almost there with AREG. However, this discussion of how to implement the LLA query has made me start thinking about the use case for it. Specifically, the description of looking at every /32 or /128 made me think about how a network administrator gathers the input for such a query. In San Diego we discussed the need for this query, but I don't think the use case for it was ever defined. Having spent last weekend grepping through my logs to eliminate some blog-referer-spam, I must admit that it never once occurred to me to issue a query on a range of IP addresses even though there were clearly ranges in the data. I certainly issued the equivalent of the one-level less specific on a single /32. Furthermore, I think there may actually be a downside to this query we have not understood. Let's say that I pluck two IPs from my logs - one that is in network A and one that is in network C. If I perform this query, I may end up with network B in the result set even though I never once saw anything from that network space in my logs. In short, I think there is a danger of assuming that all LLA space is responsible just because a network falls in between two other networks from which I've defined my lower and upper bounds. Do I have a fundamental misunderstanding of the need for this query? -andy --=_zak.ecotroph.net-8476-1097869471-0001-2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgTCCAzow ggKjoAMCAQICAw05ITANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQxMDEzMjA1ODM1WhcNMDUxMDEzMjA1ODM1WjB7MQ8wDQYDVQQE EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEGCSqG SIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQxGjAYBgkqhkiG9w0BCQEWC2FuZHlAaHhyLnVz MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0XTscSF9lNVyNyq7wCFwEb56C7WBLvAh BaPqdV8oOr5EroTgv+0zUfaP8kYlwavWeSu0XcWIcgd/ymt7PWOd8j/J91Y71cmsSg62gv6dhA8h wzxojj5Vp2x3TYf7dafzoVfhd/7Kzvzu6FqOn9C/9NKtZ0g0hzn6ChcgymCrcoyXQrmQI689sh4o RzIQC+kSPaWkOmA0eqbCpi8ASQfuyEBiXQAATxrBWURp+hzD8YYcnn88S/5Kd4GGMARtwsBR6Moe xF53oAUavRPfiM3ixDunUqgXOQ92noBoc3nIWmxGuLdTZPZgELHX1Q1FMi013PW3tIA9rhZATcIf PF/jOQIDAQABo2EwXzAOBgNVHQ8BAf8EBAMCB4AwEQYJYIZIAYb4QgEBBAQDAgWgMCwGA1UdEQQl MCOBFGFuZXd0b25AZWNvdHJvcGgubmV0gQthbmR5QGh4ci51czAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAJiErfGNCI9wRF0H8NmkSJCjzaH3yHfv0q1CwyJr6zZhkA2M+GcCoIr12PNP J10XG3WJ/96bLP2SxzFz1FC6CfMN2/XrOn1Su5wRdVBAr7lRkyqco9A7JXaW8rUwOm6DQ20eWZen FJMo/mwzDxgThS9Oyci/ASNT4ej+Yzcyq5kpMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBU b3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSsw KQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAw MFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7s vc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGR MBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUu Y29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCk HjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oL LswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoL gnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT HUb/XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMNOSEwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDQxMDE1MTk0NDI3WjAjBgkqhkiG9w0BCQQxFgQUM1xH31982pEHvp9Vm9iC LXQHfm4weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElz c3VpbmcgQ0ECAw05ITB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAgMNOSEwDQYJKoZIhvcNAQEBBQAEggEABJ6SpbBmngHJ3JwwTqlU dcU2SAFVYqT8wqtUN5pKgjQCulZQbbgbffDew+OSxgkVXexghLzz980jradbOxSqNk/Nxpc+P+HC /AL2gS9i5VUIR4vPyOXdXWZN6TEXxqA8T2r0q4509Iu7O37bfe78q8/OHROavl7KaAGWY+QDnFpW ofMiFZXswvA856BnEkOlf1WAOu8FCOQlUR5ID+Rs2vX+N/85rJC+VXwVNNyu1W6ZA+dxar9mBY+O obhEYOvbMWWLZ7eFOLOGDzS/bm9FgogIz6urOWMxtNss8U9E/uFdsAkluYkt/isUSXO47TK5Tstn vcQvgH5+OzzwY7wtHQAAAAAAAA== --=_zak.ecotroph.net-8476-1097869471-0001-2-- --===============0908219326== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp --===============0908219326==-- From crisp-bounces@ietf.org Mon Oct 18 06:54:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04919 for ; Mon, 18 Oct 2004 06:54:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJVLb-0005Td-NU for crisp-web-archive@ietf.org; Mon, 18 Oct 2004 07:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJV6i-0000Rl-N7; Mon, 18 Oct 2004 06:51:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJV1m-00006U-88 for crisp@megatron.ietf.org; Mon, 18 Oct 2004 06:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04560 for ; Mon, 18 Oct 2004 06:46:07 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJVDk-0005K4-LS for crisp@ietf.org; Mon, 18 Oct 2004 06:58:33 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id C674455F0E; Mon, 18 Oct 2004 12:45:22 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 25FDC4E3FD; Mon, 18 Oct 2004 12:45:22 +0200 (CEST) Received: from ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9IAjMx1024015; Mon, 18 Oct 2004 12:45:22 +0200 Message-ID: <41739EC1.3000405@ripe.net> Date: Mon, 18 Oct 2004 12:45:21 +0200 From: Shane Kerr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, nl MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> In-Reply-To: <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.001666 / 0.0 / 0.0 / disabled X-RIPE-Signature: 05dd58cdcc8ebcbc444f90671ed52b3d X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Andrew Newton wrote: > > Having spent last weekend grepping through my logs to eliminate some > blog-referer-spam, I must admit that it never once occurred to me to > issue a query on a range of IP addresses even though there were clearly > ranges in the data. I certainly issued the equivalent of the one-level > less specific on a single /32. > > Furthermore, I think there may actually be a downside to this query we > have not understood. Let's say that I pluck two IPs from my logs - one > that is in network A and one that is in network C. If I perform this > query, I may end up with network B in the result set even though I never > once saw anything from that network space in my logs. In short, I think > there is a danger of assuming that all LLA space is responsible just > because a network falls in between two other networks from which I've > defined my lower and upper bounds. > > Do I have a fundamental misunderstanding of the need for this query? I don't think so. To me it seems like the sort of thing that you would want to do, but since no user has asked for it (AFAIK) perhaps it isn't really needed. :) I agree with the basic premise - trying to make it easier for people to find information about abusers - but I think that ultimately for users to track down abusers: 1. they need to understand the relationship between the various ranges 2. they need to know the organisations that use the space they respresent Maybe we should look at the use case that this LLA really represents: I have a list of IP addresses and I want to find out information about these addresses. Maybe what we really want is to modify the query to allow a multiple entries, and allow the server to return the smallest set results that match all of these. Having this query would result in less network traffic than the LLA, as clients wouldn't have to get network details that they don't really care about (but can't know they don't care about until the query is done). -- Shane Kerr RIPE NCC _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 21 12:40:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21089 for ; Thu, 21 Oct 2004 12:40:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgCG-0007kS-Gl for crisp-web-archive@ietf.org; Thu, 21 Oct 2004 12:53:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKflO-0000XE-QG; Thu, 21 Oct 2004 12:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKfaw-0002lM-CS for crisp@megatron.ietf.org; Thu, 21 Oct 2004 12:15:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18327 for ; Thu, 21 Oct 2004 12:15:15 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKfna-00075u-J9 for crisp@ietf.org; Thu, 21 Oct 2004 12:28:22 -0400 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 21 Oct 2004 12:14:47 -0400 id 00420115.4177E077.000064B8 Message-ID: <4177E068.30309@verisignlabs.com> Date: Thu, 21 Oct 2004 12:14:32 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: crisp@ietf.org Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> <41739EC1.3000405@ripe.net> In-Reply-To: <41739EC1.3000405@ripe.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Shane Kerr wrote: > Andrew Newton wrote: > >> >> Having spent last weekend grepping through my logs to eliminate some >> blog-referer-spam, I must admit that it never once occurred to me to >> issue a query on a range of IP addresses even though there were >> clearly ranges in the data. I certainly issued the equivalent of the >> one-level less specific on a single /32. >> >> Furthermore, I think there may actually be a downside to this query we >> have not understood. Let's say that I pluck two IPs from my logs - >> one that is in network A and one that is in network C. If I perform >> this query, I may end up with network B in the result set even though >> I never once saw anything from that network space in my logs. In >> short, I think there is a danger of assuming that all LLA space is >> responsible just because a network falls in between two other networks >> from which I've defined my lower and upper bounds. >> >> Do I have a fundamental misunderstanding of the need for this query? > > > I don't think so. To me it seems like the sort of thing that you would > want to do, but since no user has asked for it (AFAIK) perhaps it isn't > really needed. :) I think that the point raised in SD was something like: No user has asked for it maybe because no user has realized that it was possible or that they *could* ask for it. It very well may be that by making this query possible, we change the way your users work in a positive way. A more pertinent question is probably: does this query work better for the given use case that what we have now with WHOIS? > I agree with the basic premise - trying to make it easier for people to > find information about abusers - but I think that ultimately for users > to track down abusers: > > 1. they need to understand the relationship between the various ranges > 2. they need to know the organisations that use the space they respresent > > Maybe we should look at the use case that this LLA really represents: I > have a list of IP addresses and I want to find out information about > these addresses. At some point, I realized that I was willing to believe any of the following: 1. The LLA query (or something close to it) is great, and although no user is asking for it now, it will be a big time saver for some use cases. 2. Now that we understand that getting "all" relevant networks is doable, that is good enough. 3. The LLA query is not really useful as folks are always dealing with individual IP addresses. After thinking about this some more, I will have to admit that the "researching abuse" use case seems to start with individual IP addresses rather than IP address ranges. That is, any range that a user would submit is a guess. > Maybe what we really want is to modify the query > to allow a multiple entries, and allow the server to > return the smallest set results that match all of these. So, essentially, the server would union the results of all of the "one-level-less-specific" queries for each IP address, right? > Having this query would result in less network traffic than the LLA, as > clients wouldn't have to get network details that they don't really care > about (but can't know they don't care about until the query is done). I guess I'm not sure how this query (which I think gets to the heart of this pariticular use-case) is really worth it? You can, if you are worried about round-trip times, submit more than one query per request. -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 21 14:38:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04272 for ; Thu, 21 Oct 2004 14:38:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi2K-0002u1-Os for crisp-web-archive@ietf.org; Thu, 21 Oct 2004 14:51:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhkQ-0003zE-5U; Thu, 21 Oct 2004 14:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhSg-0004Ud-EI for crisp@megatron.ietf.org; Thu, 21 Oct 2004 14:14:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01283 for ; Thu, 21 Oct 2004 14:14:51 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhfJ-000223-Eg for crisp@ietf.org; Thu, 21 Oct 2004 14:27:59 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 92D164E4C2; Thu, 21 Oct 2004 20:14:19 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 3ED2D4E355; Thu, 21 Oct 2004 20:14:19 +0200 (CEST) Received: from ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9LIEJx1001975; Thu, 21 Oct 2004 20:14:19 +0200 Message-ID: <4177FC7A.2010000@ripe.net> Date: Thu, 21 Oct 2004 20:14:18 +0200 From: Shane Kerr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, nl MIME-Version: 1.0 To: David Blacka Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> <41739EC1.3000405@ripe.net> <4177E068.30309@verisignlabs.com> In-Reply-To: <4177E068.30309@verisignlabs.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000000 / 0.0 / 0.0 / disabled X-RIPE-Signature: 9757d988947e50caa227c6264cdb7aee X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit David Blacka wrote: > Shane Kerr wrote: >> Maybe what we really want is to modify the >> query to allow a multiple entries, and allow the >> server to return the smallest set results that match >> all of these. > > > So, essentially, the server would union the results of all of the > "one-level-less-specific" queries for each IP address, right? Well, for whatever specificity was requested. But it only make sense in the context of one-level-less-specific or all-level-less-specific. >> Having this query would result in less network traffic than the LLA, >> as clients wouldn't have to get network details that they don't really >> care about (but can't know they don't care about until the query is >> done). > > > I guess I'm not sure how this query (which I think gets to the heart of > this pariticular use-case) is really worth it? You can, if you are > worried about round-trip times, submit more than one query per request. If you have a list of IP addresses you want to know about: 192.0.2.13 192.0.2.40 192.0.2.200 And these yield a number of networks less than the number of queries: 192.0.2.0/26 192.0.2.128/25 Then you've saved having to execute 192.0.2.40 at all, or at least having to have an answer for it in the request. (I am assuming that 1 query yields 1 answer - I may be wrong here.) -- Shane Kerr RIPE NCC _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Thu Oct 21 14:59:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06168 for ; Thu, 21 Oct 2004 14:59:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiM9-0003SE-Dh for crisp-web-archive@ietf.org; Thu, 21 Oct 2004 15:12:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmw-0005ev-JM; Thu, 21 Oct 2004 14:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhjQ-0003OT-KZ for crisp@megatron.ietf.org; Thu, 21 Oct 2004 14:32:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03142 for ; Thu, 21 Oct 2004 14:32:10 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhw4-0002aB-NU for crisp@ietf.org; Thu, 21 Oct 2004 14:45:18 -0400 Received: from [10.131.244.227] ([::ffff:172.25.170.10]) (AUTH: PLAIN davidb, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.verisignlabs.com with esmtp; Thu, 21 Oct 2004 14:31:39 -0400 id 004201A0.4178008B.00007961 Message-ID: <4178007C.4090800@verisignlabs.com> Date: Thu, 21 Oct 2004 14:31:24 -0400 From: David Blacka Organization: VeriSign, Inc. User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shane Kerr Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> <41739EC1.3000405@ripe.net> <4177E068.30309@verisignlabs.com> <4177FC7A.2010000@ripe.net> In-Reply-To: <4177FC7A.2010000@ripe.net> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Shane Kerr wrote: > David Blacka wrote: > >> Shane Kerr wrote: > > > > >>> Maybe what we really want is to modify the >>> query to allow a multiple entries, and allow the >>> server to return the smallest set results that match >>> all of these. >> >> >> >> So, essentially, the server would union the results of all of the >> "one-level-less-specific" queries for each IP address, right? > > > Well, for whatever specificity was requested. But it only make sense in > the context of one-level-less-specific or all-level-less-specific. Hmm. >>> Having this query would result in less network traffic than the LLA, >>> as clients wouldn't have to get network details that they don't >>> really care about (but can't know they don't care about until the >>> query is done). >> >> >> >> I guess I'm not sure how this query (which I think gets to the heart >> of this pariticular use-case) is really worth it? You can, if you are >> worried about round-trip times, submit more than one query per request. > > > If you have a list of IP addresses you want to know about: > > 192.0.2.13 > 192.0.2.40 > 192.0.2.200 > > And these yield a number of networks less than the number of queries: > > 192.0.2.0/26 > 192.0.2.128/25 > > Then you've saved having to execute 192.0.2.40 at all, or at least > having to have an answer for it in the request. I can see how doing the union on the server may save the duplicates from going out on the network. Of course, a human issuing one query at a time would also save this network traffic (although at the expense of more roundtrip overhead). I guess I'm struggling with the balance between this query's utility and the additional code and spec complexity it generates. If, for instance, it was noticably more efficient (not counting network resources) to do the search for mulitple IPs rather than handling separate queries, then it makes more sense go this route. However, you might not wish to go down this route if the goal is to try to get everyone to use UDP for this sort of case. > (I am assuming that 1 query yields 1 answer - I may be wrong here.) One query query returns one answer, but that answer could contain more than one result object, if you get my drift. -- David Blacka Sr. Engineer VeriSign Applied Research _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 22 00:52:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13490 for ; Fri, 22 Oct 2004 00:52:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrcB-0005hU-Po for crisp-web-archive@ietf.org; Fri, 22 Oct 2004 01:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKrIb-0005Sj-B5; Fri, 22 Oct 2004 00:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKrCb-0002Fk-Cn for crisp@megatron.ietf.org; Fri, 22 Oct 2004 00:38:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11796 for ; Fri, 22 Oct 2004 00:38:52 -0400 (EDT) Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrPB-0005Q9-8u for crisp@ietf.org; Fri, 22 Oct 2004 00:52:07 -0400 Received: from [10.134.194.194] ([::ffff:80.187.145.120]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 22 Oct 2004 00:38:41 -0400 id 001AB2AE.41788ED2.00001121 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=[10.134.194.194]; remoteip=::ffff:80.187.145.120; remotehost=; helo=[10.134.194.194]; receiver=zak.ecotroph.net; Received-SPF: fail (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=andy@hxr.us; remoteip=::ffff:80.187.145.120; remotehost=; helo=[10.134.194.194]; receiver=zak.ecotroph.net; In-Reply-To: <4177E068.30309@verisignlabs.com> References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> <41739EC1.3000405@ripe.net> <4177E068.30309@verisignlabs.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F8CD76E-23E4-11D9-AC51-000A95B3BA44@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Crisp] Nesting queries redux Date: Fri, 22 Oct 2004 00:38:40 -0400 To: David Blacka X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Oct 21, 2004, at 12:14 PM, David Blacka wrote: > You can, if you are worried about round-trip times, submit more than > one query per request. And this was my first thought when I read Shane's message. An IRIS client can submit multiple search sets in one pass. However, if we believe this will be a common use case, then I think I favor allowing it in AREG specifically for the purposes of passing fewer angle brackets and perhaps the ability of more efficient code paths. -andy _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 22 11:44:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15078 for ; Fri, 22 Oct 2004 11:44:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1n7-0000ks-VE for crisp-web-archive@ietf.org; Fri, 22 Oct 2004 11:57:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1Z7-0003gX-18; Fri, 22 Oct 2004 11:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1SY-0002V0-6C for crisp@megatron.ietf.org; Fri, 22 Oct 2004 11:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14498 for ; Fri, 22 Oct 2004 11:36:02 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1fL-0000aP-9i for crisp@ietf.org; Fri, 22 Oct 2004 11:49:20 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id 773B551DEB; Fri, 22 Oct 2004 17:35:31 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 223E851DEA; Fri, 22 Oct 2004 17:35:31 +0200 (CEST) Received: from ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9MFZVx1017200; Fri, 22 Oct 2004 17:35:31 +0200 Message-ID: <417928C2.9090609@ripe.net> Date: Fri, 22 Oct 2004 17:35:30 +0200 From: Shane Kerr User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, nl MIME-Version: 1.0 To: David Blacka Subject: Re: [Crisp] Nesting queries redux References: <6.1.0.6.0.20041005070615.01be8ec0@192.149.252.131> <416D68E0.9010106@verisignlabs.com> <20041014154041.GM22821@x47.ripe.net> <416EABC7.5040306@verisignlabs.com> <20041015121338.GE16659@x47.ripe.net> <9F5AB6BA-1EE2-11D9-B4A0-000A95B3BA44@hxr.us> <41739EC1.3000405@ripe.net> <4177E068.30309@verisignlabs.com> <4177FC7A.2010000@ripe.net> <4178007C.4090800@verisignlabs.com> In-Reply-To: <4178007C.4090800@verisignlabs.com> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Status: N 0.000004 / 0.0 / 0.0 / disabled X-RIPE-Signature: 3a86f125202c30105f29d6933b2ad0d1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: crisp@ietf.org X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit David Blacka wrote: > If, for instance, it was noticably more efficient (not counting network > resources) to do the search for mulitple IPs rather than handling > separate queries, then it makes more sense go this route. I guess it's about where the efficiency lies. A client can cache the server replies. In my example, with these IPs: 192.0.2.13 192.0.2.40 192.0.2.200 And these networks: 192.0.2.0/26 192.0.2.128/25 A client that operated like this: foreach IP in IP_LIST: if not (IP in NETWORKS_FOUND): NETWORK = iris_lookup(IP) NETWORKS_FOUND.append(NETWORK) endif endfor Then you'd see: iris_lookup(192.0.2.13) iris_lookup(192.0.2.128) On the wire, just using basic queries. A client that operated like this: NETWORKS_FOUND = iris_lookup(IP_LIST) Would not really save much (any?) traffic in terms of bytes, but of course it's an extra TCP setup/teardown that gets eliminated. In the UDP case for 3 IP's it doesn't make sense, but if we're talking a few hundred, all of a sudden things get a little bit interesting. I'll do some voodoo on our log files to try to see if there is any efficiency gain in the type of queries we see. > However, you might not wish to go down this route if the goal is to try > to get everyone to use UDP for this sort of case. In the case where users want information about a single IP, UDP makes sense. If users want information about a set of IP addresses, then TCP makes sense. It's almost like providing the right tool for the job. ;) -- Shane Kerr RIPE NCC _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 22 16:30:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09388 for ; Fri, 22 Oct 2004 16:30:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6Gi-0006nI-2H for crisp-web-archive@ietf.org; Fri, 22 Oct 2004 16:44:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5ig-0007G5-7k; Fri, 22 Oct 2004 16:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5cv-0003dS-06; Fri, 22 Oct 2004 16:03:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05414; Fri, 22 Oct 2004 16:03:01 -0400 (EDT) Message-Id: <200410222003.QAA05414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 22 Oct 2004 16:03:01 -0400 Cc: crisp@ietf.org Subject: [Crisp] I-D ACTION:draft-ietf-crisp-iris-areg-08.txt X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart 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 : IRIS - An Address Registry (areg) Type for the Internet Registry Information Service Author(s) : A. Newton, et al. Filename : draft-ietf-crisp-iris-areg-08.txt Pages : 63 Date : 2004-10-22 This document describes an IRIS registry schema for IP address and Autonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by Internet Protocol address registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-iris-areg-08.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-iris-areg-08.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22161740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-crisp-iris-areg-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-crisp-iris-areg-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22161740.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp --NextPart-- From crisp-bounces@ietf.org Tue Oct 26 06:03:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18338 for ; Tue, 26 Oct 2004 06:03:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMOOq-0007Zc-JZ for crisp-web-archive@ietf.org; Tue, 26 Oct 2004 06:17:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMOA6-0006oi-Da; Tue, 26 Oct 2004 06:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMO7T-0006S8-0T for crisp@megatron.ietf.org; Tue, 26 Oct 2004 05:59:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18115 for ; Tue, 26 Oct 2004 05:59:56 -0400 (EDT) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMOL6-0007WA-M7 for crisp@ietf.org; Tue, 26 Oct 2004 06:14:05 -0400 Received: by postman.ripe.net (Postfix, from userid 8) id A2CBE4EC0E; Tue, 26 Oct 2004 11:59:21 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 5B7DE4E004 for ; Tue, 26 Oct 2004 11:59:21 +0200 (CEST) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.12.10/8.11.6) with ESMTP id i9Q9xLx1015099 for ; Tue, 26 Oct 2004 11:59:21 +0200 Received: (from engin@localhost) by x47.ripe.net (8.12.10/8.12.6) id i9Q9xLwE020092 for crisp@ietf.org; Tue, 26 Oct 2004 11:59:21 +0200 Date: Tue, 26 Oct 2004 11:59:21 +0200 From: Engin Gunduz To: crisp@ietf.org Subject: Re: [Crisp] I-D ACTION:draft-ietf-crisp-iris-areg-08.txt Message-ID: <20041026095921.GG15717@x47.ripe.net> References: <200410222003.QAA05414@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline In-Reply-To: <200410222003.QAA05414@ietf.org> User-Agent: Mutt/1.4.2.1i X-RIPE-Spam-Status: N 0.000184 / 0.0 / 0.0 / disabled X-RIPE-Signature: 429252b478b77c57a5fbdeed794f2bef X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi all, Here are the diff between 07 and 08 versions: - search added - split references into normative and informative references - Examples added for specificity as an appendix - fixes in example requests and responses section - fixes in formal XML I have not included Tim's query yet, as the consensus hasn't been reached yet... -engin On 2004-10-22 16:03:01 -0400, Internet-Drafts@ietf.org wrote: > 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 : IRIS - An Address Registry (areg) Type for the Internet > Registry Information Service > Author(s) : A. Newton, et al. > Filename : draft-ietf-crisp-iris-areg-08.txt > Pages : 63 > Date : 2004-10-22 > > This document describes an IRIS registry schema for IP address and > Autonomous System Number information. The schema extends the > necessary query and result operations of IRIS to provide the > functional information service needs for syntaxes and results used by > Internet Protocol address registries. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-08.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-iris-areg-08.txt". > [...] _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp From crisp-bounces@ietf.org Fri Oct 29 13:26:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17336 for ; Fri, 29 Oct 2004 13:26:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNakX-0003yU-5n for crisp-web-archive@ietf.org; Fri, 29 Oct 2004 13:41:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaHL-0007j4-5l; Fri, 29 Oct 2004 13:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNa5S-0001Hr-3G for crisp@megatron.ietf.org; Fri, 29 Oct 2004 12:58:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15447 for ; Fri, 29 Oct 2004 12:58:46 -0400 (EDT) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaJk-0003PE-SX for crisp@ietf.org; Fri, 29 Oct 2004 13:13:37 -0400 Received: by shell-ng.nominum.com (Postfix, from userid 10182) id 6131056838; Fri, 29 Oct 2004 09:58:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by shell-ng.nominum.com (Postfix) with ESMTP id 5FCB756835; Fri, 29 Oct 2004 09:58:09 -0700 (PDT) (envelope-from amarine@nominum.com) Date: Fri, 29 Oct 2004 09:58:09 -0700 (PDT) From: April Marine To: CRISP WG Message-ID: <20041029095652.S14963@shell-ng.nominum.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: April Marine , Ted Hardie , George Michaelson Subject: [Crisp] agenda for WDC X-BeenThere: crisp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Cross Registry Information Service Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: crisp-bounces@ietf.org Errors-To: crisp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a It occurs to us that we should have an agenda. How is this? Agenda for CRISP Working Group Meeting IETF 61 - Washington, DC Tuesday, November 9, 14:15 - 15:15 o Welcome, Agenda Bashing, Status Update Chairs - 5 min o Status of draft-ietf-crisp-iris-areg-08.txt Shane Kerr, Engin Gunduz - 30 min o Status of draft-newton-crisp-iris-dchk-00.txt which has morphed into: draft-ietf-crisp-iris-dchk-01.txt draft-ietf-crisp-iris-lwz-00.txt Andy Newton - 20 mins o Other topics (if any arise) _______________________________________________ Crisp mailing list Crisp@ietf.org https://www1.ietf.org/mailman/listinfo/crisp