From hardie at qualcomm.com Mon May 5 13:46:09 2003 From: hardie at qualcomm.com (Ted Hardie) Date: Mon May 5 15:46:17 2003 Subject: [Ietf-not43] Comments? Message-ID: <382FB3C8-7F32-11D7-BBE9-000393CB0816@qualcomm.com> Howdy folks, I haven't seen any comments on Andy's posting of the proposed new text last week. Rather than refresh the working group last call (since we never really left the last one), I'd like to ask folks to get comments to the list by the end of this week (May 9th). If there are comments, we can, of course, extend discussion. regards, Ted Hardie From ehall at ehsco.com Thu May 8 16:00:27 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu May 8 16:00:33 2003 Subject: [Ietf-not43] name the baby Message-ID: <3EBAB75B.60709@ehsco.com> I've added some more meat to the ldap-whois spec and am reworking the docset to accomodate these (and other) changes. Since I don't want to do this again, I'm looking to come up with a friendly name for the spec. Although I've been using ldap-whois publically for a while, that's too much of a mouthful for long-term use. I've also been using 'the Internet Resource Query Service' privately for a while, but the acronym sounds like 'irks' which is kind of defeatist. Same with Common Resource Access Protocol, and others. Anybody got a friendly/memorable name and acronym which reflects ameneably upon a federated lookup and query service for global resources? -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Peter.Gietz at daasi.de Fri May 9 15:27:45 2003 From: Peter.Gietz at daasi.de (Peter Gietz) Date: Fri May 9 08:27:59 2003 Subject: [Ietf-not43] name the baby In-Reply-To: <3EBAB75B.60709@ehsco.com> References: <3EBAB75B.60709@ehsco.com> Message-ID: <3EBB9EC1.60505@daasi.de> What about LIRAP for LDAP based Internet Resource Access Protocol? Just my two cent. Cheers, Peter Eric A. Hall wrote: > I've added some more meat to the ldap-whois spec and am reworking the > docset to accomodate these (and other) changes. Since I don't want to do > this again, I'm looking to come up with a friendly name for the spec. > Although I've been using ldap-whois publically for a while, that's too > much of a mouthful for long-term use. I've also been using 'the Internet > Resource Query Service' privately for a while, but the acronym sounds like > 'irks' which is kind of defeatist. Same with Common Resource Access > Protocol, and others. > > Anybody got a friendly/memorable name and acronym which reflects ameneably > upon a federated lookup and query service for global resources? > -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 T?bingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From william at elan.net Fri May 9 03:48:26 2003 From: william at elan.net (william@elan.net) Date: Fri May 9 08:35:05 2003 Subject: [Ietf-not43] name the baby In-Reply-To: <3EBB9EC1.60505@daasi.de> Message-ID: Actually how about just "WRAP" - whois resource access protocol or less fitting, but better sounding "WARP" - whois access resource protocol On Fri, 9 May 2003, Peter Gietz wrote: > What about LIRAP for LDAP based Internet Resource Access Protocol? > > Just my two cent. > > Cheers, > > Peter > > Eric A. Hall wrote: > > I've added some more meat to the ldap-whois spec and am reworking the > > docset to accomodate these (and other) changes. Since I don't want to do > > this again, I'm looking to come up with a friendly name for the spec. > > Although I've been using ldap-whois publically for a while, that's too > > much of a mouthful for long-term use. I've also been using 'the Internet > > Resource Query Service' privately for a while, but the acronym sounds like > > 'irks' which is kind of defeatist. Same with Common Resource Access > > Protocol, and others. > > > > Anybody got a friendly/memorable name and acronym which reflects ameneably > > upon a federated lookup and query service for global resources? From cathym at arin.net Fri May 9 11:49:56 2003 From: cathym at arin.net (Cathy Murphy) Date: Fri May 9 10:50:01 2003 Subject: [Ietf-not43] comments on requirements In-Reply-To: <3EAD82C5.1080408@ecotroph.net> Message-ID: Andy, The changes look pretty good. Thanks for incorporating some of our suggestions. -Cathy From April.Marine at nominum.com Fri May 9 09:20:46 2003 From: April.Marine at nominum.com (April Marine) Date: Fri May 9 11:20:49 2003 Subject: [Ietf-not43] Comments? In-Reply-To: <382FB3C8-7F32-11D7-BBE9-000393CB0816@qualcomm.com> Message-ID: <20030509082025.O98925-100000@shell.nominum.com> Remember--today is last day for comments! Thanks to those who have already taken a look at the latest revision. A. On Mon, 5 May 2003, Ted Hardie wrote: > Howdy folks, > I haven't seen any comments on Andy's posting of > the proposed new text last week. Rather than refresh the > working group last call (since we never really left the last one), > I'd like to ask folks to get comments to the list by the end of this > week (May 9th). If there are comments, we can, of course, > extend discussion. > regards, > Ted Hardie > > _______________________________________________ > Ietf-not43 mailing list > Ietf-not43@lists.verisignlabs.com > https://lists.verisignlabs.com/mailman/listinfo/ietf-not43 > From ehall at ehsco.com Fri May 9 13:51:59 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Fri May 9 13:52:05 2003 Subject: [Ietf-not43] name the baby In-Reply-To: References: Message-ID: <3EBBEABF.50906@ehsco.com> Federated Registry Access Protocol = FRAP ... gesticulation = FRAG Federated Resource Information Service = FRIS ? on 5/9/2003 4:48 AM william@elan.net wrote: > Actually how about just "WRAP" - whois resource access protocol or less > fitting, but better sounding "WARP" - whois access resource protocol > > On Fri, 9 May 2003, Peter Gietz wrote: > > >> What about LIRAP for LDAP based Internet Resource Access Protocol? >> >> Just my two cent. >> >> Cheers, >> >> Peter >> >> Eric A. Hall wrote: >> >>> I've added some more meat to the ldap-whois spec and am reworking >>> the docset to accomodate these (and other) changes. Since I don't >>> want to do this again, I'm looking to come up with a friendly name >>> for the spec. Although I've been using ldap-whois publically for a >>> while, that's too much of a mouthful for long-term use. I've also >>> been using 'the Internet Resource Query Service' privately for a >>> while, but the acronym sounds like 'irks' which is kind of >>> defeatist. Same with Common Resource Access Protocol, and others. >>> >>> Anybody got a friendly/memorable name and acronym which reflects >>> ameneably upon a federated lookup and query service for global >>> resources? > > -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Fri May 9 15:17:09 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Fri May 9 14:02:44 2003 Subject: [Ietf-not43] name the baby In-Reply-To: <3EBBEABF.50906@ehsco.com> References: <3EBBEABF.50906@ehsco.com> Message-ID: <3EBBF0A5.5080403@ecotroph.net> Eric A. Hall wrote: > > Federated Resource Information Service = FRIS Federated Resource Information Service for LDAP - FRISL, but pronounced as frizzle. -andy From edmon at neteka.com Fri May 9 16:06:19 2003 From: edmon at neteka.com (Edmon Chung) Date: Fri May 9 15:10:40 2003 Subject: [Ietf-not43] name the baby References: <3EBAB75B.60709@ehsco.com> <3EBB9EC1.60505@daasi.de> Message-ID: <007f01c3165e$3148d720$0f01a8c0@neteka.inc> > What about LIRAP for LDAP based Internet Resource Access Protocol? How about just LRAP. Edmon From ehall at ehsco.com Sat May 10 11:11:47 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Sat May 10 11:11:53 2003 Subject: [Ietf-not43] changes to ldap-whois Message-ID: <3EBD16B3.6050404@ehsco.com> New drafts in the ldap-whois collection will be coming out over the next few days, but I wanted to give a heads-up on the changes. First and foremost, the specs have been extended to fully accommodate internationalized domain names as application data. Wherever possible, server operators will be required to normalize the domain names they store in their databases and clients will be required to normalize the domain names they generate from input, with the normalized forms being used for comparison operations. Wherever possible, the UTF-8 form is given preference, although there are a couple of problem areas in LDAP which prevent this from happening everywhere (specifically the domainComponent and mail attributes). This decision path is a result of analysis regarding the i18n and l10n issues in LDAP-WHOIS and IRIS (the root analysis is at http://www.ehsco.com/misc/i18n-crisp%5b3%5d.pdf if you are interested). Secondarily, I've defined a contact-lookup feature which takes an email address as input, with the client mapping this address to a fully-qualifed distinguished name (EG, mapping the input address of admins@example.com to cn=admins@example.com,cn=inetResources,dc=example,dc=com). This approach imposes namespace rules on entries, but only those entries which are to be publically accessible (these entries can also exist as referral sources which point to some other canonical entry). The third major change is the creation of a generic "resource record" object class which is subordinate to the domain name resource object class. This specifically solves the problem of finding nameservers associated with domains, while also allowing nameservers to be located with the existing domain lookup function, and also allows other kinds of resource record data to be stored in the directory. These entries can also exist as referral sources which point to other canonical entries. I've settled on Federated Internet Registry Service (FIRS) as the name. This conveys that the service is not just queries and lookups but that it is an entire application. Thanks for all the suggestions. Several other tweaks and mods are also being incorporated, but those are the major ones. Drafts will be coming over the next few days. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Internet-Drafts at ietf.org Tue May 13 08:58:59 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 13 08:02:05 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-requirements-05.txt Message-ID: <200305131158.HAA04991@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Cross Registry Internet Service Protocol (CRISP) Requirements Author(s) : A. Newton Filename : draft-ietf-crisp-requirements-05.txt Pages : 32 Date : 2003-5-12 Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-requirements-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-requirements-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-crisp-requirements-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:25:39 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:28:51 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-asn-00.txt Message-ID: <200305201125.HAA06016@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-asn-00.txt Pages : 12 Date : 2003-5-19 This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-asn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-asn-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-firs-asn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:25:43 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:28:57 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-contact-00.txt Message-ID: <200305201125.HAA06035@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Contact Information in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-contact-00.txt Pages : 11 Date : 2003-5-19 This document defines LDAP schema and searching rules for contact persons, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-contact-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-contact-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-firs-contact-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:25:48 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:05 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dns-00.txt Message-ID: <200305201125.HAA06051@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating DNS Domains in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dns-00.txt Pages : 15 Date : 2003-5-19 This document defines LDAP schema and searching rules for DNS domain names, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dns-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-dns-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-firs-dns-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:25:52 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:08 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dnsrr-00.txt Message-ID: <200305201125.HAA06067@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating DNS Resource Records in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dnsrr-00.txt Pages : 8 Date : 2003-5-19 This document defines LDAP schema and searching rules for DNS resource records, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dnsrr-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-dnsrr-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-firs-dnsrr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:25:56 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:14 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv4-00.txt Message-ID: <200305201125.HAA06087@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv4-00.txt Pages : 14 Date : 2003-5-19 This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv4-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv4-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-firs-ipv4-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:26:01 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:18 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv6-00.txt Message-ID: <200305201126.HAA06103@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv6-00.txt Pages : 14 Date : 2003-5-19 This document defines LDAP schema and searching rules for IPv6 address blocks, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv6-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv6-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-firs-ipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:26:06 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:27 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-core-00.txt Message-ID: <200305201126.HAA06119@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service: Core Elements Author(s) : E. Hall Filename : draft-ietf-crisp-firs-core-00.txt Pages : 40 Date : 2003-5-19 This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-core-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-firs-core-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Tue May 20 08:26:11 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue May 20 07:29:31 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-arch-00.txt Message-ID: <200305201126.HAA06135@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service:Architecture and Implementation Guide Author(s) : E. Hall Filename : draft-ietf-crisp-firs-arch-00.txt Pages : 28 Date : 2003-5-19 This document describes the architectural framework for the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-arch-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-arch-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-firs-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------- next part -------------- Skipped content of type multipart/alternative From ehall at ehsco.com Wed May 21 17:32:26 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed May 21 17:32:32 2003 Subject: [Ietf-not43] crisp requirements matrix In-Reply-To: <3E81F517.7030209@ecotroph.net> References: <3E81F517.7030209@ecotroph.net> Message-ID: <3ECBF06A.80807@ehsco.com> Are we planning to get a new matrix for the -05 reqs? I'm wanting to do an analysis of FIRS' conformance. on 3/26/2003 12:44 PM Andrew Newton wrote: > Here is a first pass at the crisp requirements matrix. The entries are > based on the latest draft in the repository. Therefore, they will > change with the addition of the new text from the comments period and > the expected comments due in about 2 weeks. > > If you have comments on the format or structure of the matrix, please > send them to the list. It is provided in both HTML and ASCII text format. > > -andy -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From anewton at ecotroph.net Wed May 21 19:28:19 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Wed May 21 18:12:25 2003 Subject: [Ietf-not43] crisp requirements matrix In-Reply-To: <3ECBF06A.80807@ehsco.com> References: <3E81F517.7030209@ecotroph.net> <3ECBF06A.80807@ehsco.com> Message-ID: <3ECBFD83.5040801@ecotroph.net> Eric A. Hall wrote: > Are we planning to get a new matrix for the -05 reqs? I'm wanting to do an > analysis of FIRS' conformance. Yes. I will try to get that out later this week. I've just had other things to do. -andy From anewton at ecotroph.net Thu May 22 11:49:10 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu May 22 10:35:44 2003 Subject: [Ietf-not43] new requirements matrix Message-ID: <3ECCE366.2000900@ecotroph.net> I've attached the requirements matrix as I think it matches to the latest requirements. Of course, if somebody could double check that all the MUST/SHOULD language in the requirements draft is accounted for in the matrix, that'd be swell. For your viewing pleasure, both an ASCII text and HTML version are provided. -andy -------------- next part -------------- CRISP Technical Proposal Evaluation Matrix +------------------------------------------------------------------------+ | Requirement | IRIS | LW | Comment | |------------------------------------------------------------------------| | Sample | |------------------------------------------------------------------------| | The protocl MUST be capable of | NO | YES | IRIS only gives the | | walking and chewing gum at the | | | appearance of | | same time. | | | walking and chewing | | | | | gum simultaneously, | | | | | but it in fact | | | | | requires two | | | | | separate CPU clock | | | | | cycles. On the other | | | | | hand, LW does the | | | | | walking on the | | | | | rising edge of the | | | | | cycle and the gum | | | | | chewing on the | | | | | falling edge of the | | | | | cycle. | |------------------------------------------------------------------------| | Section 3.1.2 | |------------------------------------------------------------------------| | The protocol MUST NOT employ | | | | | unique technology solutions for | | | | | all aspects and layers above the | | | | | network and transport layers and | | | | | SHOULD make use of existing | | | | | technology standards where | | | | | applicable. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST employ the use | | | | | of network and transport layer | | | | | standards as defined by the | | | | | Internet Engineering Task Force. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST define one or | | | | | more transport mechanisms for | | | | | mandatory implementation. | | | | |------------------------------------------------------------------------| | Section 3.1.3.1 | |------------------------------------------------------------------------| | The protocol MUST contain standard | | | | | schemas for the exchange of data | | | | | needed to implement the | | | | | functionality in this document. | | | | |------------------------------------+------+-----+----------------------| | there MUST be a means to allow the | | | | | use of schemas not defined by the | | | | | needs of this document. | | | | |------------------------------------+------+-----+----------------------| | Both types of schemas MUST use the | | | | | same schema language. | | | | |------------------------------------+------+-----+----------------------| | The schemas MUST be able to | | | | | express data elements with | | | | | identifying tags for the purpose | | | | | of localization of the meaning of | | | | | the identifying tags. | | | | |------------------------------------------------------------------------| | Section 3.1.4.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit an | | | | | operator from granularly assigning | | | | | multiple types of access to data | | | | | according to the policies of the | | | | | operator. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST provide an | | | | | authentication mechanism and MUST | | | | | NOT prohibit an operator from | | | | | granting types of access based on | | | | | authentication. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST provide an | | | | | anonymous access mechanism that | | | | | may be turned on or off based on | | | | | the policy of an operator. | | | | |------------------------------------------------------------------------| | Section 3.1.5 | |------------------------------------------------------------------------| | The protocol MUST be capable of | | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.6 | |------------------------------------------------------------------------| | The protocol MUST be capable of | | | | | allowing machine parsable requests | | | | | and responses. | | | | |------------------------------------------------------------------------| | Section 3.1.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require the | | | | | aggregation of data to a central | | | | | repository, server, or entity. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT require | | | | | aggregation of data indexes or | | | | | hints to a central repository, | | | | | server, or entity. | | | | |------------------------------------------------------------------------| | Section 3.1.8.1 | |------------------------------------------------------------------------| | The protocol MUST provide a | | | | | mechanism allowing a client to | | | | | determine if a query will be | | | | | denied before the query is | | | | | submitted according to the | | | | | appropriate policies of the | | | | | operator. | | | | |------------------------------------------------------------------------| | Section 3.1.9.1 | |------------------------------------------------------------------------| | The protocol MUST NOT require any | | | | | Internet registry to participate | | | | | in any authentication system. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT prohibit the | | | | | participation by an Internet | | | | | registry in federated, distributed | | | | | authentication systems. | | | | |------------------------------------------------------------------------| | Section 3.1.10 | |------------------------------------------------------------------------| | The protocol MUST be capable of returning the following types of | | non-result or error responses to all lookups and searches: | |------------------------------------------------------------------------| | permission denied - a response | | | | | indicating that the search or | | | | | lookup has failed due to | | | | | insufficient authorization. | | | | |------------------------------------+------+-----+----------------------| | not found - the desired results do | | | | | not exist. | | | | |------------------------------------+------+-----+----------------------| | insufficient resources - the | | | | | search or lookup requires | | | | | resources that cannot be | | | | | allocated. | | | | |------------------------------------------------------------------------| | Section 3.1.11.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit a | | | | | server from participating in a | | | | | query distribution system. | | | | |------------------------------------+------+-----+----------------------| | Section 3.1.12.1 | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST provide a means | | | | | by which the end-systems can | | | | | either identify or negotiate over | | | | | the protocol version to be used | | | | | for any query or set of queries. | | | | |------------------------------------+------+-----+----------------------| | All resource-specific schema MUST | | | | | provide a version identifier | | | | | attribute which uniquely and | | | | | unambiguously identifies the | | | | | version of the schema being | | | | | returned in the answer set to a | | | | | query. | | | | |------------------------------------------------------------------------| | Section 3.1.13.1 | |------------------------------------------------------------------------| | When issuing a referral, the | | | | | protocol MUST be capable of | | | | | supplying a relay bag from the | | | | | server to the client, | | | | |------------------------------------+------+-----+----------------------| | and the protocol MUST be capable | | | | | of allowing the client to submit | | | | | this relay bag with a query to the | | | | | referred server. | | | | |------------------------------------+------+-----+----------------------| | The use of the relay bag MUST be | | | | | OPTIONAL. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT make any | | | | | assumptions regarding the contents | | | | | of the relay bag, | | | | |------------------------------------+------+-----+----------------------| | but the relay bag MUST be | | | | | described using the schema | | | | | language of the protocol. | | | | |------------------------------------------------------------------------| | The protocol MUST provide different error messages to indicate whether | | the bag is: | |------------------------------------------------------------------------| | Unrecognized (permanent failure) | | | | |------------------------------------+------+-----+----------------------| | Contains unacceptable data | | | | | (permenant failure) | | | | |------------------------------------+------+-----+----------------------| | Contains data that means | | | | | processing is refused a this time | | | | | (transient failure) | | | | |------------------------------------+------+-----+----------------------| | There MUST be no more than one bag | | | | | per referral. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST NOT make an | | | | | association or linkage between | | | | | successive bags in a referral | | | | | chain. | | | | |------------------------------------+------+-----+----------------------| | The client MUST pass the bag as | | | | | part of any query made to a | | | | | referrant server as a result of a | | | | | referral. | | | | |------------------------------------------------------------------------| | Section 3.2.1.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following lookup functions: | |------------------------------------------------------------------------| | Contact lookup given a unique | | | | | reference to a contact of a | | | | | resource. | | | | |------------------------------------+------+-----+----------------------| | Nameserver lookup given a | | | | | fully-qualified host name or IP | | | | | address of a nameserver. | | | | |------------------------------------+------+-----+----------------------| | Domain lookup given a | | | | | fully-qualified domain name. | | | | |------------------------------------------------------------------------| | Section 3.2.2.1 | |------------------------------------------------------------------------| | The protocol MUST contain the following search functions: | |------------------------------------------------------------------------| | Domain name search given an exact match or reasonable subset of a | | name. | |------------------------------------------------------------------------| | This search SHOULD allow for | | | | | parameters and qualifiers designed | | | | | to allow better matching of | | | | | internationalized domain names | | | | |------------------------------------+------+-----+----------------------| | and SHOULD allow for both exact | | | | | and partial matching within the | | | | | limits of internationalized domain | | | | | names. | | | | |------------------------------------+------+-----+----------------------| | This search SHOULD NOT require | | | | | special transformations of | | | | | internationalized domain names to | | | | | accommodate this search. | | | | |------------------------------------+------+-----+----------------------| | This search MUST provide a means | | | | | to narrow the search by names | | | | | delegated under a particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domain registrant search by either | | | | | exact name or partial name match | | | | | with the ability to narrow the | | | | | search to registrants of a | | | | | particular TLD. | | | | |------------------------------------+------+-----+----------------------| | Domains hosted by a nameserver | | | | | given the fully-qualified host | | | | | name or IP address of a | | | | | nameserver. | | | | |------------------------------------------------------------------------| | Section 3.2.3.1 | |------------------------------------------------------------------------| | The data sets for contacts, | | | | | nameservers, and domains MUST be | | | | | able to express and represent the | | | | | attributes and allowable values of | | | | | registration requests in domain | | | | | registration and provisioning | | | | | protocols. | | | | |------------------------------------------------------------------------| | The schema MUST be capable of expressing the following information for | | domains: | |------------------------------------------------------------------------| | activation status | | | | |------------------------------------+------+-----+----------------------| | registrant | | | | |------------------------------------+------+-----+----------------------| | nameservers | | | | |------------------------------------+------+-----+----------------------| | technical, billing or other | | | | | contacts | | | | |------------------------------------+------+-----+----------------------| | registry delegating the domain | | | | |------------------------------------+------+-----+----------------------| | registrar for the domain | | | | |------------------------------------+------+-----+----------------------| | The data set for domains MUST be | | | | | able to express arbitrary textual | | | | | information for extensions on an | | | | | individual operator basis. | | | | |------------------------------------------------------------------------| | Section 3.2.4 | |------------------------------------------------------------------------| | The schemas used by the protocol | | | | | SHOULD be capable of off-line | | | | | serialization. | | | | |------------------------------------------------------------------------| | Section 3.2.5.1 | |------------------------------------------------------------------------| | The protocol MUST contain a | | | | | feature, used at the discretion of | | | | | a server operator, to allow a | | | | | server to express to a client a | | | | | limit on the number of results | | | | | from searches and lookups. | | | | |------------------------------------------------------------------------| | When returning result sets, the protocol MUST be able to make the | | following distinctions: | |------------------------------------------------------------------------| | an empty result set. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated for the | | | | | purpose of improving performance | | | | | bottlenecks. | | | | |------------------------------------+------+-----+----------------------| | a result set truncated to comply | | | | | with Section 3.1.1 | | | | |------------------------------------------------------------------------| | Section 3.2.6.1 | |------------------------------------------------------------------------| | The protocol MUST use the | | | | | delegation authority model | | | | | available in DNS [1] as the | | | | | primary means for determining the | | | | | authoritative source for | | | | | information regarding domains or | | | | | any other objects when applicable. | | | | |------------------------------------------------------------------------| | Section 3.2.7.1 | |------------------------------------------------------------------------| | The protocol MUST NOT prohibit the | | | | | distribution of data to exclude | | | | | any of the registry/registrar | | | | | models stated in Section 2.1.1. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be capable of | | | | | expressing referrals and entity | | | | | references between the various | | | | | models described in Section 2.1.1. | | | | |------------------------------------------------------------------------| | Section 3.2.8.1 | |------------------------------------------------------------------------| | When a value in an answer to a query cannot be given due to policy | | constraints, the protocol MUST be capable of expressing the value in | | one of three ways: | |------------------------------------------------------------------------| | complete omission of the value | | | | | without explanation | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | | | | | cannot be given due to | | | | | insufficient authorization | | | | |------------------------------------+------+-----+----------------------| | an indication that the value | | | | | cannot be given due to privacy | | | | | constraints regardless of | | | | | authorization status | | | | |------------------------------------+------+-----+----------------------| | The protocol MAY define other | | | | | values for this purpose, but MUST | | | | | define values defined above at a | | | | | minimum. | | | | |------------------------------------------------------------------------| | Section 3.2.9 | |------------------------------------------------------------------------| | The schema defining domain related | | | | | resources MUST conform to RFC 2277 | | | | | [2] regarding textual data. | | | | |------------------------------------+------+-----+----------------------| | In particular, the schema MUST be | | | | | able to indicate the charset and | | | | | language in use with unstructured | | | | | textual data. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | | | | | support multiple representations | | | | | of contact data, with these | | | | | representations complying with the | | | | | requirements in Section 3.2.3. | | | | |------------------------------------+------+-----+----------------------| | The protocol MUST be able to | | | | | provide contact data in UTF-8 | | | | |------------------------------------+------+-----+----------------------| | and SHOULD be able to provide | | | | | contact data in | | | | | | | | | | US-ASCII, other character sets, | | | | |------------------------------------+------+-----+----------------------| | and capable of specifying the | | | | | language of the data. | | | | |------------------------------------------------------------------------| | Section 4.1 | |------------------------------------------------------------------------| | Entities accessing the service | | | | | (users) MUST be provided a | | | | | mechanism for passing credentials | | | | | to a server for the purpose of | | | | | authentication. | | | | |------------------------------------------------------------------------| | Section 4.2 | |------------------------------------------------------------------------| | The protocol MUST provide a | | | | | mechanism capable of employing | | | | | many authentication types and | | | | | capable of extension for future | | | | | authentication types. | | | | |------------------------------------------------------------------------| | Section 4.3 | |------------------------------------------------------------------------| | To distribute queries for search | | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | provide a referral mechanism. | | | | |------------------------------------------------------------------------| | Section 4.4 | |------------------------------------------------------------------------| | To distribute queries for search | | | | | continuations and to issue entity | | | | | references, the protocol MUST | | | | | define a common referral scheme | | | | | and syntax. | | | | |------------------------------------+------+-----+----------------------| | Section 4.5 | | | | |------------------------------------+------+-----+----------------------| | To provide structured queries and | | | | | responses and allow for minimal | | | | | technological reinvention, the | | | | | protocol MUST employ a | | | | | pre-existing schema language. | | | | |------------------------------------+------+-----+----------------------| | Section 4.6 | | | | |------------------------------------+------+-----+----------------------| | To provide for machine consumption | | | | | as well as human consumption, the | | | | | protocol MUST define schemas for | | | | | use by the structured queries and | | | | | responses. | | | | +------------------------------------------------------------------------+ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.verisignlabs.com/pipermail/ietf-not43/attachments/20030522/24fb9ae6/crisp-matrix-0001.html From anewton at ecotroph.net Thu May 22 12:07:35 2003 From: anewton at ecotroph.net (Andrew Newton) Date: Thu May 22 10:51:35 2003 Subject: [Ietf-not43] new requirements matrix In-Reply-To: <3ECCE366.2000900@ecotroph.net> References: <3ECCE366.2000900@ecotroph.net> Message-ID: <3ECCE7B7.1080809@ecotroph.net> Andrew Newton wrote: > Of course, if somebody could double check that all > the MUST/SHOULD language in the requirements draft is accounted for in > the matrix, that'd be swell. And just five minutes after I sent it out, I have found a substantial mistake in one of the matrix items. So if we could get some independent review of the matrix vs. the requirements, that would be great! It shouldn't take more than 20 minutes for a person to do. -andy From ehall at ehsco.com Thu May 22 21:26:40 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Thu May 22 21:26:46 2003 Subject: [Ietf-not43] FIRS compliance with -05 reqs doc Message-ID: <3ECD78D0.6050909@ehsco.com> The -01 versions of the FIRS specs in the I-D queue right now are in full compliance with the -05 requirements doc. All of the MUST and SHOULD options and most of the MAY options are supported. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ From Internet-Drafts at ietf.org Wed May 28 08:43:43 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:43:48 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-asn-01.txt Message-ID: <200305281143.HAA25204@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Autonomous System Numbers in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-asn-01.txt Pages : 12 Date : 2003-5-27 This document defines LDAP schema and searching rules for autonomous system numbers, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-asn-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-asn-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-firs-asn-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:43:48 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:43:54 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-contact-01.txt Message-ID: <200305281143.HAA25220@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating Contact Information in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-contact-01.txt Pages : 12 Date : 2003-5-27 This document defines LDAP schema and searching rules for contact persons, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-contact-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-contact-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-firs-contact-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:43:53 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:00 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dns-01.txt Message-ID: <200305281143.HAA25236@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating DNS Domains in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dns-01.txt Pages : 15 Date : 2003-5-27 This document defines LDAP schema and searching rules for DNS domain names, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dns-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-dns-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-firs-dns-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:43:58 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:06 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-dnsrr-01.txt Message-ID: <200305281143.HAA25252@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating DNS Resource Records in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-dnsrr-01.txt Pages : 8 Date : 2003-5-27 This document defines LDAP schema and searching rules for DNS resource records, in support of the Internet Resource Query Service described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-dnsrr-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-dnsrr-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-firs-dnsrr-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:44:02 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:13 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv4-01.txt Message-ID: <200305281144.HAA25268@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv4 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv4-01.txt Pages : 14 Date : 2003-5-27 This document defines LDAP schema and searching rules for IPv4 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv4-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv4-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-firs-ipv4-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:44:08 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:18 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-ipv6-01.txt Message-ID: <200305281144.HAA25284@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : Defining and Locating IPv6 Address Blocks in the Federated Internet Registry Service Author(s) : E. Hall Filename : draft-ietf-crisp-firs-ipv6-01.txt Pages : 14 Date : 2003-5-27 This document defines LDAP schema and searching rules for IPv6 address blocks, in support of the Federated Internet Registry Service (FIRS) described in [FIRS-ARCH] and [FIRS-CORE]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-ipv6-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-ipv6-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-firs-ipv6-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:44:12 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:27 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-core-01.txt Message-ID: <200305281144.HAA25300@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service: Core Elements Author(s) : E. Hall Filename : draft-ietf-crisp-firs-core-01.txt Pages : 38 Date : 2003-5-27 This document describes the core technical elements of the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-core-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-core-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-firs-core-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. -------------- next part -------------- Skipped content of type multipart/alternative From Internet-Drafts at ietf.org Wed May 28 08:44:18 2003 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed May 28 07:44:31 2003 Subject: [Ietf-not43] I-D ACTION:draft-ietf-crisp-firs-arch-01.txt Message-ID: <200305281144.HAA25316@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Cross Registry Information Service Protocol Working Group of the IETF. Title : The Federated Internet Registry Service:Architecture and Implementation Guide Author(s) : E. Hall Filename : draft-ietf-crisp-firs-arch-01.txt Pages : 31 Date : 2003-5-27 This document describes the architectural framework for the Federated Internet Registry Service (FIRS), a distributed service for storing, locating and transferring information about Internet resources using LDAPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-crisp-firs-arch-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-crisp-firs-arch-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-firs-arch-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. -------------- next part -------------- Skipped content of type multipart/alternative From edlewis at arin.net Wed May 28 14:46:07 2003 From: edlewis at arin.net (Edward Lewis) Date: Wed May 28 13:46:10 2003 Subject: [Ietf-not43] Question about -firs-arch In-Reply-To: <3ECBF06A.80807@ehsco.com> References: <3E81F517.7030209@ecotroph.net> <3ECBF06A.80807@ehsco.com> Message-ID: In 4.5 you say that "any referral ... SHOULD provide multiple referrals." Coming from a DNS background, I see this as an analog to having (a requirement for) multiple NS RR's at a delegation point and reminds me of an implementation bug that can be easily avoided. Over time, having two or more NS RR's (in DNS) has become a de facto MUST - the DNS specs were written prior to RFC 2119 - even though it isn't necessary to do that to achieve the desired goal of availability via having multiple name servers which are topologically distributed. It's not necessary to have multiple NS RR's to achieve this because I, in theory, can have multiple address RR's for a domain name, and more recently, I can make use of anycasting. But, in DNS, there is still a need to have multiple NS RR's at a delegation because implementations have made the mistake of marking a name server's domain name as unresponsive if just one of the address records is unresponsive. E.g., may "point to" and . If 1.1.1.1 fails to answer, 2.2.2.2 isn't checked. My suggestion is to add a blurb saying that a URI might resolve into multiple IP addresses and that each address ought to be checked, instead of blindly relying on a second URI for "backup." This should stamp out (one of) the implementation bug(s) that plagues DNS. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. From edlewis at arin.net Wed May 28 14:51:33 2003 From: edlewis at arin.net (Edward Lewis) Date: Wed May 28 13:51:33 2003 Subject: [Ietf-not43] Question about -firs-arch In-Reply-To: References: <3E81F517.7030209@ecotroph.net> <3ECBF06A.80807@ehsco.com> Message-ID: Sorry - the 'question' as in the subj: got lost and became a suggestion... At 13:46 -0400 5/28/03, Edward Lewis wrote: >In 4.5 you say that "any referral ... SHOULD provide multiple referrals." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Digital cameras are to film cameras as Etch-A-Sketches are to canvases. From ehall at ehsco.com Wed May 28 15:11:05 2003 From: ehall at ehsco.com (Eric A. Hall) Date: Wed May 28 15:11:11 2003 Subject: [Ietf-not43] Re: Question about -firs-arch In-Reply-To: References: <3E81F517.7030209@ecotroph.net> <3ECBF06A.80807@ehsco.com> Message-ID: <3ED509C9.20009@ehsco.com> on 5/28/2003 12:46 PM Edward Lewis wrote: > My suggestion is to add a blurb saying that a URI might resolve into > multiple IP addresses and that each address ought to be checked, > instead of blindly relying on a second URI for "backup." This should > stamp out (one of) the implementation bug(s) that plagues DNS. That's a good suggestion. I also added a blurb to the SRV processing disucssion in the -core spec saying that each IP address should be tried before moving to the next-preferred host. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/