From bicknell at ufp.org Thu Jun 9 17:32:34 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 9 Jun 2005 17:32:34 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050509200742.GA75281@ussenterprise.ufp.org> References: <20050509200742.GA75281@ussenterprise.ufp.org> Message-ID: <20050609213234.GA10868@ussenterprise.ufp.org> Now that things have been quiet for a while, a resend to see if we can spark some discussion on directory services.... In a message written on Mon, May 09, 2005 at 04:07:42PM -0400, Leo Bicknell wrote: > Below is my directory services proposal, take two. Based on feedback > from the last meeting, I have removed the option of displaying SWIP > information, and also updated several minor terms which were confusing > from feedback on the mailing list. I'd like to get some discussion > going so this can be ready for the next ARIN meeting. > > Also, at the end of this message I included a context diff to call > out the changes. > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > Replace all of section three with the following rewrite. > > 3 Directory Services > > 3.1 ARIN Directory Services Databases > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. > > 3.2 Directory Information Made Public > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. > > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. ARIN staff shall maintain verification criteria and > post it on the ARIN web site. > > 3.2.1 Non-Responsive Contacts > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. > > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). > > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occurred, and the response from the resource > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. > > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > > 3.3.1.1 Outside Sources > > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. > > 3.3.2 Acceptable Usage Policy > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff and legal and posted on the ARIN website. > ARIN may require a signed copy of the AUP before providing > bulk data. > > 3.3.3 Requirements for Internet Accessible Services > > For any method of access which is provided in real time via the > Internet the following requirements must be met: > > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. > > * The distributed information service must allow public > access to reassignment information. The service may > restrict the number of queries allowed per time interval > from a host or subnet to defend against DDOS attacks, > remote mirroring attempts, and other nefarious acts. > > * The distributed information service must return current > information. > > 3.4 Distribution of the ARIN Public Information Database > > 3.4.1 Supported Uses > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > 3.4.2 Prohibited Uses > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. > > 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. > > 3.5 Distribution of the ARIN Confidential Information Database > > ARIN Staff shall use industry standard procedures to prevent > the distribution of any data in the ARIN Confidential Information > Database. > > 3.6 Implementation Details > > ARIN Staff shall document all implementation specific details for > directory services in a single document available on the web site. > The document must contain, but is not limited to: > > - Database field definitions. > - Update procedures. > - Templates. > - Points of contact. > - Copies of the AUP. > - Verification procedures. > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > Section 4.2.3.7.4: Replace with: > > All reassignment information for current blocks shall be submitted to > ARIN prior to submitting a request for a new allocation. > > -------------------Context diff below---------------------------------- > > 2c2 > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > --- > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > 25,30c25,27 > < identified by ARIN) in the APID in the following cases: > < > < - All resources delegated by ARIN. > < - If allowed by the parent delegation, and requested by > < the contact listed with the parent, a subdelegation of a > < resource. > --- > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > 45,48c42,47 > < Once the resource is suspended ARIN shall make one more request > < of all contacts listed with the resource and the parent resource > < (if available), and if no response is received in a reasonable > < amount of time the resource shall be reclaimed. > --- > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > 50,51c49,50 > < Third parties may report the inability to make contact with a > < party via information in the APID. In this case ARIN shall > --- > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > 55,57c54,56 > < holder. Offenders who fail to respond to third parties more > < than 4 times per month for three months may have their resources > < reclaimed at the discretion of ARIN staff. > --- > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > 82a82,84 > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > 89,91c91,93 > < 2 Meet the requirements in section 3.3.3. > < 3 Support the applications in section 3.3.1. > < 4 Prohibit the applications in section 3.3.2. > --- > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > 182,183d183 > < > < Section 4.2.3.7.6: Strike. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From ipgoddess at gmail.com Thu Jun 9 19:15:46 2005 From: ipgoddess at gmail.com (Stacy Taylor) Date: Thu, 9 Jun 2005 16:15:46 -0700 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050509200742.GA75281@ussenterprise.ufp.org> References: <20050509200742.GA75281@ussenterprise.ufp.org> Message-ID: <1c16a4870506091615197c2baa@mail.gmail.com> Strong Work again, Leo. I support this revision. /Stacy On 5/9/05, Leo Bicknell wrote: > > Below is my directory services proposal, take two. Based on feedback > from the last meeting, I have removed the option of displaying SWIP > information, and also updated several minor terms which were confusing > from feedback on the mailing list. I'd like to get some discussion > going so this can be ready for the next ARIN meeting. > > Also, at the end of this message I included a context diff to call > out the changes. > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > Replace all of section three with the following rewrite. > > 3 Directory Services > > 3.1 ARIN Directory Services Databases > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. > > 3.2 Directory Information Made Public > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. > > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. ARIN staff shall maintain verification criteria and > post it on the ARIN web site. > > 3.2.1 Non-Responsive Contacts > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. > > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). > > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occurred, and the response from the resource > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. > > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > > 3.3.1.1 Outside Sources > > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. > > 3.3.2 Acceptable Usage Policy > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff and legal and posted on the ARIN website. > ARIN may require a signed copy of the AUP before providing > bulk data. > > 3.3.3 Requirements for Internet Accessible Services > > For any method of access which is provided in real time via the > Internet the following requirements must be met: > > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. > > * The distributed information service must allow public > access to reassignment information. The service may > restrict the number of queries allowed per time interval > from a host or subnet to defend against DDOS attacks, > remote mirroring attempts, and other nefarious acts. > > * The distributed information service must return current > information. > > 3.4 Distribution of the ARIN Public Information Database > > 3.4.1 Supported Uses > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > 3.4.2 Prohibited Uses > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. > > 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. > > 3.5 Distribution of the ARIN Confidential Information Database > > ARIN Staff shall use industry standard procedures to prevent > the distribution of any data in the ARIN Confidential Information > Database. > > 3.6 Implementation Details > > ARIN Staff shall document all implementation specific details for > directory services in a single document available on the web site. > The document must contain, but is not limited to: > > - Database field definitions. > - Update procedures. > - Templates. > - Points of contact. > - Copies of the AUP. > - Verification procedures. > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > Section 4.2.3.7.4: Replace with: > > All reassignment information for current blocks shall be submitted to > ARIN prior to submitting a request for a new allocation. > > -------------------Context diff below---------------------------------- > > 2c2 > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > --- > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > 25,30c25,27 > < identified by ARIN) in the APID in the following cases: > < > < - All resources delegated by ARIN. > < - If allowed by the parent delegation, and requested by > < the contact listed with the parent, a subdelegation of a > < resource. > --- > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > 45,48c42,47 > < Once the resource is suspended ARIN shall make one more request > < of all contacts listed with the resource and the parent resource > < (if available), and if no response is received in a reasonable > < amount of time the resource shall be reclaimed. > --- > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > 50,51c49,50 > < Third parties may report the inability to make contact with a > < party via information in the APID. In this case ARIN shall > --- > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > 55,57c54,56 > < holder. Offenders who fail to respond to third parties more > < than 4 times per month for three months may have their resources > < reclaimed at the discretion of ARIN staff. > --- > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > 82a82,84 > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > 89,91c91,93 > < 2 Meet the requirements in section 3.3.3. > < 3 Support the applications in section 3.3.1. > < 4 Prohibit the applications in section 3.3.2. > --- > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > 182,183d183 > < > < Section 4.2.3.7.6: Strike. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > > > From Michael.Dillon at btradianz.com Fri Jun 10 05:51:06 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Jun 2005 10:51:06 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050609213234.GA10868@ussenterprise.ufp.org> Message-ID: > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. This just sucks. The RWHOIS protocol is an ancient creaking unmaintained and unsupported protocol which is sorely in need of retirement. It should be dropped from this document. The "query form accessible via the HTTP protocol" is excessively vague. Is this XML-RPC, SOAP, REST? Or yet another crude PHP hack? The FTP and CDROM ideas are not all that bad, but the wording implies that anyone who completes the form gets the data. If Osama Bin Laden fills out the form and says he needs it to evaluate potential attack targets, this wording says that he gets his CDROM just like everyone else. Also, why do we need to specify media type? Does this mean ARIN can't use a DVD-R? Let's leave the details of physical media format between ARIN staff and the applicants. If someone wants to courier over a hard drive to get an Oracle dump file, it is none of our business. And whatever happened to the IETF standard directory access protocol, namely Lightweight Directory Access Protocol (LDAP)? It's there, it works, it's scalable, it's supported, it's maintained. Thousands of companies use this protocol on a larger scale than ARIN whois and even Microsoft has bitten the bullet and stopped using their proprietary directory access protocol in favour of LDAP. This protocol is widely used by ISPs operationally in their mail server farms so most ARIN members probably have someone on staff who knows how to deal with LDAP already. And even though the IETF hasn't finished working on IRIS, ARIN should at least support XML-encoding of the whois data. This could be returned by the whois protocol using a -xml option on the query. It could be returned by XML-RPC and SOAP. And it could be the basis of the LDAP schema used in an LDAP server which is something that members could also run. That is to say, if ARIN publishes a standard LDAP schema for whois data, then members can easily set up their own distributed LDAP servers to host their own directory data and we can dismantle this whole uneccessary SWIP system and central whois database. --Michael Dillon From hannigan at verisign.com Fri Jun 10 09:33:54 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Fri, 10 Jun 2005 09:33:54 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Michael.Dillon at btradianz.com > Sent: Friday, June 10, 2005 5:51 AM > To: ppml at arin.net > Subject: Re: [ppml] Directory Services - Take 2 > > > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > [ SNIP ] > Let's leave the details of physical media > format between ARIN staff and the applicants. If someone > wants to courier over a hard drive to get an Oracle > dump file, it is none of our business. It's inefficient to require the office to be able to handle each and every exotic media request. Specifying them makes sense for both them and the customers and sets a reasonable expectation. > XML-encoding of the > whois data. I support this, and this. -M< From L.Howard at stanleyassociates.com Fri Jun 10 09:38:50 2005 From: L.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 10 Jun 2005 09:38:50 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Friday, June 10, 2005 5:51 AM > To: ppml at arin.net > Subject: Re: [ppml] Directory Services - Take 2 > > > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > This just sucks. > > The RWHOIS protocol is an ancient creaking unmaintained > and unsupported protocol which is sorely in need of > retirement. Or replacement with something better. > The "query form accessible via the HTTP protocol" is > excessively vague. Is this XML-RPC, SOAP, REST? Or yet > another crude PHP hack? What would you prefer? > > The FTP and CDROM ideas are not all that bad, but the > wording implies that anyone who completes the form > gets the data. If Osama Bin Laden fills out the form > and says he needs it to evaluate potential attack > targets, this wording says that he gets his CDROM > just like everyone else. Also, why do we need to > specify media type? Does this mean ARIN can't use > a DVD-R? Let's leave the details of physical media > format between ARIN staff and the applicants. If someone > wants to courier over a hard drive to get an Oracle > dump file, it is none of our business. I agree. I made some comment once about language allowing cuneiform on clay tablets, but the querant would have to pay for it (including staff time, if excessive). > > And whatever happened to the IETF standard directory > access protocol, namely Lightweight Directory Access > Protocol (LDAP)? It's there, it works, it's scalable, > it's supported, it's maintained. Thousands of companies > use this protocol on a larger scale than ARIN whois and > even Microsoft has bitten the bullet and stopped using > their proprietary directory access protocol in favour > of LDAP. This protocol is widely used by ISPs operationally > in their mail server farms so most ARIN members probably > have someone on staff who knows how to deal with LDAP > already. Seems like every time I hear this song, it's a solo. I'm not saying it's a bad song, but not many people seem to know the words. Either we need to hear more people say, "Yea, LDAP's the way to go," or you (or the President and Board) need to decide it's the way to go and teach everyone else to sing along. > And even though the IETF hasn't finished working on > IRIS, ARIN should at least support XML-encoding of the > whois data. This could be returned by the whois protocol > using a -xml option on the query. It could be returned > by XML-RPC and SOAP. And it could be the basis of the > LDAP schema used in an LDAP server which is something > that members could also run. That is to say, if ARIN > publishes a standard LDAP schema for whois data, then members > can easily set up their own distributed LDAP servers to host > their own directory data and we can dismantle this whole > uneccessary SWIP system and central whois database. It sounds to me like you have an alternate proposal to Leo's. You guys should either collaborate, to see if you can come up with a better mousetrap, or you should write the schema and show the distribution/referral tree. I don't think the public would need to see or draw consensus on a data dictionary, but I think we need a more specific proposal to get behind. We could approve an approach in principle, then ARIN could have full-time DBAs actually design and implement the thing. Lee > --Michael Dillon From Michael.Dillon at btradianz.com Fri Jun 10 10:26:28 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Jun 2005 15:26:28 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > > The "query form accessible via the HTTP protocol" is > > excessively vague. Is this XML-RPC, SOAP, REST? Or yet > > another crude PHP hack? > > What would you prefer? REST. For those who don't know what this is, check out this article: http://www.devx.com/DevX/Article/8155 Basically, REST is just plain old HTML forms and CGI where the arguments and options of a query are specified in the URL itself. For instance you can make a port 43 query that looks like this whois n + > 192.168.0.0 REST would specify that a server accepts a query like http://whois.arin.net/query.py?type=n&display=summ&hierarchy=down&identifier=192.168.0.0 This same URL could be generated by a plain old HTML form or by a script in an ISP's management systems. In fact, this is not all that different technically from what ARIN already does with web based queries. I am mainly asking that this type of whois query be "blessed" as an official form of publishing the whois directory, and documented so that the interface is publicly known, and perhaps even, publicly encouraged. There is no need for the HTML form to reside on an ARIN server, so people like completewhois.com and Joe's Hometown ISP should be encouraged to direct queries to this form of ARIN whois server. I'd really like to see this become the default whois protocol and retire port 43 entirely. > > have someone on staff who knows how to deal with LDAP > > already. > > Seems like every time I hear this song, it's a solo. I'm > not saying it's a bad song, but not many people seem to > know the words. Either we need to hear more people say, > "Yea, LDAP's the way to go," or you (or the President and > Board) need to decide it's the way to go and teach everyone > else to sing along. I have been hoping and praying that the board doesn't just listen to political opinions like mine, but that they hire some knowledgable technical consultants to advise them on the technical POSSIBILITIES for whois. I'm not suggesting that the decisionmaking should be handed to others, but we must realize that it is not possible for such a small select group with relatively similar technical backgrounds (IP networking) to fully comprehend the entire suite of network technology possibilities. That's where consultants can help so that you draw in the vast technical expertise that other people have in other areas. LDAP is one of those areas where we could bring in someone with a decade of experience building and operating large corporate and academic LDAP installations that may well handle larger loads than whois does. > It sounds to me like you have an alternate proposal to Leo's. Not really. I just think that this is the heart of the issue with whois currently. Leo wants to create an overarching architecture that covers all whois policy issues. In doing so, I think he hasn't paid enough attention to this core issue. > You guys should either collaborate, to see if you can come > up with a better mousetrap, or you should write the schema > and show the distribution/referral tree. I don't think the > public would need to see or draw consensus on a data dictionary, > but I think we need a more specific proposal to get behind. > We could approve an approach in principle, then ARIN could > have full-time DBAs actually design and implement the thing. I would prefer to see the schema evolve in a different way. I have always felt that the whois directory is the public subset of ARIN's (or the ISP's) internal IP records database. Therefore the schema should really be a subset of the existing ARIN IP records database, and ARIN technical staff are in the best position to publish this. If anything, I would expect policy decisions to subtract from the schema, i.e. no zipcodes, no street address. I know that I have proposed adding some kind of industry classification codes, but that was intended to support researchers and I just don't see that there is any support for special measures to assist research use of this data. So, would it be possible for ARIN staff to publish all or part of their SQL database schema (i.e. the DDL)? If we then XMLize that and LDAPize that, then we can publish something that will help others maintain consistent databases and it will have the side effect of simplifying data transfer. For instance, when an applicant has to supply full data on assignments beyond the /29 limit. Or when one company acquires another and wants to merge IP address records. --Michael Dillon From Michael.Dillon at btradianz.com Fri Jun 10 10:32:12 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 10 Jun 2005 15:32:12 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > It's inefficient to require the office to be able to handle > each and every exotic media request. Specifying them makes > sense for both them and the customers and sets a reasonable > expectation. The office already has to handle each and every exotic media request and changing policy will not change this. RRRRing... Hello, ARIN help desk. Hi ARIN person. I would like a copy of the whois database on bananaskins. Sorry, we can't do that. We have no bananaskin writers in the office. But... Hey, what if I lend you my writer? I have a better idea, how about we send you a DVD+R and you can copy it onto bananaskins yourself. --Michael Dillon P.S. I'm really asking for that bit of the policy to be less prescriptive and let the wise ARIN help desk people negotiate media types as above. If the policy says that ARIN will provide the database via FTP or on recordable media, that is all that needs to be said. And if you accept that, consider how many other bits of the proposed policy could be shortened or discarded. From lea.roberts at stanford.edu Fri Jun 10 10:39:49 2005 From: lea.roberts at stanford.edu (Lea Roberts) Date: Fri, 10 Jun 2005 07:39:49 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: On Fri, 10 Jun 2005, Hannigan, Martin wrote: > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > > Michael.Dillon at btradianz.com > > Sent: Friday, June 10, 2005 5:51 AM > > To: ppml at arin.net > > Subject: Re: [ppml] Directory Services - Take 2 > > > > > > > ARIN shall publish the APID in the following methods using > > > industry standard practices: > > > > > > - Via the WHOIS protocol. > > > - Via a query form accessible via the HTTP protocol. > > > - Via FTP to users who complete the bulk data form. > > > - Via CDROM to users who complete the bulk data form. > > > - Via the RWHOIS protocol. > > > > [ SNIP ] > > > Let's leave the details of physical media > > format between ARIN staff and the applicants. If someone > > wants to courier over a hard drive to get an Oracle > > dump file, it is none of our business. > > It's inefficient to require the office to be able to handle > each and every exotic media request. Specifying them makes > sense for both them and the customers and sets a reasonable > expectation. As often comes up in policy review, sometimes specific implementation details, in this case media type, shouldn't be written into a policy. I agree that the media types should be limited but I would trust the ARIN staff to determine which ones they can easily support and make that list available publicly. The list is bound to change over time and it shouldn't require a policy change when some fabulous new format becomes available... :-) /Lea From John.Sweeting at teleglobe.com Fri Jun 10 10:48:29 2005 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Fri, 10 Jun 2005 10:48:29 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: <1797AB680DD0D2118987009027178032183D9279@camtmms01.ad.teleglobe.com> the policy to could refer to an annex or such that ARIN staff would have the responsibility of approving and maintaining so at least the types supported could be referenced with the policy....... *-----Original Message----- *From: Lea Roberts [mailto:lea.roberts at stanford.edu] *Sent: 10 juin 2005 10:40 *To: ppml at arin.net *Subject: RE: [ppml] Directory Services - Take 2 * * *On Fri, 10 Jun 2005, Hannigan, Martin wrote: * *> > -----Original Message----- *> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of *> > Michael.Dillon at btradianz.com *> > Sent: Friday, June 10, 2005 5:51 AM *> > To: ppml at arin.net *> > Subject: Re: [ppml] Directory Services - Take 2 *> > *> > *> > > ARIN shall publish the APID in the following methods using *> > > industry standard practices: *> > > *> > > - Via the WHOIS protocol. *> > > - Via a query form accessible via the HTTP protocol. *> > > - Via FTP to users who complete the bulk data form. *> > > - Via CDROM to users who complete the bulk data form. *> > > - Via the RWHOIS protocol. *> > *> *> [ SNIP ] *> *> > Let's leave the details of physical media *> > format between ARIN staff and the applicants. If someone *> > wants to courier over a hard drive to get an Oracle *> > dump file, it is none of our business. *> *> It's inefficient to require the office to be able to handle *> each and every exotic media request. Specifying them makes *> sense for both them and the customers and sets a reasonable *> expectation. * *As often comes up in policy review, sometimes specific implementation *details, in this case media type, shouldn't be written into a policy. *I agree that the media types should be limited but I would *trust the ARIN *staff to determine which ones they can easily support and make *that list *available publicly. The list is bound to change over time and it *shouldn't require a policy change when some fabulous new format becomes *available... :-) * /Lea * From Ed.Lewis at neustar.biz Fri Jun 10 10:53:16 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 10 Jun 2005 10:53:16 -0400 Subject: other comments on Re: [ppml] Directory Services - Take 2 In-Reply-To: <20050609213234.GA10868@ussenterprise.ufp.org> References: <20050509200742.GA75281@ussenterprise.ufp.org> <20050609213234.GA10868@ussenterprise.ufp.org> Message-ID: At 17:32 -0400 6/9/05, Leo Bicknell wrote: >Now that things have been quiet for a while, a resend to see if we can >spark some discussion on directory services.... > >In a message written on Mon, May 09, 2005 at 04:07:42PM -0400, Leo >Bicknell wrote: >> Below is my directory services proposal, take two. Based on feedback >> from the last meeting, I have removed the option of displaying SWIP >> information, and also updated several minor terms which were confusing >> from feedback on the mailing list. I'd like to get some discussion >> going so this can be ready for the next ARIN meeting. >> >> Also, at the end of this message I included a context diff to call >> out the changes. >> >> $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ >> >> Replace all of section three with the following rewrite. >> >> 3 Directory Services >> >> 3.1 ARIN Directory Services Databases >> >> The ARIN Public Information Database (APID) is a collection >> of information created and collected by ARIN during the due >> course of business which the ARIN membership has deemed public >> information and decided to publish. >> >> The ARIN Confidential Information Database (ACID) is a collection >> of information created and collected by ARIN during the due course >> of business which the ARIN membership has deemed is confidential >> information that should be kept under a strict privacy policy. "a strict privacy policy" - this is too ambiguous. E.g., a policy of making everything public can be strictly enforced. Either there should be a reference to ARIN's privacy policy here or the policy should be expressed. I'm not prepared to dictate a policy, but I am guessing that the policy for ACID would be one of no disclosure to third parties except law enforcement under authorization. Such data will be encrypted when stored in or enroute to an off-site archive facility. Etc. >> 3.2 Directory Information Made Public >> >> ARIN shall publish verified contact information and the >> resource(s) allocated (including identification for that >> allocation, like date of allocation or other information >> identified by ARIN) in the APID for all resources delegated >> by ARIN. In addition, all reassignment information as defined >> by section 4.2.3.7 will be included in the APID. "Delegated" - is that the same as "allocated?" (Either this is a comment to use consistent language or a request to define a new term.) What about the history of resources, space that has been returned or reclaimed? Does this apply to pre-ARIN collected data? >> ARIN shall insure all contact information in the APID is >> verified from time to time and is correct to the best of ARIN's >> ability. ARIN staff shall maintain verification criteria and >> post it on the ARIN web site. The first word "ARIN" - does that equate to "ARIN staff" (which is also in the paragraph) in all instances? I.e., when referring to "ARIN membership" is that always explicit? >> 3.2.1 Non-Responsive Contacts >> >> If ARIN is unable to verify contact information via the normal >> verification procedure ARIN shall attempt to notify the parent >> of the resource to have the information updated. If there is >> no parent, or if the data is not corrected in a reasonable >> amount of time the resource shall be SUSPENDED. I've asked this before, but what does "SUSPENDED" mean? I ask this particularly because the word is capitalized as if it has a special meaning. I assume this does not apply to resources allocated "prior to ARIN" that appear in ARIN's WHOIS. >> >> Once the resource is suspended ARIN shall make one more >> request of all contacts listed with the resource and the >> parent resource (if available), and if no response is received >> in a reasonable amount of time the resource shall be reclaimed >> (APID records removed, DNS delegations removed, the space >> returned to the free pool). >> >> Third parties may report the inability to make contact with >> a party via information in the APID. In this case ARIN shall >> attempt the contact verification procedure for that contact >> immediately. If a response is received, ARIN should document >> that a problem occurred, and the response from the resource >> holder. Resource holders who fail to respond to third parties >> more than 4 times per month for three months may have their >> resources reclaimed at the discretion of ARIN staff. It sounds like ARIN (staff) ought to document that a problem occurred regardless of whether a response is received or not. I.e., "ARIN should document that a problem occurred, attempt the contact verification procedure, and if a response is received, document the response." >> If a third party submits reports of the inability to make contact >> that are subsequently disproven, ARIN may choose to ignore reports >> from specific companies, people, e-mail addresses, or any other >> classification means as appropriate. >> >> The ARIN staff shall publish the time thresholds and procedural >> details to implement this policy on the ARIN web site. >> >> If a resource is reclaimed under no circumstances shall the >> holder of that resource be entitled to a refund of any fees. When reading this proposal, there are times when I feel that it lacks detail and there are times when I think it has too much detail. Section 3.2.1 seems to be overly detailed - specifying too much of a process for verifying contact information. Wouldn't it be sufficient to say that - ARIN (staff) will implement procedures to check and maintain the currency of contact information in APID and ACID. ARIN will also respond to third party reports of non-functioning contact information. The procedures will be publicly documented on the ARIN web site and available for review during public policy meetings. Resources with non-functioning contact information may be subject to reclamation (I assume that is described somewhere) with no refund of any fees paid to ARIN. >> 3.3 Data Distribution >> >> 3.3.1 Methods of Access >> >> ARIN shall publish the APID in the following methods using >> industry standard practices: >> >> - Via the WHOIS protocol. >> - Via a query form accessible via the HTTP protocol. >> - Via FTP to users who complete the bulk data form. >> - Via CDROM to users who complete the bulk data form. >> - Via the RWHOIS protocol. I would like to see IRIS added, at least on the roadmap to be added. I would also give a minor plug to the effort to stamp out RWHOIS. Again, this seems like too much detail - specifying protocols and not the service. OTOH, I can see why the detail is important, so I'm not sure I'd argue to drop this list. >> All users of the APID must agree to the ARIN AUP. ARIN staff >> may make the APID available via other methods as conveniant. >> >> 3.3.1.1 Outside Sources >> >> ARIN may refer a query to a outside source (for instance via >> RWHOIS or HTTP redirect). Outside sources must: s/ a / an / >> 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. >> 2 Support the applications in section 3.3.1. applications or transports? >> 3 Prohibit the applications in section 3.3.2. I don't see any applications in 3.3.2. >> 4 Meet the requirements in section 3.3.3. What confuses me is that between this and 3.3.3 - is this a requirement that anyone holding data ARIN refers to has to meet the same standard for ARIN's servers? It would seem to me that this doesn't belong in the policy about APID/ACID but in the policy regarding the responsibilities of a resource holder. >> 3.3.2 Acceptable Usage Policy >> >> All data provided shall be subject to an AUP. The AUP shall >> be written by ARIN staff and legal and posted on the ARIN website. >> ARIN may require a signed copy of the AUP before providing >> bulk data. >> >> 3.3.3 Requirements for Internet Accessible Services >> >> For any method of access which is provided in real time via the >> Internet the following requirements must be met: >> >> * The distributed information service must be operational >> 24 hours a day, 7 days a week to both the general public >> and ARIN staff. The service is allowed reasonable >> downtime for server maintenance according to generally >> accepted community standards. What is the "distributed information service?" Is that ARIN's servers or the servers run by resource holders? How does this apply to the distribution of CDROMs (or other fixed media)? >> * The distributed information service must allow public >> access to reassignment information. The service may >> restrict the number of queries allowed per time interval >> from a host or subnet to defend against DDOS attacks, >> remote mirroring attempts, and other nefarious acts. >> >> * The distributed information service must return current >> information. >> >> 3.4 Distribution of the ARIN Public Information Database >> >> 3.4.1 Supported Uses >> >> ARIN shall make the APID available for the following uses >> (supported uses): >> >> 1 ARIN's use in implementing ARIN policies and other >> business. >> 2 Community verification, allowing members of the community >> to confirm the proper users of the various resources ARIN >> controls. >> 3 Statistic gathering by ARIN and third parties on resource >> utilization. >> 4 As a contact database to facilitate communication with the >> person or entity responsible for a particular resource. >> >> 3.4.2 Prohibited Uses >> >> ARIN prohibits the use of the APID for the following uses: >> >> 1 Sending any unsolicited commercial correspondence advertising >> a product or service to any address (physical or electronic) >> listed in the APID. >> 2 Using data in the APID to facilitate violating any state, >> federal, or local law. >> >> 3.4.3 Other Uses >> >> ARIN shall allow all non-prohibited uses of the APID, however >> unless those uses are listed as a supported use the data set >> may be changed in such a way as to render them ineffective, >> or they may be blocked outright as deemed necessary by ARIN >> staff. Users of applications not listed who are concerned >> that they are supported should introduce a proposal to add >> their application to the supported list. >> >> 3.5 Distribution of the ARIN Confidential Information Database >> >> ARIN Staff shall use industry standard procedures to prevent >> the distribution of any data in the ARIN Confidential Information >> Database. This talks about "prevention" but not allowed access. I would think that allowed access to this ought to be explained - legal access, formats in which data will be disseminated, requirements for protection enroute, requirements for destruction when done. >> 3.6 Implementation Details >> >> ARIN Staff shall document all implementation specific details for >> directory services in a single document available on the web site. >> The document must contain, but is not limited to: >> >> - Database field definitions. >> - Update procedures. >> - Templates. >> - Points of contact. >> - Copies of the AUP. >> - Verification procedures. >> >> 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. >> >> Section 4.2.3.7.4: Replace with: >> >> All reassignment information for current blocks shall be submitted to >> ARIN prior to submitting a request for a new allocation. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bicknell at ufp.org Fri Jun 10 11:12:37 2005 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 10 Jun 2005 11:12:37 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050509200742.GA75281@ussenterprise.ufp.org> References: <20050509200742.GA75281@ussenterprise.ufp.org> Message-ID: <20050610151237.GA48542@ussenterprise.ufp.org> In a message written on Mon, May 09, 2005 at 04:07:42PM -0400, Leo Bicknell wrote: > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. I think many people who are asking for various options are missing the point of this section. This section sets forth the minimum set of things ARIN staff must support _NO MATTER WHAT THE COST_. The last sentence allows ARIN Staff to consider other alternatives. If enough people ask for LDAP, and/or LDAP reduces ARIN's costs, then by all means this policy allows them to do just that. Similarly, if you want it on DVD, and ARIN has a DVD writer and the meida cost is the same, no problem. However, not everyone has DVD, so the minimum set of things must be a CDROM, which has much wider acceptance. A lot of people are pushing things that are "new". I have no opposition to "new", but ARIN staff can't be required at any cost to support every new technology that comes down the pike. I have no problem adding methods to this list, but if we add IRIS, XML, LDAP, DVD, SQL, SOAP, and all the other things people might be using to the must be supported list the ARIN staff is going to stand up before my next presentation, tell the room how it's going to cost $500,000 and four more headcount to support this policy, and it's going to get quickly shot down. I think all of the methods will still be useable by a wide audience 10 years from now. Will all the other suggestions? Will they have evolved such that new tools don't like the old formats? More to the point, if I am going to add something to the list, it needs widespread support. So far I see two in the XML camp, one in the LDAP camp, and one in the IRIS camp. That's neither concensus, nor a leading candidate. What troubles me most is that it seems a number of people would be willing to hold up all of the other reforms in this policy to piggy back on their favorite technology. If the technology is widely desired by the ARIN membership then adding a single line to this policy later with an additional proposal should be a trival excercise. Pet protocols should not be pork barreled onto this policy as a way to ram them through. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Fri Jun 10 11:32:19 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 10 Jun 2005 11:32:19 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050610151237.GA48542@ussenterprise.ufp.org> References: <20050509200742.GA75281@ussenterprise.ufp.org> <20050610151237.GA48542@ussenterprise.ufp.org> Message-ID: At 11:12 -0400 6/10/05, Leo Bicknell wrote: >More to the point, if I am going to add something to the list, it >needs widespread support. So far I see two in the XML camp, one >in the LDAP camp, and one in the IRIS camp. That's neither concensus, >nor a leading candidate. Consensus and voting are two different things. I have suggested IRIS (which uses XML as it's presentation format for those counting such things), hoping there would be some dialogue. Is IRIS unknown to people on this list? The reason I have raised IRIS is that it is an improvement over WhosIs and RWhoIs, it can replace the two of them. IRIS is not yet complete, so it is a long-term replacement, not an immediate item. >What troubles me most is that it seems a number of people would be >willing to hold up all of the other reforms in this policy to piggy >back on their favorite technology. If the technology is widely >desired by the ARIN membership then adding a single line to this >policy later with an additional proposal should be a trival excercise. >Pet protocols should not be pork barreled onto this policy as a way >to ram them through. My problems with the policy is that the terminology is inconsistent (which leads to interpretation problems) and that its detail varies from segment to segment. Directory services is one of the major external functions of a registry (DNS, billing, registration are the others), yet I don't see any background material for this policy. Has ARIN (membership, AC, staff) ever identified the constituencies that rely on the directory services? Has there been constituency-by-constituency delineation of requirements for the directory services? It's really hard to effectively evaluate a policy statement without understanding the underlying system. It's like putting regulation ahead of the technology. What "reforms" does this proposal bring? Why is there the feeling that people are "piggy backing" "favorite technology" to prevent the reforms? I have suggested that IRIS become a priority - but that's not the major problem I have with the proposal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From woody at pch.net Fri Jun 10 12:10:49 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 10 Jun 2005 09:10:49 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: > > > - Via CDROM to users who complete the bulk data form. This one seems like a pain. Unlike the others, which are queries of a database, one way or other, this one involves one-off manual labor. -Bill From hannigan at verisign.com Fri Jun 10 12:31:15 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Fri, 10 Jun 2005 12:31:15 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Bill > Woodcock > Sent: Friday, June 10, 2005 12:11 PM > To: ppml at arin.net > Subject: RE: [ppml] Directory Services - Take 2 > > > > > > - Via CDROM to users who complete the > bulk data form. > > This one seems like a pain. Unlike the others, which are > queries of a > database, one way or other, this one involves one-off manual labor. What percentage of requests for data are CD-ROM based? -M< From woody at pch.net Fri Jun 10 12:42:02 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 10 Jun 2005 09:42:02 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: > What percentage of requests for data are CD-ROM based? Presumably a very small number, which would seem to make it inefficient to keep a mechanism in place to serve a small number of potential requests which could just as well be served via the normal mechanism. -Bill From ahp at hilander.com Fri Jun 10 12:51:43 2005 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 10 Jun 2005 10:51:43 -0600 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: --On June 10, 2005 9:42:02 -0700 Bill Woodcock wrote: > > What percentage of requests for data are CD-ROM based? > > Presumably a very small number, which would seem to make it inefficient > to keep a mechanism in place to serve a small number of potential > requests which could just as well be served via the normal mechanism. This raises another point, isn't putting that kind of detail in a policy statement really unnecessary? Doesn't that fall under the category of an implementation detail? ALec From william at elan.net Fri Jun 10 12:57:37 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 09:57:37 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: On Fri, 10 Jun 2005, Bill Woodcock wrote: > > What percentage of requests for data are CD-ROM based? > > Presumably a very small number, which would seem to make it inefficient to > keep a mechanism in place to serve a small number of potential requests > which could just as well be served via the normal mechanism. There are certain organizations that want to make certain data they got came from ARIN and has in no way been altered. So alternative to this for those organizations would be for arin to put the bulk data in archive, and encrypt/sign it with their private key and then distribute through secure channel. Doing CDROM dump is faster/easier until all technologies and standards to do all that are readily available. And I suspect those who do need CDROM dumps will be willing to compensate whatever manual labor is required ... If number of requests is low, you have nothing to worry about as far as ARIN staff taking too much time on it. -- William Leibzon Elan Networks william at elan.net From william at elan.net Fri Jun 10 13:15:40 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 10:15:40 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: On Fri, 10 Jun 2005 Michael.Dillon at btradianz.com wrote: >> ARIN shall publish the APID in the following methods using >> industry standard practices: >> >> - Via the WHOIS protocol. >> - Via a query form accessible via the HTTP protocol. >> - Via FTP to users who complete the bulk data form. >> - Via CDROM to users who complete the bulk data form. >> - Via the RWHOIS protocol. > > This just sucks. > > The RWHOIS protocol is an ancient creaking unmaintained > and unsupported protocol which is sorely in need of retirement. > It should be dropped from this document. It can be dropped later on when replacement for it is readily available. So when CRISP/IRIS is implemented and multiple open-source and commercial IRIS servers are avaialble for providing ip database data over then next then ARIN can start to retire RWHOIS. > The "query form accessible via the HTTP protocol" is > excessively vague. Is this XML-RPC, SOAP, REST? Or > yet another crude PHP hack? That is fair but only to the point that HTTP is being reused by other protocols. When its one of those other protocols - they should not really be considered HTTP at all should have done as IPP and SIP as officially separate protocols. So far as I'm concerned HTTP means accessible to users using normal HTML web browser that is able so support POST or GET. As to if the POST or GET are processing by pre-compiled "C" cgi, perl, php or asp script, servlet that is implementation detail and whatever ARIN wants it will use. > The FTP and CDROM ideas are not all that bad, but the > wording implies that anyone who completes the form > gets the data. If Osama Bin Laden fills out the form > and says he needs it to evaluate potential attack > targets, this wording says that he gets his CDROM > just like everyone else. Also, why do we need to > specify media type? Does this mean ARIN can't use > a DVD-R? In my original text from Whois AUP Policy it was "CDROM or other media" implying that anything similar (like DVD) could be supported as well. The reason for CDROM first is that everyone can read CDs but DVDs still require newere computers. > And whatever happened to the IETF standard directory > access protocol, namely Lightweight Directory Access > Protocol (LDAP)? That protocol was considered for whois (ip or domain) data during CRISP WG and rejected there after the vote (BTW - I voted for LDAP). You should have been active at LDAP if you wanted it that much.... > And even though the IETF hasn't finished working on > IRIS, ARIN should at least support XML-encoding of the > whois data. In what form? You want ARIN to create its own standard? BTW - I think IRIS needs to be explicitely mentioned in the proposed policy - by the time policy is approved (probably within a year if not longer) and then implemented, it'd be IETF proposed standard fore sure. -- William Leibzon Elan Networks william at elan.net From randy at psg.com Fri Jun 10 13:18:14 2005 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2005 10:18:14 -0700 Subject: [ppml] Directory Services - Take 2 References: Message-ID: <17065.52054.510019.888525@roam.psg.com> >> What percentage of requests for data are CD-ROM based? > Presumably ... why presume when arin actually knows? From william at elan.net Fri Jun 10 13:23:29 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 10:23:29 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: On Fri, 10 Jun 2005 Michael.Dillon at btradianz.com wrote: > media types as above. If the policy says that ARIN will > provide the database via FTP or on recordable media, that > is all that needs to be said. I like this wording of "recordable media" ! -- William Leibzon Elan Networks william at elan.net From william at elan.net Fri Jun 10 13:27:52 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 10:27:52 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: <1797AB680DD0D2118987009027178032183D9279@camtmms01.ad.teleglobe.com> References: <1797AB680DD0D2118987009027178032183D9279@camtmms01.ad.teleglobe.com> Message-ID: On Fri, 10 Jun 2005, Sweeting, John wrote: > the policy to could refer to an annex or such that ARIN staff would have the > responsibility of approving and maintaining so at least the types supported > could be referenced with the policy....... I think policy should list types that are expected to be supported and we can change the list later one as necessary as part of our normal policy development process. That does not mean ARIN staff can not support other types, but doing so would be at their own discretion. Creating separate "policy" system on how new type are to be approved seems excessive. -- William Leibzon Elan Networks william at elan.net From randy at psg.com Fri Jun 10 13:28:14 2005 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2005 10:28:14 -0700 Subject: [ppml] Directory Services - Take 2 References: Message-ID: <17065.52654.257374.773746@roam.psg.com> >>> ARIN shall publish the APID in the following methods using >>> industry standard practices: >>> >>> - Via the WHOIS protocol. >>> - Via a query form accessible via the HTTP protocol. >>> - Via FTP to users who complete the bulk data form. >>> - Via CDROM to users who complete the bulk data form. >>> - Via the RWHOIS protocol. >> >> This just sucks. >> >> The RWHOIS protocol is an ancient creaking unmaintained >> and unsupported protocol which is sorely in need of retirement. >> It should be dropped from this document. > It can be dropped later on when replacement for it is readily available. recycle an old pet rock, same usability, less maintenance randy From randy at psg.com Fri Jun 10 13:33:24 2005 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2005 10:33:24 -0700 Subject: [ppml] Directory Services - Take 2 References: Message-ID: <17065.52964.923425.653568@roam.psg.com> > As often comes up in policy review, sometimes specific implementation > details, in this case media type, shouldn't be written into a policy. > I agree that the media types should be limited but I would trust the ARIN > staff to determine which ones they can easily support and make that list > available publicly. The list is bound to change over time and it > shouldn't require a policy change when some fabulous new format becomes > available... :-) bingo! From Ed.Lewis at neustar.biz Fri Jun 10 14:05:03 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 10 Jun 2005 14:05:03 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <17065.52964.923425.653568@roam.psg.com> References: <17065.52964.923425.653568@roam.psg.com> Message-ID: >> As often comes up in policy review, sometimes specific implementation >> details, in this case media type, shouldn't be written into a policy. >> I agree that the media types should be limited but I would trust the ARIN >> staff to determine which ones they can easily support and make that list >> available publicly. The list is bound to change over time and it >> shouldn't require a policy change when some fabulous new format becomes >> available... :-) > >bingo! I'm for this too, when writing a policy I agree we want "service in" and "implementation out". (Which is why I also balk at all the detail in the text about non-responsive contacts.) The reason I raised IRIS (repeatedly, to the point of beating the proverbial dead mule) is that I think there's a bit of chicken-and-egg going on here. Not in the need for clients and servers, but in the way the IETF works. The IETF works on volunteered actions from the community. ARIN is ideally suited, as much as any organization in North America, to volunteer the knowledgeable resources to push through the specification for IRIS's address registry. (The doc in question is http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris-areg-11.txt.) ARIN can't "ram" this through the IETF, but the membership should keep participation in this a priority. IRIS isn't the only engineering concern, it's one of many. If we don't use policy to track engineering efforts like this, what do we use? (That was the question I posed during the open policy bof in Orlando.) How do we indicate that ARIN spends time and effort on helping IRIS through the IETF process as well as helps provide the servers and clients? (Note: "provide" does not mean the staff implements and maintains the code. It *could* mean that the budget has money set aside to fund the development.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From bmanning at vacation.karoshi.com Fri Jun 10 14:26:11 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 10 Jun 2005 18:26:11 +0000 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: <20050609213234.GA10868@ussenterprise.ufp.org> Message-ID: <20050610182611.GE2785@vacation.karoshi.com.> On Fri, Jun 10, 2005 at 10:51:06AM +0100, Michael.Dillon at btradianz.com wrote: > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > This just sucks. > > The RWHOIS protocol is an ancient creaking unmaintained > and unsupported protocol which is sorely in need of retirement. Michael, while i will not disagree about the desire for retiring said protocol, you seem confused about WHOIS vs RWHOIS. WHOIS is ancient, creaking - with various bodies building incompatable shims/expectations on this (excessively) flexible protocol. My mail archives(*) do not see when the last supported/maintained change was made to the whois protocol so that would be pre 1994. (no that does not count the tweeks various folks have made to try and "standardise" the query type or return string... with only slightly more success than attempts to standardize the format of the DNS TXT rr type...) (pop quiz... which is more extensible, whois or finger?) rWHOIS, on the other hand, is a decade or so younger than the venerable WHOIS... and is maintained and supported. e.g. ---------------------------------------------------------------------- Date: Tue, 7 Jun 2005 16:07:46 -0400 Subject: [ANN] rwhoisd-1.5.9.5 and rwhoisd-1.5.10-pre5 List-Id: General user list for the RWhois protocol and reference software Hello folks, This is a bug fix release containing Joe Pruett's IPv4 formatting fix. These versions are recommended over previous releases. Just a reminder: the main difference between the 1.5.9.x series and the 1.5.10 series is the NETBLOCK index type, which allows the indexer to index off-boundary network block ranges (or just allow you to specify everything in network ranges rather than CIDR notation). Feedback on the 1.5.10 releases would be appreciated. Anyway, get them at: ------------------------------------------------------------------ other comments (thanks Lea) wrt over specification of implementation details are spot on. IMHO of course. * most of the mail archives are swapped out... on old media types that are tough to get support/drivers for ... :( --bill From marla_azinger at eli.net Fri Jun 10 14:30:42 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 11:30:42 -0700 Subject: [ppml] Directory Services - Take 2 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B158@wava00s2ke2k01.corp.pvt> Although my background knowledge of why this is really needed...I tend to lean towards this being taken out of the proposed policy. For me, the points below are what I stand by as support for the deletion of this "entry" in the proposed proposal. -Dictation of implementation detail that doesnt belong in policy text -It involves manual labor and cost that can be avoided Marla -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Alec H. Peterson Sent: Friday, June 10, 2005 9:52 AM To: Bill Woodcock; Hannigan, Martin Cc: ppml at arin.net Subject: RE: [ppml] Directory Services - Take 2 --On June 10, 2005 9:42:02 -0700 Bill Woodcock wrote: > > What percentage of requests for data are CD-ROM based? > > Presumably a very small number, which would seem to make it inefficient > to keep a mechanism in place to serve a small number of potential > requests which could just as well be served via the normal mechanism. This raises another point, isn't putting that kind of detail in a policy statement really unnecessary? Doesn't that fall under the category of an implementation detail? ALec From marla_azinger at eli.net Fri Jun 10 14:33:40 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 11:33:40 -0700 Subject: [ppml] Directory Services - Take 2 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2015122C0@wava00s2ke2k01.corp.pvt> Valid point...but if I read this proposal right...this requirment also extends to RWHOIS users...and as an RWHOIS user...I'm not about to support a policy that requires me to do this CDROM dump to anyone who requests it. Time and Money. Marla ELI and Frontier Communications -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of william(at)elan.net Sent: Friday, June 10, 2005 9:58 AM To: Bill Woodcock Cc: Hannigan, Martin; ppml at arin.net Subject: RE: [ppml] Directory Services - Take 2 On Fri, 10 Jun 2005, Bill Woodcock wrote: > > What percentage of requests for data are CD-ROM based? > > Presumably a very small number, which would seem to make it inefficient to > keep a mechanism in place to serve a small number of potential requests > which could just as well be served via the normal mechanism. There are certain organizations that want to make certain data they got came from ARIN and has in no way been altered. So alternative to this for those organizations would be for arin to put the bulk data in archive, and encrypt/sign it with their private key and then distribute through secure channel. Doing CDROM dump is faster/easier until all technologies and standards to do all that are readily available. And I suspect those who do need CDROM dumps will be willing to compensate whatever manual labor is required ... If number of requests is low, you have nothing to worry about as far as ARIN staff taking too much time on it. -- William Leibzon Elan Networks william at elan.net From marla_azinger at eli.net Fri Jun 10 14:37:54 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 11:37:54 -0700 Subject: [ppml] Directory Services - Take 2 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2015122C2@wava00s2ke2k01.corp.pvt> Thank you. I like it...I use it...and really...it doesnt creak. ;o) Marla -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of bmanning at vacation.karoshi.com Sent: Friday, June 10, 2005 11:26 AM To: Michael.Dillon at btradianz.com Cc: ppml at arin.net Subject: Re: [ppml] Directory Services - Take 2 On Fri, Jun 10, 2005 at 10:51:06AM +0100, Michael.Dillon at btradianz.com wrote: > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > This just sucks. > > The RWHOIS protocol is an ancient creaking unmaintained > and unsupported protocol which is sorely in need of retirement. Michael, while i will not disagree about the desire for retiring said protocol, you seem confused about WHOIS vs RWHOIS. WHOIS is ancient, creaking - with various bodies building incompatable shims/expectations on this (excessively) flexible protocol. My mail archives(*) do not see when the last supported/maintained change was made to the whois protocol so that would be pre 1994. (no that does not count the tweeks various folks have made to try and "standardise" the query type or return string... with only slightly more success than attempts to standardize the format of the DNS TXT rr type...) (pop quiz... which is more extensible, whois or finger?) rWHOIS, on the other hand, is a decade or so younger than the venerable WHOIS... and is maintained and supported. e.g. ---------------------------------------------------------------------- Date: Tue, 7 Jun 2005 16:07:46 -0400 Subject: [ANN] rwhoisd-1.5.9.5 and rwhoisd-1.5.10-pre5 List-Id: General user list for the RWhois protocol and reference software Hello folks, This is a bug fix release containing Joe Pruett's IPv4 formatting fix. These versions are recommended over previous releases. Just a reminder: the main difference between the 1.5.9.x series and the 1.5.10 series is the NETBLOCK index type, which allows the indexer to index off-boundary network block ranges (or just allow you to specify everything in network ranges rather than CIDR notation). Feedback on the 1.5.10 releases would be appreciated. Anyway, get them at: ------------------------------------------------------------------ other comments (thanks Lea) wrt over specification of implementation details are spot on. IMHO of course. * most of the mail archives are swapped out... on old media types that are tough to get support/drivers for ... :( --bill From hannigan at verisign.com Fri Jun 10 14:43:08 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Fri, 10 Jun 2005 14:43:08 -0400 Subject: [ppml] Directory Services - Take 2 Message-ID: > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Friday, June 10, 2005 2:34 PM > To: william(at)elan.net; Bill Woodcock > Cc: Hannigan, Martin; ppml at arin.net > Subject: RE: [ppml] Directory Services - Take 2 > > > Valid point...but if I read this proposal right...this > requirment also extends to RWHOIS users...and as an RWHOIS > user...I'm not about to support a policy that requires me to > do this CDROM dump to anyone who requests it. Time and Money. > Shouldn't there be some way for people not connected to the Internet to get the data? For example, many 3 letter agencies arent connected to the Internet. CD-ROM is widespread and is a smart pick to consolidate down to people who need it on "any" media. -M< From william at elan.net Fri Jun 10 14:44:33 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 11:44:33 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050610182611.GE2785@vacation.karoshi.com.> References: <20050609213234.GA10868@ussenterprise.ufp.org> <20050610182611.GE2785@vacation.karoshi.com.> Message-ID: On Fri, 10 Jun 2005 bmanning at vacation.karoshi.com wrote: > Michael, > > while i will not disagree about the desire for retiring > said protocol, you seem confused about WHOIS vs RWHOIS. > > WHOIS is ancient, creaking - with various bodies building incompatable > shims/expectations on this (excessively) flexible protocol. > My mail archives(*) do not see when the last supported/maintained > change was made to the whois protocol so that would be pre 1994. > (no that does not count the tweeks various folks have made to > try and "standardise" the query type or return string... with > only slightly more success than attempts to standardize the > format of the DNS TXT rr type...) Despite that, whois is heavily by all registries and rwhois is not used for anything more then ip database access for some ARIN ISPs who do not want to swip their data directly to ARIN. > (pop quiz... which is more extensible, whois or finger?) > > rWHOIS, on the other hand, is a decade or so younger than the venerable > WHOIS... and is maintained and supported. e.g. Bill, Arent you confused below about support and development of the protocol and support of the particular server/client implementation (considerd to be reference implementation) of this protocol? There are lots and lots of whois servers (like say ripedb) that are maintained as well and are updated a lot more often ... > ---------------------------------------------------------------------- > > Date: Tue, 7 Jun 2005 16:07:46 -0400 > Subject: [ANN] rwhoisd-1.5.9.5 and rwhoisd-1.5.10-pre5 > List-Id: General user list for the RWhois protocol and reference software > > Hello folks, > > This is a bug fix release containing Joe Pruett's IPv4 formatting > fix. These versions are recommended over previous releases. > > Just a reminder: the main difference between the 1.5.9.x series and > the 1.5.10 series is the NETBLOCK index type, which allows the > indexer to index off-boundary network block ranges (or just allow you > to specify everything in network ranges rather than CIDR notation). > Feedback on the 1.5.10 releases would be appreciated. > > Anyway, get them at: > > > > ------------------------------------------------------------------ > > other comments (thanks Lea) wrt over specification of > implementation details are spot on. IMHO of course. > > * most of the mail archives are swapped out... on old media types that > are tough to get support/drivers for ... :( > > --bill > -- William Leibzon Elan Networks william at elan.net From bmanning at vacation.karoshi.com Fri Jun 10 14:54:24 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 10 Jun 2005 18:54:24 +0000 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: <20050609213234.GA10868@ussenterprise.ufp.org> <20050610182611.GE2785@vacation.karoshi.com.> Message-ID: <20050610185424.GF2785@vacation.karoshi.com.> > > (no that does not count the tweeks various folks have made to > > try and "standardise" the query type or return string... with > > only slightly more success than attempts to standardize the > > format of the DNS TXT rr type...) > > Despite that, whois is heavily by all registries and rwhois is not > used for anything more then ip database access for some ARIN ISPs > who do not want to swip their data directly to ARIN. and said RIR's could just as easily use finger or DNS for doing what they do w/ whois... > >rWHOIS, on the other hand, is a decade or so younger than the venerable > > WHOIS... and is maintained and supported. e.g. > > Bill, > > Arent you confused below about support and development of the protocol > and support of the particular server/client implementation (considerd to > be reference implementation) of this protocol? you did see my comment (retained at the top of this posting, and not just to annoy bottom-feeding scumsuckers...) regarding protocol vs folks trying, occasionally with some desperation, to standardize a particular format for a query or its reply. Just like the good folks who occasionally try to fix/subtype fields in the DNS TXT rr's. > There are lots and lots of whois servers (like say ripedb) that are > maintained as well and are updated a lot more often ... maintaining servers and updating data are not the same as a supported and maintained protocol... which was Michaels claim. None of the RIRs, to my knowledge, have made a fundamental change in the whois protocol, they are just tweeking data formats. It is instructive to go read the actual WHOIS specs. So no, I'm not confused. > -- > William Leibzon --bill From marla_azinger at eli.net Fri Jun 10 15:07:36 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 12:07:36 -0700 Subject: [ppml] Directory Services - section 3.4.3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> " 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list." I request that this section be re-written into a less wordy (syntactically easy to read) manner. In order to help and not hinder I have made a suggested re-write. I think I interpreted it right...but if there is a portion that isnt...let me know. Suggested re-write: ARIN shall allow usage of the APID per the approved list. If the APID is used in a way other than what is on the approved usage list then ARIN staff reserves the right to render the data set ineffective or block the user. If a desired use/application of the APID is not present on the current "approved list", then a proposal to add the desired use/application must be sumbitted and follow the proposal policy. Marla -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo Bicknell Sent: Monday, May 09, 2005 1:08 PM To: ppml at arin.net Subject: [ppml] Directory Services - Take 2 Below is my directory services proposal, take two. Based on feedback from the last meeting, I have removed the option of displaying SWIP information, and also updated several minor terms which were confusing from feedback on the mailing list. I'd like to get some discussion going so this can be ready for the next ARIN meeting. Also, at the end of this message I included a context diff to call out the changes. $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ Replace all of section three with the following rewrite. 3 Directory Services 3.1 ARIN Directory Services Databases The ARIN Public Information Database (APID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed public information and decided to publish. The ARIN Confidential Information Database (ACID) is a collection of information created and collected by ARIN during the due course of business which the ARIN membership has deemed is confidential information that should be kept under a strict privacy policy. 3.2 Directory Information Made Public ARIN shall publish verified contact information and the resource(s) allocated (including identification for that allocation, like date of allocation or other information identified by ARIN) in the APID for all resources delegated by ARIN. In addition, all reassignment information as defined by section 4.2.3.7 will be included in the APID. ARIN shall insure all contact information in the APID is verified from time to time and is correct to the best of ARIN's ability. ARIN staff shall maintain verification criteria and post it on the ARIN web site. 3.2.1 Non-Responsive Contacts If ARIN is unable to verify contact information via the normal verification procedure ARIN shall attempt to notify the parent of the resource to have the information updated. If there is no parent, or if the data is not corrected in a reasonable amount of time the resource shall be SUSPENDED. Once the resource is suspended ARIN shall make one more request of all contacts listed with the resource and the parent resource (if available), and if no response is received in a reasonable amount of time the resource shall be reclaimed (APID records removed, DNS delegations removed, the space returned to the free pool). Third parties may report the inability to make contact with a party via information in the APID. In this case ARIN shall attempt the contact verification procedure for that contact immediately. If a response is received, ARIN should document that a problem occurred, and the response from the resource holder. Resource holders who fail to respond to third parties more than 4 times per month for three months may have their resources reclaimed at the discretion of ARIN staff. If a third party submits reports of the inability to make contact that are subsequently disproven, ARIN may choose to ignore reports from specific companies, people, e-mail addresses, or any other classification means as appropriate. The ARIN staff shall publish the time thresholds and procedural details to implement this policy on the ARIN web site. If a resource is reclaimed under no circumstances shall the holder of that resource be entitled to a refund of any fees. 3.3 Data Distribution 3.3.1 Methods of Access ARIN shall publish the APID in the following methods using industry standard practices: - Via the WHOIS protocol. - Via a query form accessible via the HTTP protocol. - Via FTP to users who complete the bulk data form. - Via CDROM to users who complete the bulk data form. - Via the RWHOIS protocol. All users of the APID must agree to the ARIN AUP. ARIN staff may make the APID available via other methods as conveniant. 3.3.1.1 Outside Sources ARIN may refer a query to a outside source (for instance via RWHOIS or HTTP redirect). Outside sources must: 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. 2 Support the applications in section 3.3.1. 3 Prohibit the applications in section 3.3.2. 4 Meet the requirements in section 3.3.3. 3.3.2 Acceptable Usage Policy All data provided shall be subject to an AUP. The AUP shall be written by ARIN staff and legal and posted on the ARIN website. ARIN may require a signed copy of the AUP before providing bulk data. 3.3.3 Requirements for Internet Accessible Services For any method of access which is provided in real time via the Internet the following requirements must be met: * The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. * The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. * The distributed information service must return current information. 3.4 Distribution of the ARIN Public Information Database 3.4.1 Supported Uses ARIN shall make the APID available for the following uses (supported uses): 1 ARIN's use in implementing ARIN policies and other business. 2 Community verification, allowing members of the community to confirm the proper users of the various resources ARIN controls. 3 Statistic gathering by ARIN and third parties on resource utilization. 4 As a contact database to facilitate communication with the person or entity responsible for a particular resource. 3.4.2 Prohibited Uses ARIN prohibits the use of the APID for the following uses: 1 Sending any unsolicited commercial correspondence advertising a product or service to any address (physical or electronic) listed in the APID. 2 Using data in the APID to facilitate violating any state, federal, or local law. 3.4.3 Other Uses ARIN shall allow all non-prohibited uses of the APID, however unless those uses are listed as a supported use the data set may be changed in such a way as to render them ineffective, or they may be blocked outright as deemed necessary by ARIN staff. Users of applications not listed who are concerned that they are supported should introduce a proposal to add their application to the supported list. 3.5 Distribution of the ARIN Confidential Information Database ARIN Staff shall use industry standard procedures to prevent the distribution of any data in the ARIN Confidential Information Database. 3.6 Implementation Details ARIN Staff shall document all implementation specific details for directory services in a single document available on the web site. The document must contain, but is not limited to: - Database field definitions. - Update procedures. - Templates. - Points of contact. - Copies of the AUP. - Verification procedures. 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation. -------------------Context diff below---------------------------------- 2c2 < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ --- > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ 25,30c25,27 < identified by ARIN) in the APID in the following cases: < < - All resources delegated by ARIN. < - If allowed by the parent delegation, and requested by < the contact listed with the parent, a subdelegation of a < resource. --- > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. 45,48c42,47 < Once the resource is suspended ARIN shall make one more request < of all contacts listed with the resource and the parent resource < (if available), and if no response is received in a reasonable < amount of time the resource shall be reclaimed. --- > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). 50,51c49,50 < Third parties may report the inability to make contact with a < party via information in the APID. In this case ARIN shall --- > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall 55,57c54,56 < holder. Offenders who fail to respond to third parties more < than 4 times per month for three months may have their resources < reclaimed at the discretion of ARIN staff. --- > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. 82a82,84 > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > 89,91c91,93 < 2 Meet the requirements in section 3.3.3. < 3 Support the applications in section 3.3.1. < 4 Prohibit the applications in section 3.3.2. --- > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. 182,183d183 < < Section 4.2.3.7.6: Strike. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From plzak at arin.net Fri Jun 10 15:23:18 2005 From: plzak at arin.net (Ray Plzak) Date: Fri, 10 Jun 2005 15:23:18 -0400 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> Message-ID: <20050610192322.64A9E1FEFA@mercury.arin.net> Two items: 1. In response to the media question; ARIN has only provided bulk WHOIS via ftp. The only data CD-ROM that ARIN has produced in the last five years was in conjunction with the database conversion several years ago. One was prepared for each organization and provided all data relative to all of the resources for that organization that was in the ARIN database. 2. Marla raised an interesting point. Does this policy apply to the rWHOIS servers? If so that will need to be taken that into consideration when performing the staff and legal impact analysis. Ray > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > Azinger, Marla > Sent: Friday, June 10, 2005 3:08 PM > To: Leo Bicknell; ppml at arin.net > Subject: RE: [ppml] Directory Services - section 3.4.3 > > " 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list." > > > I request that this section be re-written into a less wordy > (syntactically easy to read) manner. In order to help and not hinder I > have made a suggested re-write. I think I interpreted it right...but if > there is a portion that isnt...let me know. > > Suggested re-write: > > ARIN shall allow usage of the APID per the approved list. If the APID > is used in a way other than what is on the approved usage list then ARIN > staff reserves the right to render the data set ineffective or block the > user. If a desired use/application of the APID is not present on the > current "approved list", then a proposal to add the desired > use/application must be sumbitted and follow the proposal policy. > > > > Marla > > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo > Bicknell > Sent: Monday, May 09, 2005 1:08 PM > To: ppml at arin.net > Subject: [ppml] Directory Services - Take 2 > > > > Below is my directory services proposal, take two. Based on feedback > from the last meeting, I have removed the option of displaying SWIP > information, and also updated several minor terms which were confusing > from feedback on the mailing list. I'd like to get some discussion > going so this can be ready for the next ARIN meeting. > > Also, at the end of this message I included a context diff to call > out the changes. > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > Replace all of section three with the following rewrite. > > 3 Directory Services > > 3.1 ARIN Directory Services Databases > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. > > 3.2 Directory Information Made Public > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. > > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. ARIN staff shall maintain verification criteria and > post it on the ARIN web site. > > 3.2.1 Non-Responsive Contacts > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. > > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). > > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occurred, and the response from the resource > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. > > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore > reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > > 3.3.1.1 Outside Sources > > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. > > 3.3.2 Acceptable Usage Policy > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff and legal and posted on the ARIN > website. > ARIN may require a signed copy of the AUP before providing > bulk data. > > 3.3.3 Requirements for Internet Accessible Services > > For any method of access which is provided in real time via the > Internet the following requirements must be met: > > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. > > * The distributed information service must allow public > access to reassignment information. The service may > restrict the number of queries allowed per time interval > from a host or subnet to defend against DDOS attacks, > remote mirroring attempts, and other nefarious acts. > > * The distributed information service must return current > information. > > 3.4 Distribution of the ARIN Public Information Database > > 3.4.1 Supported Uses > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > 3.4.2 Prohibited Uses > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence > advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. > > 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. > > 3.5 Distribution of the ARIN Confidential Information Database > > ARIN Staff shall use industry standard procedures to prevent > the distribution of any data in the ARIN Confidential Information > Database. > > 3.6 Implementation Details > > ARIN Staff shall document all implementation specific details for > directory services in a single document available on the web site. > The document must contain, but is not limited to: > > - Database field definitions. > - Update procedures. > - Templates. > - Points of contact. > - Copies of the AUP. > - Verification procedures. > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > Section 4.2.3.7.4: Replace with: > > All reassignment information for current blocks shall be submitted to > ARIN prior to submitting a request for a new allocation. > > -------------------Context diff below---------------------------------- > > 2c2 > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > --- > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > 25,30c25,27 > < identified by ARIN) in the APID in the following cases: > < > < - All resources delegated by ARIN. > < - If allowed by the parent delegation, and requested by > < the contact listed with the parent, a subdelegation of a > < resource. > --- > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > 45,48c42,47 > < Once the resource is suspended ARIN shall make one more request > < of all contacts listed with the resource and the parent > resource > < (if available), and if no response is received in a reasonable > < amount of time the resource shall be reclaimed. > --- > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > 50,51c49,50 > < Third parties may report the inability to make contact with a > < party via information in the APID. In this case ARIN shall > --- > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > 55,57c54,56 > < holder. Offenders who fail to respond to third parties more > < than 4 times per month for three months may have their > resources > < reclaimed at the discretion of ARIN staff. > --- > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > 82a82,84 > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > 89,91c91,93 > < 2 Meet the requirements in section 3.3.3. > < 3 Support the applications in section 3.3.1. > < 4 Prohibit the applications in section 3.3.2. > --- > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > 182,183d183 > < > < Section 4.2.3.7.6: Strike. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From marla_azinger at eli.net Fri Jun 10 15:30:43 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 12:30:43 -0700 Subject: [ppml] Directory Services - section 3.4.3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2015122C6@wava00s2ke2k01.corp.pvt> Ray- your response in regards to section 3.3.1 not 3.4.3 correct? Just to make sure no one is confused. Marla -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ray Plzak Sent: Friday, June 10, 2005 12:23 PM To: ppml at arin.net Subject: RE: [ppml] Directory Services - section 3.4.3 Two items: 1. In response to the media question; ARIN has only provided bulk WHOIS via ftp. The only data CD-ROM that ARIN has produced in the last five years was in conjunction with the database conversion several years ago. One was prepared for each organization and provided all data relative to all of the resources for that organization that was in the ARIN database. 2. Marla raised an interesting point. Does this policy apply to the rWHOIS servers? If so that will need to be taken that into consideration when performing the staff and legal impact analysis. Ray > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > Azinger, Marla > Sent: Friday, June 10, 2005 3:08 PM > To: Leo Bicknell; ppml at arin.net > Subject: RE: [ppml] Directory Services - section 3.4.3 > > " 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list." > > > I request that this section be re-written into a less wordy > (syntactically easy to read) manner. In order to help and not hinder I > have made a suggested re-write. I think I interpreted it right...but if > there is a portion that isnt...let me know. > > Suggested re-write: > > ARIN shall allow usage of the APID per the approved list. If the APID > is used in a way other than what is on the approved usage list then ARIN > staff reserves the right to render the data set ineffective or block the > user. If a desired use/application of the APID is not present on the > current "approved list", then a proposal to add the desired > use/application must be sumbitted and follow the proposal policy. > > > > Marla > > > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo > Bicknell > Sent: Monday, May 09, 2005 1:08 PM > To: ppml at arin.net > Subject: [ppml] Directory Services - Take 2 > > > > Below is my directory services proposal, take two. Based on feedback > from the last meeting, I have removed the option of displaying SWIP > information, and also updated several minor terms which were confusing > from feedback on the mailing list. I'd like to get some discussion > going so this can be ready for the next ARIN meeting. > > Also, at the end of this message I included a context diff to call > out the changes. > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > Replace all of section three with the following rewrite. > > 3 Directory Services > > 3.1 ARIN Directory Services Databases > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. > > 3.2 Directory Information Made Public > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. > > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. ARIN staff shall maintain verification criteria and > post it on the ARIN web site. > > 3.2.1 Non-Responsive Contacts > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. > > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). > > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occurred, and the response from the resource > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. > > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore > reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > > 3.3.1.1 Outside Sources > > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. > > 3.3.2 Acceptable Usage Policy > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff and legal and posted on the ARIN > website. > ARIN may require a signed copy of the AUP before providing > bulk data. > > 3.3.3 Requirements for Internet Accessible Services > > For any method of access which is provided in real time via the > Internet the following requirements must be met: > > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. > > * The distributed information service must allow public > access to reassignment information. The service may > restrict the number of queries allowed per time interval > from a host or subnet to defend against DDOS attacks, > remote mirroring attempts, and other nefarious acts. > > * The distributed information service must return current > information. > > 3.4 Distribution of the ARIN Public Information Database > > 3.4.1 Supported Uses > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > 3.4.2 Prohibited Uses > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence > advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. > > 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. > > 3.5 Distribution of the ARIN Confidential Information Database > > ARIN Staff shall use industry standard procedures to prevent > the distribution of any data in the ARIN Confidential Information > Database. > > 3.6 Implementation Details > > ARIN Staff shall document all implementation specific details for > directory services in a single document available on the web site. > The document must contain, but is not limited to: > > - Database field definitions. > - Update procedures. > - Templates. > - Points of contact. > - Copies of the AUP. > - Verification procedures. > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > Section 4.2.3.7.4: Replace with: > > All reassignment information for current blocks shall be submitted to > ARIN prior to submitting a request for a new allocation. > > -------------------Context diff below---------------------------------- > > 2c2 > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > --- > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > 25,30c25,27 > < identified by ARIN) in the APID in the following cases: > < > < - All resources delegated by ARIN. > < - If allowed by the parent delegation, and requested by > < the contact listed with the parent, a subdelegation of a > < resource. > --- > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > 45,48c42,47 > < Once the resource is suspended ARIN shall make one more request > < of all contacts listed with the resource and the parent > resource > < (if available), and if no response is received in a reasonable > < amount of time the resource shall be reclaimed. > --- > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > 50,51c49,50 > < Third parties may report the inability to make contact with a > < party via information in the APID. In this case ARIN shall > --- > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > 55,57c54,56 > < holder. Offenders who fail to respond to third parties more > < than 4 times per month for three months may have their > resources > < reclaimed at the discretion of ARIN staff. > --- > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > 82a82,84 > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > 89,91c91,93 > < 2 Meet the requirements in section 3.3.3. > < 3 Support the applications in section 3.3.1. > < 4 Prohibit the applications in section 3.3.2. > --- > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > 182,183d183 > < > < Section 4.2.3.7.6: Strike. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From william at elan.net Fri Jun 10 15:38:13 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 10 Jun 2005 12:38:13 -0700 (PDT) Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050610185424.GF2785@vacation.karoshi.com.> References: <20050609213234.GA10868@ussenterprise.ufp.org> <20050610182611.GE2785@vacation.karoshi.com.> <20050610185424.GF2785@vacation.karoshi.com.> Message-ID: On Fri, 10 Jun 2005 bmanning at vacation.karoshi.com wrote: > maintaining servers and updating data are not the same > as a supported and maintained protocol... which was > Michaels claim. Which is exactly what I meant and you appear to have missed. NEITHER whois NOR rwhois protocols are maintained! But comparatively speaking for those unmaintained protocols the use of whois is bigger on the order of 1000:1. So not surprisingly there are calls for ARIN not to support rwhois (but no calls I hear of the same for whois!). But really we can't stop supporting either one until we have adequate replacement and rwhois is more advanced protocol then whois, so whois is NOT replacement for rwhois and calls for ARIN to stop supporting it are wrong and we don't have anything better standardized or implemented to enough of the degree that we could even say that using rwhois IS NOT RECOMMENDED (take it as IETF words). Now once IRIS is out of the ietf standardization bag and begins to get some use than in maybe 2-3 years we can re-examine that and consider saying that RWHOIS support should be shifted out. > tweeking data formats. It is instructive to go read the actual > WHOIS specs. So no, I'm not confused. The great thing about whois is you don't need to read the spec to implement it (and that is coming from somebody who has definitely read the spec many times just in case), its just TCP ask/answer with no serious effort to standardize the functionality or format. So if we agree that whois is just all that and any attempts to introduce format into the response is bad, then lets go ahead and quickly dump RPSL since it apparently standardizes the wrong thing and impedes on somebody else's protocol space! Of course its not all that easy because sometimes protocols are built on top of the other, we have seen it many times - remember earlier post by Michael about SOAP and XML-RPC? LDAP has also been used in that way and in fact had been seriosly considered as basis for future whois at CRISP WG as I mentioned. P.S. If you look at HTML it is in fact tweaking of the old format, they've been rather successful at that too... -- William Leibzon Elan Networks william at elan.net From plzak at arin.net Fri Jun 10 15:38:52 2005 From: plzak at arin.net (Ray Plzak) Date: Fri, 10 Jun 2005 15:38:52 -0400 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D2015122C6@wava00s2ke2k01.corp.pvt> Message-ID: <20050610193856.AFADF1FF05@mercury.arin.net> It had to do with the applicability of all of this policy to rWHOIS. Sorry if I muddied the waters. Ray > -----Original Message----- > From: Azinger, Marla [mailto:marla_azinger at eli.net] > Sent: Friday, June 10, 2005 3:31 PM > To: Ray Plzak; ppml at arin.net > Subject: RE: [ppml] Directory Services - section 3.4.3 > > Ray- your response in regards to section 3.3.1 not 3.4.3 correct? Just > to make sure no one is confused. > > Marla > > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Ray > Plzak > Sent: Friday, June 10, 2005 12:23 PM > To: ppml at arin.net > Subject: RE: [ppml] Directory Services - section 3.4.3 > > > Two items: > > 1. In response to the media question; ARIN has only provided bulk WHOIS > via > ftp. The only data CD-ROM that ARIN has produced in the last five years > was > in conjunction with the database conversion several years ago. One was > prepared for each organization and provided all data relative to all of > the > resources for that organization that was in the ARIN database. > > 2. Marla raised an interesting point. Does this policy apply to the > rWHOIS > servers? If so that will need to be taken that into consideration when > performing the staff and legal impact analysis. > > Ray > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > > Azinger, Marla > > Sent: Friday, June 10, 2005 3:08 PM > > To: Leo Bicknell; ppml at arin.net > > Subject: RE: [ppml] Directory Services - section 3.4.3 > > > > " 3.4.3 Other Uses > > > > ARIN shall allow all non-prohibited uses of the APID, however > > unless those uses are listed as a supported use the data set > > may be changed in such a way as to render them ineffective, > > or they may be blocked outright as deemed necessary by ARIN > > staff. Users of applications not listed who are concerned > > that they are supported should introduce a proposal to add > > their application to the supported list." > > > > > > I request that this section be re-written into a less wordy > > (syntactically easy to read) manner. In order to help and not hinder I > > have made a suggested re-write. I think I interpreted it right...but if > > there is a portion that isnt...let me know. > > > > Suggested re-write: > > > > ARIN shall allow usage of the APID per the approved list. If the APID > > is used in a way other than what is on the approved usage list then ARIN > > staff reserves the right to render the data set ineffective or block the > > user. If a desired use/application of the APID is not present on the > > current "approved list", then a proposal to add the desired > > use/application must be sumbitted and follow the proposal policy. > > > > > > > > Marla > > > > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo > > Bicknell > > Sent: Monday, May 09, 2005 1:08 PM > > To: ppml at arin.net > > Subject: [ppml] Directory Services - Take 2 > > > > > > > > Below is my directory services proposal, take two. Based on feedback > > from the last meeting, I have removed the option of displaying SWIP > > information, and also updated several minor terms which were confusing > > from feedback on the mailing list. I'd like to get some discussion > > going so this can be ready for the next ARIN meeting. > > > > Also, at the end of this message I included a context diff to call > > out the changes. > > > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > > > Replace all of section three with the following rewrite. > > > > 3 Directory Services > > > > 3.1 ARIN Directory Services Databases > > > > The ARIN Public Information Database (APID) is a collection > > of information created and collected by ARIN during the due > > course of business which the ARIN membership has deemed public > > information and decided to publish. > > > > The ARIN Confidential Information Database (ACID) is a collection > > of information created and collected by ARIN during the due course > > of business which the ARIN membership has deemed is confidential > > information that should be kept under a strict privacy policy. > > > > 3.2 Directory Information Made Public > > > > ARIN shall publish verified contact information and the > > resource(s) allocated (including identification for that > > allocation, like date of allocation or other information > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > > > > ARIN shall insure all contact information in the APID is > > verified from time to time and is correct to the best of ARIN's > > ability. ARIN staff shall maintain verification criteria and > > post it on the ARIN web site. > > > > 3.2.1 Non-Responsive Contacts > > > > If ARIN is unable to verify contact information via the normal > > verification procedure ARIN shall attempt to notify the parent > > of the resource to have the information updated. If there is > > no parent, or if the data is not corrected in a reasonable > > amount of time the resource shall be SUSPENDED. > > > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > > > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > > attempt the contact verification procedure for that contact > > immediately. If a response is received, ARIN should document > > that a problem occurred, and the response from the resource > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > > > > If a third party submits reports of the inability to make contact > > that are subsequently disproven, ARIN may choose to ignore > > reports > > from specific companies, people, e-mail addresses, or any other > > classification means as appropriate. > > > > The ARIN staff shall publish the time thresholds and procedural > > details to implement this policy on the ARIN web site. > > > > If a resource is reclaimed under no circumstances shall the > > holder of that resource be entitled to a refund of any fees. > > > > 3.3 Data Distribution > > > > 3.3.1 Methods of Access > > > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > > 3.3.1.1 Outside Sources > > > > ARIN may refer a query to a outside source (for instance via > > RWHOIS or HTTP redirect). Outside sources must: > > > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > > > > 3.3.2 Acceptable Usage Policy > > > > All data provided shall be subject to an AUP. The AUP shall > > be written by ARIN staff and legal and posted on the ARIN > > website. > > ARIN may require a signed copy of the AUP before providing > > bulk data. > > > > 3.3.3 Requirements for Internet Accessible Services > > > > For any method of access which is provided in real time via the > > Internet the following requirements must be met: > > > > * The distributed information service must be operational > > 24 hours a day, 7 days a week to both the general public > > and ARIN staff. The service is allowed reasonable > > downtime for server maintenance according to generally > > accepted community standards. > > > > * The distributed information service must allow public > > access to reassignment information. The service may > > restrict the number of queries allowed per time interval > > from a host or subnet to defend against DDOS attacks, > > remote mirroring attempts, and other nefarious acts. > > > > * The distributed information service must return current > > information. > > > > 3.4 Distribution of the ARIN Public Information Database > > > > 3.4.1 Supported Uses > > > > ARIN shall make the APID available for the following uses > > (supported uses): > > > > 1 ARIN's use in implementing ARIN policies and other > > business. > > 2 Community verification, allowing members of the community > > to confirm the proper users of the various resources ARIN > > controls. > > 3 Statistic gathering by ARIN and third parties on resource > > utilization. > > 4 As a contact database to facilitate communication with the > > person or entity responsible for a particular resource. > > > > 3.4.2 Prohibited Uses > > > > ARIN prohibits the use of the APID for the following uses: > > > > 1 Sending any unsolicited commercial correspondence > > advertising > > a product or service to any address (physical or electronic) > > listed in the APID. > > 2 Using data in the APID to facilitate violating any state, > > federal, or local law. > > > > 3.4.3 Other Uses > > > > ARIN shall allow all non-prohibited uses of the APID, however > > unless those uses are listed as a supported use the data set > > may be changed in such a way as to render them ineffective, > > or they may be blocked outright as deemed necessary by ARIN > > staff. Users of applications not listed who are concerned > > that they are supported should introduce a proposal to add > > their application to the supported list. > > > > 3.5 Distribution of the ARIN Confidential Information Database > > > > ARIN Staff shall use industry standard procedures to prevent > > the distribution of any data in the ARIN Confidential Information > > Database. > > > > 3.6 Implementation Details > > > > ARIN Staff shall document all implementation specific details for > > directory services in a single document available on the web site. > > The document must contain, but is not limited to: > > > > - Database field definitions. > > - Update procedures. > > - Templates. > > - Points of contact. > > - Copies of the AUP. > > - Verification procedures. > > > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > > > Section 4.2.3.7.4: Replace with: > > > > All reassignment information for current blocks shall be submitted to > > ARIN prior to submitting a request for a new allocation. > > > > -------------------Context diff below---------------------------------- > > > > 2c2 > > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > > --- > > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > 25,30c25,27 > > < identified by ARIN) in the APID in the following cases: > > < > > < - All resources delegated by ARIN. > > < - If allowed by the parent delegation, and requested by > > < the contact listed with the parent, a subdelegation of a > > < resource. > > --- > > > identified by ARIN) in the APID for all resources delegated > > > by ARIN. In addition, all reassignment information as defined > > > by section 4.2.3.7 will be included in the APID. > > 45,48c42,47 > > < Once the resource is suspended ARIN shall make one more request > > < of all contacts listed with the resource and the parent > > resource > > < (if available), and if no response is received in a reasonable > > < amount of time the resource shall be reclaimed. > > --- > > > Once the resource is suspended ARIN shall make one more > > > request of all contacts listed with the resource and the > > > parent resource (if available), and if no response is received > > > in a reasonable amount of time the resource shall be reclaimed > > > (APID records removed, DNS delegations removed, the space > > > returned to the free pool). > > 50,51c49,50 > > < Third parties may report the inability to make contact with a > > < party via information in the APID. In this case ARIN shall > > --- > > > Third parties may report the inability to make contact with > > > a party via information in the APID. In this case ARIN shall > > 55,57c54,56 > > < holder. Offenders who fail to respond to third parties more > > < than 4 times per month for three months may have their > > resources > > < reclaimed at the discretion of ARIN staff. > > --- > > > holder. Resource holders who fail to respond to third parties > > > more than 4 times per month for three months may have their > > > resources reclaimed at the discretion of ARIN staff. > > 82a82,84 > > > All users of the APID must agree to the ARIN AUP. ARIN staff > > > may make the APID available via other methods as conveniant. > > > > > 89,91c91,93 > > < 2 Meet the requirements in section 3.3.3. > > < 3 Support the applications in section 3.3.1. > > < 4 Prohibit the applications in section 3.3.2. > > --- > > > 2 Support the applications in section 3.3.1. > > > 3 Prohibit the applications in section 3.3.2. > > > 4 Meet the requirements in section 3.3.3. > > 182,183d183 > > < > > < Section 4.2.3.7.6: Strike. > > > > -- > > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > > PGP keys at http://www.ufp.org/~bicknell/ > > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org > > From woody at pch.net Fri Jun 10 15:36:52 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 10 Jun 2005 12:36:52 -0700 (PDT) Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> Message-ID: > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list." Let's just get clear what this paragraph is trying to say right now, first: It's saying that ARIN will maintain BOTH a list of ALLOWED (and supported) uses, AND a list of PROHIBITED uses. Anything not on either list is unsupported and may be blocked at any time at the discretion of staff. An ongoing mechanism for adding things to the "allowed" list is mandated. This seems like the same overspecification rathole we usually fall into, which makes for really vague, confusing, and difficult-to-implement policies. How about just deleting section 3.3.2, and replacing sections 3.4 and 3.5 with: 3.4 Acceptable Use of the ARIN Public Information Database 3.4.1 ARIN prohibits use of the APID for: 3.4.1.1 the addressing of any unsolicited commercial correspondence advertising a product or service, or 3.4.1.2 to facilitate the violation of any law. 3.4.2 Other uses of the APID shall be allowed, so long as they do not adversely impact use of the APID by others, or impose an unreasonable burden upon ARIN. 3.5 Distribution of the APID 3.5.1 While recipients of the APID may reuse or redistribute data contained in the APID, any derivatives must also abide by the Acceptable Use Policy defined in Section 3.4. Is anything significant lost or left out by that edit? From andy at hxr.us Fri Jun 10 15:41:53 2005 From: andy at hxr.us (Andrew Newton) Date: Fri, 10 Jun 2005 15:41:53 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: <17065.52964.923425.653568@roam.psg.com> Message-ID: For what it is worth, I agree with Ed. On Jun 10, 2005, at 2:05 PM, Edward Lewis wrote: > The IETF works on volunteered actions from the community. ARIN is > ideally suited, as much as any organization in North America, to > volunteer the knowledgeable resources to push through the > specification for IRIS's address registry. (The doc in question is > http://www.ietf.org/internet-drafts/draft-ietf-crisp-iris- > areg-11.txt.) ARIN can't "ram" this through the IETF, but the > membership should keep participation in this a priority. > > IRIS isn't the only engineering concern, it's one of many. If we > don't use policy to track engineering efforts like this, what do we > use? (That was the question I posed during the open policy bof in > Orlando.) How do we indicate that ARIN spends time and effort on > helping IRIS through the IETF process as well as helps provide the > servers and clients? (Note: "provide" does not mean the staff > implements and maintains the code. It *could* mean that the budget > has money set aside to fund the development.) Some of the ARIN staff have been participating the working group. If they've been missing their kids birthdays or whatever because there is no proper support in place for them, then something needs to be adjusted. So I agree with Ed. The intent of IRIS-AREG in CRISP is to have something that works with all RIRs, and therefore the participation by ARIN staff is necessary. -andy From bmanning at vacation.karoshi.com Fri Jun 10 15:42:57 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 10 Jun 2005 19:42:57 +0000 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: <20050609213234.GA10868@ussenterprise.ufp.org> <20050610182611.GE2785@vacation.karoshi.com.> <20050610185424.GF2785@vacation.karoshi.com.> Message-ID: <20050610194257.GA3952@vacation.karoshi.com.> > The great thing about whois is you don't need to read the spec to implement > it thats deserving a tee-shirt-level quote. thanks william. --bill From marla_azinger at eli.net Fri Jun 10 15:44:41 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 12:44:41 -0700 Subject: [ppml] Directory Services - section 3.4.3 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D2015122C7@wava00s2ke2k01.corp.pvt> I agree and like what you suggest. Thanks for helping to simplify! Marla -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Friday, June 10, 2005 12:37 PM To: Azinger, Marla Cc: Leo Bicknell; ppml at arin.net Subject: RE: [ppml] Directory Services - section 3.4.3 > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list." Let's just get clear what this paragraph is trying to say right now, first: It's saying that ARIN will maintain BOTH a list of ALLOWED (and supported) uses, AND a list of PROHIBITED uses. Anything not on either list is unsupported and may be blocked at any time at the discretion of staff. An ongoing mechanism for adding things to the "allowed" list is mandated. This seems like the same overspecification rathole we usually fall into, which makes for really vague, confusing, and difficult-to-implement policies. How about just deleting section 3.3.2, and replacing sections 3.4 and 3.5 with: 3.4 Acceptable Use of the ARIN Public Information Database 3.4.1 ARIN prohibits use of the APID for: 3.4.1.1 the addressing of any unsolicited commercial correspondence advertising a product or service, or 3.4.1.2 to facilitate the violation of any law. 3.4.2 Other uses of the APID shall be allowed, so long as they do not adversely impact use of the APID by others, or impose an unreasonable burden upon ARIN. 3.5 Distribution of the APID 3.5.1 While recipients of the APID may reuse or redistribute data contained in the APID, any derivatives must also abide by the Acceptable Use Policy defined in Section 3.4. Is anything significant lost or left out by that edit? From woody at pch.net Fri Jun 10 15:48:03 2005 From: woody at pch.net (Bill Woodcock) Date: Fri, 10 Jun 2005 12:48:03 -0700 (PDT) Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> References: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> Message-ID: More suggested edits: > ARIN shall insure all contact information in the APID Perhaps you mean "ensure that". > is verified from time to time and is correct to the best of > ARIN's ability. Estimation rather than ability. Correctness is a property, not an action. > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. The "parents" of resources are themselves resources, and not subject to notification. The _recipients_ of resources, or the _recipients_ of _parent resources_, however, are organizations, and thus subject to notification. > Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. While I appreciate the intention here, I'm sure someone can generate enough contact attempts to overwhelm the ability of a reasonable resource-holder to respond. So I'm not sure that this is actually useful. I do agree that if they fail to respond to _ARIN contacts_, their space should eventually be pulled. > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. Vast overspecification. > ARIN shall publish the APID in the following methods using > industry standard practices: > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. Again, this is vast overspecification. > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. Points 2-4 are redundant with point 1, and can thus be deleted. > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. These two sentences are mutually exclusive. Pick one, preferably the latter, and delete the other. > * The distributed information service must return current > information. Overspecification. Of course that'll be done to the best of staff's ability. -Bill From marla_azinger at eli.net Fri Jun 10 16:04:13 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 10 Jun 2005 13:04:13 -0700 Subject: [ppml] Directory Services - section 4.2.3.7.4 Message-ID: <10ECB7F03C568F48B9213EF9E7F790D209B15A@wava00s2ke2k01.corp.pvt> "Section 4.2.3.7.4: Replace with: All reassignment information for current blocks shall be submitted to ARIN prior to submitting a request for a new allocation." I'm not clear on what this is supposed to be clarifying or correcting. After disection of both (current and proposed)...I dont agree with this change. This change appears to say a seperate submittion must be made to ARIN before requesting more. When I think the point of this section is supposed just mean... "usage (reallocation and reassignments) need to be visible on WHOIS or RWHOIS before sending in a new request to ARIN." Isnt that what it is supposed to mean? Marla -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of Leo Bicknell Sent: Thursday, June 09, 2005 2:33 PM To: ppml at arin.net Subject: Re: [ppml] Directory Services - Take 2 Now that things have been quiet for a while, a resend to see if we can spark some discussion on directory services.... In a message written on Mon, May 09, 2005 at 04:07:42PM -0400, Leo Bicknell wrote: > Below is my directory services proposal, take two. Based on feedback > from the last meeting, I have removed the option of displaying SWIP > information, and also updated several minor terms which were confusing > from feedback on the mailing list. I'd like to get some discussion > going so this can be ready for the next ARIN meeting. > > Also, at the end of this message I included a context diff to call > out the changes. > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > > Replace all of section three with the following rewrite. > > 3 Directory Services > > 3.1 ARIN Directory Services Databases > > The ARIN Public Information Database (APID) is a collection > of information created and collected by ARIN during the due > course of business which the ARIN membership has deemed public > information and decided to publish. > > The ARIN Confidential Information Database (ACID) is a collection > of information created and collected by ARIN during the due course > of business which the ARIN membership has deemed is confidential > information that should be kept under a strict privacy policy. > > 3.2 Directory Information Made Public > > ARIN shall publish verified contact information and the > resource(s) allocated (including identification for that > allocation, like date of allocation or other information > identified by ARIN) in the APID for all resources delegated > by ARIN. In addition, all reassignment information as defined > by section 4.2.3.7 will be included in the APID. > > ARIN shall insure all contact information in the APID is > verified from time to time and is correct to the best of ARIN's > ability. ARIN staff shall maintain verification criteria and > post it on the ARIN web site. > > 3.2.1 Non-Responsive Contacts > > If ARIN is unable to verify contact information via the normal > verification procedure ARIN shall attempt to notify the parent > of the resource to have the information updated. If there is > no parent, or if the data is not corrected in a reasonable > amount of time the resource shall be SUSPENDED. > > Once the resource is suspended ARIN shall make one more > request of all contacts listed with the resource and the > parent resource (if available), and if no response is received > in a reasonable amount of time the resource shall be reclaimed > (APID records removed, DNS delegations removed, the space > returned to the free pool). > > Third parties may report the inability to make contact with > a party via information in the APID. In this case ARIN shall > attempt the contact verification procedure for that contact > immediately. If a response is received, ARIN should document > that a problem occurred, and the response from the resource > holder. Resource holders who fail to respond to third parties > more than 4 times per month for three months may have their > resources reclaimed at the discretion of ARIN staff. > > If a third party submits reports of the inability to make contact > that are subsequently disproven, ARIN may choose to ignore reports > from specific companies, people, e-mail addresses, or any other > classification means as appropriate. > > The ARIN staff shall publish the time thresholds and procedural > details to implement this policy on the ARIN web site. > > If a resource is reclaimed under no circumstances shall the > holder of that resource be entitled to a refund of any fees. > > 3.3 Data Distribution > > 3.3.1 Methods of Access > > ARIN shall publish the APID in the following methods using > industry standard practices: > > - Via the WHOIS protocol. > - Via a query form accessible via the HTTP protocol. > - Via FTP to users who complete the bulk data form. > - Via CDROM to users who complete the bulk data form. > - Via the RWHOIS protocol. > > All users of the APID must agree to the ARIN AUP. ARIN staff > may make the APID available via other methods as conveniant. > > 3.3.1.1 Outside Sources > > ARIN may refer a query to a outside source (for instance via > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > 2 Support the applications in section 3.3.1. > 3 Prohibit the applications in section 3.3.2. > 4 Meet the requirements in section 3.3.3. > > 3.3.2 Acceptable Usage Policy > > All data provided shall be subject to an AUP. The AUP shall > be written by ARIN staff and legal and posted on the ARIN website. > ARIN may require a signed copy of the AUP before providing > bulk data. > > 3.3.3 Requirements for Internet Accessible Services > > For any method of access which is provided in real time via the > Internet the following requirements must be met: > > * The distributed information service must be operational > 24 hours a day, 7 days a week to both the general public > and ARIN staff. The service is allowed reasonable > downtime for server maintenance according to generally > accepted community standards. > > * The distributed information service must allow public > access to reassignment information. The service may > restrict the number of queries allowed per time interval > from a host or subnet to defend against DDOS attacks, > remote mirroring attempts, and other nefarious acts. > > * The distributed information service must return current > information. > > 3.4 Distribution of the ARIN Public Information Database > > 3.4.1 Supported Uses > > ARIN shall make the APID available for the following uses > (supported uses): > > 1 ARIN's use in implementing ARIN policies and other > business. > 2 Community verification, allowing members of the community > to confirm the proper users of the various resources ARIN > controls. > 3 Statistic gathering by ARIN and third parties on resource > utilization. > 4 As a contact database to facilitate communication with the > person or entity responsible for a particular resource. > > 3.4.2 Prohibited Uses > > ARIN prohibits the use of the APID for the following uses: > > 1 Sending any unsolicited commercial correspondence advertising > a product or service to any address (physical or electronic) > listed in the APID. > 2 Using data in the APID to facilitate violating any state, > federal, or local law. > > 3.4.3 Other Uses > > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list. > > 3.5 Distribution of the ARIN Confidential Information Database > > ARIN Staff shall use industry standard procedures to prevent > the distribution of any data in the ARIN Confidential Information > Database. > > 3.6 Implementation Details > > ARIN Staff shall document all implementation specific details for > directory services in a single document available on the web site. > The document must contain, but is not limited to: > > - Database field definitions. > - Update procedures. > - Templates. > - Points of contact. > - Copies of the AUP. > - Verification procedures. > > 3.7 [Routing Registry] Copy Verbatim from the existing 3.4. > > Section 4.2.3.7.4: Replace with: > > All reassignment information for current blocks shall be submitted to > ARIN prior to submitting a request for a new allocation. > > -------------------Context diff below---------------------------------- > > 2c2 > < $Author: bicknell $ - $Date: 2005/02/03 15:27:41 $ - $Revision: 1.2 $ > --- > > $Author: bicknell $ - $Date: 2005/05/09 20:06:30 $ - $Revision: 1.4 $ > 25,30c25,27 > < identified by ARIN) in the APID in the following cases: > < > < - All resources delegated by ARIN. > < - If allowed by the parent delegation, and requested by > < the contact listed with the parent, a subdelegation of a > < resource. > --- > > identified by ARIN) in the APID for all resources delegated > > by ARIN. In addition, all reassignment information as defined > > by section 4.2.3.7 will be included in the APID. > 45,48c42,47 > < Once the resource is suspended ARIN shall make one more request > < of all contacts listed with the resource and the parent resource > < (if available), and if no response is received in a reasonable > < amount of time the resource shall be reclaimed. > --- > > Once the resource is suspended ARIN shall make one more > > request of all contacts listed with the resource and the > > parent resource (if available), and if no response is received > > in a reasonable amount of time the resource shall be reclaimed > > (APID records removed, DNS delegations removed, the space > > returned to the free pool). > 50,51c49,50 > < Third parties may report the inability to make contact with a > < party via information in the APID. In this case ARIN shall > --- > > Third parties may report the inability to make contact with > > a party via information in the APID. In this case ARIN shall > 55,57c54,56 > < holder. Offenders who fail to respond to third parties more > < than 4 times per month for three months may have their resources > < reclaimed at the discretion of ARIN staff. > --- > > holder. Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. > 82a82,84 > > All users of the APID must agree to the ARIN AUP. ARIN staff > > may make the APID available via other methods as conveniant. > > > 89,91c91,93 > < 2 Meet the requirements in section 3.3.3. > < 3 Support the applications in section 3.3.1. > < 4 Prohibit the applications in section 3.3.2. > --- > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > 182,183d183 > < > < Section 4.2.3.7.6: Strike. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From randy at psg.com Fri Jun 10 18:55:39 2005 From: randy at psg.com (Randy Bush) Date: Fri, 10 Jun 2005 15:55:39 -0700 Subject: [ppml] Directory Services - Take 2 References: <17065.52964.923425.653568@roam.psg.com> Message-ID: <17066.6763.81553.797424@roam.psg.com> separation of policy from mecahnism is taught in opsys 101 randy From william at elan.net Sat Jun 11 14:31:37 2005 From: william at elan.net (william(at)elan.net) Date: Sat, 11 Jun 2005 11:31:37 -0700 (PDT) Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: References: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> Message-ID: On Fri, 10 Jun 2005, Bill Woodcock wrote: > > If ARIN is unable to verify contact information via the normal > > verification procedure ARIN shall attempt to notify the parent > > of the resource to have the information updated. > > The "parents" of resources are themselves resources, and not subject to > notification. The _recipients_ of resources, or the _recipients_ of > _parent resources_, however, are organizations, and thus subject to > notification. Parents of resources are organizations, but you really are not going to contact organization directly, you're going to contact POC for that organization (which ones?). > > Resource holders who fail to respond to third parties > > more than 4 times per month for three months may have their > > resources reclaimed at the discretion of ARIN staff. Again its not resource holder who fails to respond, its POC that fails to respond. My view is that organization can be considered to have bad resource info and uncontactable if none of its POCs can be contacted. Also where did "4 times per month for three month" detail came from? > While I appreciate the intention here, I'm sure someone can generate > enough contact attempts to overwhelm the ability of a reasonable > resource-holder to respond. There are also cases when one organization is not contactable by somebody else because of its local mail or other settings (spam filters that prevent contact from everyone from specific country are known to exist). ARIN staff should have reasonable discretion to decide on if there are enough reports being made to conclude that POC is not responding not to just one or two people but majority of those who want to contact it. > So I'm not sure that this is actually useful. > I do agree that if they fail to respond to _ARIN contacts_, their space > should eventually be pulled. That's a given for sure. > > The ARIN staff shall publish the time thresholds and procedural > > details to implement this policy on the ARIN web site. > > Vast overspecification. I disagree. ARIN is not required to adapt specific procedures on how its determining if contact is bad, etc. All it says is that the procedures it decides on should be public (and ARIN staff can change it any time they like I'd expect). > > ARIN shall publish the APID in the following methods using > > industry standard practices: > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > Again, this is vast overspecification. Again disagree. I think minimum required support mechanisms for data access should be made available and listed. ARIN staff is free to decide to support something else like LDAP but not at the expense of protocols widely used like whois. > > ARIN may refer a query to a outside source (for instance via > > RWHOIS or HTTP redirect). Outside sources must: > > 1 Have an AUP deemed compatible with the ARIN AUP by ARIN staff. > > 2 Support the applications in section 3.3.1. > > 3 Prohibit the applications in section 3.3.2. > > 4 Meet the requirements in section 3.3.3. > > Points 2-4 are redundant with point 1, and can thus be deleted. Points 2-4 are redundant only if AUP is large enough to include 3.3.x which is not clear right now. > > * The distributed information service must be operational > > 24 hours a day, 7 days a week to both the general public > > and ARIN staff. The service is allowed reasonable > > downtime for server maintenance according to generally > > accepted community standards. > > These two sentences are mutually exclusive. Pick one, preferably the > latter, and delete the other. I think instead of saying the service "MUST" be operational, it should say: * The distributed information service is expected to be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. Then the two sentences in the paragraph are no longer inconsistent with each other. > > * The distributed information service must return current > > information. > > Overspecification. Of course that'll be done to the best of staff's > ability. Again changing from "must return " to "is expected to return" may help. -- William Leibzon Elan Networks william at elan.net From Michael.Dillon at btradianz.com Mon Jun 13 05:26:04 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 10:26:04 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050610151237.GA48542@ussenterprise.ufp.org> Message-ID: > In a message written on Mon, May 09, 2005 at 04:07:42PM -0400, Leo > Bicknell wrote: > > ARIN shall publish the APID in the following methods using > > industry standard practices: > This section sets forth the minimum set of things ARIN staff must > support _NO MATTER WHAT THE COST_. Interesting to note that you saw no need to use the acronym APID in your posting. In that case, why do we need to invent 2 new acronymns, APID and ACID? On the one hand, ACID is already a common technical acronym used by people who deal with databases, so why should the ARIN internal database suddenly try to coopt this term? Seems to me that the "ARIN whois directory" is good enough and most of the time can be shortened to "whois directory". Bye bye APID. As for ARIN's private data, it certainly does not need a public acronym or even a public name. And I don't really see the need to even mention it in policies beyond the mention of the fact that ARIN collects certain bits of information. We can assume that this information is stored in various internal databases that are protected by ARIN's privacy policies and the laws of the USA. No need to deal with this stuff in the "whois directory" policy. --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 05:37:47 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 10:37:47 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > > What percentage of requests for data are CD-ROM based? > > Presumably a very small number, which would seem to make it inefficient to > keep a mechanism in place to serve a small number of potential requests > which could just as well be served via the normal mechanism. Unless ARIN charges a fee to recover the costs involved. In that case, the policy should not mention CD-ROMs at all, it should just have something about ARIN being open to send the data on some media if the requestor covers the costs. If the requestor offers to buy a Blue-Ray writer for ARIN in order to receive Blue-Ray disks, then I would prefer that ARIN staff deal with such requests without the hinderance of poorly thought out policies. ARIN has a woeful history of getting stuck in a technical rut with the whois directory and we have an opportunity here to correct that. Let's not create new ruts for the future. Deprecate rwhois, document the existing REST service (web form query), add an XML encapsulation of the data (borrowed from IRIS) so that whois and REST users can optionally request the easy-to-parse data, and set up an LDAP server using the same data schema as IRIS. That way we move ahead. We get rid of rwhois which is a bad protocol and a single bad implementation. We fix whois by making the data parseable but we do so in a backwards compatible manner (-x option). We provide data in a parseable format (XML or LDAP) and the XML format is integrated into the two existing delivery mechanisms, whois and REST. This sets the stage for possible future transition to IRIS. Or, if IRIS fails or we decide that it is basicall a domain registrar protocol and overkill for ARIN, we could either transition to LDAP, or stick with the improved REST or the improved whois. Why so many choices? Simply because we are 90% of the way there already, so it is not a lot of effort to put all of this in place. And since none of us are crystal ball readers, it seems wise to create a level playing field of 3 protocols that are now roughly level in features, and see where that takes us. --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 05:50:15 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 10:50:15 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > > And even though the IETF hasn't finished working on > > IRIS, ARIN should at least support XML-encoding of the > > whois data. > > In what form? You want ARIN to create its own standard? That seems to be the historical precedent... But by reusing the IRIS XML schema, ARIN isn't really creating it's own standard. It's more like a partial implementation of the most useful part of some work that has not yet completed its track through the IETF. > BTW - I think IRIS needs to be explicitely mentioned in the proposed > policy - by the time policy is approved (probably within a year if not > longer) and then implemented, it'd be IETF proposed standard fore sure. I disagree. Just because something is an IETF standard doesn't mean that ARIN ever needs to use it. IRIS was primarily created to meet the needs of domain name registries and registrars. And we simply don't know if it will actually meet anyone's needs or be widely deployed. ARIN's needs are more simple and we would be better off to sit on the sidelines and wait until the dust settles. I don't see LDAP as a competitor for IRIS, but more as a replacement for rwhois. All of the larger ARIN members already run LDAP servers in their company and have staff who know how to set up and run an LDAP server. But precious few have anyone who knows how to run rwhois. Also, LDAP has a security model that could replace SWIP, i.e. I could put all my address data into my LDAP server and give ARIN a password that allows them to read the private data that they need to evaluate my new address applications. If we officially deprecate rwhois in the new policy, then I would like to see something there to continue ARIN's support of distributing the address data rather than centralising it all into a single SWIP repository. I think there is real social value in the distributed database model and I want ARIN to continue to support that. I see LDAP as the easiest way to continue to do this. It is easy for the ISP to set up an operate an LDAP server. And it is easy for those who need to query the data to get it from my LDAP server because LDAP is widely supported by scripting languages and by email server software. Often the queries of the ARIN whois directory are directly or indirectly supporting email spam filtering which is why the support of LDAP in email server software matters. --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 05:57:32 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 10:57:32 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > How do we indicate that ARIN spends time and effort on > helping IRIS through the IETF process as well as helps provide the > servers and clients? (Note: "provide" does not mean the staff > implements and maintains the code. It *could* mean that the budget > has money set aside to fund the development.) > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 > NeuStar I believe you are the primary author of IRIS and since Neustar is in the domain name business, the main group which will benefit from IRIS, I have to ask this. Why should ARIN spend money or energy to support the domain name industry? It is simply not what ARIN is there to do. And I wonder, if ARIN did spend money on IRIS development, how much of that money might find its way into your pocket somewhere down the line? I'm not accusing you of anything here, but this discussion is about policymaking and it is customary, when making policies, to make sure that any conflicts of interest are publicly noted so that people can factor them into their decisions. Perhaps you have never found yourself in such a position before and are not aware of this. --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 06:06:33 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 11:06:33 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050610185424.GF2785@vacation.karoshi.com.> Message-ID: > maintaining servers and updating data are not the same > as a supported and maintained protocol... which was > Michaels claim. None of the RIRs, to my knowledge, have > made a fundamental change in the whois protocol, they are just > tweeking data formats. It is instructive to go read the actual > WHOIS specs. So no, I'm not confused. And I am suggesting that ARIN do it's own data tweak by offering the easy-to-parse option of getting the whois data on port 43 (and via REST) in the XML encapsulation defined by IRIS. It has been 10 years since I looked at whois protocol documents but I have always thought of it as a non-protocol protocol. In any case, my argument is probably more with implementations that with protocols in the abstract. The rwhois mess is what I am trying to get rid of. Now that I know there is an update, I either have to find someone who hasn't looked at rwhois in 2 years to figure out whether it is any use and implement it, or I have to do so myself. If this were an LDAP server, then one of the people on staff who deal with LDAP would have told me about the next software upgrade and made a recommendation about whether or not we should upgrade and what benefits we might get. That is what I mean by "supported", not sporadic activity on a mostly dead mailing list. --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 06:10:07 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 11:10:07 +0100 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <10ECB7F03C568F48B9213EF9E7F790D209B159@wava00s2ke2k01.corp.pvt> Message-ID: > ARIN shall allow all non-prohibited uses of the APID, however > unless those uses are listed as a supported use the data set > may be changed in such a way as to render them ineffective, > or they may be blocked outright as deemed necessary by ARIN > staff. Users of applications not listed who are concerned > that they are supported should introduce a proposal to add > their application to the supported list." ARIN shall publish a list of prohibited uses of the data published in the ARIN whois directory. Any other use is allowed. ARIN reserves the right to change the data format of the published directory with 6 months public notice. --Michael Dillon From andy at hxr.us Mon Jun 13 08:08:41 2005 From: andy at hxr.us (Andrew Newton) Date: Mon, 13 Jun 2005 08:08:41 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: On Jun 13, 2005, at 5:50 AM, Michael.Dillon at btradianz.com wrote: > IRIS was primarily created to > meet the needs of domain name registries and registrars. Actually, both the IRIS and FIRS proposals had the address registry components from the start. This type of argument can easily be used in the following ways: HTTP was primarily created to meet the needs of HTML (and not XML). LDAP was primarily created to meet the needs of X.500 networks (and not IP networks). -andy From Michael.Dillon at btradianz.com Mon Jun 13 08:35:26 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 13:35:26 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > > IRIS was primarily created to > > meet the needs of domain name registries and registrars. > > Actually, both the IRIS and FIRS proposals had the address registry > components from the start. This type of argument can easily be used > in the following ways: > HTTP was primarily created to meet the needs of HTML (and not XML). > LDAP was primarily created to meet the needs of X.500 networks > (and not IP networks). Actually, no. HTTP was primarily created to meet the needs of the international scientific community for sharing research documents, in particular the high energy physics community. LDAP was primarily created for corporations who wanted to provide IP network access to directories that were on non-IP protocol networks. In both cases, the protocol was created to serve the needs of a group of PEOPLE. And in both cases, the application of the protocol spread to meet the needs of a more general population, i.e. all people who want to share any kind of documents, and all organizations who want to publish directories of any type. IRIS (formerly called FIRS) hasn't even gotten to first base yet. And although the architects did envisage IRIS spreading slightly beyond the domain name registrar community, that doesn't mean that anyone has proven that it will meet those needs. Actually, given the fact that someone whipped together a working prototype of LDAP-based FIRS in a couple of days, I wonder why people continue to chase this overly narrow protocol. Wouldn't it make more sense to develop an XML directory access protocol that provides XML-encapsulated access to directories that are currently stored in LDAP backends? In my opinion, there is absolutely no real-world need for IRIS that couldn't be met by a more generic XML-encapsulated protocol. Seems to me that the two main arguments against LDAP are that some people find the wire-encoding used by LDAP to be ugly. So why not create XDAP and replace ASN.1 with XML? That separates the schema design from the protocol. And the second thing that people have against LDAP is that it uses a hierarchical data schema (rather similar to RIPE and RPSL and SNMP) that is rooted in some ANSI/ITU top level. That was solved a long time ago by hanging things off of a branch registered by the IETF. I know this is veering a bit far from stuff that should be written into ARIN policy, but this list is the only place I know of to provide public input to the ARIN BoT, ARIN staff, and ARIN AC. The BoT and the staff do have a certain amount of freedom of action to improve things without policies having to be written and I would like to think that when they see ideas expressed on this list, they at least give those ideas some consideration as they put together thier own roadmaps for the future. Speaking of which, what is the future of ARIN in an IPv6 world? Do we close up shop? Or is the coordination and communication and publishing role of ARIN still something valuable which we should develop further? --Michael Dillon From andy at hxr.us Mon Jun 13 09:14:15 2005 From: andy at hxr.us (Andrew Newton) Date: Mon, 13 Jun 2005 09:14:15 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: <72CEE632-4A45-43F2-A0C3-BD28CBF230EF@hxr.us> On Jun 13, 2005, at 8:35 AM, Michael.Dillon at btradianz.com wrote: > IRIS (formerly called FIRS) IRIS and FIRS were never the same thing. They were two totally different proposals. [..snip..] > Actually, given the fact that someone whipped together a working > prototype of LDAP-based FIRS in a couple of days, I wonder why > people continue to chase this overly narrow protocol. Wouldn't > it make more sense to develop an XML directory access protocol > that provides XML-encapsulated access to directories that are > currently stored in LDAP backends? LDAP is a protocol. The back-end for ARIN is what is stored in their relational databases. Are you proposing that ARIN re-engineer their entire registration system just so they can have an LDAP backend? -andy From Michael.Dillon at btradianz.com Mon Jun 13 09:26:28 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 14:26:28 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <72CEE632-4A45-43F2-A0C3-BD28CBF230EF@hxr.us> Message-ID: > > Actually, given the fact that someone whipped together a working > > prototype of LDAP-based FIRS in a couple of days, I wonder why > > people continue to chase this overly narrow protocol. Wouldn't > > it make more sense to develop an XML directory access protocol > > that provides XML-encapsulated access to directories that are > > currently stored in LDAP backends? > > LDAP is a protocol. The back-end for ARIN is what is stored in their > relational databases. Are you proposing that ARIN re-engineer their > entire registration system just so they can have an LDAP backend? No. Change the last line to read: ...currently stored in the backends of LDAP servers. I'm suggesting that ARIN map it's existing backend database into an LDAP schema and an XML schema and then serve the data to end users in the form. And I am suggesting that the IRIS XML schema should be the model for the encapsulated data that ARIN puts onto the wire, i.e. they should create an LDAP schema that is a one-to-one mapping of the IRIS XML schema. The end result is 3 services using 3 protocols and 2 encodings. ASN.1 over LDAP. XML over whois port 43. XML over REST (which is basically just HTTP with URL-encoded GET queries). I'm not concerned with the formats or tools used in ARIN's backends at all. I just would like to see them provide better gateways to that data, i.e. publish the ARIN whois directory in a manner that is an incremental improvement over the past and provides the very real possibility that it may be "good enough" for the next 20 years or so. LDAP indisputedly has a future. XML indisputedly has a future. Whois on port 43 is so darned simple that it has a future until people realise that LDAP or REST are better ways to do the job. HTTP indisputedly has a future and REST is merely HTTP with the standard use of URL-encoded GETs and standard documented field names in an HTML form. Maybe IRIS has a future. Maybe it doesn't. ARIN can't afford to be on the bleeding edge. We should be conservative and let the domain name people sort out the details. If they come up with something that is as futureproof as LDAP or XML or REST, then we should consider IRIS at that point in time but NOT BEFORE! --Michael Dillon From andy at hxr.us Mon Jun 13 10:07:18 2005 From: andy at hxr.us (Andrew Newton) Date: Mon, 13 Jun 2005 10:07:18 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: <0359AFCC-7282-45FA-9C12-3706A08393E0@hxr.us> On Jun 13, 2005, at 9:26 AM, Michael.Dillon at btradianz.com wrote: > I'm suggesting that ARIN map it's existing backend database into > an LDAP schema This is much easier said than done. By its very nature of being rooted in X.500 DAP and the X.500 tree structure, LDAP imposes a hierarchical tree structure on any data model. Trying to take a highly relational data set and putting into a tree causes many nodes to be replicated (leading to bloat due to multiple copies of the same data). I once had a relational data set of 6 million objects that exploded into 115 million objects when I tried to load it into an LDAP server. There are ways around it, as the FIRS proposal proves. Again, the CRISP wg looked at both methods. It concluded that both would work. However, the LDAP approach required so much engineering on top of LDAP that it made the point of re-use questionable. -andy From Ed.Lewis at neustar.biz Mon Jun 13 10:10:22 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 13 Jun 2005 10:10:22 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: At 10:37 +0100 6/13/05, Michael.Dillon at btradianz.com wrote: >future. Deprecate rwhois, document the existing REST >service (web form query), add an XML encapsulation of >the data (borrowed from IRIS) so that whois and REST >users can optionally request the easy-to-parse data, and >set up an LDAP server using the same data schema as IRIS. The CRISP WG of the IETF considered two proposals, one being IRIS (with it's XML presentation format) and the other FIRS, a LDAP-based approach using an ASN.1 presentation format. The WG decided in favor of IRIS, eschewing the LDAP approach. If you think that an XML presentation format would work with an LDAP approach, I'd suggest documenting this and presenting it for review of the CRISP WG. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From randy at psg.com Mon Jun 13 10:24:08 2005 From: randy at psg.com (Randy Bush) Date: Mon, 13 Jun 2005 15:24:08 +0100 Subject: [ppml] Directory Services - Take 2 References: <0359AFCC-7282-45FA-9C12-3706A08393E0@hxr.us> Message-ID: <17069.38664.823064.50604@roam.psg.com> > On Jun 13, 2005, at 9:26 AM, Michael.Dillon at btradianz.com wrote: >> I'm suggesting that ARIN map it's existing backend database into >> an LDAP schema i am suggesting that arin run their backends on servers colored pink. you mean that's a little too detailed for you? :-) randy From Michael.Dillon at btradianz.com Mon Jun 13 10:37:02 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 15:37:02 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <0359AFCC-7282-45FA-9C12-3706A08393E0@hxr.us> Message-ID: > > I'm suggesting that ARIN map it's existing backend database into > > an LDAP schema > > This is much easier said than done. By its very nature of being > rooted in X.500 DAP and the X.500 tree structure, LDAP imposes a > hierarchical tree structure on any data model. Trying to take a > highly relational data set and putting into a tree causes many nodes > to be replicated (leading to bloat due to multiple copies of the same > data). This may be so, but we don't have this problem. IP address allocation inherently follows a hierarchical model so the problem of bloat arises when you try to cram it into a flat relational model. In fact, most of these problems with bloat come from people who try to use some crude tool to convert formats rather than think through the problem. IP address records should map to LDAP just fine. And I am not suggesting that ARIN should replace their current relational databases. Just allow some LDAP queries to retrieve data in the same way that current whois queries retrieve data. This is what I mean by "mapping". You put in a gateway server that accepts an LDAP query and maps it to some kind of SQL query to the backend. This is very common in the LDAP world where most large LDAP directories do use a relational database backend. I am not suggesting that ARIN provide full-blown LDAP access to the ARIN whois directory. There is no need to support additional types of query above and beyond what is done today unless it is easy, cheap and makes sense. The advantage of LDAP is to provide a standard way of encapsulating the data that crosses the wire so that the client is in no danger of making parsing errors and so that the server is in no danger of accidentally sending unparseable data because somebody put a comma in the middle of their company name. LDAP ANS.1, like XML, separates the data structure from the data content so that the client can extract the data content with 100% certainty that the "city" field contains a city name, not a state code or a phone number. REST already achieves this structure/content separation on the URL-encoded GET requests, but the current ARIN web query server does not preserve the separation of structure and content in its answers. By using XML it would achieve this and be superior to whois on port 43. But if the web server can do this, then there is no reason why the same thing could not be done in the port 43 server. Bottom line is that whois data is recorded by RIRs in some kind of database with a defined schema, either RIPE/RPSL or SQL. It isn't hard for them to publish their whois directory in a way that preserves the schema across the wire so that a cityname in the database is always clearly identified as a cityname when the client recieves the answer, 100% guaranteed. LDAP and XML can provide that guarantee. --Michael Dillon P.S. the original whois free text format was never intended for anything other than human eyeballs to parse it. Therefore, that format became obsolete roughly in 1996 when people started building tools to generate whois queries. We have now had almost 10 years of this screenscraping. Please, let's fix this now. From Michael.Dillon at btradianz.com Mon Jun 13 10:42:15 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 15:42:15 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > If you think that an XML presentation format would work with > an LDAP approach, I'd suggest documenting this and presenting > it for review of the CRISP WG. I'm not interested in the views of the CRISP WG. I was on the mailing list when the working prototype of the LDAP implementation was whipped up in about two days and presented to the group. I saw the vote a short time later where the IRIS approach was voted on. I could clearly see that the group was more interested in reinventing the wheel to serve the needs of the domain name industry than in simplicity. I have no interest in understanding the needs of the domain name industry or participating in their market creation rituals. If they can't see that simple general purpose protocols are easier to implement, manage, and deploy, then I am not going to waste my breathe (or fingertips). --Michael Dillon From Michael.Dillon at btradianz.com Mon Jun 13 10:43:40 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 15:43:40 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <17069.38664.823064.50604@roam.psg.com> Message-ID: > i am suggesting that arin run their backends on servers colored pink. > you mean that's a little too detailed for you? :-) Before I answer that, I'd like to know the distance between ARIN's server farm and the nearest auto paint supplier. ;-) --Michael Dillon From Ed.Lewis at neustar.biz Mon Jun 13 10:41:56 2005 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 13 Jun 2005 10:41:56 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: At 10:57 +0100 6/13/05, Michael.Dillon at btradianz.com wrote: >I believe you are the primary author of IRIS and since >Neustar is in the domain name business, the main group >which will benefit from IRIS, I have to ask this. Why >should ARIN spend money or energy to support the domain >name industry? It is simply not what ARIN is there to do. Yes, and the moon landings were all my doing too. I have not been a contributor to the development of IRIS. I've reviewed it and discussed it, but can't claim to have helped its forward progress in any way. What leads you to believe that I am a "primary author" of IRIS? >And I wonder, if ARIN did spend money on IRIS development, >how much of that money might find its way into your pocket >somewhere down the line? I can honestly say "none." >I'm not accusing you of anything here, Sounds like you are. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying. From andy at hxr.us Mon Jun 13 11:34:15 2005 From: andy at hxr.us (Andrew Newton) Date: Mon, 13 Jun 2005 11:34:15 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: On Jun 13, 2005, at 10:37 AM, Michael.Dillon at btradianz.com wrote: >>> I'm suggesting that ARIN map it's existing backend database into >>> an LDAP schema >>> >> >> This is much easier said than done. By its very nature of being >> rooted in X.500 DAP and the X.500 tree structure, LDAP imposes a >> hierarchical tree structure on any data model. Trying to take a >> highly relational data set and putting into a tree causes many nodes >> to be replicated (leading to bloat due to multiple copies of the same >> data). >> > > This may be so, but we don't have this problem. IP address > allocation inherently follows a hierarchical model so the > problem of bloat arises when you try to cram it into a flat > relational model. First, there are more objects in the ARIN database than just IP addresses. Things like contacts and organizations with multiple relationships make for a relational model. Second, IP addresses present a particular issue. Do you base the DIT on an IP classful hierarchy? Doing it on bit boundaries leads to DNs longer than my arm for v4... what about v6? What about assignments with the same starting and/or ending address? If IP addresses are opaque to the DIT, that means you aren't using the DIT which begs the question of why you are using LDAP. This problem is far more complex than you are painting it. On Jun 13, 2005, at 10:42 AM, Michael.Dillon at btradianz.com wrote: >> If you think that an XML presentation format would work with >> an LDAP approach, I'd suggest documenting this and presenting >> it for review of the CRISP WG. >> > > I'm not interested in the views of the CRISP WG. Why? Both the IRIS and FIRS proposals took into consideration IP address registries from day one. -andy From Michael.Dillon at btradianz.com Mon Jun 13 11:49:58 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 13 Jun 2005 16:49:58 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: Message-ID: > If IP addresses are opaque to the > DIT, that means you aren't using the DIT which begs the question of > why you are using LDAP. This problem is far more complex than you > are painting it. This problem has already been solved. Just take the XML schema from IRIS and map it into LDAP. The point of using LDAP is not to somehow be pure to some mythical x.500 model, but simply to allow the deployment of of-the-shelf software for both the server and client side of the whois directory queries. LDAP, whether you like it or not, is a widely deployed, well-understood and well-supported technology with many off-the-shelf server and client implementations available, both commercial and open source. Every one of the larger ARIN members already runs LDAP in their organization and has some level of LDAP expertise on staff. This is a ubiquitous technology. ARIN can't afford to develop new technology. We have to work with stuff that is already available off the shelf and can be glued together with a minimum of additional development. All the technology suggestions I have made for improving the publication of the whois directory, were made with this in mind. ARIN simply cannot piggyback off the IRIS development being done by the very wealthy domain name industry until they have implemented IRIS, worked out the bugs, and seeded the market for software implementations so that ARIN can pick and choose. There simply isn't a business case for small non-profit ARIN to spend money on a tool that is intended to benefit the much better funded for-profit domain name industry. --Michael Dillon From andy at hxr.us Mon Jun 13 16:20:40 2005 From: andy at hxr.us (Andrew Newton) Date: Mon, 13 Jun 2005 16:20:40 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: Message-ID: <86FC3441-7494-4AC8-8C61-47D8E3CDD418@hxr.us> On Jun 13, 2005, at 11:49 AM, Michael.Dillon at btradianz.com wrote: >> If IP addresses are opaque to the >> DIT, that means you aren't using the DIT which begs the question of >> why you are using LDAP. This problem is far more complex than you >> are painting it. >> > > This problem has already been solved. Just take the XML > schema from IRIS and map it into LDAP. This would need to be specified. As Ed suggested earlier, you should document this mapping for all to see. My apologies to Leo and everybody else for taking this thread down the LDAP pros vs. cons avenue. Let us not derail the original topic. I think there is some concern that listing wire protocols is too specific, and this type of high-degree of specificity has caused trouble in the past. On the other hand, there is concern that if there is no policy regarding newer wire protocols (be it LDAP, IRIS, or CHEESE-WIZ), then ARIN will never get around to deploying them. Perhaps the right thing to do is to concentrate the policy only on the currently deployed access mechanisms and leave room for future access mechanisms. -andy From markk at verisignlabs.com Mon Jun 13 16:59:50 2005 From: markk at verisignlabs.com (Mark Kosters) Date: Mon, 13 Jun 2005 16:59:50 -0400 Subject: [ppml] Directory Services - Take 2 In-Reply-To: References: <20050509200742.GA75281@ussenterprise.ufp.org> <20050610151237.GA48542@ussenterprise.ufp.org> Message-ID: <20050613205950.GQ4211@verisignlabs.com> On Fri, Jun 10, 2005 at 11:32:19AM -0400, Edward Lewis wrote: > Directory services is one of the major external functions of a > registry (DNS, billing, registration are the others), yet I don't see > any background material for this policy. Has ARIN (membership, AC, > staff) ever identified the constituencies that rely on the directory > services? Has there been constituency-by-constituency delineation of > requirements for the directory services? > > It's really hard to effectively evaluate a policy statement without > understanding the underlying system. It's like putting regulation > ahead of the technology. Bingo. In my opinion, you have hit the basis of the problem here. We need to develop the purpose and scope of this directory service before coming to some sort of agreeable policy. Based on the purpose, the scope can be vastly different. For example: if the purpose of this directory is to be a way of anyone to independently audit the allocations and subsequent assignments then the access control should be open for all organizational and contact records associated with that part of the ip space or as space. If the purpose of the directory is to provide contact information for network problems, then perhaps org info should be hidden and contact info should only be known to isps and no one else. If the purpose of the directory is to provide information to law enforcement then org and contact info should be given to those bodies and no one else. If the purpose of the directory is to protect someones trademark, then the legal community should have access to the org and contact info and nobody else. Maybe this one is a bit far-fetched but I do know of at least one person who is dreaming about trademarking their ip space. The reality of this is that there is a whole host of purposes we need to drill down on to figure out why we need to have directory service in the first place along with its scope of usage. Once we are clear on a list of purposes, IMHO, we can then go down the policy path. > What "reforms" does this proposal bring? Why is there the feeling > that people are "piggy backing" "favorite technology" to prevent the > reforms? I have suggested that IRIS become a priority - but that's > not the major problem I have with the proposal. Leo has spent many hours writing up a lot of text and I thank him for bringing this to the table. But there is a lot of stuff built into this policy that allows for multiple vectors for argument, confusion, and filling of email boxes. I think we need to step back as you said and look at the purpose and scope first. Regards, Mark -- Mark Kosters markk at verisignlabs.com Verisign Applied Research From hannigan at verisign.com Mon Jun 13 23:55:54 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Mon, 13 Jun 2005 23:55:54 -0400 Subject: [ppml] Directory Services - section 3.4.3 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Bill > Woodcock > Sent: Friday, June 10, 2005 3:48 PM > To: Leo Bicknell > Cc: ppml at arin.net > Subject: RE: [ppml] Directory Services - section 3.4.3 > [ SNIP ] > > ARIN shall publish the APID in the following > methods using > > industry standard practices: > > - Via the WHOIS protocol. > > - Via a query form accessible via the HTTP protocol. > > - Via FTP to users who complete the bulk data form. > > - Via CDROM to users who complete the bulk data form. > > - Via the RWHOIS protocol. > > Again, this is vast overspecification. This isn't vast overspecification. It's better described as a minimum level of service delivery. As far as the CD-ROM argument goes, it's not that big of a deal. It actually covers quite a few scenarios that could arise. Staff could probably figure out on their own if a CD-ROM made sense, but there's no harm in saying "else...CD-ROM". -M< From Michael.Dillon at btradianz.com Tue Jun 14 05:42:51 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Jun 2005 10:42:51 +0100 Subject: [ppml] Directory Services - Take 2 In-Reply-To: <20050613205950.GQ4211@verisignlabs.com> Message-ID: > We need to develop the purpose and scope of this directory service > before coming to some sort of agreeable policy. Based on the purpose, > the scope can be vastly different. I tried to focus discussion on this point once before with this proposal http://www.arin.net/policy/proposals/2004_4.html 1. ARIN shall maintain and publish a directory of contact information for the purposes of facilitating the operation of interconnected IP networks. 2. This directory will contain contact information for all organizations and individuals within the ARIN region who have received IP allocations or AS numbers directly from ARIN or its predecessors. 3. Organizations and individuals must guarantee to ARIN that contact addresses published in the whois directory will reach a person who is ready, willing and able to communicate regarding network operations and interconnect issues and who is able to act on that communication. 4. Any other organizations may elect to be listed in the whois directory as long as they make the guarantee detailed in item 3. 5. All contacts listed in the whois directory will be contacted periodically and the directory will indicate information which may be stale if contact cannot be made promptly. 6. Additionally, the whois directory will contain, directly or indirectly, a record of all address blocks sub-allocated or assigned by the entities mentioned in item 3. 7. The records mentioned in item 6 will not identify the organization or individual receiving the address block or their exact location. These records will only indicate an organizational type, the nearest municipality providing postal service to the end user, state/province and country. At the time, the AC seemed to be taking an "all or nothing" position on new policy and since a majority of members didn't support this as is, they dropped the whole thing. But now, the mood seems to have changed to one of bundling up policy incrementally which I think is good. In that case, I would like to reintroduce this proposal here as the strawman and hopefully we can build it up into something that is acceptable to all. Then, once we have the purpose and scope agreed upon, we can tackle the rest of the problem. By the way, if you don't understand one of the points above, or find yourself disagreeing with a point, it might be a good idea to review the URL above. In particular, item 7 is explained there. --Michael Dillon From Michael.Dillon at btradianz.com Tue Jun 14 05:53:56 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 14 Jun 2005 10:53:56 +0100 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: Message-ID: > > > - Via CDROM to users who complete the bulk data form. > This isn't vast overspecification. It's better described as a minimum > level of service delivery. When you put a statement like that in policy then you are implying that CD-ROM is the only acceptable media. What happens if the data won't fit on one CD-ROM. Will ARIN staff sit there swapping in CD-Rs, and then do it all over again to verify that they are all readable? If we simple say -Via recordable media to users who have signed the bulk data AUP Then we are not overspecifying the details. ARIN is still free to offer the data on a DVD-R with 5 copies of the data in different formats for $100 or on CD-R with your choice of a single data format for $2,000 dollars. The extra fee covers the time spent sitting and swapping disks. People can ask ARIN to buy a USB 2.0 or Firewire drive, load the 5 formats of the database and mail it to them. Or people can drive up to the ARIN offices with a PC containing a DLT drive and 100baseT network card to do a high-speed SMB transfer of the data onto tape. These are all details which are not specified in the policy and which are not possible if the policy mentions CDROM. That is why that phrase is OVERSPECIFICATION. > Staff > could probably figure out on their own if a CD-ROM made sense, but > there's no harm in saying "else...CD-ROM". Yes, there is harm in saying "else...CD-ROM". By doing that we usurp the ability of ARIN staff to use their own judgement. We are micromanaging. Do you like your boss to tell you in detail how to do your daily tasks? Policy is like instructions from the boss and good policy should not overspecify in the same way that good managers should not micromanage. --Michael Dillon From jwkckid1 at ix.netcom.com Tue Jun 14 16:36:29 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 14 Jun 2005 13:36:29 -0700 Subject: [ppml] Directory Services - section 3.4.3 References: Message-ID: <42AF3F96.118CC77@ix.netcom.com> Michael and all, I agree with Michael here. It seems logical and reasonable that a more open definition of storage media is appropriate. CD-R's are "ok" however DVD-R's are more efficient. Michael.Dillon at btradianz.com wrote: > > > > - Via CDROM to users who complete the bulk data form. > > > This isn't vast overspecification. It's better described as a minimum > > level of service delivery. > > When you put a statement like that in policy then you > are implying that CD-ROM is the only acceptable media. > What happens if the data won't fit on one CD-ROM. Will > ARIN staff sit there swapping in CD-Rs, and then do > it all over again to verify that they are all readable? > If we simple say > > -Via recordable media to users who have signed the bulk data AUP > > Then we are not overspecifying the details. ARIN is still > free to offer the data on a DVD-R with 5 copies of the data > in different formats for $100 or on CD-R with your choice > of a single data format for $2,000 dollars. The extra fee > covers the time spent sitting and swapping disks. People can > ask ARIN to buy a USB 2.0 or Firewire drive, load the 5 formats > of the database and mail it to them. Or people can drive up > to the ARIN offices with a PC containing a DLT drive and > 100baseT network card to do a high-speed SMB transfer of the > data onto tape. > > These are all details which are not specified in the policy > and which are not possible if the policy mentions CDROM. That > is why that phrase is OVERSPECIFICATION. > > > Staff > > could probably figure out on their own if a CD-ROM made sense, but > > there's no harm in saying "else...CD-ROM". > > Yes, there is harm in saying "else...CD-ROM". By doing that we > usurp the ability of ARIN staff to use their own judgement. > We are micromanaging. Do you like your boss to tell you in > detail how to do your daily tasks? Policy is like instructions > from the boss and good policy should not overspecify in the same > way that good managers should not micromanage. > > --Michael Dillon Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owen at delong.com Tue Jun 14 15:09:50 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2005 12:09:50 -0700 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: References: Message-ID: --On Tuesday, June 14, 2005 10:53 AM +0100 Person who prefers not to be attributed wrote: >> > > - Via CDROM to users who complete the bulk data form. > >> This isn't vast overspecification. It's better described as a minimum >> level of service delivery. > > When you put a statement like that in policy then you > are implying that CD-ROM is the only acceptable media. > What happens if the data won't fit on one CD-ROM. Will > ARIN staff sit there swapping in CD-Rs, and then do > it all over again to verify that they are all readable? > If we simple say > No, it's not. That would be true if there weren't a subsequent statement that OTHER MEDIA can be made available at ARIN's discretion. However, such a statement is present in the proposed policy, thus trumping any such implication. > -Via recordable media to users who have signed the bulk data AUP > > Then we are not overspecifying the details. ARIN is still > free to offer the data on a DVD-R with 5 copies of the data > in different formats for $100 or on CD-R with your choice > of a single data format for $2,000 dollars. The extra fee > covers the time spent sitting and swapping disks. People can > ask ARIN to buy a USB 2.0 or Firewire drive, load the 5 formats > of the database and mail it to them. Or people can drive up > to the ARIN offices with a PC containing a DLT drive and > 100baseT network card to do a high-speed SMB transfer of the > data onto tape. > Right... Then, users are free to expect any random form of media they choose. The policy as written makes it very clear that ARIN will publish the data on CDROM and MAY publish it on other media upon request if ARIN feels such request is not overly burdensome. The policy as written is better than your proposal, no matter how many times you repeat your proposal. > These are all details which are not specified in the policy > and which are not possible if the policy mentions CDROM. That > is why that phrase is OVERSPECIFICATION. > That simply isn't true. Under the proposed policy, all of those things are possible, but, the policy makes it clear that they are at ARINs discretion. >> Staff >> could probably figure out on their own if a CD-ROM made sense, but >> there's no harm in saying "else...CD-ROM". > > Yes, there is harm in saying "else...CD-ROM". By doing that we > usurp the ability of ARIN staff to use their own judgement. > We are micromanaging. Do you like your boss to tell you in > detail how to do your daily tasks? Policy is like instructions > from the boss and good policy should not overspecify in the same > way that good managers should not micromanage. > In my opinion, this simply isn't an accurate interpretation of the policy as worded. The policy as worded guarantees that at a minimum, CD-ROM will be available. CDROM is currently the most common form of mass-storage media. As to the data not fitting, let's look at that realistically. The ARIN region now consists essentially of the united States and Canada. To the best of my knowledge, everything else has been shifted either to LACNIC or AFRINIC. Let's overestimate a bit and say that the ARIN region contains 1/2 of all IP allocations. ARIN does not allocate or assign smaller than a /22 (other than a statistically meaningless handfull of exchange point allocations and the swamp). More than 3/4ths of ARIN allocations are /20 or larger. There are roughly 16 million /24s, which translates to roughly 8 million /24s in the ARIN region. 1/4 of that is 2 million /24s which translate to approximately 0.5 million /22s. The remaining 6 million /24s translate into 0.375 million /20s, so, a gross overestimation of the maximum size of the database is rougly 0.875 million records. I believe the average whois record is approximately 512 bytes, so, we have 875,000 records at 512 bytes is 448,000,000 bytes which is roughly 428 Megabytes. A CDROM is 700 Megabytes. You can fit almost two copies of the worst case database on a CDROM. The argument of what happens when the database exceeds a CDROM is specious. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Jun 14 15:36:14 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 14 Jun 2005 12:36:14 -0700 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <42AF3F96.118CC77@ix.netcom.com> References: <42AF3F96.118CC77@ix.netcom.com> Message-ID: --On Tuesday, June 14, 2005 1:36 PM -0700 Jeff Williams wrote: > Michael and all, > > I agree with Michael here. It seems logical and reasonable that > a more open definition of storage media is appropriate. CD-R's > are "ok" however DVD-R's are more efficient. > Actually, in this case, since the database maxes out at about 1/2 a CD, they are not more efficient... They are more expensive and take longer to burn. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jwkckid1 at ix.netcom.com Tue Jun 14 23:13:10 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 14 Jun 2005 20:13:10 -0700 Subject: [ppml] Directory Services - section 3.4.3 References: Message-ID: <42AF9CC3.562EA7F0@ix.netcom.com> Owne and all, Good argument if your data/figures are accurate, and I cannot say that they are not. However your argument is based on the now or near term, not the long term. Things change quickly... Owen DeLong wrote: > --On Tuesday, June 14, 2005 10:53 AM +0100 Person who prefers not to be > attributed wrote: > > >> > > - Via CDROM to users who complete the bulk data form. > > > >> This isn't vast overspecification. It's better described as a minimum > >> level of service delivery. > > > > When you put a statement like that in policy then you > > are implying that CD-ROM is the only acceptable media. > > What happens if the data won't fit on one CD-ROM. Will > > ARIN staff sit there swapping in CD-Rs, and then do > > it all over again to verify that they are all readable? > > If we simple say > > > No, it's not. That would be true if there weren't a subsequent statement > that OTHER MEDIA can be made available at ARIN's discretion. > However, such a statement is present in the proposed policy, thus trumping > any such implication. > > > -Via recordable media to users who have signed the bulk data AUP > > > > Then we are not overspecifying the details. ARIN is still > > free to offer the data on a DVD-R with 5 copies of the data > > in different formats for $100 or on CD-R with your choice > > of a single data format for $2,000 dollars. The extra fee > > covers the time spent sitting and swapping disks. People can > > ask ARIN to buy a USB 2.0 or Firewire drive, load the 5 formats > > of the database and mail it to them. Or people can drive up > > to the ARIN offices with a PC containing a DLT drive and > > 100baseT network card to do a high-speed SMB transfer of the > > data onto tape. > > > Right... Then, users are free to expect any random form of media they > choose. The policy as written makes it very clear that ARIN will publish > the data on CDROM and MAY publish it on other media upon request if ARIN > feels such request is not overly burdensome. The policy as written > is better than your proposal, no matter how many times you repeat your > proposal. > > > These are all details which are not specified in the policy > > and which are not possible if the policy mentions CDROM. That > > is why that phrase is OVERSPECIFICATION. > > > That simply isn't true. Under the proposed policy, all of those things > are possible, but, the policy makes it clear that they are at ARINs > discretion. > > >> Staff > >> could probably figure out on their own if a CD-ROM made sense, but > >> there's no harm in saying "else...CD-ROM". > > > > Yes, there is harm in saying "else...CD-ROM". By doing that we > > usurp the ability of ARIN staff to use their own judgement. > > We are micromanaging. Do you like your boss to tell you in > > detail how to do your daily tasks? Policy is like instructions > > from the boss and good policy should not overspecify in the same > > way that good managers should not micromanage. > > > In my opinion, this simply isn't an accurate interpretation of the policy > as worded. The policy as worded guarantees that at a minimum, CD-ROM > will be available. CDROM is currently the most common form of mass-storage > media. As to the data not fitting, let's look at that realistically. > > The ARIN region now consists essentially of the united States and Canada. > To the best of my knowledge, everything else has been shifted either to > LACNIC or AFRINIC. Let's overestimate a bit and say that the ARIN region > contains 1/2 of all IP allocations. ARIN does not allocate or assign > smaller than a /22 (other than a statistically meaningless handfull of > exchange point allocations and the swamp). More than 3/4ths of ARIN > allocations are /20 or larger. There are roughly 16 million /24s, which > translates to roughly 8 million /24s in the ARIN region. 1/4 of that is > 2 million /24s which translate to approximately 0.5 million /22s. The > remaining 6 million /24s translate into 0.375 million /20s, so, a gross > overestimation of the maximum size of the database is rougly 0.875 million > records. > > I believe the average whois record is approximately 512 bytes, so, we > have 875,000 records at 512 bytes is 448,000,000 bytes which is > roughly 428 Megabytes. A CDROM is 700 Megabytes. You can fit almost > two copies of the worst case database on a CDROM. > > The argument of what happens when the database exceeds a CDROM is specious. > > Owen > > -- > If it wasn't crypto-signed, it probably didn't come from me. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From jwkckid1 at ix.netcom.com Tue Jun 14 23:18:56 2005 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Tue, 14 Jun 2005 20:18:56 -0700 Subject: [ppml] Directory Services - section 3.4.3 References: <42AF3F96.118CC77@ix.netcom.com> Message-ID: <42AF9E1E.CB14BF7C@ix.netcom.com> Owen and all, I respectively disagree in part. I can burn a DVD-R much faster than a CD-R. And more data can be stored on a DVD than a CD. Hence making the DVD a more effective and efficient media. DVD-R's are however more expensive, which won't last long... Hence I was thinking long term in my previous response/remarks which I believe Michael was as well, unless I miss my guess... Owen DeLong wrote: > --On Tuesday, June 14, 2005 1:36 PM -0700 Jeff Williams > wrote: > > > Michael and all, > > > > I agree with Michael here. It seems logical and reasonable that > > a more open definition of storage media is appropriate. CD-R's > > are "ok" however DVD-R's are more efficient. > > > Actually, in this case, since the database maxes out at about 1/2 a CD, > they are not more efficient... They are more expensive and take longer > to burn. > > Owen > -- > If it wasn't crypto-signed, it probably didn't come from me. > > ------------------------------------------------------------------------ > > Part 1.2 Type: application/pgp-signature > Encoding: 7bit Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owen at delong.com Wed Jun 15 04:01:59 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jun 2005 01:01:59 -0700 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <42AF9CC3.562EA7F0@ix.netcom.com> References: <42AF9CC3.562EA7F0@ix.netcom.com> Message-ID: <3D0323AE928A648CC365BBCF@[172.17.1.152]> It's based on IPv4 and ARIN being unlikely to gain territory or a significant additional percentage of IPv4 allocations. Admittedly, v6 could change things, but, frankly, it looks like v6 will most likely make the database smaller not larger unless significant policy changes take place. However, another thing to consider is that when things do change, so can policies. I'm betting we can change ARIN policies if it becomes necessary much faster than IPv6 will cause the policy change to be necessary. Owen --On Tuesday, June 14, 2005 20:13 -0700 Jeff Williams wrote: > Owne and all, > > Good argument if your data/figures are accurate, and I cannot > say that they are not. However your argument is based on the > now or near term, not the long term. Things change quickly... > > Owen DeLong wrote: > >> --On Tuesday, June 14, 2005 10:53 AM +0100 Person who prefers not to be >> attributed wrote: >> >> >> > > - Via CDROM to users who complete the bulk data >> >> > > form. >> > >> >> This isn't vast overspecification. It's better described as a minimum >> >> level of service delivery. >> > >> > When you put a statement like that in policy then you >> > are implying that CD-ROM is the only acceptable media. >> > What happens if the data won't fit on one CD-ROM. Will >> > ARIN staff sit there swapping in CD-Rs, and then do >> > it all over again to verify that they are all readable? >> > If we simple say >> > >> No, it's not. That would be true if there weren't a subsequent statement >> that OTHER MEDIA can be made available at ARIN's discretion. >> However, such a statement is present in the proposed policy, thus >> trumping any such implication. >> >> > -Via recordable media to users who have signed the bulk data AUP >> > >> > Then we are not overspecifying the details. ARIN is still >> > free to offer the data on a DVD-R with 5 copies of the data >> > in different formats for $100 or on CD-R with your choice >> > of a single data format for $2,000 dollars. The extra fee >> > covers the time spent sitting and swapping disks. People can >> > ask ARIN to buy a USB 2.0 or Firewire drive, load the 5 formats >> > of the database and mail it to them. Or people can drive up >> > to the ARIN offices with a PC containing a DLT drive and >> > 100baseT network card to do a high-speed SMB transfer of the >> > data onto tape. >> > >> Right... Then, users are free to expect any random form of media they >> choose. The policy as written makes it very clear that ARIN will publish >> the data on CDROM and MAY publish it on other media upon request if ARIN >> feels such request is not overly burdensome. The policy as written >> is better than your proposal, no matter how many times you repeat your >> proposal. >> >> > These are all details which are not specified in the policy >> > and which are not possible if the policy mentions CDROM. That >> > is why that phrase is OVERSPECIFICATION. >> > >> That simply isn't true. Under the proposed policy, all of those things >> are possible, but, the policy makes it clear that they are at ARINs >> discretion. >> >> >> Staff >> >> could probably figure out on their own if a CD-ROM made sense, but >> >> there's no harm in saying "else...CD-ROM". >> > >> > Yes, there is harm in saying "else...CD-ROM". By doing that we >> > usurp the ability of ARIN staff to use their own judgement. >> > We are micromanaging. Do you like your boss to tell you in >> > detail how to do your daily tasks? Policy is like instructions >> > from the boss and good policy should not overspecify in the same >> > way that good managers should not micromanage. >> > >> In my opinion, this simply isn't an accurate interpretation of the policy >> as worded. The policy as worded guarantees that at a minimum, CD-ROM >> will be available. CDROM is currently the most common form of >> mass-storage media. As to the data not fitting, let's look at that >> realistically. >> >> The ARIN region now consists essentially of the united States and Canada. >> To the best of my knowledge, everything else has been shifted either to >> LACNIC or AFRINIC. Let's overestimate a bit and say that the ARIN region >> contains 1/2 of all IP allocations. ARIN does not allocate or assign >> smaller than a /22 (other than a statistically meaningless handfull of >> exchange point allocations and the swamp). More than 3/4ths of ARIN >> allocations are /20 or larger. There are roughly 16 million /24s, which >> translates to roughly 8 million /24s in the ARIN region. 1/4 of that is >> 2 million /24s which translate to approximately 0.5 million /22s. The >> remaining 6 million /24s translate into 0.375 million /20s, so, a gross >> overestimation of the maximum size of the database is rougly 0.875 >> million records. >> >> I believe the average whois record is approximately 512 bytes, so, we >> have 875,000 records at 512 bytes is 448,000,000 bytes which is >> roughly 428 Megabytes. A CDROM is 700 Megabytes. You can fit almost >> two copies of the worst case database on a CDROM. >> >> The argument of what happens when the database exceeds a CDROM is >> specious. >> >> Owen >> >> -- >> If it wasn't crypto-signed, it probably didn't come from me. >> >> ---------------------------------------------------------------------- >> -- >> >> Part 1.2 Type: application/pgp-signature >> Encoding: 7bit > > Regards, > > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1 at ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Jun 15 04:10:51 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jun 2005 01:10:51 -0700 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <42AF9E1E.CB14BF7C@ix.netcom.com> References: <42AF3F96.118CC77@ix.netcom.com> <42AF9E1E.CB14BF7C@ix.netcom.com> Message-ID: <0E3CED8527736A23A53299C2@[172.17.1.152]> Well... DVD burners have improved a bit from last time I looked. The newest ones are up to 16x, while CD burners continue to limp along at about 54x. However, I don't share your optimism about the pricing on the media. As to long term thinking, when it comes to something that long term, the policy can easily be changed when we get to that point. Right now, the database easily fits on CD with room to spare and I don't see any advantage to specifying DVD instead. Every DVD drive will read a CD. The reverse is not true. When we get to a point where CD drives that don't read DVDs are mostly a thing of the past, and, media is the same cost, then, I can't imagine it will be more than trivial effort to update the policy accordingly. ARIN policies do not need to be long term on the kind of time horizon you're talking about here. They should work for at least a couple of years, but, sacrificing current compatibility in the name of long term optimism when it is so easy to update them is suboptimal in my opinion. Owen --On Tuesday, June 14, 2005 20:18 -0700 Jeff Williams wrote: > Owen and all, > > I respectively disagree in part. I can burn a DVD-R much faster than > a CD-R. And more data can be stored on a DVD than a CD. Hence > making the DVD a more effective and efficient media. DVD-R's are > however more expensive, which won't last long... Hence I was thinking > long term in my previous response/remarks which I believe Michael was > as well, unless I miss my guess... > > Owen DeLong wrote: > >> --On Tuesday, June 14, 2005 1:36 PM -0700 Jeff Williams >> wrote: >> >> > Michael and all, >> > >> > I agree with Michael here. It seems logical and reasonable that >> > a more open definition of storage media is appropriate. CD-R's >> > are "ok" however DVD-R's are more efficient. >> > >> Actually, in this case, since the database maxes out at about 1/2 a CD, >> they are not more efficient... They are more expensive and take longer >> to burn. >> >> Owen >> -- >> If it wasn't crypto-signed, it probably didn't come from me. >> >> ---------------------------------------------------------------------- >> -- >> >> Part 1.2 Type: application/pgp-signature >> Encoding: 7bit > > Regards, > -- > Jeffrey A. Williams > Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) > "Be precise in the use of words and expect precision from others" - > Pierre Abelard > > "If the probability be called P; the injury, L; and the burden, B; > liability depends upon whether B is less than L multiplied by > P: i.e., whether B is less than PL." > United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] > =============================================================== > Updated 1/26/04 > CSO/DIR. Internet Network Eng. SR. Eng. Network data security > IDNS. div. of Information Network Eng. INEG. INC. > E-Mail jwkckid1 at ix.netcom.com > Registered Email addr with the USPS > Contact Number: 214-244-4827 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Wed Jun 15 05:19:47 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 15 Jun 2005 10:19:47 +0100 Subject: [ppml] Too many words... In-Reply-To: Message-ID: > That would be true if there weren't a subsequent statement > that OTHER MEDIA can be made available at ARIN's discretion. > However, such a statement is present in the proposed policy, thus trumping > any such implication. Then why say things twice when one statement will do. "Recordable media can be made available at ARIN's discretion". > Right... Then, users are free to expect any random form of media they > choose. Nope. Users are free to negotiate a deal with ARIN in regards to copies of the database without any interference from overly specific policy. ARIN staff can use their discretion, charge a reasonable fee for the service, schedule the service to be done at ARIN's convenience, etc. We don't need to write any of these words in the policy in order to make this possible. > The policy as written makes it very clear that ARIN will publish > the data on CDROM and MAY publish it on other media upon request if ARIN > feels such request is not overly burdensome. And when we discover that publishing it on CD-ROM *IS* burdensome, then what do we do. ARIN has never published the whois directory on CD-ROM in the past and no investigation has been done into the feasability of ARIN supplying recordable media. Therefore it is highly inappriate for the policy makers to choose CD-ROM to be embedded in the policy. There is no need for this, no demonstrated demand, and it is not in line with the purpose and scope of the whois directory because we haven't even decided what that is yet. This is the danger in writing too many words, too soon. > The policy as written > is better than your proposal, no matter how many times you repeat your > proposal. I haven't made any proposal other than to shorten, simplify and get rid of unneccessary details that should be decided by ARIN staff or the BoT, not by ARIN policy. > In my opinion, this simply isn't an accurate interpretation of the policy > as worded. The policy as worded guarantees that at a minimum, CD-ROM > will be available. CDROM is currently the most common form of mass-storage > media. As to the data not fitting, let's look at that realistically. In my world, hard drives are the most common form of mass-storage media. They are widely available with standard interfaces such as USB 2.0 and Firewire that make them very portable. The second most common form of mass-storage media in my world, is the DVD. Arguably, DVDs are more portable than CD-ROM so if the policy is going to mention a specific media, then DVD is it. However, I would disagree with this policy in the same way and for the same reasons if all occurrences of CD-ROM were replaced with DVD. > I believe the average whois record is approximately 512 bytes, so, we > have 875,000 records at 512 bytes is 448,000,000 bytes which is > roughly 428 Megabytes. A CDROM is 700 Megabytes. You can fit almost > two copies of the worst case database on a CDROM. Earlier someone pointed out that the ideal way to distribute the whois data was to provide 5 copies in various formats. Clearly, this will not fit on a CD-ROM, therefore it is questionable whether CD-ROM is suitable for ARIN to use in a simple manner. > The argument of what happens when the database exceeds a CDROM is specious. No, you have proved that the data already exceeds the capacity of a CD-ROM unless ARIN only provides it in one raw file format that doesn't have a lot of overhead. --Michael Dillon From owen at delong.com Wed Jun 15 06:36:42 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 15 Jun 2005 03:36:42 -0700 Subject: [ppml] Too many words... In-Reply-To: References: Message-ID: <39ED4FB1589C6C3DAB5D6890@[172.17.1.152]> >> That would be true if there weren't a subsequent statement >> that OTHER MEDIA can be made available at ARIN's discretion. >> However, such a statement is present in the proposed policy, thus > trumping >> any such implication. > > Then why say things twice when one statement will do. > > "Recordable media can be made available at ARIN's discretion". > Because the way it was originally worded provides a minimum standard and allows flexibility beyond that. For that matter, the word "Recordable" serves little purpose in your statement. "Other media" is, I think, a better choice. >> The policy as written makes it very clear that ARIN will publish >> the data on CDROM and MAY publish it on other media upon request if ARIN >> feels such request is not overly burdensome. > > And when we discover that publishing it on CD-ROM *IS* burdensome, > then what do we do. ARIN has never published the whois directory > on CD-ROM in the past and no investigation has been done into > the feasability of ARIN supplying recordable media. Therefore > it is highly inappriate for the policy makers to choose CD-ROM > to be embedded in the policy. There is no need for this, no > demonstrated demand, and it is not in line with the purpose > and scope of the whois directory because we haven't even decided > what that is yet. > I don't know that your statement is necessarily true. I suspect that Leo probably did talk to the staff and did put some effort into determining the feasibility of what he proposes. Admittedly, we are both making assumptions here. I know that there have been requests in the past for the data to be available on CD-ROM, so, the statement that there is no demonstrated demand is not true, although I cannot quantify the demonstrated demand, there is some. Finally as to being out of the purpose and scope, if the purpose and scope are not yet defined, you cannot say that it is in or out. An undefined area is an undefined area. A point cannot be determined to be inside or outside of said area until the area becomes defined. >> The policy as written >> is better than your proposal, no matter how many times you repeat your >> proposal. > > I haven't made any proposal other than to shorten, simplify > and get rid of unneccessary details that should be decided > by ARIN staff or the BoT, not by ARIN policy. > And my opinion is that your attempt to shorten and simplify does not produce as good a result and that the details you are attempting to get rid of are not unnecessary. As usual, I suspect we should agree to disagree on this. > In my world, hard drives are the most common form of mass-storage > media. They are widely available with standard interfaces such as > USB 2.0 and Firewire that make them very portable. The second > most common form of mass-storage media in my world, is the DVD. > Arguably, DVDs are more portable than CD-ROM so if the policy is > going to mention a specific media, then DVD is it. > As tempting as it is, I will refrain from a comparison between your world and the world in which the rest of us live. I'd really like to know how you can argue that a DVD is more portable than a CD. DVD and CD are eactly the same size and weight. Any DVD drive will read a CD. Not every CD drive will read a DVD. So, CDs are readable in more drives (hardware portability) and have the same size and weight (physical portability) vs. DVDs. I would argue, thus, that CDs are slightly more portable. >> I believe the average whois record is approximately 512 bytes, so, we >> have 875,000 records at 512 bytes is 448,000,000 bytes which is >> roughly 428 Megabytes. A CDROM is 700 Megabytes. You can fit almost >> two copies of the worst case database on a CDROM. > > Earlier someone pointed out that the ideal way to distribute > the whois data was to provide 5 copies in various formats. > Clearly, this will not fit on a CD-ROM, therefore it is > questionable whether CD-ROM is suitable for ARIN to use > in a simple manner. > Unless, of course, the CD came with the data in one portable format and scripts were made available to convert to any of the 5 aforementioned formats. (The scripts could even fit on the CD if this was considered useful). I can see a need for multiple formats for online distribution, but, I'm less convinced of a need for more than one format on a media distribution. >> The argument of what happens when the database exceeds a CDROM is > specious. > > No, you have proved that the data already exceeds the capacity of a > CD-ROM unless ARIN only provides it in one raw file format that > doesn't have a lot of overhead. > Or in more than one format using any form of reasonably good compression. It's not like you need to produce an uncondensed index for optimal insertion on a read-only media distribution. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Wed Jun 15 07:28:58 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 15 Jun 2005 12:28:58 +0100 Subject: [ppml] Too many words... In-Reply-To: <39ED4FB1589C6C3DAB5D6890@[172.17.1.152]> Message-ID: > For that matter, the word "Recordable" serves little purpose in your > statement. "Other media" is, I think, a better choice. "Recordable media" is a plain English term used to draw a distinction between the things we are talking about and other things like the "news media". It is possible to write clear and simple policies in plain English without resorting to overspecification of details which should not be within the scope of ARIN policy at all. > I don't know that your statement is necessarily true. I suspect that Leo > probably did talk to the staff and did put some effort into determining > the feasibility of what he proposes. Admittedly, we are both making > assumptions here. I'm not making assumptions. I quote from a staff email of June 10th: 1. In response to the media question; ARIN has only provided bulk WHOIS via ftp. The only data CD-ROM that ARIN has produced in the last five years was in conjunction with the database conversion several years ago. One was prepared for each organization and provided all data relative to all of the resources for that organization that was in the ARIN database. > And my opinion is that your attempt to shorten and simplify does not > produce as good a result and that the details you are attempting to get > rid of are not unnecessary. As usual, I suspect we should agree to > disagree on this. Do you really believe that it is necessary for us to expand ARIN's policy and create a requirement for CD-ROM publishing that did not exist in the past? > Unless, of course, the CD came with the data in one portable format and > scripts were made available to convert to any of the 5 aforementioned > formats. So now you want ARIN to not only maintain a virtually obsolete means of data transfer, but also to maintain and provide software to decode the data? Will ARIN also provide technical support for this software? And will the policy detail the hours of technical support and whether or not this software support is by phone or by email? Is there anyone else out there who believes in the maxim: "Less is MORE!"? --Michael Dillon From Michael.Dillon at btradianz.com Wed Jun 15 07:35:19 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 15 Jun 2005 12:35:19 +0100 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <87psun7tct.fsf@valhalla.seastrom.com> Message-ID: > The folks who suggest arbitrary media on a cost-recovery basis are > setting ARIN up for a huge annoyance of one-offs. The procedure for > making a database copy for a customer should be "insert blank media, > push button, put label on media, put media in envelope, put envelope > in fedex". I agree. That is why I want to see a minimum of detail in the policy and a maximum amount of discretion for ARIN staff to either say "NO!" or to negotiate a price. I have absolutely no idea of the demand for this type of service which is why I want the power to reside with the staff. If there is a significant demand, then I trust the staff to negotiate technical details and pricing. And if there is little demand, then I trust the staff to say no to these requests. I have only mentioned a lot of different media because scenario analysis is a useful way of standing back and surveying the problem and the set of solutions to the problem. Once you get a view of the overall landscape you can generally make better decisions about what needs to be done and what should be left to nature (or ARIN staff) to take care of. --Michael Dillon From ppml at rs.seastrom.com Wed Jun 15 07:37:38 2005 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Wed, 15 Jun 2005 07:37:38 -0400 Subject: [ppml] Directory Services - section 3.4.3 In-Reply-To: <87psun7tct.fsf@valhalla.seastrom.com> (Robert E. Seastrom's message of "Wed, 15 Jun 2005 07:27:30 -0400") References: <42AF3F96.118CC77@ix.netcom.com> <42AF9E1E.CB14BF7C@ix.netcom.com> <0E3CED8527736A23A53299C2@[172.17.1.152]> <87psun7tct.fsf@valhalla.seastrom.com> Message-ID: <87slzj6ebh.fsf@valhalla.seastrom.com> Owen DeLong writes: Well... DVD burners have improved a bit from last time I looked. The newest ones are up to 16x, while CD burners continue to limp along at about 54x. However, I don't share your optimism about the pricing on the media. As to long term thinking, when it comes to something that long term, the policy can easily be changed when we get to that point. I think the list manager software may have eaten a previous post I made with comments on this subject, so please forgive if this is redundant. The folks who suggest a policy that explicitly permits arbitrary media on a cost-recovery basis are setting ARIN up for a huge annoyance of one-offs. The procedure for making a database copy for a customer should be "insert blank media, push button, put label on media, put media in envelope, put envelope in fedex". It should be a process that is sufficiently automated that one has an intern do it, not an engineer. I don't think the policy should not specify a media type or a file format though. The policy should leave media type(s) up to ARIN staff and stipulate that they be reviewed periodically, without specifying an interval so as to allow staff maximum flexibility to upgrade when media type evolution or acute space shortage make it reasonable to do so. ---Rob PS: The media cost for DVD vs. CD is so small in the context of the other fixed costs in delivering a copy (labor, cardboard mailer, shipping, order processing and handling) as to be safely ignored. Personally, I like the idea of DVD because it allows the flexibility to put the database on it in multiple different file formats without undue concern about running out of space on the media as a result. The LERG, for instance, is provided in both position-sensitive-card-image and MS Access formats (not that I'm suggesting either of those). That leaves open the possibility of simultaneously having tab-separated, sql database dump, XML, other experimental or transitional formats. From hannigan at verisign.com Thu Jun 16 18:38:02 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Thu, 16 Jun 2005 18:38:02 -0400 Subject: [ppml] Directory Services - section 3.4.3 Message-ID: > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of > Robert E. Seastrom > Sent: Wednesday, June 15, 2005 7:38 AM > To: Owen DeLong > Cc: Jeff Williams; Michael.Dillon at btradianz.com; ppml at arin.net > Subject: Re: [ppml] Directory Services - section 3.4.3 > > [ SNIP ] > > The folks who suggest a policy that explicitly permits arbitrary media > on a cost-recovery basis are setting ARIN up for a huge annoyance of > one-offs. They'll see one-offs regardless. Without some very minor explicity, you could say that everything would be a one off. From william at elan.net Fri Jun 17 22:32:30 2005 From: william at elan.net (william(at)elan.net) Date: Fri, 17 Jun 2005 19:32:30 -0700 (PDT) Subject: [ppml] [ipv6-wg@ripe.net] Minutes IPv6 WG RIPE 50 (fwd) Message-ID: FYI (especially last part of the meeting minutes on /48 allocation size) ---------- Forwarded message ---------- Date: Fri, 17 Jun 2005 19:26:09 -0700 From: David Kessens To: ipv6-wg at ripe.net Cc: meeting at ripe.net Subject: [ipv6-wg at ripe.net] Minutes IPv6 WG RIPE 50 I did not receive any comments on the draft minutes (v1) by June 10. Therefore, the draft minutes (v1) are now the official minutes of our session during RIPE 50 except for one typo that I found myself, in the last sentence, please replace 'exepected' by 'expected'. Thanks, David Kessens --- ----- Forwarded message from David Kessens ----- Date: Tue, 31 May 2005 20:42:40 -0700 From: David Kessens To: ipv6-wg at ripe.net Cc: meeting at ripe.net Please see below for our first cut of the minutes for our working group session during RIPE 50. Please let me know if you have any comments or corrections. The minutes will be declared final by Friday, June 10, 2005 if no significant changes (other than typo fixes and minor editorial issues) are found. David Kessens --- Draft Minutes (v1) IPv6 WG RIPE 50 When: Friday, 6 May 2005, 09:00 - 10:30 Where: C58, Clarion Hotel, Stockholm, SE Minute Taker: Adrian Bedford Quick Update from the RIPE NCC Regarding IPv6 Services (Ruud de Kooter - RIPE NCC) After the presentation, Ruud was asked if there were plans to integrate the IPv6 whois interface with the main whois. Currently the proxy cannot talk to the interface and this hampers some functionality (such as rate limiting). Ruud asked Shane Kerr to answer this. Shane explained that the RIPE NCC has a v6 proxy running over a v4 database backend. The RIPE NCC has been looking at how people use the database for two years and patterns suggest that now would be a good time to integrate native IPv6 into the server using /48 as a client identifier. Discussion on: Global IPv6 Routing Table Status (Gert Doering, Spacenet) Gert indicated that the Routing Working Group was discussing best practices for BGP filters. The overall thrust of the presentation was that v6 is growing smoothly with no big disasters so far. A question was asked about ratio comparison between the numbers of Autonomous Systems (AS) announced by IPv6 networks as opposed to v4. The current data suggests that there are 1.419 announced entries per originating AS for v6 and 10.308 for v4. A point was made that Deutsche Telecom (DT), who have one of the largest v6 allocations made to date would not announce their block as one AS, they would be more likely to split this and allocate blocks to different service providers for political reasons. Someone from DT commented that the company has the right to do this, though denied that the move was in any way politically motivated. Renumbering IPv6 Networks (Stig Venaas, Uninett & Tim Chown, University of Southampton) After the presentation, it was mentioned that we are assuming that customers of service providers will keep their space, yet ten years ago major providers did force renumbering onto customers. It was agreed that renumbering of IPv6 is, at least in principal, no different to what happened with v4. Developments/Initiatives Regarding IPv6 in the RIPE Region and Beyond - Francis Dupont: Point6 (http://www.point6.net/ - Gert Doering: A new maillist for discussion of ipv6 operational issues was started: http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ After the announcement of the list, it was agreed that having a publicly available archive of this new list would be a good idea. Although it exists on the site that hosts the list, this is a personal website and for stability purposes, maybe a copy of the archive should be placed elsewhere. It was felt that the RIPE website was unsuitable for this. - Carlos Friacas: o IPv6 - Advanced Network Developments's first year in Portugal o 9K IPv6 Schools' Network Initiative o About the IPv6 Steering Committee Revisiting the /48 recommendation There was a lengthy discussion around RFC 3177. It was made clear that the discussion was not intended to reach final consensus on all the issues involved, but merely to serve as a way to get an idea about the general direction on where the community would like to go to make it possible to write up an initial proposal. Many agreed that the /48 is too much for many users for now and in the future. A discussion followed about how we should define a site with the suggestion that we need to accept that this can remain a grey area, which is not at all well defined right now. Discussion is needed around this topic, though the group tended to accept that it might not be easy to put down limits in black and white. Most people in the room felt that RFC3177 needs a revision. Most people felt that the /48 limit itself doesn't need to be changed, but most agreed that there is a need for a new category that falls somewhere between /48 and /64 for users that have a need for subnetting but for which a /48 seems excessive. This category would fit the mass consumermarket or (very) small office market, however, it was noted that we should base the category on technical needs of the user, not in economic terms like mass consumer market. It is exepected that an Internet Draft will be written that can be discussed at RIPE 51. ----- End forwarded message -----